Мониторинг приложения: какие сигналы нужны сначала

Ошибки, задержки, доступность и продуктовые симптомы вместо сотен графиков.

Короткий ответ

Ошибки, задержки, доступность и продуктовые симптомы вместо сотен графиков. На практике ответ сводится к четырём решениям: начните с пользовательского пути; определите допустимый уровень сервиса; настройте алерты только на действие; регулярно удаляйте бесполезный шум.

Что важно понять

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

Порядок действий

Начните с пользовательского пути.
Определите допустимый уровень сервиса.
Настройте алерты только на действие.
Регулярно удаляйте бесполезный шум.

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

Частые ошибки

оптимизировать процесс без понимания узкого места. Из-за этого решение опирается на неверное исходное предположение.
наказывать людей за сообщения об ошибках. Так инструмент или процесс начинает маскировать проблему вместо её решения.
хранить критические знания только в голове одного разработчика. Ошибка часто проявляется только в ближайшем реальном сценарии.
Не определить критерий готовности. Без него невозможно отличить завершённую работу от бесконечной настройки.

Когда базового подхода недостаточно

Процесс должен уменьшать риск и время обратной связи. Если правило создаёт работу, но не помогает обнаруживать или предотвращать ошибки, его стоит пересмотреть.

Итог

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