Закрываем нашу смоделированную историю. Проблема здесь даже не в том, что кто-то посмотрел «не на тот график». Дашборд честно отвечал на вопрос, который ему задали: сервис технически отвечает? Да. Только пользователь приходил за другим — ему нужно было закончить покупку.
И вот тут полезно посмотреть на свой мониторинг со стороны:
1. Какое действие пользователя для сервиса действительно критично?
2. Увидим ли мы, если именно оно начнёт ломаться только у части людей? (Например, в одном регионе, на одном endpoint или в конкретном сценарии, пока общие графики остаются зелёными).
3. Узнаем ли мы о проблеме раньше поддержки? Если первым настоящим алертом становится сообщение пользователя «у вас ничего не работает», значит, в наблюдаемости есть слепая зона.
4. Когда сигнал приходит, понятно ли инженеру, что с ним делать? Сам по себе график, сообщающий в три часа ночи «что-то выросло», ценности добавляет мало.
Можно взять один свой сервис и быстро прогнать его по чек-листу из четырёх вопросов:
✔️ Что пользователь должен успешно сделать?
✔️ Видим ли мы сбой именно этого сценария?
✔️ Узнаем ли мы об этом раньше пользователя?
✔️ Понятно ли дежурному после сигнала, что делать дальше?
Если на половине вопросов появилось «ну-у-у…», это отличный повод покопаться в архитектуре алертов 👀
А если хочется не просто читать разборы, а попробовать выстроить SRE-подход вокруг своего сервиса на практике, 21 сентября у нас стартует 7-дневный SRE-интенсив. Это прикладной формат для тех, кто хочет связать разрозненные практики в единую рабочую систему.