Обзор VOID Report 2024

В начале 2024 года вышел отчет VOID Report 2024, подготовленный Courtney Nash, ведущим исследователем проекта The VOID. Отчет основан на крупнейшей публичной базе инцидентов VOID (Verica Open Incident Database), включающей более 10 000 инцидентов из почти 600 компаний, и дополняется исследованием практик анализа инцидентов (Incident Analysis). Цель отчета – изучить непреднамеренные последствия автоматизации (Unintended Consequences of Automation in Software) и показать, каким образом автоматизация влияет на инциденты и почему системы, создаваемые для повышения надежности, нередко становятся источником дополнительных рисков.

Для читателей, ранее не знакомых с отчетами VOID, кратко приводятся ключевые выводы предыдущего выпуска:

• Длительность инцидента не даёт понимания сути произошедшего;
• Нет корреляции между длительностью и сложностью инцидентов;
• Инциденты происходят в компаниях любого масштаба;
• MTTR (Mean Time To Recovery) является ненадежной метрикой для сложных систем;
• RCA (Root Cause Analysis, анализ первопричин) постепенно уходит из практики компаний.

Для подготовки отчета VOID Report 2024 был проведен короткий исследовательский опрос, направленный на изучение процессов анализа инцидентов (Incident Analysis) в отрасли. В опросе приняли участие представители 55 компаний, основная часть респондентов — из ролей SRE в технологических компаниях. Полученные данные позволили сформулировать следующие выводы:
1. Сильная организационная поддержка анализа инцидентов (поддержка руководства или наличие Center of Excellence) коррелирует с:
— лучшей интеграцией результатов анализа в планирование;
— более последовательными процессами управления инцидентами;
— стандартизированным и согласованным сбором данных;
— более высокой уверенностью в результатах анализа.
2. Большинство компаний рассматривают анализ инцидентов прежде всего как средство предотвращения будущих инцидентов, однако только 40% считают, что анализ действительно помогает снизить вероятность повторения инцидентов;
3. Несмотря на наличие специализированных ролей и формальных процессов, единообразие в сборе и применении результатов анализа остается проблемой для заметной части компаний.

Основной раздел отчета был посвящен исследованию роли автоматизации в инцидентах. Под автоматизацией понимается использование программных механизмов для выполнения задач вместо человека, преимущественно повторяющихся. Для анализа применялся тематический анализ (Thematic Analysis по методологии Braun & Clarke). Все инциденты из базы VOID (более 10 000) были отобраны по ключевым словам: CI/CD, Retry storm, Self-heal/ing, Alert/ing/ed, Automation, Automated, Load balancing, Load balancer, Detection. Начальная выборка составила 459 инцидентов, после ручной фильтрации выделено 189 инцидентов, в описаниях которых автоматизация упоминалась как значимый элемент. Получено следующее распределение:
77% — Contributing factor (автоматизация выступала фактором, способствующим инциденту);
75% — Manual intervention required (для устранения инцидента требовалось ручное вмешательство);
34% — Detection (автоматизация обнаружила проблему);
20% — Solution (автоматизация выступала частью решения за счет автоматического восстановления);
37% — Action item (автоматизация фигурировала в списке действий после инцидента);
14% — Hindering remediation (автоматизация затрудняла устранение инцидента).

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

1. Автоматизация играет несколько ролей в инцидентах — может одновременно быть и частью проблемы, и частью решения;
2. Автоматизация нередко ухудшает ситуацию — массовые повторные попытки (retry storms), неправильные взаимодействия, конфигурационные сбои, непрозрачность состояния;
3. Человек остаётся незаменимым — автоматизация по-прежнему требует вмешательства, особенно в сложных сценариях.

На основании того, как автоматизация упоминалась в отчетах об инцидентах, были выделены шесть архетипов автоматизации (Automation Archetypes):

1. The Sentinel (Сторож) — классический мониторинг и алертинг, который может как своевременно выявлять проблемы, так и перегружать шумом и вызывать Alert fatigue;
2. The Gremlin (Гремлин) — мелкие, но деструктивные ошибки конфигурации и развертывания;
3. The Meddler (Подстрекатель) — сценарии самоусиления и ухудшения ситуации в момент попытки исправления;
4. The Unreliable Narrator (Ненадежный рассказчик) — автоматизация, создающая неполную или ошибочную картину происходящего;
5. The Spectator (Наблюдатель) — автоматизация настроена, но реальную работу выполняют инженеры;
6. The Action Item (Пункт действий) — предложения улучшить или расширить автоматизацию после инцидента, что нередко повышает связанность системы и создает новые точки отказа.

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

В заключительной части отчета предлагается рассматривать автоматизацию как участника инженерной команды. Автоматизация должна:

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

Авторам важно подчеркнуть необходимость перехода к принципам Совместных когнитивных систем (Joint Cognitive Systems, JCS), где автоматизация и инженер взаимно усиливают друг друга, а не пытаются заменить друг друга.

Основные результаты из исследования и отчета VOID Report 2024 приведены ниже: