#заметка_гостя - Дмитрий Синявский
Мониторинг —
это инструмент, который
не предотвращает сбои, а лишь сигнализирует о том, что проблема проявилась. Сотни графиков, сотни алертов – человеку это все анализировать не под силу, люди устают от постоянного шума алертов и получают выученную глухоту – просто перестают реагировать на сигналы. Потому компании тратят миллионы, а иногда десятки миллионов на системы мониторинга и попытки упростить работу инженеров и автоматизировать анализ работы информационных систем.
Но чего стоит прекрасно настроенный мониторинг, если
пользователи сообщают о проблеме раньше, чем вы проанализировали и сделали вывод по десяткам и сотням технических алертов?
Я не отрицаю, что технические алерты нужны, как способ
быстрее разобраться в сбое, но интересно ли вашему пользователю, как сейчас работают ваши системы? Он
пришел за услугами вашего продукта, который решает его проблему и только. Потому бизнесу важнее знать,
каково клиенту взаимодействовать с продуктом, и
узнавать об ухудшении работы предоставляемого функционала раньше, чем у пользователя кончится запас терпения, и он уйдет к конкуренту.
Я предпочитаю
подход SLI/SLO, который основывается на
контроле метрик критических путей пользователя. Если пользователь испытывает проблемы на критическом пути, значит он может его не завершить, и компания потеряет клиента и деньги. Алерты по таким метрикам позволяют системе показывать, что качество обслуживания начало ухудшаться
до того, как это заметили пользователи, позволяя вовремя внести коррективы. Вы делаете своим главным объектом заботы именно
пользователя, а не систему. Это значительно снижает количество алертов, на которые надо реагировать, что делает инженеров более сосредоточенными и внимательными.
А у вас бывали ситуации, когда из-за сбоев или недоступности вы переставали пользоваться сервисом?
Интервью с Димой вы можете все так же посмотреть на
YouTube и
RuTube 🎥