Когда все поломалось. Анти-кейсы и работа над ошибками
Каждый начинающий ИТ-менеджер верит в то, что можно построить надежный на 100% сервис, выстроив правильные процессы и написав всеобъемлющие регламенты. Конечно, эти мечты разбиваются о реальность. Жизнь во всем своем многообразии играет против нас.
Почему идеальных сервисов не бывает
Начинается с человеческого фактора. Ты можешь собрать базу знаний в 200+ статей. И иметь курс молодого бойца, в котором каждый специалист поддержки получает в том числе и понимание, что такое «закрытый учетный период». Однако когда пользователь со склада готовой продукции просит исправить определенный документ, потому что из-за этого по учету не хватает продукции для отгрузки, дежурный специалист находит в базе знаний именно ту статью с описанием ручной корректировки, которая с периода опытно-промышленной эксплуатации по недосмотру осталась в базе знаний и не была удалена после стабилизации системы, забывает все то, чему его учили на вводном тренинге, и спокойно перепроводит документ трехмесячной давности, заставляя финансовую службу перезакрывать подряд три периода.
Добавляем присущий всем людям оптимизм — недооценку риска и переоценку возможностей. Клиент просит провести обновление сильно устаревшей версии конфигурации 1С (три основных релиза) и одновременно перейти на новую версию платформы. Команда соглашается, поскольку впереди налоговая отчетность и новые релизы помогут ее сдать с меньшим объемом ручного труда — это хороший шаг навстречу клиенту. И вроде бы все по отдельности протестировано, но сроки сжатые, и полного финального тестирования, включая тестирование бизнес-пользователями, провести не хватает времени — и вот уже после запуска в продуктив тормозится на несколько дней процесс согласования платежей, пока «на горячую» вычищаются баги.
Следующая карта — теория вероятностей. Отличное начало поддержки второй линии для нового клиента. Фидбек от ИТ-руководителя прекрасный на протяжении первых трех месяцев, есть даже готовность написать отзыв. Но увольнение по вполне объективным причинам одновременно двух специалистов поддержки, совпавшее с приемом компанией нескольких других крупных клиентов и, как следствие, невозможностью балансировать ресурс, запускают «спираль смерти». Ухудшаются показатели SLA, и клиент начинает задавать вопросы. Новички ухудшают баланс экспертизы в команде и увеличивают долю заявок, эскалируемых на третью линию клиента — вопросы становятся интенсивнее. Оставшиеся крепкие середняки работают с перегрузками, под эмоциональным прессингом, выгорают и случаются еще увольнения. В итоге разрушается все, и клиент потерян.
Наконец, козырь — финансовые ограничения. Ты не можешь добиться стопроцентного резервирования мощностей, этого просто не выдержит никакая экономика.
Когда инциденты становятся уроками
Что же объединяет все перечисленные кейсы? Это не опыт неофитов в поддержке, а кейсы из жизни одного из ведущих поставщиков услуг поддержки сложных корпоративных 1С-решений, прошедшего сертификацию по ISO 9000 и ISO 20000, и двадцать лет потратившего на улучшение своих процессов.
Задача менеджера в поддержке очень проста: каждый день работать над тем, чтобы минимизировать вероятность возникновения сбоев, и сократить их последствия, если они все-таки произошли. Конечно, надо понимать, что тема выстраивания надежного сервиса слишком обширна, чтобы раскрыть ее в короткой заметке. Поэтому попробуем сфокусироваться только на одном аспекте — какую работу ИТ-менеджмент проводит по итогам инцидента.
Первым делом после каждого инцидента собирается critical report. Его функции и задачи:
Собрать полную фактологию сбоя (что и когда происходило, какие действия предпринимали сотрудники, какая коммуникация велась). Табличка с хронологией — самый простой и удобный инструмент для достижения следующей задачи, а именно:
- выравнять понимание по фактологии между разными сторонами (затронутый инцидентом бизнес, одна или несколько технических служб);
- выявить все возникшие в ходе развития ситуации ошибки, приведшие в итоге к инциденту или усугубившие его. Поскольку ИТ-системы и процесс их поддержки чаще всего базово зарезервированы, для инцидента обычно одной ошибки недостаточно. Так, один простой инцидент с недоступностью поддержки 24×7 из-за отключения света в здании «намотал на себя» три ошибки подрядчика и две ошибки ИТ-службы заказчика;
- сформулировать список действий, которые все участвующие стороны проведут по итогу инцидента, о чем расскажем далее;
- согласовать понимание ошибок и мероприятия между всеми техническими и бизнес-службами. Обычно это самый непростой шаг, но если предыдущие шаги проведены аккуратно и в компании налажена культура открытости (об этом в конце колонки), то процесс идет гораздо легче.
Возвращаясь к мероприятиям. Обычно они сводятся к следующим комбинациям:
- обучение, возможно повторное, людей (ИТ- и бизнес-персонала), что было проведено практически в каждом из приведенных кейсов;
- уточнение регламентов действий, как произошло в случае с отключением света;
- изменение процессов в бизнесе. Так, в кейсе со срывом закрытия были скорректированы бизнес-процессы на стороне финансовой функции — появилась карта коммуникации и формализован график;
- переоценка матрицы рисков и уточнение красных флажков. Кейс с одновременным обновлением трех релизов конфигурации и одного релиза платформы привел именно к этому;
- уточнение SLA между ИТ и бизнесом. Кейс с закрытием подсветил необходимость сделать это, поскольку до инцидента финансовая служба не подключалась к обсуждению SLA и, как следствие, не понимала его и влияние SLA на их работу;
- наконец, полный пересмотр какого-то процесса, что случилось в драматическом кейсе с развалом поддержки нового клиента. Процесс приема нового сервиса на сопровождение пришлось радикально пересмотреть и в определенных сложных случаях усилить резервами.
Важно, что ценность возникает не только в самом документе, но и в процессе его создания. Те обсуждения, что проходят в момент создания отчета, дают новую информацию о рисках, которые иначе были бы скрыты в процессе. Как банальный пример: после проникновения вируса-шифровальщика в наш периметр, высказывание «если бы не бекапы на ресурсе Х, то простой был бы значительно больше» привело к полному пересмотру стратегии резервного копирования. И такое «если бы не ..., то ...» мы за нашу двадцатилетнюю историю слышали не один раз. Эти обсуждения дают прекрасную возможность включить в critical report не только проявившиеся риски, но и те факторы, которым требуется уделить дополнительное внимание.
Легко заметить, что все описанное очень похоже на протоколы расследования авиационных катастроф и действия авиакомпаний по итогу получения этих протоколов от МАК, конечно, в заметно более миниатюрном масштабе. Что и неудивительно: отрасль с гораздо меньшими последствиями сбоев учится у более зрелой отрасли, которая кровью прошла этот путь. При этом, в отличие от авиации, по нашему мнению, создание такого отчета — задача самой ИТ-службы. Это прививает большее чувство владения процессом и ответственности. Очень хорошо также привлекать к этому старших или ведущих специалистов, которые находятся в кадровом резерве, это прекрасная практика для них. Такой подход позволяет руководству проверить их умение взять ответственность на себя, позволяет им видеть картину более широко и тренирует навыки планирования и коммуникации.
Право на ошибку
Отдельно хотелось бы написать и о том, без чего этот нормальный процесс тюнинга качества поддержки и выведения его на нужное количество «9к» надежности не будет работать — без культурных факторов.
Базовый — это толерантность к ошибкам. На первом же вводном тренинге в нашей компании, который проводится одним из топ-менеджеров, каждый новичок получает понимание, что мы работаем не идеально и это норма. Это право на ошибку мы далее подтверждаем и на разборах полетов.
Отсутствие наказаний за ошибку приводит к тому, что люди не боятся говорить правду. Это критически важно в оперативной работе по инциденту, когда нужно быстро детально разобраться в сути проблемы, чтобы не пойти по неправильному пути ее решения. Это дает возможность авторитетно и владея предметом общаться в разборе с бизнес-заказчиками, будучи уверенным в фактологии и повышая уровень доверия к ИТ-службе. Без этого не обойтись в разработке логики предотвращения подобных проблем в будущем, ведь обычно к критическому инциденту приводит не одна, а несколько ошибок, и важно вскрыть и проработать их все. Открытый разговор без вмененного негатива позволяет разобрать проблему во всех аспектах.
Терпимость к ошибкам зеркалится нетерпимостью к втиранию очков и приукрашиванию действительности. Поскольку такое поведение, в отличие от ошибки, это сознательный вред процессу, то за такое действительно можно наказывать. У нас был даже один случай увольнения руководителя за подобные систематические инциденты.
Наконец, очень хорошо, если разбор полетов становится частью работающей культуры/процесса постоянных улучшений. Когда те мероприятия, которые выработаны по итогу разбора становятся частью общего беклога улучшений процесса, проходят общую приоритизацию, по ним проводится ревью на регулярных встречах, — гораздо меньше вероятности, что что-то останется недоделанным.
Резюмируя написанное:
- идеального процесса сопровождения не существует;
- не жалейте времени и сил на качественную проработку critical report;
- культура терпимости к ошибкам помогает в улучшении процесса.
Опубликовано 03.10.2025
