Спостережуваність перевіряється не на демо для менеджменту. Вона перевіряється о третій ночі, коли задзвенів пейджер, ти ще напівсонний, і в тебе є десять хвилин, щоб зрозуміти, що горить. Якщо в цей момент дашборди красиві, але не відповідають на питання «що зламано й наскільки погано» — вся ця спостережуваність була декоративною.
Я пройшов через етап, коли ми міряли все. Сотні графіків, десятки дашбордів, метрики на кожен чих. Виглядало солідно. А під час реального інциденту ми гортали ці екрани й не могли знайти головного — де саме почалась деградація і кого вона зачепила. Забагато сигналу — це той самий шум, просто дорожчий.
Тоді я змінив підхід. Спершу питання, потім метрики. Що я хочу знати першим о третій ночі? Скільки користувачів зараз страждає. Який шлях запиту зламався. Чи це наша проблема, чи впав хтось нижче за течією. Кожна метрика має заслужити своє місце тим, що відповідає на одне з таких питань. Не відповідає — вона тільки заважає.
Далі — три речі разом, бо поодинці вони брешуть. Метрики кажуть, що щось не так. Логи кажуть, що саме сталось на конкретному запиті. Трейси кажуть, де в ланцюжку сервісів застряг час. Метрика без трейса — це тривога без адреси. Трейс без метрики — це історія без масштабу. Я хочу за пару кліків пройти шлях від «щось не так» до «ось цей сервіс, ось цей запит, ось цей рядок».
І окремо про алерти. Алерт має означати дію, а не факт. «CPU 80%» — це не інцидент, це погода. «Помилки на оформленні замовлення ростуть пʼять хвилин» — ось за цим варто будити людину. Кожен алерт, який дзвенить і не вимагає нічого робити, повільно вбиває довіру до всієї системи. Через місяць таких сповіщень люди починають ігнорувати пейджер — і пропускають справжній.
Стійка система — це не та, де багато графіків. Це та, де о третій ночі ти за десять хвилин розумієш, що відбувається, і йдеш це лагодити, а не шукати.
– Sergey Shinder
