Давайте поговорим о процессах во время инцидентов и после инцидентов. Как бы вы описали ключевые обязанности или действия DevOps лидера во время инцидента?

Подсказки:

• Учтите аспекты кооперации во время расследования инцидентов
• Подумайте об подходах к созданию культуры без обвинений во время инцидентов
• Расскажите о процессе анализа причин возникновения проблем и ваше участие в нем
• Есть ли у вас виденье о том как стоило бы выработать процесс выработки решений для предотвращения будущих инцидентов?
• Какого процесса постмортемов вы бы хотели придерживаться

Выше ожиданий:

• Понимание принципов SRE в управлении инцидентами
• Знание общепринятых рамок классификации инцидентов
• Опыт интеграции инструментов observability
• Внедрение автоматики для реагирования на инциденты

Обычно нам нужно следовать структурированным процессам, таким как те, что описаны в ITIL (Библиотека инфраструктуры информационных технологий) или адаптированные из практик SRE Google, которые сосредоточены на минимизации времени до решения проблемы и влияния на клиентов. Когда команда DevOps входит в состав команды инженеров по эксплуатации, мы следуем следующему процессу:

Совместная работа во время расследования инцидентов

Используйте выделенный канал связи (Zoom, Telegram и т. д.) для координации инцидентов, где все заинтересованные стороны могут взаимодействовать.

Обычно здесь участвуют следующие ключевые люди:

• Инцидент-менеджер: Координирует реакцию и принимает решения
• Лидер по коммуникациям: Обновляет заинтересованные стороны
• Технический лидер: Руководит техническим расследованием
• Секретарь: Документирует временные рамки и принятые действия

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

• Предоставление регулярных обновлений статуса
• Честное признание известного и неизвестного
• Использование ясного, нетехнического языка для бизнес-заинтересованных сторон

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

• Платформы управления инцидентами (PagerDuty, OpsGenie)
• Общие панели мониторинга
• Коллаборативные инструменты для редактирования тексты (наподобие notion)

Создание культуры без вины (blameless)

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

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

Использовать соответствующий язык, который фокусируется на обучении и улучшении, а не на поиске виновных:

• Вместо вопроса "Кто сломал систему?" задавать вопрос "Какие условия позволили этому случиться?"
• Фокусироваться на "как", а не на "кто"

Процесс анализа первопричины

Использовать следующий подход для выявления первопричины:

1. Сбор данных: Сбор журналов, метрик, событий в выбранный период и показания свидетелей
2. Выявление непосредственной технической причины инцидента причины
3. Проведение более глубокого анализа: Использование таких методов, как "5 почему" или "Диаграмма Исикавы", для выявления коренных причин
4. Учет сопутствующих факторов: Технический долг, пробелы в процессах, проблемы с коммуникацией
5. Документирование результатов: Создание всеобъемлющего отчета о расследовании

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

Использовать инструменты, которые облегчают анализ первопричин:

• Системы распределенного трассировки (Jaeger, Zipkin)
• Платформы агрегации логов (ELK Stack, Grafana)
• Инструменты поиска корреляции событий

Предложение решений по предотвращению

Предложить приоритизированный план устранения неполадок, основанный на влиянии, усилии и вероятности повторения.

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

Разделить превентивные меры на:

• Технические решения: Изменения кода, улучшения архитектуры, автоматизированные тесты
• Улучшения процессов: Улучшенные процедуры проверки, обновленные руководства по работе
• Образовательные мероприятия: Обучение, обмен знаниями

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

Внедрить SLO (Service Level Objectives) и бюджеты на ошибки, чтобы направить принятие решений о вложениях в надежность.

Пример матрицы предотвращения:

| Решение                                           | Влияние  | Усилия  | Приоритет |
|---------------------------------------------------|----------|---------|-----------|
| Добавить circuit breaker к API вызовам            | Высокий  | Средний | 1         |
| Увеличить покрытие тестами                        | Средний  | Высокий | 2         |
| Обновить руководство по реагированию на инциденты | Средний  | Низкий  | 1         |

Процесс постмортама и его важность

Проведите тщательные ревью постмортама для крупных инцидентов, документируя:

• Временную шкалу инцидента
• Методы обнаружения
• Действия по реагированию
• Корневые причины и сопутствующие факторы
• Оценка воздействия
• Действия по предотвращению

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

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

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

Структурируйте постмортемы так, чтобы они были основанными на фактах, тщательными и ориентированными на будущее. Избегайте языка, который возлагает вину.

Классификация и управление инцидентами

Классификаторы инцидентов, чтобы категоризировать инциденты на основе:

• Воздействие: Влияние на пользователей или бизнес-операции
• Неотложность: Как быстро требуется реакция
• Приоритет: Объединенная оценка воздействия и неотложности

Общие системы классификации включают:

• P1: Критический сбой сервиса, влияющий на всех пользователей
• P2: Сильно затронута основная функциональность для многих пользователей
• P3: Незначительно затронута небольшая функция для некоторых пользователей
• P4: Косметические проблемы с минимальным воздействием

Принципы SRE в управлении инцидентами

• Используйте SLI (Service Level Indicators) и SLO (Service Level Objectives) для объективного измерения состояния сервиса и руководства по приоритезации инцидентов
• Внедряйте бюджеты на ошибки, чтобы сбалансировать работу над надежностью и разработкой новых функций
• Практикуйте сокращение трудозатрат, автоматизируя повторяющиеся задачи по реагированию на инциденты
• Применяйте планирование емкости (capacity planning), чтобы предотвратить инциденты, связанные с ресурсами

Создайте цикл непрерывного улучшения, где уроки из инцидентов непосредственно влияют на приоритеты разработки.

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

Усовершенствованная интеграция инструментов observability

Используйте весь стек observability, который объединяет:

• Метрики: Численные данные о производительности системы
• Журналы: Подробные записи об событиях системы
• Трейсы: Информация о маршрутах запросов через систему
• События: Значительные изменения или действия в системе

Системы observability следует проектировать с самого начала создания сервисов:

• Интегрировать инструменты мониторинга в кодовую базу
• Стандартизировать форматов журналов
• Внедрять распределенной трассировки
• Создание осмысленных проверок состояния

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

Автоматизированное реагирование на инциденты

Разработать руководства и playbooks для распространенных инцидентов, которые документируют стандартные шаги по расследованию и разрешению.

Внедрить автоматизированное устранение для хорошо известных проблем:

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

Создать интеграции ChatOps, которые позволяют командам выполнять общие действия непосредственно из площадки коммуникации.

Создать ботов для реагирования на инциденты, которые могут:

• Автоматически собирать релевантную информацию
• Создавать каналы инцидентов
• Уведомлять соответствующий персонал