Андрей Шантарин

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

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

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

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

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

Отчет Service Desk видит только вторую половину инцидента

Разберем описанную ситуацию подробнее. Представим, что в 8:20 начала деградировать интеграция между внутренней системой электронного документооборота — СЭД — и оператором ЭДО. Согласованные и подписанные отгрузочные документы продолжали создаваться, но передавались все медленнее. В очереди накапливались сообщения, а статусы обработки перестали вовремя возвращаться во внутреннюю систему.

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

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

В отчете результат выглядит хорошо: первая реакция — пять минут, восстановление с момента обращения — 40 минут, SLA выполнен. Но на самом деле бизнес жил с нарушением не 40, а 85 минут. Первые 45 из них не попали в отчет Service Desk, потому что никто еще не зарегистрировал инцидент.

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

Есть и вторая «слепая зона». В 9:45 интеграционная служба снова заработала, но процесс отгрузки еще не восстановлен. Нужно обработать накопившиеся документы без потерь и дублирования, синхронизировать их статусы с внутренней системой и проверить отгрузки, затронутые инцидентом.

Кроме того, причина сбоя может остаться. Если обмен восстановили перезапуском службы, организация уменьшила продолжительность текущего инцидента, но не обязательно снизила вероятность следующего. Показатель среднего времени, необходимого для устранения сбоя (Mean Time to Repair, MTTR) может улучшаться, а надежность сервиса — нет. Значит, вопрос уже не в том, как еще быстрее обработать заявку.

Что должно сработать без звонка пользователя?

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

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

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

Затем — ограничение последствий. Для этого нужна заранее согласованная резервная процедура подготовки и передачи документов. Возможность ее применения должна определяться не во время аварии, а заранее — совместно с логистикой, юридической службой и информационной безопасностью.

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

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

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

Как применить эту модель к своим сервисам

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

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

Следующий вопрос — насколько далеко может распространиться локальная проблема. Можно ли остановить неудачное изменение до массового воздействия? Продолжит ли внутренняя система готовить и сохранять документы, если оператор ЭДО временно недоступен? Существует ли заранее согласованный порядок для отгрузок, которые нельзя отложить? Цель не в том, чтобы любой процесс бесконечно работал при любых отказах. Важно, чтобы граница допустимой деградации и действия после ее достижения не выяснялись впервые во время аварии.

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

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

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

Что можно изменить за один квартал

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

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

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

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

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

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

***

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

Автор – Андрей Шантарин, ИТ-директор завода «Уралхиммаш»