Год по ITIL: Change Management сработал, сопротивление команды - тоже

Примерно год назад мы запустили у себя нормальный Change Management - не «у нас есть папка с задачами в трекере», а процесс по ITIL v3 2011 Edition со всеми атрибутами: CAB, RFC, классификация изменений по категориям, окна обслуживания, постимплементационное ревью. Причиной послужило несколько неприятных инцидентов подряд: изменения в prod без согласования, которые приводили к падениям посреди рабочего дня. Решили, что это уже не случайность, а система.

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

Что получилось с цифрами. До внедрения доля «аварийных изменений» - тех, что применялись без RFC и вне согласованных окон - была около 40% от всего потока. Сейчас это около 8%. Не ноль, аварийные изменения всё равно случаются, и в ITIL для них есть отдельный путь - Emergency RFC и Emergency CAB. Но раньше «аварийное» по факту значило «нам лень оформлять», а теперь это реальная нештатная ситуация. Разница ощутима.

Главный вызов оказался не технический. Мы ожидали, что основная работа - это настроить трекер, придумать шаблоны RFC, договориться о времени CAB. Оказалось, что самым трудным стало изменение привычки: «я знаю, что делаю, зачем мне согласование?» Несколько опытных инженеров первые два-три месяца воспринимали процесс как недоверие к их квалификации. Это не капризы - у людей за плечами годы работы, где скорость реакции ценилась выше формализма. Объяснять пришлось не «что такое ITIL», а «почему это полезно нам, а не заказчику на бумаге».

Прорыв случился сам собой - один из тех инженеров, который громче всех сопротивлялся, на третьем месяце сам инициировал RFC на казалось бы рутинное обновление драйвера сетевой карты на сервере. В процессе оформления обнаружил, что в том же окне планировалось ещё одно изменение от другого коллеги, которое с его изменением конфликтовало. Без CAB они бы применили оба изменения одновременно и потом час разбирались бы, что пошло не так. После этого разговоров «зачем формализм» стало значительно меньше.

Где ITIL v3 работает хорошо, а где скрипит. Managed-сопровождение - хорошая почва для ITIL: клиентов несколько, инфраструктуры разные, команда одна. Без процессов изменение на контуре одного клиента рискует повлиять на соседний через общую сеть мониторинга или резервного копирования. CAB это ловит.

Хуже работает там, где изменения мелкие и частые - правки конфигов Nginx, небольшие скриптовые задачи. Для них мы ввели категорию «стандартное изменение» с упрощённым процессом: предварительно согласованный шаблон, без CAB, но с обязательной фиксацией факта и постимплементационной отметкой. Это компромисс, и в духе ITIL он вполне законный.

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

DR-контекст. Параллельно с Change Management мы в этом году занимались DR-планами - и обнаружили прямую связь. Учебное восстановление у одного из клиентов показало, что часть инфраструктурных изменений в prod просто не попала в документацию DR. Без Change Management это невидимо - изменение применили, инцидента нет, а в DR-плане осталась старая схема. RFC с описанием изменения хотя бы даёт трассируемость: что менялось, когда, кем.

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

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