Основы реагирования на инциденты

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

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

• Увеличение числа нарушений работы службы
• Нет эффективного метода отслеживания и реагирования на инциденты (все импровизировано и реакционный)
• Неприемлемая продолжительность решения проблемы
• Время разрешения не улучшается или становится хуже
• Сведения и состояние трудно найти
• Повторение одинаковых проблем и ошибок

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

Основы и столпы

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

Реагирование на инциденты также имеет основу. Существует три основных принципа, которые поддерживают хороший план реагирования на инциденты:

• Составы
• Роли
• Вращения

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

Составы

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

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

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

Роли

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

• основной ответственный: это "ключевой человек", который обычно первым прибивает на место происшествия; то есть первый инженер на дежурстве, которого вызывают при возникновении инцидента.
• вторичный ответчик: это тот, кто выступает в качестве резервной копии и может выполнить шаг, если основной ответитель недоступен или если требуется вторая пара глаз.
• эксперты в предметной области (SMEs): это люди, которые обладают глубокими знаниями в определённой области ваших операций. Они там, если первичным и вторичным ответчикам нужно передать проблему кому-то из экспертов. Они не звонят все время, но доступны, когда их специализированные навыки необходимы. Вы должны поддерживать список SMEs в различных темах (например, база данных, интерфейсная инфраструктура, сетевая инфраструктура, веб-приложения, кибербезопасность и т. д.).
• командир инцидента: это важная роль в крупномасштабном инциденте или сбое, который влияет на множество различных компонентов и /или требует координации между различными командами и системами. Командир инцидента будет человеком, который координирует большую часть обсуждений и деятельность по реагированию и восстановлению. Руководитель инцидента следит за "большой картиной". Они следят за тем, что происходит и кто что делает. Руководитель инцидента отлично подходит для того, чтобы инженеры оставались сосредоточенными и занимались устранением проблем, не мешая и не отменяя работу друг друга.
• Scribe: роль писца заключается в том, чтобы документировать беседу вокруг инцидента максимально подробно. Команды обычно используют телефонные мосты, конференц-звонки или видеочаты, чтобы собрать всех вместе и попытаться понять, что происходит, что, безусловно, может помочь создать пространство для беседы. Тем не менее, нам трудно разобраться в том, что инженеры говорили и делали, если это не транскрибировано. В результате писец является человеком, который может помочь нам задокументировать максимально возможное, чтобы позже его просмотреть. Писец фиксирует все доступные данные; не только действия членов команды, но и то, что они говорят, и даже то, что они чувствуют или воспринимают.
• Координатор коммуникации: можно рассматривать этого человека как "менеджера по связям с общественностью" в случае инцидента. Координатор коммуникации работает вместе с командиром инцидента, чтобы поделиться информацией об инциденте с теми, кто не участвует в активной работе по устранению и восстановлению после инцидента. Это может включать клиентов, отделы продаж и маркетинга, поддержку клиентов и любые другие заинтересованные лица в организации или вне организации, которые должны быть осведомлены о том, что происходит, и состояние прогресса реагирования и исправления.

Вращения

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

Существует множество различных способов распределения смен. Планирование смен может быть сложным стратегическим процессом. Смены не должны назначаться случайным образом; Вы должны подумать о планировании, чтобы сделать его как можно эффективнее ( и как можно приятно для членов команды).

Ниже приведены некоторые методы планирования смен:

• 24 x 7: это смена, в которой члены команды дежурят в течение нескольких дней подряд. Это простой способ распределить смены, но вы должны быть осторожны, чтобы ограничить их продолжительность. Смены, превышающие три-четыре дня, могут быть вредными для общего здоровья инженерного персонала, и, таким образом, снижает надежность всей системы.
• Следуйте за солнцем смены: это модель смены, в которой инженеры планируют свои смены по вызову только в течение обычных рабочих часов и затем передают ответственность по вызову другому коллеге, расположенному в другом часовом поясе, в конце рабочего дня.

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