Трудно решить инцидент тогда, когда инцидента нет

Один из топовых способов въебать кучу времени в расследование инцидента, поднять кучу людей, несколько раз прийти в тупик и бессистемно потыкаться в поисках проблем — забыть сформулировать в чём проблема.

Когда я говорю “в чём проблема”, я не имею ввиду такие вещи, как:
- рост потребления памяти
- троттлинг цпу
- потери пакетов
- высокий уровнь ошибок
Это — симптомы, наблюдения, факты. Они помогают нам подтвердить, опровергнуть или придумать гипотезы о происходящем. Но они не являются проблемой сами по себе.

Проблема — в том, что именно мешает пользователям сделать свою задачу. Например — делать заказы, отправлять письма, отправлять сообщения, смотреть статьи. Если вы инженер и не получается сопоставить происходящее с пользовательской проблемой — ищите компетентного менеджера. Он придёт и скажет вам, что тревога ложная 🙂

Только наглядно наблюдая проблему, понимая её ближайшие и очевидные симптомы, можно понять — получилось ли решить инцидент.

Условный высокий уровень 502-ых может продолжаться столько угодно, если он не мешает пользователя делать заказы (потому что есть retry или fallback-механизм).

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