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

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

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

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

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

Цена инцидента

Простои — серьёзная проблема для организаций любого размера во всех отраслях, и электронная коммерция не является исключением. Недавний опрос, проведённый компанией Information Technology Intelligence Consulting (ITIC), показал:

• 98% организаций заявили, что один час простоя стоит более 100 000 долларов;
• 60% заявили, что один час простоя обходится им более чем в 300 000 долларов;
• 33% заявили, что один час простоя обходится им в сумму от 1 до 5 миллионов долларов.

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

• Разочарованные клиенты;
• Плохие отзывы;
• Потеря рекламного бюджета;
• Множество новых заявок в службу поддержки;
• Антиреклама;
• Сокращение лояльности.

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

Проблема или инцидент?

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

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

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

Что такое управление инцидентами?

Управление инцидентами включает в себя действия по выявлению, анализу и устранению технических сбоев в работе бизнеса. Другими распространёнными терминами для обозначения серьёзности угроз являются: «Управление серьёзными инцидентами» или «Управление критическими инцидентами».

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

• Планирование

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

• Сотрудничество

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

• Протоколирование

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

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

Приоритизация

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

• Инциденты с низким приоритетом

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

• Инциденты среднего приоритета

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

• Высокоприоритетные инциденты

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

Жизненный цикл инцидента

Каждый инцидент, с которым сталкивается команда поддержки, проходит одинаковый «жизненный цикл инцидента». Этот процесс включает набор из шести этапов: «Новый», «Назначен», «В процессе», «Приостановлен», «Решён» и «Закрыт».

Новый: Данный статус инцидента подразумевает, что служба поддержки получила информацию об инциденте, но ещё не передала заявку на исправление.

Назначен: Статус подразумевает, что инцидент был назначен исполнителю.

В процессе: Исполнитель команды поддержки работает над разрешением назначенного ему инцидента.

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

Решён: Статус подразумевает, что служба поддержки подтверждает разрешение инцидента и обнуление таймеров SLA до исходных значений.

Закрыто: На стороне инициатора инцидента получено подтверждение об устранении инцидента, никаких дальнейших действий не требуется.

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

Группа управления инцидентами

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

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

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

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

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

Определение основной проблемы

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

• Перегрузка

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

• Спам

Если пользователи перегружают сервер спамом (к примеру, большой объём публикаций отзывов от гостевых/анонимных пользователей), они могут создать избыточный «шум», который приведет к сбою системы.

• Скачкообразное повторение запросов

Если пользователи не могут получить доступ к сервису и постоянно повторяют попытку, (например, переход в корзину), частые повторные запросы могут привести к перегрузке системы.

• Плохая система обмена данными

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

• Недостатки масштабируемости

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

• Незапланированные работы/изменения

Такое происходит, когда один из сервисов/партнёров вдруг начинает проводить технические работы на своей стороне, предварительно никого не уведомив. Аналогичная ситуация возникает, когда сторонний сервис (к примеру, служба доставки) без уведомления внезапно обновляет API и интеграция перестаёт работать.

Эскалация инцидента

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

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

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

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

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

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

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

Процесс управления инцидентами (ключевые шаги по разрешению инцидентов)

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

• Идентификация: Первоначальное обнаружение инцидента.

• Ведение журнала: Фиксация информации об инциденте, включая информацию об инициаторе/канале связи, дату и время инцидента, а также другие подробности инцидента; обновление информации о статусах инцидентов.

• Категоризация: идентификация принадлежности инцидента к соответствующей категории и подкатегории.

• Приоритизация: оценка инцидента и его влияния на бизнес и ключевых заинтересованных лиц.

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

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

• Разрешение: Выполнение необходимых действий и процессов для разрешения инцидента.

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

Моделирование инцидентов

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

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

По сути, наличие модели или «шаблона» помогает командам по управлению инцидентами понять, как полностью управлять влиянием инцидента на бизнес-операции и соответствовать требованиям SLA.

Заключение

Всего один инцидент может поставить под угрозу всю компанию и её бизнес.

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

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