Настройка SLA-мониторинга: где отказывает веб-приложение
SLA мониторинг настройка начинается не с дашборда, а с разбора цепочки запроса: разрешение имени, установка защищённого соединения, балансировщик, процесс приложения, пул соединений к базе, синхронные вызовы внешних сервисов. Простой веб-приложения редко наступает целиком — сначала отваливается одно звено, а остальные слои продолжают отвечать. Задача первого этапа — понять, на каком участке пропадает пользовательский запрос и каким сигналом это видно снаружи.
Дальше разделяем мониторинг доступности на внешний и внутренний. Пробы из нескольких точек видят только крайний слой: отвечает ли страница, укладывается ли ответ в отведённое время, проходит ли ключевой сценарий — вход, поиск, оформление. Метрики самого приложения знают то, что снаружи не видно: насыщение пула соединений, рост очереди обработки, долю ответов с ошибкой на конкретном маршруте. Склеиваем оба контура по одному пути запроса и снимаем сбор в Prometheus, иначе проверка живости отдаёт успех, пока сценарий пользователя уже лежит.
Ложные срабатывания — не мелочь, а прямая цена настройки. Одиночная проба из одной точки, порог без удержания по времени, отсутствие группировки однотипных сигналов: дежурный получает шквал уведомлений, привыкает их игнорировать, и настоящий отказ тонет в шуме. Задержка складывается из периода опроса, окна оценки условия и маршрута доставки — секунды на каждом шаге превращаются в десятки минут до того, как инженер вообще узнает о проблеме.
Для эксплуатации это оборачивается тем, что инцидент нельзя ни доказать, ни разобрать: нет разделения симптома и причины, нет истории деградации, а обязательства по доступности нечем подтвердить. Разбираем, как это закрывается: от карты точек отказа и согласованных порогов до правил эскалации, которые не будят никого зря.
Что даёт контроль: окна обслуживания и классы отказов
Пока контроль не размечен, любой рост времени ответа выглядит одинаково: дежурный получает уведомление, идёт смотреть логи и только потом понимает, плановый это перезапуск или отказ базы. Разметка снимает эту неопределённость — плановые работы уходят в отдельные окна обслуживания, а сбои получают класс по последствиям.
Что меняется в эксплуатации
Окна обслуживания перестают быть устным договором. Регламентные работы и миграции публикуются как интервалы с явным исключением из расчёта доступности — график не проседает из-за плановых действий, а сам факт работ виден и заказчику, и дежурному.
Классы отказов разведены по порогам срабатывания. Деградация, частичный отказ и полная недоступность получают разные условия и разные каналы оповещения: рост времени ответа поднимает дежурного по расписанию, недоступность внешнего контура — сразу и с эскалацией. Границы окон и сами классы взяты из практики управления услугами (ITIL), поэтому их не приходится изобретать заново.
Как считаем эффект
Основная метрика — время восстановления. До разметки оно считалось «от звонка до звонка» и включало диагностику: типовой инцидент занимал 40-60 минут. После точка отсчёта сдвигается на первое срабатывание порога, а маршрут до ответственного известен заранее — 8-15 минут на большинство сценариев.
Вторая метрика — доля срабатываний, приведших к реальным действиям. Если дежурный открывает уведомление и ничего не делает, порог выставлен неверно. Держим эту долю выше 80% и пересматриваем правила после каждого разбора.
Форматы контроля: внешний сервис, свой сервис, гибрид
Формат контроля выбирают по двум вопросам: нужно ли видеть сервис изнутри и допустимо ли, что система мониторинга упадёт вместе с сервером. Внешний сервис проверяет то, что видит пользователь, но о состоянии процессов, очередей и свободного места на диске он не знает. Самостоятельный мониторинг даёт полную картину, зато живёт на том же контуре, что и приложение.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Внешний сервис мониторинга | Нужна независимая проверка доступности из разных регионов | Не видит процессов, очередей и ресурсов сервера |
| Самостоятельный мониторинг | Свой контур, полный контроль над данными и правилами | Падение сервера гасит и мониторинг — проверять некому |
| Гибридный мониторинг | Критичный сервис, где нужны обе картины сразу | Сложнее в настройке, нужна согласованная модель оповещений |
На практике чистые варианты встречаются редко. Внешние проверки ловят недоступность и истёкший сертификат, но не показывают, что сервис отвечает медленно из-за переполненной очереди. Агент на сервере видит внутреннее состояние, однако при отказе железа он молчит — и без независимой проверки сбой остаётся незамеченным.
Когда гибридный формат оправдан
Гибридный мониторинг нужен там, где простой обходится дороже настройки: агент на сервере собирает метрики по процессам и ресурсам, внешние проверки независимо фиксируют доступность, коды ответа и время отклика из разных точек. Условие одно — заранее договориться, какая система считает инцидент открытым, иначе дежурный получает два оповещения об одном сбое и со временем перестаёт реагировать на оба.
Этапы внедрения: от инвентаризации до передачи регламентов
Инвентаризация сервисов — не формальность: пока нет списка компонентов и их владельцев, любая метрика висит в воздухе. Поэтому начинаем с аудита — сверяем то, что реально работает, с документацией и фиксируем расхождения. Затем строим карту зависимостей: без неё непонятно, падение какого узла считать инцидентом, а какое — фоновым шумом.
- Аудит инфраструктуры и приложений: перечень сервисов, владельцев, внешних интеграций, режимов работы.
- Карта зависимостей: связи «клиент — сервис — база — очередь», критичные пути, точки отказа.
- План внедрения: какие показатели снимаем первыми, пороги срабатывания, окна оповещений, порядок раскатки по средам.
- Настройка сбора и оповещений: проверки доступности, времени отклика и корректности ответов, маршрутизация уведомлений по дежурным.
- Проверка на реальных сбоях: имитируем отказ узла, задержку ответа, недоступность базы — правим ложные срабатывания и пороги.
- Передача регламентов: описание метрик, инструкции дежурным, порядок эскалации и разбора инцидентов.
Роли и зоны ответственности на каждом шаге
Аудит и карту зависимостей ведём совместно с вашей командой — без знания бизнес-логики часть критичных путей не видна. Пороги и правила эскалации согласуем с теми, кто будет дежурить: регламент, написанный «снаружи», не соблюдают.
Проверка перед передачей
Прогоняем контрольный сценарий: останавливаем сервис, вносим задержку, отключаем зависимость — и сверяем, что уведомление пришло нужному дежурному за ожидаемое время. Регламенты считаем принятыми, когда дежурный самостоятельно воспроизводит разбор инцидента по инструкции.
Что остаётся у вас: конфигурации, схемы и регламенты
Все настройки после внедрения остаются у вас: конфигурация мониторинга, схема оповещений, регламент реагирования и рабочая документация. Комплект собран так, чтобы поддержку вела ваша команда или другой подрядчик — без восстановления логики по звонкам.
- Конфигурация мониторинга: перечень проверок — доступность, время ответа, ключевые сценарии пользователя; пороги срабатывания и окна подавления ложных срабатываний.
- Схема оповещений: маршруты по уровням критичности, каналы доставки, дежурные группы, правила эскалации и время ожидания на каждом шаге.
- Регламент реагирования: уровни инцидентов, целевое время реакции и восстановления, порядок действий дежурного, точки передачи ответственности.
- Инструкции для дежурных: первичные проверки, типовые причины сбоя, шаблоны сообщений для внутренних и внешних получателей.
- Схема инфраструктуры: сервисы, зависимости между ними, внешние точки присутствия — с пометкой, где стоят проверки.
- Доступы и порядок правок: роли наблюдателей, журнал изменений, версионирование конфигураций в вашем хранилище.
Как выглядит комплект документации
Комплект — три слоя: технический (конфигурации и схемы), эксплуатационный (регламент, инструкции, панели состояния) и передаточный (карта доступов, контакты ответственных, порядок правок). Всё хранится в вашем репозитории и вашем облаке, в текстовых форматах, читаемых без нашего инструмента. На передаче проходим по пунктам с дежурным: как добавить проверку, как отключить шумное оповещение, как откатить правку.
Кейс: убрали ложные срабатывания и сократили простой вдвое
Разбираем внедрение на сервисе с высокой нагрузкой: каталог с оформлением и оплатой заказов, пик приходится на вечерние часы, дежурство круглосуточное. До работ мониторинг держался на одном пороге и не различал «страница отвечает» и «заказ реально оформляется».
Что было до
Проверка раз в минуту била по главной: любой всплеск времени ответа порождал поток уведомлений — около 120 за неделю, из которых реальными были единицы. Дежурный привык к шуму и разбирал сигналы выборочно. Настоящий отказ оплаты обнаружили через 40 минут по обращениям покупателей. Доступность сервиса держалась на 99,4%, время простоя — около 4 часов в месяц, время восстановления — до 50 минут: диагностика каждый раз начиналась с нуля.
Что стало после
Мониторинг разложили на уровни: синтетические сценарии полного пути заказа, метрики приложения и счётчики бизнес-событий — число успешных оплат в минуту. Сигнал уходит дежурному только когда подтверждаются минимум два уровня, а на период регламентных работ и выпуска релиза открывается окно подавления. Уведомления и эскалации собраны в PagerDuty, поэтому дежурный видит один инцидент, а не десять.
Ложные срабатывания упали до 15 в неделю, время обнаружения — с 40 до 4 минут. Время восстановления сократилось вдвое, до 20 минут: к моменту разбора уже есть графики и история запросов по проблемному пути. Доступность сервиса выросла до 99,95%, простой — с 4 часов до 40 минут в месяц.
Чем отличается мониторинг доступности от контроля уровня сервиса?
Мониторинг доступности отвечает на один вопрос: отвечает ли сервис на запрос. Это бинарный сигнал — код ответа и время отклика по заданному адресу. Контур ловит падение целиком, но не замечает, что сервис работает медленно или отдаёт ошибки только на части запросов.
Контроль уровня сервиса шире: он описывает, как сервис обслуживает пользователя. Доля успешных запросов, время ответа на 95-м процентиле, частота отказов на критичных сценариях. Формально адрес «доступен», но если оформление заказа идёт 8 секунд, уровень сервиса нарушен, а проверка доступности молчит.
Проверка извне идёт с внешнего узла и показывает ровно то, что видит пользователь. Синтетические проверки прогоняют сценарий целиком — вход, поиск, оплата — и дают ранний сигнал о деградации, но не заменяют данные о реальном трафике.
| Вариант | Что показывает | Ограничения |
|---|---|---|
| Проверка извне | Доступность адреса, время ответа | Не видит процессы внутри сервиса |
| Синтетические проверки | Прохождение ключевого сценария | Фиксированный путь, редкие ветки не ловит |
| Метрики приложения | Очереди, ошибки, время обработки | Нужна инструментировка кода |
| Контроль уровня сервиса | Долю успешных запросов, целевые значения | Требует согласованных целей и разметки путей |
Доступность — фундамент: без неё остальные метрики не считаются. Уровень сервиса — надстройка, которая переводит технические сигналы в целевые значения: сколько девяток держим, какая доля запросов укладывается в отклик, при каком отклонении поднимается тревога.
Без второго контура команда узнаёт о проблеме от пользователей, а не от системы. Поэтому мы настраиваем оба уровня и связываем их в одну картину с регламентом реакции.
Технические сомнения: что уточняют перед стартом
Перед стартом инженерные команды задают похожие вопросы — не про важность контроля, а про то, как это отразится на их работе: сколько будет ложных тревог, что делать в пик сезона, где заканчивается наша ответственность. Ниже — ответы на те, что чаще всего всплывают при разборе задачи.
Как отсекаете ложные срабатывания?
Оповещение поднимается только после нескольких неудачных проверок подряд с разных точек наблюдения — одиночный всплеск задержки или кратковременный обрыв связи дежурного не будит. Отдельно настраиваем пороги для синтетических проверок пользовательских сценариев и для метрик самого приложения: природа у них разная, и общий порог даёт шум.
Что происходит на пиковых нагрузках?
Статический порог на пике сезона или во время кампании даёт либо лавину оповещений, либо пропуск реальной деградации. Поэтому часть проверок переводим на динамический порог — сравнение с тем же часом и днём недели, — а на период распродаж заводим отдельный профиль с расширенным набором метрик.
Где граница зон ответственности?
Мы отвечаем за сбор метрик, правила срабатывания, доставку оповещений и разбор инцидентов по приложению. На стороне заказчика остаются доступы к инфраструктуре, изменения в коде и согласование регламента эскалации: кому и куда идёт сигнал, кто принимает решение об откате. По внешним сервисам заранее фиксируем, кто ведёт коммуникацию с их поддержкой.
Как выглядит этапность внедрения?
Начинаем с пилота на двух-трёх критичных сценариях — вход в личный кабинет, сквозной путь оформления заказа. Смотрим реакцию на реальном трафике, правим пороги и только потом раскатываем на остальные сервисы. Так лишние тревоги отсеиваются до того, как мониторинг начнёт влиять на дежурства.
Обсудим задачу: с чего начинаем и что нужно от вас
Чтобы вернуться с оценкой сроков и планом работ, а не с общими словами, нужны исходные данные и доступы. Первый разбор — один разговор: смотрим, как приложение устроено сейчас, какие сбои уже были и что для вас считается недоступностью.
Дальше — короткий пилотный сервис на согласованном контуре: ставим проверки, собираем статистику и сверяем её с реальными инцидентами. Так видно, какие пороги дают ложные срабатывания, а какие пропускают деградацию. По итогам пилота разворачиваем мониторинг на всём контуре и выполняем передачу мониторинга с документацией и правилами дежурства.
Что нужно от вас на старте:
- критичные сценарии — вход, оплата, поиск, оформление заказа: что считаем недоступностью;
- схема приложения и внешние зависимости: база данных, очереди, платёжные и партнёрские интеграции;
- доступы на чтение к логам и текущим системам наблюдения, конфигурации веб-сервера и балансировщика;
- история инцидентов: что ломалось, как узнавали, сколько восстанавливали;
- окна обслуживания и допустимое время реакции и восстановления по каждому сценарию;
- контакт дежурного и правила эскалации — кому и как сообщать о срабатывании;
- требования к хранению метрик и политика доступа к ним.
Части данных может не быть — соберём вместе на разборе. Опишите задачу и пришлите то, что есть: вернёмся с оценкой сроков, планом работ и предложением по пилотному сервису.
