Описание ключевых процессов управления ИТ-услугами

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

Понятие инцидента

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

Среди основных типов событий присутствуют:

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

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

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

Место управления инцидентами в общей системе информационной безопасности

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

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

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

Особенности управления событиями безопасности

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

Управление инцидентами информационной безопасности основано на следующих действиях:

• определение. В организации отсутствует методика выявления и классификации инцидентов, описание их основных параметров, поэтому сотрудники встают перед необходимостью или самостоятельно определять критерии события, или игнорировать его. Вход в сеть под аккаунтом другого сотрудника, согласно стандартам, является инцидентом информационной безопасности, но он не будет зафиксирован в журнале, так как сотрудники считают такое поведение стандартным и дозволенным, особенно в условиях дефицита кадровых ресурсов;
• оповещение о возникновении. Даже если какое-либо событие может быть определено согласно принятым в организации методикам или личному мнению сотрудника как инцидент, чаще всего в организации не разработаны стандарты и маршруты оповещения о таких событиях. Даже если кем-то будет выявлен факт копирования документов, относящихся к коммерческой тайне, сотрудник встанет в тупик перед вопросом, кто именно и в какой форме должен быть оповещен об этом инциденте: его руководитель, служба безопасности или иное лицо;
• регистрация. Эта часть стандартов является наиболее невыполнимой для российских компаний, инциденты не идентифицируются, соответственно, не фиксируются. Отсутствует практика заведения регистров учета, в которых бы фиксировались значимые события, что впоследствии давало бы материал для их анализа и прогноза возможных атак;
• устранение причин и последствий. Любой инцидент вызывает определенные следы и последствия, которые, с одной стороны, могут мешать деятельности компании, с другой – служат материалом для проведения расследования причин его возникновения. Отсутствие регламентов устранения последствий может привести как к накоплению ошибок, так и к полному уничтожению доказательственной базы, позволяющей выявить виновника произошедшей ситуации. Любые срочные меры, предпринимаемые для восстановления стабильности, могут случайно или намеренно уничтожить следы проникновения в базу данных;
• меры реагирования на инциденты. В ряде случаев возникновение инцидента может потребовать срочных мер реагирования, например, отключения компьютера от сети, приостановки передачи информации, установки контакта с провайдером. Должны быть определены органы и должностные лица, ответственные за разработку механизма реагирования и его оперативную реализацию;
• расследование. Полномочия по расследованию должны быть переданы из ведения IT-службы в компетенцию служб безопасности. В рамках расследования должны быть изучены журналы учета, проанализированы действия всех пользователей и администраторов, которые имели доступ к системам в период возникновения чрезвычайной ситуации. Расследование должно стать одним из основных элементов управления инцидентами. На практике в российских компаниях от реализации этого этапа отказываются, ограничиваясь устранениями последствий произошедшего события. При необходимости расследование должно производиться с привлечением оперативно-следственных органов;
• реализация превентивных мер. В большинстве случаев инциденты не являются единичными, их возникновение свидетельствует о том, что в системе ИБ возникла брешь и аналогичные случаи будут повторяться. Во избежание этих рисков необходимо по результатам расследования подготовить протокол или акт комиссии, в котором определить, какие именно меры должны быть применены для предотвращения аналогичных ситуаций. Кроме того, применяются определенные меры дисциплинарной ответственности, предусмотренные Трудовым кодексом и внутренними регламентами;
• аналитика. Все события, нарушающие регламентированные процессы и могущие быть квалифицированы в качестве инцидентов информационной безопасности, должны стать основой для анализа, который поможет определить их характер, проявить системность и выработать рекомендации для совершенствования системы ИБ, действующей в компании.

Управление инцидентами в безопасности с помощью «СёрчИнформ КИБ» упрощает работу ИБ-службы компании: система экстренно реагирует на нарушения политик безопасности и снабжает ИБ-специалиста большой доказательной базой.

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

Процедура управления

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

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

В структуре документа, оформляемого в виде положения или регламента, должны выделяться следующие подразделы:

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

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

Устранение причин и последствий события, его расследование

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

На этапе расследования от должностных лиц организации требуется:

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

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

Как расследовать утечки информации с помощью DLP-системы? Читать.

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

Непосредственно после выявления инцидента предпринимаются оперативные меры по устранению его последствий. На следующем этапе необходим анализ причин его возникновения и совершение комплекса действий, направленных на предотвращение возможного повторения аналогичного события. Сегодня основным регламентирующим документом, предлагающим стандарты реакции на инциденты, стал ISO/IEC 27000:2016, это последняя версия совместной разработки ISO и Энергетической комиссии. В России на основе более ранних версий ISO/IEC разработаны ГОСТы. В рамках ISO/IEC 27000:2016 предлагается создать специальную службу поддержки, Service Desk, на которую должны быть возложены функции управления инцидентами.

Аудит соблюдения стандартов

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

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

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

ПОПРОБУЙТЕ «СЁРЧИНФОРМ КИБ»!

Полнофункциональное ПО без ограничений по пользователям и функциональности.

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

Чем обусловливается необходимость принятия регламента

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

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

Структура регламента

Разрабатывая регламент информационной безопасности, каждая компания учитывает особенности процессов производства и информационной инфраструктуры, архитектуры системы. У банка, внутренняя система которого не может иметь выход в Интернет и правила работы сотрудников которого устанавливаются стандартами Центрального банка РФ, и теплоэлектростанции, где основная задача информационной системы – поддержание безопасности, по-разному будет устроена модель взаимодействия сотрудников с рабочими станциями и сетями. Будут различаться и регламенты. Для небольшой фирмы, работающей в торговле или сфере услуг, разрабатываемый ими регламент информационной безопасности будет иметь стандартизированную структуру.

Общие положения и основные обязанности пользователя

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

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

Среди иных возможных обязанностей сотрудников компаний и работников IT-подразделений:

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

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

Обеспечение антивирусной безопасности

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

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

В этом разделе необходимо рассмотреть:

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

Безопасность персональных данных

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

В разделе могут содержаться следующие положения:

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

Работа в сети Интернет

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

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

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

Иные нормы

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

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

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

Процесс управления инцидентами в DevOps и SRE

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

An advantage of the “you build it, you run it” approach is that it offers the flexibility agile teams need, but it can also obscure who is responsible for what and when. DevOps teams can be comfortable—and successful—with less structured development processes. But it’s best to standardize on a core set of processes for incident management so there is no question how to respond in the heat of an incident, and so you can track issues and report how they’re resolved.

Три принципа управления инцидентами в командах DevOps

• Дежурство по очереди. Обычно команды DevOps не назначают конкретных членов команды на разрешение конфликтов, а создают график дежурств и распределяют его между членами команды.
• Кто разработал, тот лучше всего подходит для внесения исправлений. Основная идея принципа «кто разработал, тот и запускает» заключается в том, что люди, которые больше знакомы с сервисом (разработчики), лучше всего подходят для исправления перебоев в его работе.
• Разрабатывайте быстро, но не забывайте сообщать о прогрессе. Когда разработчики понимают, что они и их команда теряют время при сбое в работе, появляется стимул писать более качественный код.

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

В нашем Справочнике по управлению инцидентами мы описываем подход к управлению инцидентами, подходящий именно командам DevOps.

Управление инцидентами для высокоскоростных команд

Для участников команд ИТ и эксплуатации инциденты всегда были суровой реальностью. Сегодня методы информирования об инцидентах осваивают в том числе команды DevOps и службы поддержки клиентов.

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

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

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

Далее приведены наши рекомендации по информированию об инцидентах. Из них вы узнаете:

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

Кому нужно информирование об инциденте?

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

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

Подготовка к информированию об инцидентах

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

Ваше понимание инцидента

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

Какие бы пороговые значения вы ни установили для каждого уровня опасности инцидента, важно определить четкие критерии (лучше всего с привязкой к измеримому показателю). Если вы присваиваете инциденту уровень опасности 1, важно, чтобы любой участник вашей команды четко понимал его особенности.

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

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

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

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

• Специальная страница статусов
• Встроенный статус
• Эл. почта
• Рабочий чат
• Социальные сети
• SMS

Специальная страница статусов

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

Встроенный статус

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

Почта

Избавьте сотрудников и агентов от необходимости переключаться между приложениями и устраните нехватку информации с помощью Halp. Halp позволяет Jira Service Management синхронизировать обсуждения в Slack или Microsoft Teams с заявками. Эффективное взаимодействие между популярными инструментами чата и службой поддержки помогает четко понять контекст проблемы и ускорить ее решение.

Социальные сети

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

Настраивайте оповещения и сообщения с учетом аудитории

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

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

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

Подготовка шаблонов сообщений об инцидентах и отказах

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

Заранее согласуйте объявление с менеджерами и сохраните его в шаблон. Так вы легко дополните его необходимой информацией и сможете выпустить в тот же день, когда произойдет инцидент.

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

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

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

Профессиональное управление общением

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

Пролог. Централизованное обсуждение во внутренней команде

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

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

Часть 1. Первое сообщение

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

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

Часть 2. Регулярные обновления во время инцидента

Крайне важно сообщать информацию в ходе инцидента.

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

Автор книги Google Site Reliability Engineering о роли ведущего специалиста по взаимодействию с клиентами пишет следующее.

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

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

Обязательно наладьте общение с пострадавшими пользователями и другими заинтересованными сторонами. Информируйте пользователей о ситуации через заранее определенные каналы. Можно разместить оповещение из Statuspage на главной странице, чтобы клиенты видели, что команда знает о проблеме. Это сэкономит время агентов, избавив их от лишней работы. Держите клиентов в курсе событий, используя несколько каналов связи: SMS, электронную почту и push-уведомления на мобильные устройства.

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

Часть 3. Разрешение, отчет о разборе инцидента, дальнейшие действия

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

Приведем выдержку из этой публикации.

Костяк отчета о разборе инцидента состоит из следующих простых частей.

• Признайте наличие проблемы, проявите сочувствие к тем, кого затронул инцидент, и принесите извинения.
• Объясните, что пошло не так и почему.
• Объясните, что было сделано для разрешения инцидента и предотвращения повторных инцидентов.
• Признайте наличие проблемы, проявите сочувствие и принесите извинения еще раз.

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

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

Изучайте информирование об инцидентах с помощью Statuspage

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

Читать учебное руководство

Шаблоны и примеры информирования об инцидентах

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