Принципы реагирования на инциденты
Современные организации используют преимущества доступности, эффективности и удобства облачных сред, но сталкиваются со многими проблемами по мере перехода на цифровые технологии, который подразумевает перемещение части бизнеса в облачные службы.
Некоторые распространенные проблемы, с которыми вы можете столкнуться в вашей организации, включают:
- Увеличение количества нарушений работы служб
- Отсутствие эффективного метода отслеживания и реагирования на инциденты (все является ситуационным и реакционным)
- Неприемлемое время для разрешения
- Время для разрешения не улучшается или даже ухудшается
- Трудно найти информацию и состояние
- Повторяются одни и те же проблемы и ошибки
Для удовлетворения этих проблем необходимо четко определенный план реагирования на инциденты, построенный на твердом фундаменте.
Основания и основополагающие элементы
Цель основания — поддерживать и скреплять структуру над ним. В отдельном вводном модуле для этой схемы обучения мы обсуждали идею о том, что работа над надежностью строится на базовом уровне мониторинга, и что реагирование на инциденты находится чуть выше в иерархии.
Реагирование на инциденты также имеет под собой основание. Существует три основных принципа, которые поддерживают хороший план реагирования на инциденты:
- реестры;
- Роли
- ротации.
В этом уроке вы узнаете, что такое каждый из этих столпов и какие части они играют в разработке стратегии реагирования на инциденты, которая перемещает вас дальше по пути к целям надежности.
реестры;
Важно иметь хороший план, но план бесполезен без людей, чтобы выполнить его. Таким образом, лучше всего начать с определения того, кто, как ожидается, реагировать на проблемы и как сообщить им, когда их ответ необходим.
Лучший способ решить эту задачу — создать реестр. Реестр — это список людей, назначенных в команду по вызову. Эта команда должна состоять из нескольких инженеров. Эти члены группы должны иметь знания и навыки для решения типов проблем, которые могут возникнуть в вашей среде, а также обучения в ответ на инциденты.
Однако списка имен недостаточно. Необходимо создать платформу вокруг того, кто звонит в любой момент, и то, что каждый человек должен делать. Вот где приходят роли.
Роли
Роли приводят порядок к тому, что будет хаотичным ( или, в лучшем случае, нерегламентированным) ответом. Это делается путем определения конкретных функций, которые должны быть приняты каждым человеком в определенной ситуации, и место каждого из них в "цепочке команд". Роли могут различаться по организации или даже по типу инцидента, но следующие роли обычно должны быть частью организованной группы реагирования на инциденты:
- Основной ответчик: это "точка человека", который обычно первый человек на месте происшествия; то есть первый инженер по вызову, который вызывается при возникновении инцидента.
- Вторичный ответ: это тот, кто выступает в качестве резервной копии и может выполнить шаг, если основной ответчик недоступен или если требуется вторая пара глаз.
- Эксперты по темам (SMEs): это люди, которые имеют подробные знания о конкретном аспекте ваших операций. Они там, если первичные и вторичные ответчики нуждаются в эскалации проблемы кому-то с большим опытом. Они не звонят все время, но доступны, когда их специализированные навыки необходимы. Вы должны поддерживать список SMEs в различных темах (например, база данных, интерфейсная инфраструктура, сетевая инфраструктура, веб-приложения, кибербезопасность и т. д.).
- Командир инцидента: это важная роль в крупномасштабном инциденте или сбоях, влияющих на множество различных компонентов и (или) требует координации между различными командами и системами. Командир инцидента будет человеком, который координирует много беседы и усилия по реагированию и исправлению. Командир инцидента следит за "большой картиной"; они держат вкладки на том, что происходит и кто делает то. Командир инцидента отлично подходит для обеспечения того, чтобы инженеры оставались сосредоточенными и что они работают над своими собственными усилиями по исправлению, не выполняя шаги или отменяя работы друг друга.
- Писец: роль писца заключается в том, чтобы документировать беседу вокруг инцидента максимально подробно. Обычно команды используют телефонные мосты, конференц-связь или видеочат, чтобы собраться вместе и попытаться понять, что происходит. Это, безусловно, помогает создать пространство для обсуждения. Тем не менее, нам трудно пройти и понять подробно то, что инженеры говорили и делают, если это не транскрибируется. В результате, писец является человеком, который может помочь нам документировать как можно больше, чтобы просмотреть позже. Подписка фиксирует все возможные данные; не только то, что делают члены команды, но и то, что они говорят, и даже то, что они чувствуют или испытывают.
- Координатор коммуникации: подумайте об этом человеке как "менеджер по связям с общественностью" для инцидента. Координатор коммуникации работает вместе с командиром инцидента, чтобы поделиться информацией об инциденте с теми, кто не участвует в активной работе по устранению и восстановлению после инцидента. Это может включать клиентов, отделы продаж и маркетинга, поддержку клиентов и любые другие заинтересованные лица в организации или вне организации, которые должны быть осведомлены о том, что происходит, и состояние прогресса реагирования и исправления.
ротации.
Теперь у вас есть список сотрудников команды реагирования и назначены соответствующие роли. Следующим и последним шагом является создание ротации, представляющей собой график назначения смен, в которых каждый человек доступен для вызова.
Есть много разных способов разделения на смены. Планирование смен может быть сложным стратегическим процессом. Смены не должны назначаться случайным образом; Вы должны подумать о планировании, чтобы сделать его как можно эффективнее ( и как можно приятно для членов команды).
Приведем некоторые методы планирования смен.
- 24 x 7: это смена, в которой члены команды находятся на вызове в течение нескольких дней подряд. Это простой способ распределить смены, но вы должны соблюдать осторожность и ограничивать длительность смен. Смены, превышающие три-четыре дня, могут быть вредными для общего здоровья инженерного персонала, и, таким образом, снижает надежность всей системы.
- Следите за сменами солнца: это модель смены, в которой инженеры планируют смены по вызову только в течение обычных рабочих часов, а затем отдают свою ответственность по вызову в конце своего рабочего дня другому коллеге, расположенному в другом часовом поясе.
Это лишь несколько примеров того, как можно назначать смены. Важно распределять смены таким образом, чтобы это лучше всего подходило для сотрудников вашей команды реагирования. Существует множество способов настройки смен, особенно для выходных, когда инженеры нуждаются в большей гибкости. Инженеры должны быть в состоянии легко передать свою роль кому-нибудь еще, если возникнут не связанные с работой конфликты.