#заметка_гостя - Дмитрий Синявский

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

Но чего стоит прекрасно настроенный мониторинг, если пользователи сообщают о проблеме раньше, чем вы проанализировали и сделали вывод по десяткам и сотням технических алертов?

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

Я предпочитаю подход SLI/SLO, который основывается на контроле метрик критических путей пользователя. Если пользователь испытывает проблемы на критическом пути, значит он может его не завершить, и компания потеряет клиента и деньги. Алерты по таким метрикам позволяют системе показывать, что качество обслуживания начало ухудшаться до того, как это заметили пользователи, позволяя вовремя внести коррективы. Вы делаете своим главным объектом заботы именно пользователя, а не систему. Это значительно снижает количество алертов, на которые надо реагировать, что делает инженеров более сосредоточенными и внимательными.

А у вас бывали ситуации, когда из-за сбоев или недоступности вы переставали пользоваться сервисом?

Интервью с Димой вы можете все так же посмотреть на YouTube и RuTube 🎥