Мнимая прозрачность. Часть I. Продукт.

Самая опасная ситуация в управлении - не когда ничего не видно, а когда кажется, что всё видно.

Я проходил такой сценарий. Сначала вы держите систему руками: смотрите логи, лезете в запросы, разбираетесь в каждом странном отклонении - жуть полная. Потом (ты же умный тимлид) появляются метрики. Дашборды, статусы, агрегированные показатели, алерты - все красиво, как на новогодней елке. “Все видно”.

Ну и все, жить стало легче. Команда реже лезет в логи, ты - тем более. Все есть на дашах. Если что-то ломается - уведомление падает в чатик. Благодать.
Однако через какое-то время система начинает вести себя хуже. Ломается чаще. Ошибки становятся неожиданными, и то, что раньше ловилось на ранней стадии, доезжает до инцидентов. 

Почему такое стало происходить? А потому что “видно” и “понятно, что происходит” - вещи разные. Метрики создали ощущение контроля, но не улучшили прозрачность. Наоборот - успокоившись, что теперь за вас на все смотрят аналитические скрипты, вы перестали понимать поведение системы. Зададимся вопросом - метрики-то зачем внедряли, какова была реальная цель? Чтобы система стала прозрачнее, предсказуемее. К сожалению, одних дашей в графане и нотификаций в чате недостаточно. Если при изменении метрик никто не может объяснить, почему - это мнимая прозрачность, ее на самом деле нет. 

Любой алерт должен порождать действие, а у каждой метрики - ответственный за объяснение ее поведения. 
При любом заметном отклонении метрики должен быть короткий разбор: что произошло, почему и как это можно было заметить раньше. Без этого вы просто копите историю непонятных просадок. И обратно тоже работает - если метрика вернулась из просадки, должно быть четкое понимание, почему это произошло. 

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