ИТ‑инцидент как проверка зрелости бизнеса

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

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

Какие бывают инциденты и как они отражаются на бизнесе

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

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

Второй тип связан с доступностью: ломается критичный внутренний сервис, клиенты не могут пользоваться привычными каналами. «Упали» интернет-банк или мобильное приложение, не работает личный кабинет, завис сайт с заказами, недоступны кассы. Для имиджа это самый болезненный сценарий, так как пользователи практически не готовы терпеть такие сбои. Им трудно принять объяснение «техника иногда ломается», особенно когда речь о базовых ежедневных сервисах банка, страховой, маркетплейса. Это крайне важно для федеральных сервисов и ресурсов: проблему воспринимают как личную: «почему мой сервис, которым я пользуюсь каждый день, вдруг не работает».

Коммуникация при инциденте: принципы и роли

Правильно выстроенная коммуникация не менее значима, чем скорость самого «ремонта». Без плана начинается хаос: руководители и сотрудники дают разные комментарии, внутренние письма «утекают» в мессенджеры и СМИ, вы теряете контроль, а негатив разрастается быстрее, чем идут технические работы. План коммуникации при инциденте должен соблюдаться так же серьезно, как план аварийного восстановления инфраструктуры.

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

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

Что и как говорить клиентам

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

Что именно не работает сейчас? Это затрагивает все операции конкретного клиента или только их часть? Сколько примерно продлится ограничение? Что компания делает прямо сейчас, чтобы устранить проблему? Какие доступны альтернативные способы совершить важные операции?

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

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

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

Коммуникация с партнерами и корпоративными клиентами

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

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

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

Коммуникация с сотрудниками: внутренний контур

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

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

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

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

Внутренняя работа ИТ‑команды: инструменты и роли

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

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

Отдельный вопрос – культура работы с ошибками. По большей части причина – человеческий фактор: не туда нажали, неверно настроили параметр, пропустили предупреждение.

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

В итоге компания тратит много лишнего времени на расследование того, что можно было бы узнать в первые минуты, и может лишиться сотен миллионов из-за простоя. Концепция blameless culture предлагает иной подход. Фокус смещается с поиска персонального виновного на выявление корневой причины и улучшение системы. Признание своей ошибки воспринимается как профессиональный поступок, а не повод для публичной порки, и человек, допустив ошибку, гораздо быстрее выходит на связь и помогает все исправить. Также важно делать работу над ошибками – post-mortem: исследовать инциденты, чтобы они не повторялись.

Как считать деньги: базовые подходы к оценке ущерба от инцидента

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

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

Самый простой способ приблизительно оценить ущерб – рассчитать стоимость минуты или часа работы: годовая выручка делится на 365 дней, потом – на 24 часа, затем – на 60 минут. Так можно примерно понять, сколько вы зарабатываете в единицу времени, если распределение более-менее равномерное. Эта методика понятна финансистам и топ-менеджерам, ее легко встроить в риск-модели. Но здесь есть важные ограничения, о которых нельзя забывать.

Более продвинутый подход: учет сезонности и поведенческих данных

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

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

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

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

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

Сведение всего вместе: как выстроить управленческий контур

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

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

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

Заключение

ИТ-инцидент в современном мире – это не вопрос «сломался ли сервер», а комплексная проверка зрелости компании. Как быстро она замечает и признает проблему, насколько честно и понятно говорит с клиентами, партнерами и сотрудниками, умеет ли считать деньги и соотносить риски с вложениями.

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

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

Статью подготовил Илья Захаров, эксперт, директор департамента разработки средств мониторинга «Группы Астра».