Время на восстановление работы после инцидентов увеличивается с каждым годом. И это на фоне рекордных затрат на инструменты наблюдаемости.
Доля команд с MTTR > одного часа растет из года в года: 7% в 2021 году, 64% в 2022 году, 74% в 2023 году и 82% в 2024 году. При этом среднее количество инструментов, используемых одной командой, выросло до 8–9 различных платформ.
И ответ команд пока что один — «нужно больше»: больше инструментов, больше дашбордов, больше сигналов. Все исходят из предпосылки, что главная проблема — это видимость.
Однако после определенного порога избыток данных observability приводит к когнитивной перегрузке. Это мешает поиску первопричин (RCA) и лишь увеличивает MTTR. Как ни парадоксально, больше сигналов часто означает меньше ясности.
Инженер не способен сопоставить 8 дашбордов на 4 разных платформах, когда инцидент происходит в 2 часа ночи. Он ищет сигнал, похожий на то, что он уже видел ранее.
Анализ подходов к снижению MTTR показывает, что скорость восстановления стабильно обеспечивают 3 вещи:
⚪️быстрое и точное обнаружение
⚪️инструментарий с низкой кардинальностью
⚪️понятные пути диагностики
Что с этим можно сделать?
⚪️ Измеряйте то, куда уходит внимание инженера. Что конкретно он открывал во время аварии? На какие графики смотрел дольше 30 секунд? Какие действия предпринимал? А что полностью проигнорировал?
⚪️ Проектируйте дашборды под инциденты, а не под покрытие. Каждая панель должна отвечать на конкретный вопрос, который возникает у инженера во время сбоя. Если вы не можете сформулировать этот вопрос — удаляйте панель.
⚪️ Качество сигнала важнее его объема. Один точный алерт, указывающий на корень проблемы, ценнее 50 алертов, требующих расшифровки. Регулярно проверяйте соотношение алертов к действиям. Если инженеры постоянно «гасят» или игнорируют уведомления — система шлет вам сигнал о собственной неэффективности.
⚪️ Проводите аудит внимания после крупных сбоев. Общайтесь с инженерами: что они открывали, что сработало, а что только мешало. Три месяца такой практики дадут вам более честное понимание ценности вашего observability-стека, чем любой отчет.
@DevOpsKaz 😛