Root cause нашли, но проблемы только начинаются: как работает problem management на аутсорсе
Раз в неделю выходит из строя один и тот же сервис. Администратор перезапускает его, пользователи снова получают доступ к системе, а инцидент закрывают. Через несколько месяцев авария становится привычной частью эксплуатации: команда уже знает последовательность действий, а бизнес - сколько времени придется ждать восстановления.
Такой подход может поддерживать сервис "на плаву", но не устраняет саму неисправность. Управление проблемами - problem management - начинается с вопроса: почему сбой повторяется и что нужно изменить, чтобы он больше не возникал?
Для сервисного провайдера это естественное продолжение управления инцидентами. Если однотипные обращения появляются регулярно, команда должна перейти от восстановления работоспособности к поиску и устранению первопричины. Однако в условиях аутсорсинга найти root cause - только половина задачи. Вторая часть сложнее: понять, кто способен устранить проблему и как добиться изменений, если причина находится за пределами зоны прямого контроля подрядчика.
Неисправность может быть связана с продуктом вендора, устаревшей системой заказчика, особенностями архитектуры или работой другой подрядной организации. Внешний инженер не всегда может самостоятельно внести исправления, но это не означает, что проблема обречена на повторение. Можно подготовить доказательную базу, предложить обходное решение, согласовать доработку с владельцем системы или инициировать изменения у производителя.
На практике аутсорсинг problem management требует не только технической экспертизы, но и зрелого взаимодействия между всеми участниками процесса. Ниже - несколько историй, показывающих, почему после обнаружения причины работа иногда только начинается.
Когда проблема была в структуре базы данных
Один из заказчиков - крупный облачный провайдер, предоставляющий резервное копирование как сервис, BaaS (Backup as a Service). Решение построено на базе Veeam. У заказчика есть собственная опытная команда, а специалисты интегратора подключаются к наиболее сложным случаям, требующим глубокого знания продукта и смежных технологий.
Инфраструктура обслуживает тысячи клиентов и включает десятки отдельных инсталляций. В некоторых тенантах количество точек восстановления достигает сотен тысяч. По мере роста объема данных Veeam Service Provider Console стала работать все медленнее: интерфейс долго загружался, периодически зависал и завершал работу с ошибками.
Для администраторов резервного копирования это означало потерю основного инструмента контроля. Они не могли оперативно проверить, завершились ли задания, созданы ли копии и находится ли сервис в штатном состоянии. Временным решением была очистка накопившихся сессий. После нее консоль оживала, но проблема возвращалась, когда база снова заполнялась.
Повторяющийся сбой стал поводом запустить полноценный анализ первопричин инцидентов. Поскольку Veeam использует Microsoft SQL Server, к расследованию подключили экспертов по этой СУБД. Совместная работа разных специалистов позволила посмотреть на ситуацию не только со стороны прикладного продукта, но и на уровне хранения данных и выполнения запросов.
Узкое место обнаружили в схеме базы. В таблице `[dbo].[C.BObjects]` отсутствовал некластеризованный индекс по полю `id` с включенным столбцом `viobject_type`. Из-за этого запросы каждый раз просматривали всю таблицу объектов резервного копирования. Чем больше становился массив данных, тем дольше выполнялись операции - вплоть до полной остановки интерфейса.
Специалисты создали индекс на уровне СУБД, после чего заказчик добавил его в рабочую базу. Консоль вернулась к нормальной скорости, повторные зависания прекратились, а ручная очистка сессий больше не потребовалась. Формально первопричина относилась к продукту вендора, но ждать исправления в новом релизе не пришлось: проблему устранили в текущей конфигурации.
Этот пример хорошо показывает, что управление проблемами ITSM не должно ограничиваться регистрацией RCA-документа. Важно довести расследование до практического результата: изменения в конфигурации, понятного плана действий или согласованного решения с владельцем продукта.
Почему аутсорсеру невыгодны постоянные сбои
Иногда высказывается предположение, что подрядчику выгодно поддерживать постоянный поток аварий: чем больше инцидентов, тем больше оплачиваемых работ. Такая логика кажется понятной, но не учитывает устройство большинства сервисных контрактов и реальные риски для исполнителя.
Обычно применяются две основные модели. Первая - Time & Material. Заказчик приобретает определенный объем часов, например 500 часов в год, и использует их для разных задач: расследований RCA, аудитов, настройки систем, внедрения изменений и устранения сложных неисправностей.
При этом стороны заранее определяют, как распоряжаться неиспользованным объемом. По мере работы команда все глубже понимает ИТ-ландшафт клиента и может предложить полезные инициативы: оптимизировать мониторинг, устранить технический долг, обновить документацию или провести профилактическое обследование. В такой модели подрядчику выгоднее не количество аварий, а ценность результата и доверие заказчика.
Вторая распространенная схема - фиксированная плата за сервис с установленными уровнями качества и доступности. Здесь повторяющиеся инциденты, наоборот, создают дополнительные риски: растет нагрузка на инженеров, ухудшаются показатели SLA, появляются претензии и необходимость компенсировать нарушения. Поэтому зрелый поставщик стремится сокращать число повторных обращений, а не поддерживать их искусственно.
Именно поэтому услуги ITSM аутсорсинг включают не только обработку заявок, но и профилактическую работу: выявление типовых отказов, анализ тенденций, контроль известных ошибок, управление изменениями и оценку технического долга.
Что делать, если первопричина находится у другого участника
Второй сценарий сложнее: причина найдена, но исправить ее напрямую невозможно. Например, ошибка обнаружена в программном обеспечении производителя, а обновление еще не выпущено. Или неисправность связана с системой, которую сопровождает другая компания.
В этом случае problem manager должен разделить проблему на несколько управляемых частей. Сначала фиксируется подтвержденная причина и собираются доказательства: логи, временные метки, результаты тестов, описание воспроизводимости и влияние на бизнес. Затем определяется временный обходной путь, который снижает вероятность повторного сбоя или сокращает время восстановления.
После этого формируется обращение к владельцу компонента. Хорошо подготовленный кейс с конкретными техническими данными значительно повышает шанс, что вендор или другой подрядчик быстро примет проблему в работу. Одновременно важно определить ответственных, сроки и критерии готовности исправления.
Если окончательное устранение невозможно в приемлемые сроки, проблему переводят в режим контролируемого риска. В базе знаний описывают симптомы, последовательность восстановления, ограничения обходного решения и условия, при которых требуется эскалация. Это не полноценное устранение причины, но гораздо более зрелый подход, чем каждый раз начинать расследование заново.
Когда проблему сознательно не устраняют
Бывают ситуации, в которых исправление технически возможно, но экономически или организационно неоправданно. Например, система близка к выводу из эксплуатации, миграция уже запланирована, а стоимость изменений превышает потенциальный ущерб от редких отказов.
В таком случае решение не должно выглядеть как игнорирование проблемы. Ее регистрируют, оценивают риски, фиксируют принятое решение и назначают условия пересмотра. Владелец бизнеса должен понимать, почему команда не устраняет первопричину сейчас, какие последствия допустимы и какой план предусмотрен при ухудшении ситуации.
Это важное отличие зрелого процесса от обычного "закрытия заявки". Иногда лучший результат управления проблемой - не дорогостоящая доработка, а осознанное принятие риска с понятными мерами контроля.
Как понять, работает ли problem management
О зрелости процесса говорят не количество созданных RCA-отчетов, а измеримые изменения в эксплуатации. Полезно отслеживать долю повторных инцидентов, среднее время устранения известных ошибок, число проблем без владельца, сроки реализации корректирующих действий и количество аварий, предотвращенных благодаря профилактическим мерам.
Отдельно стоит проверять качество базы знаний. Если после расследования инженер все равно тратит часы на поиск контекста, значит, результаты problem management не встроены в повседневную работу поддержки.
Для компаний, выбирающих управление ИТ-инфраструктурой на аутсорсе, важно заранее выяснить, входит ли в услугу полноценное управление проблемами. Нужно уточнить, кто инициирует расследования, как определяется приоритет, кто согласует изменения, каким образом взаимодействуют с вендорами и что происходит с проблемами, которые нельзя устранить сразу.
В конечном счете аутсорсинг не снимает с заказчика ответственности за решения, но позволяет получить доступ к более широкому набору компетенций. В крупных сервисных командах можно быстро подключить специалистов по базам данных, сетям, виртуализации, безопасности и конкретным продуктам. Именно такая связка помогает перейти от бесконечного перезапуска сервисов к устранению причин и контролируемому снижению рисков. Подробный разбор подходов к problem management и практических сценариев доступен в материале об управлении проблемами в ITSM на аутсорсе.