Надёжность выразили в минутах бюджета ошибок, а не только в процентах

Что болело

Т-Банк обслуживает около 45 млн клиентов — треть населения России. На таком масштабе, говорят авторы прямо, «невозможно поддерживать руками что-либо»: нельзя лично обзвонить пострадавших, нельзя разово договориться между командами, которых в компании тысячи. Мониторинг при этом складывался стихийно — по словам авторов, «зоопарк различных инструментов», у каждой команды свой, без общей картины здоровья экосистемы.

Отдельная проблема — само понятие надёжности. Внутренние метрики вроде аптайма базы данных ничего не говорят о том, что видит клиент: балансировщик может лежать при полностью живой БД, и по внутренним показателям всё будет «зелёным».

Что хотели получить

Перевести надёжность из ощущения в измеримую и управляемую величину — с показателем, целью и последствиями нарушения, — а не в перечень разрозненных дашбордов, которые никто не сводит воедино.

Что сделали

Компания выстроила цепочку понятий и процессов вокруг неё.

SLI → SLO → SLA → бюджет ошибок. SLI (Service Level Indicator) — показатель работоспособности услуги, привязанный к клиентскому опыту, а не к внутренней метрике: пример из статьи — доля успешно выполненных операций, а не аптайм БД при неработающем балансировщике. SLO (Service Level Objective) — целевое значение SLI, например 99% успешных операций. SLA (Service Level Agreement) — последствия нарушения SLO. Бюджет ошибок — величина, обратная SLA: при цели 99,99% годовой бюджет составляет ровно 52 минуты 35 секунд простоя, которые система может «законно» потратить, не нарушив обещание.

MTBF и MTTR как рычаги. Чтобы уложиться в бюджет ошибок, нужно увеличивать среднее время между сбоями (MTBF) и уменьшать среднее время восстановления (MTTR). Оба показателя — средние, а значит требуют статистики, а статистика требует сбора, хранения и анализа данных в промышленном масштабе.

Процесс релизов «Колобок». На масштабе в тысячи и десятки тысяч сотрудников «нельзя просто договориться между собой», поэтому решение о том, можно ли сейчас выкатывать релиз, формализовано светофором: красный — нельзя вообще, жёлтый — можно с разрешения SRE, зелёный — можно без разрешения. Критерии — рабочий день или нет, рабочее время или нет, есть ли уже критические сбои.

Контроль качества до продакшена. Внутренняя платформа разработки Spirit объединяет GitOps, обязательное ревью и Quality Gates — автоматические проверки покрытия тестами, статический анализ, анализ уязвимостей и перформанс-тесты — раньше, чем код доедет до релиза.

Отказоустойчивость по конструкции. Приложения, инфраструктура и сервисы разнесены по дата-центрам; внутренние платформы вроде DBaaS, S3aaS, LBaaS, KafkaaaS и K8SaaS избавляют тысячи команд от необходимости самим поднимать и настраивать инфраструктурные сервисы. Выкладка в прод идёт без даунтайма — blue-green деплой и канареечные релизы, а отказоустойчивость проверяют учениями.

Центр надёжности и роль CRO. Отдельная структура внедряет практики SRE на уровне всей компании: вводит термины «инцидент» и «уровень инцидента», развивает инструменты наблюдаемости, консультирует команды. Chief Reliability Officer описан как «правая рука CTO, зам по надёжности» — роль нужна потому, что без выделенного фокуса продвигать интересы надёжности в большой компании тяжело.

Обработка инцидента. Телеметрия с инфраструктуры, приложений, услуг и бизнес-логов стекается в Sage с алертингом; первый адресат алерта — дежурный в чате. Правило самого алерта: он должен быть «максимально говорящим» — с контекстом, ссылкой на дашборд, ссылкой на поисковый запрос и runbook (что за алерт, что вероятно сломалось, как чинить), потому что «в три часа ночи инженер не готов решать ребусы». Уровень критичности определяют по трём осям — финансовые/регуляторные/пиар-риски, критичность услуги, длительность и охват влияния на клиентов, — и от уровня зависит цепочка эскалации: все инциденты идут в чат Emergency Tech Team, оранжевые — CRO, красные — совету по ИТ (IT Board), чёрные — отдельной команде помощи клиентам.

Разгрузка контакт-центра. Расчёт в статье прямой: при 1% пострадавших клиентов из 45 млн это 450 тысяч человек, треть из них позвонит — 150 тысяч обращений против обычных нескольких сотен одновременных. Поэтому в момент инцидента включаются: информационная или блокирующая плашка на сайте/в приложении, встраивание сценария сбоя прямо в диалог с ботом («может быть, через бота решим?»), закрытие части чатов с готовым ответом о статусе проблемы вместо постановки в очередь.

Постанализ и постмортем. Простые сбои разбираются лайтовым постанализом; серьёзные («красно-чёрные») выносятся на еженедельную встречу всех SRE-инженеров с детальным разбором последствий для бизнеса и клиентов и планом, как не допустить повтора.

Чем автоматизировали

Обе платформы — собственная разработка Т-Банка. Sage — платформа наблюдаемости, заменившая «зоопарк» разрозненных инструментов мониторинга; в неё стекается телеметрия и настроен алертинг, включая Anomaly Analyzer — модель, которая строит прогноз метрики и сравнивает с ним текущие показания. FineDog — система учёта надёжности и инцидент-менеджмента: ведёт SLA услуг, показывает здоровье экосистемы в моменте, регистрирует каждый инцидент как нарушение SLA и уведомляет причастных. Разделение между ними чёткое: Sage показывает метрики механики, которые могут привести к инциденту, FineDog — сами инциденты. Отдельно упомянут helpdesk Forge, который ведёт не техническую, а клиентскую проекцию сбоя: что делали, чтобы помочь, какие обходные решения предлагали.

Что получилось

Статья формулирует эффект качественно, а не в цифрах: «мы быстрее обнаруживаем проблемы, у нас меньше время реакции, а значит, наш MTTR будет уменьшаться». Годовую цель доступности перевели в конкретное число минут и секунд, которое можно потратить, — это меняет разговор о рисках и планировании работ с абстрактного процента на управляемый бюджет.

Что не получилось и где было тяжело

Статья объясняет методику и инструменты подробно, но не приводит ни одной цифры «было — стало»: какой была надёжность до перехода на модель SLI/SLO/SLA и насколько она выросла после — не сказано ни разу. Это методический разбор устройства системы, а не отчёт о результате внедрения.

Наблюдательность создаёт и собственную нагрузку: как только появляется инструмент вроде Sage, в него, по признанию авторов, «все начинают ломиться лить данные» — и дальше это уже задача на масштабируемое хранилище и поиск, а не разовая настройка.

Что отсюда забрать

1. Бюджет ошибок — не процент, а число, которым можно управлять. 52 минуты 35 секунд в год считаются и планируются, а абстрактные «99,99%» — нет.
2. SLI привязывайте к клиентскому опыту, а не к внутренней метрике. Живая база при мёртвом балансировщике — рабочий пример того, как удобная метрика маскирует реальный простой.
3. Формализуйте решение «можно ли выкатывать релиз». Светофор с понятными критериями снимает необходимость договариваться вручную на масштабе, где договориться уже нельзя.
4. Разгрузка контакт-центра — часть плана на инцидент, а не импровизация. Готовые сценарии (плашка, встраивание в диалог бота, ответ в чате) нужны заранее: во время сбоя счёт идёт не на часы.
5. Роль, отвечающая за надёжность, должна быть у кого-то одной. Центр надёжности и CRO — способ не дать теме размыться между командами, у каждой из которых свои приоритеты.

На какую зрелость это тянет

По AVLУправление доступностью — четвёртый уровень. Показатель определён формулой (SLI → SLO → SLA → бюджет ошибок), под него выстроены инструменты (Sage, FineDog), процессы (эскалация по уровням, релизный светофор) и выделенная роль (CRO) — это управляемая практика, а не набор разрозненных мер.

Ограничение то же, что и у любого методического разбора без цифр: подтвердить эффект «было — стало» по этому источнику нельзя — авторы рассказывают, как устроена система, а не насколько лучше стало после её внедрения.

Оговорка обязательна: оценка сделана по одной публичной статье компании о себе, а не по обследованию. Внутренние цифры и процессы независимой проверке не поддаются.