Часть 1. Как подружить бизнес и инженеров через общие цифры

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

Меня зовут Дмитрий Химион, я руководитель ML Platform в X5 Digital. Эта статья написана по мотивам моего доклада на HighLoad++ в ноябре 2025 года. Тогда он вошёл в топ-10 лучших докладов конференции и вызвал неожиданно широкий интерес. Видимо, задев актуальную боль многих команд: «как превратить SLA из формальной цифры в надёжную систему расчётов, понятную бизнесу и инженерам».

В статье расскажу, как мы «жили у границы потери доверия к SLA» и что с этим сделали: от запроса руководства и пересборки инцидент-менеджмента до доверенного алгоритма расчёта потерь и разделения SLA на бизнес- и технический уровни.

В первой части разберём:

• как мы пересобрали инцидент-менеджмент (ИМ) и почему без сильного ИМ любой SLA остаётся декоративным;

• как работает алгоритм расчёта потерь, как мы его тестировали и доказывали надёжность и состоятельность;

• зачем понадобилось разделение SLA на уровни и какую задачу решает каждый из них.

Будет полезно всем, кто уже перерос уровень «у нас есть мониторинг и алерты» и хочет сделать сильный компас из инцидент-менеджмента и SLA управляемой системой, понятной и бизнесу, и инженерам.

Запрос от руководства

Последние несколько лет в X5 Digital я занимался вопросами оценки SLA. Отправной точкой для нашей истории послужил серьёзный инцидент и последующий разбор на уровне высшего руководства. В этот момент стало очевидно, что при критических сбоях наш старый подход к оценке SLA выглядел бледновато: не давал единой, доверенной оценки влияния на бизнес и не помогал быстро договориться о цифрах. С этого запроса началась докрутка: сначала инцидент‑менеджмента, а затем и распространение общего подхода к расчёту SLA.

Контекст

В X5 работает более 375 тысяч сотрудников. IT‑подразделение — примерно 6000 человек, из них чуть больше 500 инженеров, наше подразделение X5 Digital. Мы отвечаем за онлайн‑заказы: всё, что клиент заказывает в «Пятёрочке», «Перекрёстке», «Чижике» и других сетях, проходит через нас. В сутки это более 500 000 заказов и около 4 500 000 килограммов продуктов.

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

Руководство хотело перестать обсуждать сбои в жанре «кажется, всё было плохо где-то около часа и потеряли примерно несколько миллионов рублей» и перейти к формулировке «такие-то компоненты наших систем были недоступны N минут с 10:ХХ до 10:ХХ, это стоило нам XХХХХХ рублей».

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

Отдельным пунктом возник запрос на «технический SLA». Сначала он звучал расплывчато, но со временем оформился в «Мы хотим знать, как на самом деле живут наши сервисы, даже если они не влияют на бизнес и деньги, и что происходит, когда они деградируют и ломаются».

И, конечно, были сроки. На старте задача звучала: «Сделайте это за три месяца». Это было амбициозно, но оказалось вполне реально.

Нет дыма без огня

Итак, перейдём к типовой ситуации с крупным инцидентом и жирными потерями. Когда в большой компании происходит серьёзный инцидент, руководители высокого уровня подключаются к срочному созвону и разбирают, что произошло: где сломалось, какие сервисы или системы затронуты и кто от кого зависел.

Дальше нужно оценить последствия: сколько времени сервис был недоступен, во что это обошлось бизнесу. Здесь у нас начинались расхождения. Команды приносили разные цифры: считали простои и потери по своим данным и методикам. Эти оценки хоть и выглядели корректно, но в общую картину не складывались. Во многом потому, что расчёты SLA и потерь в большом IT-подразделении велись разрозненно, с разными подходами и алгоритмами.

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

Базовые механизмы оценки SLA

Мы быстро пришли к выводу: показательный и достоверный SLA невозможен без сильного, «ездящего по рельсам» инцидент-менеджмента.

Вот что мы успели за три месяца в режиме «педаль в пол»:

• Полностью пересобрали роль инцидент-менеджера: как он ведёт инциденты, проводит встречи, модерирует людей. Также зафиксировали разбор timeline инцидента: копаем первопричины, смотрим на триггер, фиксируем Action items. Это нужно было повторить столько раз, сколько необходимо, чтобы этот флоу стал мантрой каждого тимлида.

• Сделали шаблоны, чтобы сократить время работы с инцидентами, упростить заполнение и не забывать ключевые шаги.

• Ввели жёсткий срок на разбор причин и последствий — три дня или «за вами уже выехала команда».

• Подключили к разборам директоров разработки. Руководители наконец увидели, где конкретно мы теряем время и деньги.

• Запустили еженедельную встречу, на которой CIO вместе со своими подчинёнными и директорами разработки обсуждают инциденты: что произошло, как отреагировали, что изменилось в системе, какой был триггер и какими были первопричины и, самое главное, что уже сделали, чтобы подобное не повторилось. Это, пожалуй, ключевой тонизирующий момент обновлённого процесса.

• Разработали точный алгоритм расчёта потерь в инцидентах. С этой большой задачей уложились в два месяца, что я считаю серьёзным достижением. В прошлом такой же результат достигался за 6 месяцев.

• Построили SLA для работы с бизнесом, чтобы в любой момент можно было показать, с какой надёжностью мы как IT-подразделение работаем для бизнеса. Это мощнейший и важнейший шаг навстречу прозрачности.

Измерение процесса инцидент-менеджмента

Как только появилась базовая модель SLA и первые данные, на нас посыпались вопросы, набросы и челленджи. И это абсолютно ожидаемо и нормально, ничего плохого в этом нет. Руководство хочет видеть и чувствовать картину полностью:

• Какой у нас baseline по инцидентам?

• Сколько инцидентов вообще происходит за период?

• Покажите метрики!

• А теперь разрезы. Какой SLA был и какой стал?

• Как он меняется во времени? 

• Какая у нас динамика, какие тренды долгосрочные и краткосрочные?

Чем больше таких вопросов мы получали, тем очевиднее становилось, что нужны не подборки цифр по отдельным инцидентам, а общая система измерений. Так сформулировали, что включить в систему метрик:

1. Оценка качества работы самого процесса ИМ: насколько хорошо мы отслеживаем проблемы в сервисах, с какой скоростью реагируем на них и как быстро восстанавливаем работу, какой % инцидентов происходит без алертов и тп.

2. Полнота сбора данных об инцидентах — без них SLA никак не посчитаешь. Все ли ключевые поля инцидентов заполняются в процессе фиксации, описания и разбора инцидента.

3. Сами метрики SLA — итоговый «язык» общения с бизнесом: сколько времени и как конкретно сервис был недоступен и самое главное для бизнеса, сколько это стоило.

Оценка качества выполнения процесса

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

Также стали «выпуклыми» разрезы инцидентов по подразделениям не только в рамках X5 Digital, но и по остальным подразделениям компании, да ещё и с разрезами по степени недоступности, компонентам и времени. Вот пример.

Когда появились базовые разрезы по инцидентам, стало интересно смотреть не только на «сколько их вообще», но и на то, в какие дни недели и время суток какие именно инциденты происходят.

На графике ниже показано распределение инцидентов по часам в течение суток. На нём видно аномалию: инцидентов заметно больше ближе к 00:00. И это не случайность, а наше перформанс‑тестирование на ПРОД-е и инциденты с action items на доработку узких мест нашей платформы, где мы не выдерживали.

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

Если смотреть только на количество инцидентов за длительный промежуток времени, то распределение выглядит ожидаемо, напоминая график гиперболы y = 1/x в положительных значениях: много коротких инцидентов и мало длинных. Но если переключиться с количества на потери, картина резко меняется.

Потери распределяются иначе и в зависимости от продолжительности инцидента «плавают». На очень длинных инцидентах мы теряем не так много, а вот на часовых и двухчасовых иногда теряем существенно. Самое главное, что их не так много, следовательно, и action items в них немного. Сфокусировав свои усилия на их исправлении, можно существенно улучшить SLA относительно малой кровью.

Полнота сбора данных об инцидентах

Следующий элемент системы — полнота сбора данных по инцидентам. Чтобы её отследить, мы используем две точки:

1. Момент инициализации — инцидент заводит команда мониторинга 24/7. Здесь фиксируются первичные параметры: что упало, когда, какие симптомы.

2. Этап работы инцидент-менеджмента — когда инцидент уже в работе, подключается инцидент-менеджер и добавляет детали: причины, затронутые компоненты, длительность, последствия, принятые меры.

Почему так? У каждого этапа свой набор обязательных полей, которые ценны для анализа как процесса, так и расчёта SLA. Мы смотрим на тренд их заполнения и долю инцидентов — они должны быть очень близки к 100%.

Значения ниже ~95% становятся сигналом, что что-то идёт не так.

А 60%, как на графике выше, это пример середины недели (на момент скриншота). В «свежих» инцидентах часть полей ещё может быть не заполнена, и это нормально. Когда данные наконец накопились и стали стабильными по качеству и полноте, мы смогли идти дальше.

Расчёты SLA

Прежде чем смотреть на цифры, договоримся, что именно мы, в X5 Digital, считаем, когда говорим про SLA и потери.

Первый вариант — SLA без учёта отскока. Здесь мы фиксируем только прямые потери во время инцидента: берём период недоступности сервиса и оцениваем, сколько денег бизнес недополучил в это окно. Отскок — это период времени после инцидента, когда идёт аномальный подъём (в нашем случае по количеству заказов). Отскок длится, пока поведение заказов не сливается с нормой. Это несложно увидеть на графиках и написать автоматизацию для определения границ.

Пример: падает продакшн, и мы не можем выдавать заказы. Пока сервис недоступен, мы теряем деньги (корректнее говорить недополучаем, но это душное финансовое слово). Затем сервис поднимается, пользователи частично возвращаются и оформляют заказы, которые не сделали во время инцидента. В расчёте SLA без учёта отскока этот эффект восстановления спроса мы игнорируем.

Ниже пример с синтезированными данными SLA за третий квартал (Q3). Здесь всё считается в рублях и можно увидеть итоговое значение SLA — 99,994% (четыре девятки) и помесячное распределение, например, для сентября.

Теперь тот же SLA, но с другой логикой.

SLA с учётом отскока пытается учесть эластичность спроса, а именно факт того, что после восстановления сервиса часть пользователей возвращается и всё-таки совершает заказы, которые не смогла сделать во время инцидента. Бывают приколы, что отскок больше потерь. Говорит ли это о том, что если прикладывать прод, мы будем больше зарабатывать? Нет, это просто редкие и веселящие аномалии.

В приведённом примере SLA с учётом отскока получается около 100% (это шалит округление в «шестой девятке», да и выше пяти девяток всё равно нет смысла считать). Если говорить про суть дела, это улучшение примерно на одну тысячную относительно варианта расчёта потерь без отскока.

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

Вот исторические данные для иллюстрации объективности расчёта: июнь, второй квартал XXXX года (ибо деперсонализация и нельзя такие данные раскрывать). Дашборд показывает не только хорошие периоды, но и провальные, когда SLA не дотягивает и до трёх девяток: 99,571%.

Алгоритм расчёта потерь, тесты и доказательства

Мы построили систему, посчитали потери — всё работает. Затем случился новый крупный инцидент, после которого началось очередное обсуждение. Приходим с цифрами: «Вот столько‑то миллионов, вот столько времени были недоступны». И дальше классика: «Расскажите, откуда у вас такие цифры? Вы что, серьёзно? У нас по расчётам в десять раз меньше». Тут вспоминается сцена из фильма «Красная жара» и фраза «Какие ваши доказательства?».

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

Стало понятно, что нужна не только модель и интерфейс с красивой визуализацией, но и доказательная база: почему мы уверены, что наш расчёт статистически значим, и насколько точно он отражает реальность.

Алгоритм расчёта потерь

В основе алгоритма лежит классическая матстатистика и работа с временными рядами. Мы исходили из того, что инциденты разной длительности требуют разной логики расчёта, поэтому алгоритм не универсальный «на всё», а адаптируется под конкретный тип инцидента. Надо отметить, что мы пробовали, и не раз, модели машинного обучения, в основном классические типа ARIMA, SARIMA и их модификации, но они не улучшили результаты работы нашего базового алгоритма. Были неплохи, но точность оказалась чуть хуже той, что у нас уже была, и, самое главное, ML-решение в итоге сложнее интерпретировать и сложнее им управлять даже при наличии SHAP.

Управляемость, скорость изменений и способность рассказать, почему такой расчёт потерь, оказалось важнее, чем наличие слова «ML» в алгоритме и проекте. Всё же про ML надо отметить, что у нас большие планы на нейросети, и мы будем их пробовать в скором времени, но пока у нас и так всё отлично. Что мы в итоге используем:

1. Используются инструменты матстата.

2. Логика очень разная в зависимости от длительности инцидентов.

3. Подгонка сигнатуры — коэффициент корреляции Пирсона.

4. Манипуляции со стационарностью, декомпозицией и автокорреляцией.

5. Хаки — фильтры для работы с сигналами (физика).

Итог: 11 базовых каналов потерь + прямые затраты + клиентский капитал. Из этих каналов формируются итоговые потери, на которых строится и SLA без учёта отскока, и SLA с учётом отскока.

Тестирование алгоритма и доказательство эффективности

На глаз всегда хорошо видно, как гладко и почти идеально график прогноза ложится на факт, совпадая на 99%, но «на глаз» никто никому, естественно, не поверит. Нужны доказательства. Работоспособность алгоритма подтверждали тестами. Многими тестами. Для этого мы:

1. Нарезали инциденты по разным окнам длительности — 15, 30, 60, 90 минут и так далее, опираясь на статистику по длительности наших реальных инцидентов, слава богу, с метриками и данными у нас проблем уже нет. 

2. Таймлайн нарезали со сдвигом в 15 минут примерно за месяц. 

3. В сумме по всем 11 каналам потерь (мобильные приложения «Пятёрочка», «Перекрёсток», «Чижик» и другие) получилось около 163 680 тестовых точек. Примерно по 15 тысяч на канал, что уже статистически значимо.

Вот пример нашего распределения. Думаю, у вас оно примерно такое же, плюс-минус: много коротких, мало продолжительных.

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

Относительная погрешность на этом наборе данных получилась около 2% (и очень похоже на MAPE):

Абсолютная погрешность тоже остаётся в разумных пределах и не имеет сильного абсолютного отклонения по времени суток, что очень хорошо (и сильно похоже на MAE):

То есть наш алгоритм на выборке из 163 000 синтетически нарезанных тестов ведёт себя стабильно и предсказуемо и показывает ошибку чуть меньше 2%.

Инциденты с потерями ночью и инциденты с потерями днём – не одно и то же. Поэтому следующим шагом мы посмотрели распределение инцидентов и потерь. Синий график на иллюстрации ниже — это количество инцидентов, красный — величина потерь. Оценивали их в разрезе дней и часов в течение суток. Сразу видно, что почти все потери укладываются в диапазон с 9 до 21.

На baseline видно, что красный график прогноза точно повторяет синий фактический график, практически сливаясь с ним, чего мы и добиваемся.

Получилось, что около 95% потерь, возникающих в инцидентах, попадают в точность работы алгоритма со средневзвешенной погрешностью примерно 2%. Это во многом объясняется распределением пользовательской активности и тем, что наши разработчики работают примерно в одно и то же время. Рабочие часы, релизы, пики нагрузки — всё накладывается друг на друга. Накатили релиз или провели какие-то работы — получили проблему на продакшене.

Далее важнейшая, если не кульминационная вещь: мы глубже смотрим на средневзвешенную погрешность (очень похоже на классический WAPE). Ниже на одном графике показана погрешность по каналам, а на другом — по всем инцидентам сразу. Если посчитать интеграл под красной кривой, получится единица. Она всегда должна получаться. Это непреложное правило и хороший тест на целостность проверок. Это означает, что распределение охватывает все инциденты.

А следующий график оказался особенно ценным. Если у вас есть похожий алгоритм, рекомендую сделать такой же тест.

Мы посмотрели на распределение доли экспериментов в процентах от величины погрешности и увидели, что для инцидентов разной длительности точность расчёта потерь почти одинаковая. Кривые накладываются друг на друга с точностью до десятых долей процентов, а иногда и сотых долей процента. Физически для нашего процесса инцидент-менеджмента и оценки SLA неважно, из каких инцидентов и какой длительности у нас будет состоять оцениваемый месяц, квартал или год и какое внутри распределение, точность оценки всегда будет одинаковой до десятых, а то и сотых долей процента. Это даёт нам ещё больше уверенности и доказательной базы для коллег и бизнеса. Это отличный результат, но так было не всегда. В ранних версиях распределения были растянуты по оси Х, на части длительностей инцидентов ошибка была высокой и они не имели одинаковой формы.

Итог тестов алгоритма расчёта потерь

Если перевести все графики и значения в практический и физический смысл, вывод такой: алгоритм даёт устойчивую точность, достаточную для уверенности в предоставляемых по SLA цифрах и принятых на их основе решениях.

Когда мы считаем SLA, например, на уровне четырёх девяток, фактическая ошибка оценки уходит примерно в пятый знак после запятой или в седьмую девятку, если говорить терминами девяток. Это значит, что округление «не в ту сторону» возможно только на уровне третьего после целевого знака. Такой точности более чем достаточно, чтобы считать алгоритм рабочим и доверять ему.

Например, при SLA = 99,99% и погрешности ±0,00027 реальное значение лежит в диапазоне примерно от 99,9897% до 99,9903%. Округление даже одного последнего знака сводит диапазон к единому значению. Для большинства инцидентов, около 90% сбоев и 95% потерь, относительная ошибка оценки составляет порядка 2,5%.

Соответственно, при разных уровнях SLA погрешность ведёт себя одинаково:

• при SLA = 99,999% остаётся в пределах ±0,00027%,

• при SLA = 99,99% — в тех же пределах,

• при SLA = 99,9% — ±0,0027%.

Все результаты мы упаковали в презентацию и спросили у коллег, как они считают потери сами и какие у них алгоритмы расчёта потерь, и показали, как считаем мы.

Со временем наши данные стали эталоном расчёта потерь по инцидентам для всей компании и начали выгружаться в общую витрину в DWH. Сейчас SLA в разных подразделениях считается уже на основе этих данных.

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

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

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

Также можно прочитать статьи о доступности, мониторинге и том, как отделять рабочие метрики от шума:

– Доступность IT-систем: поругаться или договориться?
– Как понять, что мониторинг в ЦОДе шумит