Ваша команда инженеров испытывает усталость от бдительности? Задайте эти 8 вопросов

Усталость от предупреждений является распространенной проблемой среди инженерных групп, которые управляют операциями и обслуживают инфраструктуру.

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

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

«По мере роста количества и сложности функций и инфраструктуры улучшение оповещений обычно отходит на второй план в списке приоритетов»

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

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

Что мы думаем о стратегии оповещения

Концепция «дисциплины предупреждений» лежит в основе контроля над предупреждениями. Как и при работе с функциями, к оповещениям и стратегии оповещений следует подходить обдуманно и структурировано. Однако, в отличие от полнофункциональной работы, это не то, что можно хорошо спланировать заранее.

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

8 вопросов, которые следует задать при оценке предупреждений вашей команды

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

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

Затем каждое оповещение проходит контрольный список вопросов:

1. Актуально ли оповещение?

Любые оповещения, вызванные устаревшими или необслуживаемыми системами, не должны беспокоить дежурного инженера и должны быть немедленно удалены.

2. Является ли оповещение действенным?

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

3. Является ли информация в предупреждении немедленно полезной, даже если она не требует действий?

Мы можем разделить предупреждающую информацию на две большие категории.

• Сигналы: эти предупреждения предупреждают о том, что система работает на пределе своих возможностей, но не обязательно означают, что это влияет на службу. Примером может быть один из ваших серверов, работающих на 100% ЦП. Если служба все еще работает нормально, должны ли дежурные тратить драгоценное время на расследование? В конце концов, ваш сервер просто работает с наилучшим соотношением цены и качества!
• Симптомы: эти оповещения срабатывают, когда это влияет на качество обслуживания клиентов. Примером здесь может служить количество ошибок HTTP 5XX, которые ваша служба возвращает вызывающим абонентам.

Эти две категории лучше всего работают в тандеме. Дежурный должен реагировать и устранять симптомы и рассматривать сигналы только как дополнительный источник информации.

4. Если оповещение является действенным и пейджинговым, нужно ли его обрабатывать немедленно?

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

5. Если это действенно, есть ли ссылка на модуль Runbook или устранение неполадок? Являются ли шаги достаточно четкими, чтобы их мог выполнить любой инженер в команде?

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

« Четкая, простая и актуальная информация об устранении неполадок в предупреждениях имеет большое значение для сокращения среднего времени на устранение последствий инцидента и восстановление после него »

Даже если у вас есть опыт, вы могли написать код так давно, что не помните четко, что он должен делать. Четкая, простая и актуальная информация об устранении неполадок в предупреждениях имеет большое значение для сокращения среднего времени на смягчение последствий и восстановление после инцидента (MTTM и MTTR).

6. Если это применимо, есть ли ссылка на информационную панель и показаны ли на ней все известные потенциальные причины?

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

7. Является ли предупреждение слишком деликатным или недостаточно конкретным? Выиграет ли это от десенсибилизации или изменения масштаба?

Многие оповещения полезны, но неправильно откалиброваны. Они могут быть либо слишком широкими и не стрелять каждый раз, когда должны, либо слишком конкретными и стрелять несколько раз по одному и тому же инциденту, что только добавляет шума.

8. Наконец, должен ли человек заниматься исправлением?

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

Это особенно верно, если вы работаете на облачной платформе, такой как AWS, и можете выделить инфраструктуру, не беспокоясь о запросе дополнительного оборудования. Например, если узел в вашем поисковом кластере показывает неисправные диски, почему бы не заменить его автоматически? Если службе не хватает вычислительных ресурсов из-за увеличения трафика, почему бы не увеличить масштаб и не добавить дополнительные виртуальные машины или контейнеры? Затем сведения об исправлении могут быть отправлены команде по каналам без предупреждений, чтобы они могли просмотреть их на досуге.

Вы ответили «нет» хотя бы на один из этих вопросов?

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

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

Вам интересно, как мы работаем в Intercom? Мы будем рады поговорить с вами — ознакомьтесь с нашими открытыми инженерными ролями.