Ключевые метрики надежности¶

или Как измерить "здоровье" системы¶

Представьте, что вы покупаете подержанный автомобиль. Как оценить его надежность? Вы спрашиваете не только "сколько он стоит", но и "как часто ломается", "как быстро его чинят", "сколько стоят запчасти". Ответы на эти вопросы - субъективная оценка его "доступности" для поездок.

С цифровыми сервисами та же история. Чтобы понять, насколько они надежны, мы не можем полагаться на чьи-то ощущения или мнения. Нам нужны точные, конкретные, численные метрики. Именно для этого существуют MTBF, MTTF, MTTR и Availability — фундаментальные метрики, которые переводят разговоры о "стабильности" на язык чисел, которые понятны всем.

Городская служба такси¶

Давайте представим, что наш сервис - это городская служба такси.

Цель: Доставлять пассажиров из точки А в точку Б.
Сбой: Такси ломается и не может выполнять заказы.

Теперь посмотрим на метрики через эту призму.

1. MTTF (Mean Time To Failure): среднее время до поломки¶

Простыми словами: это среднее время, которое такси беспроблемно работает с момента выпуска с завода до первой поломки.

Как считать: берём все новые автомобили, смотрим, через сколько километров (или месяцев) у каждого случилась первая серьёзная поломка, и выводим среднее.
Что показывает: насколько "живучий" изначально продукт. Высокий MTTF — значит, автомобиль (или сервер, или микросервис) хорошо спроектирован и собран.
Пример: если MTTF нового модельного ряда такси 50000 км, то это хороший показатель. Если же первая коробка передач выходит из строя в среднем на 5000 км - это катастрофа, не нужно нам такого.
В IT: для оборудования (дисков, серверов) MTTF - ключевая характеристика от производителя. Для программного обеспечения аналогом может быть "среднее время наработки до бага".

Важно: MTTF считают до первого сбоя. После ремонта начинается новый цикл.

2. MTTR (Mean Time To Repair/Recovery): среднее время на восстановление¶

Простыми словами: это среднее время, которое механики тратят на то, чтобы починить сломавшееся такси и снова выпустить его на линию.

Как считать: суммируем все часы простоя в ремонте для всех поломок и делим на количество поломок.
Что показывает: насколько мы быстры и эффективны в устранении неисправностей. Низкий MTTR - это золотой стандарт. Это значит, что у нас есть запчасти на складе, обученные механики и чёткие инструкции по ремонту.
Пример: MTTR = 2 часа. Машину быстро отбуксировали в сервис, быстро диагностировали и заменили топливный насос. MTTR = 2 дня. Запчасти нужно было ждать из другого города, а единственный механик был в отпуске. Пассажиры недовольны. Да и машина два дня стояла и не зарабатывала деньги. Владелец бизнеса тоже недоволен.
В IT: MTTR - главный фокус SRE. В него входит всё: время на обнаружение проблемы (мониторинг), диагностику (логи, трейсы), само исправление (rollback, хотфикс) и проверку. Автоматизация и продуманные runbook’и направлены именно на сокращение MTTR.

MTTR - комплексный показатель, и он состоит из следующих фаз (именно на них нужно декомпозировать дашборды):

MTTD (Mean Time To Detect): время от начала сбоя до срабатывания алерта.
MTTA (Mean Time To Acknowledge): время от алерта до принятия инцидента инженером.
MTTF (Mean Time To Fix): время на диагностику и применение фикса.
MTTV (Mean Time To Verify): время на подтверждение восстановления работы.

3. MTBF (Mean Time Between Failures): среднее время между сбоями¶

Простыми словами: это средний промежуток времени между окончанием одного ремонта такси и началом следующей его поломки. Или, иначе, как часто в среднем ломается именно эта машина.

Как считать: MTBF = MTTF + MTTR. Мы смотрим на весь жизненный цикл: поработала → сломалась (MTTF) → чинилась (MTTR) → снова поработала.
Что показывает: как часто система создаёт нам проблемы. Высокий MTBF — это хорошо. Это значит, что поломки редкие (высокий MTTF) и/или чиним мы их очень быстро (низкий MTTR).
Пример: У Такси №1 MTTF = 30 дней, MTTR = 1 день. MTBF = 31 день. У Такси №2 MTTF = 10 дней, но MTTR = 1 час. MTBF = 10 дней + ~0 = ~10 дней. Первое такси ломается реже, но второе, хоть и ломается чаще, почти не выбывает из строя.
В IT: MTBF — хороший высокоуровневый индикатор для бизнеса. "Наш Service Controller имеет MTBF 720 часов" звучит убедительно. Но для инженеров важнее дробить его на MTTF и MTTR, чтобы понимать, над чем работать: над предотвращением сбоев или над скоростью восстановления.

Итог по трём метрикам: - MTTF: качество "железа" (или кода). - MTTR: качество нашей "скорой помощи". - MTBF: общее впечатление пассажиров о доступности машины.

4. Доступность (Availability): итоговый показатель "работоспособности"¶

Способность системы обслуживать запросы в нужный момент. Измеряется в процентах (например, 99,9% или "три девятки"). Это самый базовый, но не единственный показатель стабильности.

Вернёмся к нашей службе такси. У нас в парке 100 машин. За месяц каждая в среднем:

Работала (была доступна) 700 часов (MTTF).
Ремонтировалась (была недоступна) 20 часов (MTTR).

Доступность (A) это просто процент времени, когда услуга была готова к работе.

Формула (упрощённо): Availability = (Время работы) / (Общее время) = MTTF / (MTTF + MTTR) = MTTF / MTBF или Availability = Uptime / (Uptime + Downtime)

В реальных системах используется A = (MTBF - MTTR) / MTBF, где MTBF = MTTF + MTTR.

Для нашего такси: A = 700 / (700 + 20) = 700 / 720 ≈ 0,972, или 97,2%.

Это значит, что в любой случайный момент времени вероятность того, что конкретное такси будет на линии, составляет 97,2%.

Уровни доступности: "девятки"¶

В IT доступность измеряют в "девятках". Это не магия, а строгие математические рамки.

Уровень доступности	Процент	Максимальное допустимое время простоя в год	Аллегория для службы такси (на 100 машин)
Одна "девятка"	99%	3.65 дня (~87,6 часов)	Катастрофа. В среднем 1 машина постоянно в ремонте. Пассажиров не возят днями.
Две "девятки"	99,9%	8,76 часов	Плохо. Каждый месяц каждая машина "болеет" больше часа. Постоянные задержки.
Три "девятки"	99,9%	~8,76 часов в год	Приемлемо для многих бизнесов. В год вся служба в целом не работает менее 9 часов. Это ~43 минуты в месяц.
Четыре "девятки"	99,99%	~52,6 минуты в год	Хороший уровень. Это менее 5 минут прохода в месяц. Пассажир почти никогда не заметит проблем.
Пять "девяток"	99,999%	~5,26 минут в год	Уровень жизненно важных систем (энергетика, связь). Недоступность - это ЧП. В нашем примере это означало бы иметь бригаду механиков и склад запчастей в каждом гараже.

Каждая следующая "девятка" стоит на порядки дороже предыдущей. Переход с 99% до 99,9% (выигрыш 0,9%) требует в 10 раз меньшего простоя. Переход с 99,99% до 99,999% (выигрыш 0,009%) — это титанические усилия по резервированию каждого винтика и полной автоматизации восстановления. И огромная куча денег. Да и нужно ли оно?

Как этим пользоваться на практике?¶

Не гонитесь за "пятью девятками" просто так. Для какого-то сервиса 99,9% может быть более чем достаточно, и это сэкономит миллионы на инфраструктуре.
Улучшайте то, что дешевле. Часто проще и эффективнее снизить MTTR (улучшить мониторинг и автоматизацию восстановления), чем пытаться увеличить MTTF (сделать систему в разы стабильнее). Если ваш MTTR 4 часа, а цель 99,95%, вам нужен MTTF не менее 800 часов. Улучшив восстановление до 30 минут (MTTR=0,5h), для той же цели хватит MTTF всего в 100 часов!
Говорите с бизнесом на одном языке. "Нам нужна доступность 99,95" это понятное обязательство. Оно означает: "Мы можем позволить себе около 4.5 часов простоя в год. Давайте решим, как мы будем распределять этот бюджет (на плановые работы и на незапланированные сбои)".

5. Надежность (Reliability): зачем мы всё это измеряем?¶

Это более широкая концепция. Это способность системы корректно выполнять свои функции (включая обработку данных, согласованность, скорость ответа) в течение заданного периода времени при определенных условиях. Надежная система не просто "доступна", она работает правильно.

Представьте, что вы приходите в кофейню. Доступность это дверь открыта, и свет горит. Вы можете войти. Но надежность это то, что происходит дальше: бариста не забывает рецепт капучино, кофемашина не ломается посреди заказа, а ваш любимый десерт есть в наличии. Надежность это способность системы выполнять заявленную функцию без сбоев в течение определенного времени и в определенных условиях.

Простыми словами: если доступность отвечает на вопрос "Работает ли система ВООБЩЕ?", то надежность отвечает на более глубокий вопрос: "А КАК ИМЕННО она работает? Можно ли на неё положиться?".

Как пример: надежность службы такси¶

Вернемся к нашей службе такси с доступностью 99,9%. Машины почти всегда на линии. Но это не означает надежности:

Машина может ехать со скоростью 20 км/ч из-за неисправности (система работает, но не выполняет функцию адекватно).
Водитель может постоянно терять маршрут (высокий уровень ошибок - error rate).
Машина может приезжать с опозданием в 30 минут (высокая задержка - latency).
В салоне может не работать кондиционер или вонять (деградация функциональности).

Всё это показатели ненадежности, даже если формально машина "доступна" и приехала.

Как связаны метрики с надежностью?¶

Надежность это композитная, более широкая характеристика, которая складывается из: 1. Высокой доступности (A): система должна быть готова к работе. 2. Низкого MTTR: если случился сбой, мы должны восстановить функциональность как можно быстрее. 3. Высокого MTTF/MTBF: сбои должны случаться редко. 4. Стабильности ключевых параметров работы: это то, что мы измеряем метриками качества работы (SLIs): задержка, пропускная способность, частота ошибок. Именно они показывают, насколько хорошо система выполняет свою задачу.

Доступность это необходимое, но не достаточное условие надежности. Система может иметь 99,99% доступности, но быть абсолютно ненадежной, если в 1% случаев она работает с неприемлемой задержкой в 10 секунд для пользователя.

Практический вывод для SRE¶

Когда мы говорим о целях надежности (SLO), мы почти никогда не говорим просто "доступность 99,9%". Мы говорим о комплексных обещаниях:

"В 99,9% случаев запрос к API завершится со статусом 200 OK менее чем за 500 мс".
"В 99% случаев виртуальная машина будет создаваться быстрее, чем за 100 секунд".

Здесь мы видим, как доступность (запрос завершился) сочетается с качеством работы (за 500 мс). Это и есть современное понимание надежности: система не просто жива, она здорова и делает то, что от неё ожидают.

Поэтому, проектируя систему, мы думаем не только о том, как сделать её "неубиваемой" (MTTF), но и о том, как быстро обнаружить и вылечить её "недомогание" (MTTR), и как определить, что такое это самое "здоровье" (SLI/SLO). И только управляя всеми этими аспектами, мы создаем по-настоящему надежный сервис, на который могут положиться и пользователи, и бизнес.

6. Устойчивость (Resilience): способность не просто выживать, а выдерживать удары¶

Представьте две службы такси из нашего примера. У обеих одинаковый показатель доступности 99,9%. Но есть ключевое различие:

Первая служба достигает этого показателя, потому что её машины очень надёжны (высокий MTTF), но когда редкая поломка всё же случается - начинается хаос. Нет запасных машин, механики в панике, клиенты ждут часами.
Вторая служба специально проектировалась иначе. Её машины могут ломаться чуть чаще, но у неё есть система: 10% парка всегда стоят в резерве, механики знают чёткие инструкции на 20 основных поломок, а диспетчер моментально перебрасывает заказы на свободные авто.

У второй службы есть устойчивость (Resilience): способность предвидеть, поглощать и адаптироваться к нештатным ситуациям, сохраняя ключевые функции.

Если надёжность это "как долго система работает без сбоев в идеальных условиях", то устойчивость это "как система ведёт себя, когда идеальные условия заканчиваются, и начинаются реальные проблемы".

Ключевые принципы Resilience:¶

Принцип "надежных систем не бывает" (даже написал отдельную главу: Восемь смертных грехов распределённых систем). Устойчивая архитектура исходит из того, что сети ненадёжны, задержки непредсказуемы, а оборудование ломается. Поэтому она готовится к сбоям, а не просто надеется на их отсутствие.
Стратегии реализации устойчивости:
- Избыточность (Redundancy): не один сервер в дата-центре, а несколько в разных географических зонах. Если падает один, то система автоматически переключается на другие.
- "Мягкая" деградация" (Graceful Degradation): если падает сервис, взаимодействующий с биллингом, личный кабинет продолжает работать. Главная функция (возможность управления своей инфраструктурой) сохранена.
- Отказоустойчивость (Fault Tolerance): способность продолжать работу даже при отказе отдельных компонентов. Например, распределённая база данных, которая может потерять один узел без потери данных и доступности.
- Автоматическое восстановление (Self-healing): система сама обнаруживает сбой (например, зависший контейнер), убивает проблемный экземпляр и запускает новый без участия человека.

Как Resilience связан с метриками MTTF и MTTR?¶

Устойчивая система намеренно перераспределяет усилия:

Она может иметь чуть более низкий MTTF, потому что сознательно использует больше сложных, распределённых компонентов (которые могут отказывать), но при этом...
Она радикально снижает MTTR (иногда до секунд), потому что восстановление зашито в её архитектуру и происходит автоматически.
Итоговый MTBF и Availability при этом могут быть выше, чем у "хрупкой", но изначально надежной системы, потому что единичные сбои почти не влияют на общую работоспособность.

Аллегория: Мост vs. паутина¶

Хрупкая, но "надёжная" система это каменный мост. Пока всё в порядке, он чрезвычайно прочен (высокий MTTF). Но если в одной арке возникнет критическая трещина (сбой), весь мост рухнет. MTTR будет катастрофически велик, потому что нужны годы на перестройку.
Устойчивая система это сеть или паутина. Отдельные нити рвутся постоянно (низкий MTTF для компонентов). Но структура в целом сохраняет форму и функциональность, потому что нагрузка перераспределяется. А "ремонт" (MTTR) - это быстрое плетение новой нити на месте разрыва.

Resilience - инженерия устойчивости¶

Современный SRE не просто следит за метриками, а активно проектирует и тестирует устойчивость:

Chaos Engineering (по-русски произносится как "кейос"): намеренное, контролируемое внесение сбоев в работающую систему (например, отключение сервера или замедление сети), чтобы проверить, как она выдерживает удар и восстанавливается, например, chaosctl network --latency 100ms --namespace app --duration 10m
Сценарии Disaster Recovery (DR): наличие актуальных планов аварийного восстановления (Disaster Recovery Plan) и регулярные учения (Disaster Recovery Test) на случай полного уничтожения какого-то сервиса, базы данных, дата-центра или любого другого компонента,: как быстро и без потерь данных можно поднять сервис в другом регионе, и можно ли поднять вообще и укладываемся ли в RTO и RPO?

Надежность (Reliability) говорит нам: "Мы построили хорошую дорогу, по которой можно ехать 100500 км без поломок". Устойчивость (Resilience) добавляет: "А еще мы проложили параллельные объездные пути, поставили аварийные телефоны каждые 5 км и обучили водителей менять колесо за 5 минут. Если что-то пойдет не так на главной дороге вы всё равно доедете до цели".

Именно сочетание измеряемой надежности (через метрики) и проектируемой устойчивости позволяет создавать системы, которые не просто работают в теории, а стабильно служат пользователям в суровых условиях реального, не фантастического мира.

7. Стабильность¶

В теории надежности нет такого понятия. "Cтабильность" это неформальный бытовой термин, который может означать либо надёжность, либо доступность, либо предсказуемость поведения. Под стабильностью можно понимать способность системы предоставлять свои сервисы в соответствии с ожиданиями пользователей, несмотря на внутренние сбои, изменения нагрузки или внешние воздействия. Стабильность - это пользовательское восприятие надежности сервиса.

Домашнее задание¶

Есть два сервиса. Один работает 90 дней без сбоев, а потом 10 дней лежит. Второй работает 9 дней, потом лежит один день, и так по кругу все 100 дней.

Рассчитать: MTBF, MTTR и определить, какой сервис надежнее на отчётном периоде в 100 дней.

Заключение¶

MTTF, MTTR, MTBF и Availability это не просто аббревиатуры. Это основа основ для мышления о надежности. Они позволяют перейти от эмоций ("опять всё упало!") к анализу ("наш MTTR в этом месяце вырос, потому что не было runbook на новую ошибку БД").

Как хороший врач смотрит не только на температуру, но и на давление и анализы, так и грамотный SRE смотрит на всю совокупность этих метрик, чтобы поставить точный "диагноз" системе и назначить правильное "лечение".