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

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

И становится только хуже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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