Дашборд зеленый, API отвечает, алертов нет. Но клиент не получил результат, а команда снова вручную спасла процесс. Это надежная система или просто сбой, который пока умеют скрывать люди и процессы?

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

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

Формально система доступна. Фактически ее надежность оплачена вниманием команды.

У меня сейчас похожий кейс в анализе и классификации звонков АТС/телефонии. Я сделал dashboard контроля: он показывает исходы звонков по рассматриваемому потоку около 30 000 звонков в месяц, включая автоответчик.

Там хорошо видно различие между technical status и business outcome. АТС может вернуть "отвечен", потому что соединение было, но фактически ответил автоответчик, а не реальный абонент.

Для бизнес-процесса это не успешный контакт. Дозвон нужно продолжать до реального ответа абонента и получения результата. Иначе технический "answered" становится зеленой метрикой, которая не означает завершенный результат.

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

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

Для меня практическая проверка надежности начинается с пяти вопросов:

— Какой результат должен получить пользователь или бизнес-процесс? — Может ли этот результат не случиться при зеленых технических метриках? — Где люди регулярно компенсируют слабость системы вручную? — Видим ли мы фактическую цепочку зависимостей и владельцев? — Что произойдет, если самый опытный инженер сегодня не подключится?

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

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

А у вас мониторинг показывает состояние сервисов или факт, что пользователь действительно получил результат?

#backend #infra #SRE #observability #teamlead #engineeringmanagement #izagprog