Рекомендации и советы по реагированию на инциденты

1. Соберите тревожный комплект

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

Этот комплект может содержать разную информацию.

• Планы реагирования на инциденты
• Списки контактов
• Графики дежурств
• Правила эскалации
• Ссылки на инструменты для организации конференц-связи
• Коды доступа
• Директивные документы
• Техническая документация и перечни процедур

2. Не перечьте перечням процедур

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

3. Постигните хаос, стремитесь к стабильности

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

4. Не держитесь за NOC

В прошлом функции мониторинга и оповещения в крупных ИТ-системах ложились на центры управления сетями (Network Operations Center, NOC). Современные средства управления инцидентами позволяют значительно оптимизировать этот процесс. Процедуры доставки оповещений автоматизируются на основании предопределенных типов оповещений, графиков работы команды и правил эскалации. Таким образом исключается вероятность ошибок, связанных с человеческим фактором, и (или) задержек.

5. Собирайте вместе и повышайте удобство

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

6. Помните: знания — сила

Примитивное оповещение сообщает о наличии проблемы, но не всегда объясняет ее суть. Из-за этого возникают ненужные задержки, поскольку командам приходится проводить анализ и искать причины оповещения. Когда в оповещениях содержатся технические сведения о событиях, которые спровоцировали их отправку, можно быстрее приступить к исправлению.

7. Настройте оповещения для своих оповещений

Латинская фраза Quis custodiet ipsos custodes («Кто устережет сторожей?») отсылает нас к общечеловеческой проблеме. Используемые ИТ-командами и разработчиками средства мониторинга подвержены инцидентам и сбоям не меньше систем, которые они должны защищать. Создайте всеобъемлющие процессы оповещения, чтобы постоянно проверять работоспособность систем и инструментов для их мониторинга.

8. «Остановите кровотечение»

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

9. Не пытайтесь действовать в одиночку

Культ героев в командах ИТ и DevOps теряет популярность. Уже не модно быть инженером-одиночкой, который постоянно работает по вечерам и на выходных, потому что только он знает, как восстановить системы. Теперь команды работают сообща. Прочность цепи определяется самым слабым звеном, поэтому нужно развивать всю команду, а не только одного гуру.

10. Обеспечьте прозрачность

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

11. Учитесь на сбоях

Большинство команд ИТ и DevOps признается, что им хватает времени только на оценку «серьезных сбоев в работе». Это неплохо для начала, однако не стоит игнорировать небольшие инциденты, которые могут иметь долгосрочные последствия. Необязательно составлять обстоятельный отчет по каждому инциденту, но разбор никогда не повредит.

12. Найдите основную причину (Основной причины нет!)

Или все-таки есть? При анализе инцидента редко удается определить единственную «основную» причину. Зачастую системы слишком сложны и взаимозависимы, чтобы можно было назвать одну основную причину инцидента. Даже если основная причина кажется очевидной (например, аварийное завершение работы приложения вызвано нажатием определенной клавиши), обычно нужно разобраться, какие внешние факторы привели к аварийному завершению работы (или не препятствовали ему). Ищите несколько основных причин, чтобы получить более полное представление об инцидентах.

13. Воздержитесь от обвинений

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

И еще кое-что

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