SLA как инструмент, а не отчёт

Часть 2. Масштабирование, автоматизация, AI и два компонента надёжности

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

Меня зовут Дмитрий Химион, я руководитель ML Platform в X5 Digital. В первой части ^[1] я рассказал, как мы пересобрали инцидент-менеджмент как процесс и внедрили единый алгоритм расчёта потерь, позволивший бизнесу и командам прийти к общему знаменателю.

В этой части речь пойдёт о следующем этапе — масштабировании и удешевлении. О том, что происходит, когда SLA считается корректно, цифрам уже доверяют, но компания продолжает развиваться. У неё кратно растёт количество разработчиков, архитектура усложняется и количество сбоев (напомню, что инциденты и сбои это наши обиходные синонимы и да по ITIL это не одно и тоже, уж простите) тоже растёт. Тогда ограничением становится не математика ^[2] и перегибы полиномов высоких порядков, а люди, ручной труд, коммуникации и скорость реакции ^[3].

Как упростить и автоматизировать дорогой и долгий процесс инцидент-менеджмента

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

Параллельно начали накапливаться коммуникационные издержки. Инциденты разбирала команда инцидент-менеджмента, а потери считала команда технической аналитики. Между ними шла постоянная коммуникация и, конечно же, случались проволочки из-за критически важных ОКР-ов, встреч и удлиняющих коммуникацию удлиняющих коммуникацию. Во-первых, посмотрим на процесс самого обнаружения и инициации работы с инцидентом.

Чуть погодя мы увидели процесс в цифрах: 

• Время детекции по медиане — 4 минуты, а по 75-му процентилю — 15 минут. Не очень хорошо, но можно принять.

• С реакцией всё выглядело хуже: медиана — те же 4 минуты, но для четверти инцидентов реакция занимала 10–12 минут. Для продакшена это чувствительно, тем более с учётом денежных оборотов.

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

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

Пять предикатов для автоматизации

Погнали сразу автоматизировать? Э, нет, так просто это не работает. Если вы пойдёте по такому пути, то почти гарантированно упрётесь в отсутствие нескольких базовых вещей:

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

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

• Нужен актуальный состав команд. Звонить человеку, который уволился несколько дней назад, с криком: «Слава, у нас горит продакшн» — плохая идея.

• Все эти источники информации ^[4] должны быть оцифрованы и доступны системе: дежурства, структура команд, роли, контакты.

Без этой базы нет смысла начинать автоматизацию. Если её нет, то вы обречены на провал. У нас, к счастью, всё это уже было. И ещё был внутренний платформенный сервис Duty, в рамках которого мы докрутили остальной функционал, связанный с инцидент-менеджментом и запуском работы над инцидентом.

Заведение инцидента

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

Следующий шаг — обзвон дежурных. При инициализации инцидента выбирается список команд, которые базово приглашаются «к слоту». Для этого есть простой интерфейс, подтягивающий данные из календаря дежурств в Duty. В нём видно, какие команды дежурят в конкретный день и кто именно находится на смене.

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

После того как проблему устранили, инцидент закрывается. Данные по нему собираются, делается выжимка и выгружается в тикет.

Результаты в цифрах

Мы сравнили данные на начало 2024 года и за лето 2025. Время детекции изменилось, но главное — ускорилась реакция. И по медиане, и по 75-му процентилю она сократилась примерно в четыре раза. Ускорение на 300% — отличный результат за шесть кварталов.

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

Использование ML-моделей для инцидент-менеджмента

Первое, что продолжало даваться особенно дорого — полнота данных, на которых мы считаем SLA. Анализ тредов в чатах быстро превращался в ад. Один тред на 300+ сообщений, чтобы понять что происходит в инциденте. При этом читать их всё равно приходилось, хотя бы для того, чтобы понять контекст и подключиться к инциденту.

Сбор таймлайнов и уточнение потерь превратились в отдельный вид насилия над собой, потому что требовали времени и высокой концентрации при сборе таймлайна из того же треда на 300+ сообщений. А эти данные могут быть нужны сразу после инцидента: руководство хочет быстро понять, что произошло, где именно и во сколько это обошлось бизнесу, и по горячим следам выполнить разбор.

По сути, вся эта боль ^[5] касается работы с текстом: анализ чатов, комментариев, таймлайнов, объяснений, уточнений. А технологии машинного обучения ^[6] довольно прозрачно намекали, что большие языковые модели неплохо справляются с этим типом задач. Так началась вторая волна преобразований.

Волна преобразований № 2

На практике это выглядит так. Заходим в тред с упоминанием, а инцидент горит уже не первые 30 минут. В треде 300-500 сообщений, которые нужно прочитать.

Начинаем с последних 100 сообщений, но контекст всё равно непонятен. Лезем глубже, читаем 200 сообщений, в контекст въезжаем, но на это уходит очень много времени.

Мы расширили функционал нашей агентской системы, которая является частью ML-платформы. Пишем команду !summary, и выгружается сжатое описание происходящего: какие команды задействованы, где возникла проблема, какой компонент деградировал, какая ошибка ^[7] наблюдается. Правда, заставить её работать содержательно и выдавать короткий, структурированный текст с акцентами на важных моментах стоило усилий и не одного десятка итераций доработок. Но для первичного понимания контекста этого достаточно и всего за 2-3 секунды.

Тут экономия времени, мягко говоря, жирнющая и умножается на количество уникальных людей участвующих в инциденте не с начала. Вот пример из боевого инцидента, как выглядит выжимка. Прочитать 10 коротких строчек дело 10-15 секунд против 6-10 минут чтения 100+ сообщений.

Следующий шаг — таймлайн. В средних и особенно крупных инцидентах он 100% становится «стратегическим закапыванием трудозатрат» Да, дорого, но делать надо. На сбор качественного и полезного для разбора таймлайна уходили часы работы, а при необходимости коммуникации с командами ещё больше. Первая версия была небольшой и скромной, вот пример:

Во второй, доработанной версии таймлайн стал строго структурирован с секциями и визуальным разделением для простоты восприятия ^[8] информации людьми. Появилось краткое описание, TL;DR (too long; didn’t read — «слишком длинно, не читал»), тайминги, список участников и последовательная хронология событий. Причины инцидента, способы устранения и даже action items, которые обсуждались участниками инцидента в процессе, извлекались автоматически. В итоге при разборе стало гораздо легче погрузиться в контекст. Вот пример того, как это выглядит сейчас:

Плюсы использования LLM в инцидент-менеджменте

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

• !summary — чтобы быстро разобраться в сути инцидента.

Когда тебя упоминают в треде, где уже накопилось 300–500 сообщений, читать всё подряд долго и больно. Команда !summary позволяет за 30 секунд понять, что произошло, какие команды задействованы и где именно возникла проблема.

• !timeline — для получения хронологии инцидента.

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

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

По цифрам экономия выглядит прилично:

• около 20 минут в среднем на сбор и оформление одного инцидента;

• около двух минут в среднем на погружение в контекст для вновь подключившегося человека;

• и условный «миллион минут» на бесконечные треды, которые теперь просто не нужно перечитывать целиком.

Был и положительный побочный эффект. Команда !summary моментально расползлась по компании. Теперь почти любой тред разрастается до сотни сообщений, и каждый второй сотрудник вызывает саммари. Но это уже приятная неожиданность, не более того.

Ограничения и побочные эффекты использования LLM

Теперь о том, что важно учитывать:

• Галлюцинации и додумывание фактов.

LLM склонны заполнять пробелы, особенно когда не хватает данных или интеграций с источниками данных через RAG или MCP. В одном из саммари, например, в списке участников, фигурировали Геннадий, Кирилл, Владимир, Михаил и Андрей, притом что двое из них вообще не участвовали в решении инцидента.

​​Аналогично в длинных тредах с никнеймами и шутками. Из-за отсутствия более полной интеграции LLM-ассистента с корпоративным чатом и возможности вытащить данные о полных именах участников модель пытается сопоставить ник с именем и выбирает наиболее вероятный вариант. Кирилл, а может быть Коля или Константин? И ладно бы на этом всё закончилось, но выдуманные «участники» могут быть приглашены на разбор инцидента и даже искренне хотеть помочь, вообще не будучи в контексте. Естественно, этот случай получил максимальную огласку и доработку LLM-ассистента быстро реализовали, но без пары сотен сообщений, смеха и шуток не обошлось.

• Ограничения в работе с большим контекстом.

Когда LLM работают с длинными тредами, всё упирается в аппаратные ресурсы и размер контекстного окна. В больших контекстах можно просто не влезть в окно модели, и тогда возникают ошибки. У нас был кейс, когда LLM-ассистента натравили на тред с 900+ сообщений, и он ничего не вытащил, выдавая ошибку. В логах мы нашли сообщение, что размер контекста более 320 000 токенов при тогдашнем ограничении в 35 000 токенов, если мне не изменяет память ^[9], так что это тоже надо иметь в виду.

Видим ли мы все инциденты?

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

У нас есть команда технической аналитики, которая занимается анализом внутренних процессов, метриками релизов и в том числе расчётом потерь в инцидентах. Для этого у них есть детектор аномалий, который анализирует временной ряд и показывает в нём аномалии с определёнными свойствами. Этот инструмент помогает нам увидеть то, что мы упустили из вида по текущим приборам.

Возьмём кусочек процесса улучшения и тестирования детектора аномалий. Если посмотреть на тепловую карту итерации доработки (честно стыренную с Демо команды тех-аналитики), опытный глаз сразу увидит показатель False Negative Rate (FN), означающий, что даже на тестовой выборке около 0,53% инцидентов проходят мимо нашего внимания ^[10]. Они были, но мы их не увидели. Классическая проблема классификации «спам/не-спам», здесь «инцидент/не инцидент». Всегда есть слепая зона. 

На этой же иллюстрации видна и обратная сторона. False Positive Rate (FP rate) составлял около 6,17%. Инцидента не было, но инструмент говорил «ВОЛКИ!». Конечно, можно прикрутить метрику ROC AUC, потому что по сути решается задача бинарной классификации, но это уже другая история.

Раньше было больше 11%, то есть точность алгоритма заметно выросла и это данные на конец 2025. Сейчас детектор стал лучше, но всё ещё ошибается.

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

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

• слабая деградация, которую можно отмести, потому что в ней зарыто много FP;

• сильная деградация, которая указывает либо на уже существующий инцидент, либо на новый.

На следующем графике как раз такой случай. Инцидента раньше не было, но детектор его подсветил. Мы его оформили, посмотрели, кто что выкатывал или менял. Сигнатура получилась неявная, слегка стохастическая, но этого оказалось достаточно, чтобы нащупать настоящий инцидент, завести и разобрать его.

Новые инциденты появляются нечасто. В целом это означает, что процесс инцидент-менеджмента работает стабильно и полнота охвата продукта нашими observability-инструментами достаточно высокая. Но инструмент нужен не для того, чтобы найти ещё 800 инцидентов, а чтобы контролировать собственную слепоту и понимать, что «наше зрение ^[11] всё еще достаточно чёткое и хорошее».

Автономность инцидент-менеджмента и снятие нагрузки с команды технической аналитики

В нашем процессе изначально участвовали две команды: инцидент-менеджмент и техническая аналитика. По мере развития процесса между ними повышалась интенсивность коммуникации и рос и растёт запрос на оперативные данные.

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

Логично ^[12], что за ответами на вопросы все обращались в команду технической аналитики. А они не всегда могли сразу ответить, из-за чего важная информация могла не поступить к руководству вовремя. А такие задержки — всегда проблема, особенно если надо принимать решение в моменте. Поэтому следующим шагом оптимизации процесса стало уменьшение зависимости инцидент-менеджмента от технической аналитики.

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

Это статистика. Если что-то посчиталось неправильно, сразу повлиять на это нельзя. Поэтому понять, что происходит, и исправить без привлечения тех аналитики не получится. Там «грелось» сильнее всего, поэтому мы сделали интерфейс, позволяющий анализировать, крутить и пересчитывать потери по инцидентам автономно. Он выглядит так:

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

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

Все вышеприведённые улучшения и автоматизации привели нас к конфигурации: один инцидент-менеджер на 500 человек. Конечно, круто, что один человек справляется с таким объёмом работы, но это же означает и высокий bus factor. Любой шаг в сторону — отпуск, больничный, конференция или долгое отсутствие — и процессу труба. Поэтому некоторое время назад у нас появился второй инцидент-менеджер. Сейчас их двое, но важно, что процесс уже был выстроен так, что один человек мог полностью с ним справиться.

Как не звать лишних людей в инциденты

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

Ответ оказался довольно простым. Чтобы понять масштаб проблемы, недостаточно написать саммари в треде или услышать пару фраз на созвоне. Не всегда бывает сразу понятно, насколько всё плохо. А главное, в моменте просто негде взять объективную оценку происходящего. !summary не отвечает на вопрос «насколько всё плохо?».

Руководителю в такой ситуации непонятно сразу несколько вещей:

• это лёгкая деградация или уже серьёзная проблема;

• нужно ли вообще подключаться к инциденту или там сами разберутся;

• нужно ли бросать всё и мобилизовывать ресурсы, потому что SLA для нас — весьма острый вопрос.

Оперативного инструмента, который давал бы такой контекст, не было, поэтому мы его сделали.

Интерфейс для руководителей

Представьте: суббота, вы на даче жарите шашлык. В продакшене что‑то случилось и прилетает нотификация. У вас выбор: «горит прод» или «горит шашлык». Как понять, надо ли подключаться к звонку?

Интерфейс, который решает эту проблему, работает так. Руководитель заходит в мессенджере в бота и нажимает кнопку «Покажи потери по текущим инцидентам». Система возвращает агрегированную картину. Цифры не принципиальны, важна логика принятия решения:

• если потери небольшие, можно не подключаться;

• если потери большие, подключаемся без вопросов.

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

Это особенно важно, потому что около 90% инцидентов происходят в рабочее время. А чем выше руководители, тем чаще они заняты на встречах. И если есть возможность не дёргаться лишний раз и не бежать на каждый созвон «на всякий случай», то это разумное решение.

Бизнес-SLA и технический SLA

И вот мы подошли к самой интересной части всей истории — разделению бизнес-SLA и технического SLA. В начале первой статьи я описывал запрос руководства по части SLA, и там фигурировали обе формулировки. Зачем их нужно разделять? Бизнес-SLA мы обсудили и считаем его в рублях, а в чём считать «технический SLA»?

Ответ содержится в двух ключевых тезисах:

1. Потери могут быть без ошибок.

2. Ошибки могут быть без потерь.

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

Ошибки без потерь — обратная ситуация, знакомая многим инженерам. Graceful degradation, retry, throttling: сервисы деградируют, ошибки есть, но пользователь либо почти ничего не замечает, либо вообще не сталкивается с проблемой, хотя технически проблемы были и даже самые серьёзные.

Два этих сценария как раз разделяют бизнес-SLA и технический SLA.

Бизнес-SLA: про деньги, но не про здоровье системы

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

В рамках бизнес-SLA могут одновременно существовать отсутствие ошибок и наличие потерь в одном флаконе. Формально всё будет выглядеть «хорошо».

Четыре девятки — это очень хороший SLA. Я работал в разных компаниях, и такой показатель отражает весьма высокий уровень надёжности. Кажется, чего ещё хотеть? Бизнес доволен, деньги зарабатываются.

Технический SLA: про здоровье продукта, а не про деньги

Технический SLA мы рассматриваем с позиции качества, устойчивости и внутреннего состояния системы.

Нам не нравится, когда продукт работает не так: растёт медианное время ответа, становится слишком много троттлинга и/или ретраев, система работает медленно или нестабильно, хотя для пользователя всё ещё выглядит корректной. Мы собираем эти сигналы и формируем из них технический SLA, фиксируя ошибки, которые могут быть вообще не видны бизнесу и не влияют на деньги напрямую.

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

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

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

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

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

Соответственно, в техническом SLA мы считаем длительность аномального поведения ^[13] системы (того поведения ^[14], которое мы, как инженеры, считаем некорректным или опасным).

Далее в техническом SLA появляется разбивка:

• по департаментам (в общий SLA пока свести не удалось),

• по сервисам,

• по критичности.

Mission Critical — это наш продакшен.

Business Critical — ситуации, которые напрямую влияют на решения бизнеса или на ход разработки продукта. Например, упала тестовая среда или отчёт в DWH, на основе которого принимаются решения, не прогрузился ко встрече с СЕО.

Office Critical — всё остальное: вики начала тормозить или перестали работать вспомогательные сервисы. Например, детектор аномалий или сервис оценки потерь. Если вдруг наш LLM-ассистент окажется недоступен, инцидент-менеджмент быстро вернётся в ручной режим каменного века, и придётся вспомнить, как собирать таймлайны и агрегировать руками контекст проблемы.

Выводы

Если вам нужен достоверный SLA, стоит начинать с ревизии инцидент-менеджмента. Это фундамент, на котором держится всё остальное.

Общепринятый SLA предполагает одновременное выполнение трёх условий:

• есть надёжный алгоритм и полные данные,

• прозрачная логика расчётов,

• доказательная база надёжности и точности алгоритма.

Метрики SLA считаются на основе данных, которые генерирует процесс инцидент-менеджмента. Если процесс ИМ деградирует или теряет сбор данных, SLA также теряет релевантность. А вместе с этим уходит и доверие к цифрам и алгоритму, без которых SLA перестаёт быть инструментом управления и объективного контроля.

Использование ML-моделей — это уже гигиена и способ автоматизировать рутинные части процесса. LLM-ки ускоряют работу и снижают нагрузку, но принцип Human as a Judge пока что обязателен.

Один инцидент-менеджер на 500 человек — это реально. Это соотношение можно использовать как ориентир и смотреть, где вы находитесь сейчас и какой у вас запас роста и зрелости процесса.

И напоследок:

• Бизнес-SLA нужен для разговора с бизнесом. Он отвечает на вопрос про деньги и «потери».

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

Оба этих SLA нужны. По отдельности они не дают полной картины. Вместе — позволяют управлять надежностью продукта обоснованно и через цифры.

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

– Как понять, что мониторинг в ЦОДе шумит ^[15]
– Утечка, которой не было: как Next.js раздувает RAM в Kubernetes ^[16]