Как мы внедряли Change Management по ITIL v3: RFC, CAB и три месяца боли

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

ITIL v3 у них уже лежал на полке в виде книжек, несколько сотрудников прошли Foundation. Но между «знаем теорию» и «работает в пятницу вечером» - дистанция ощутимая.

С чего начали

Первым делом разобрались, что именно считать изменением. Это звучит просто, но на практике половина споров на старте - именно об этом. Обновить антивирусные базы - это изменение? А добавить пользователя в группу AD? Мы договорились о трёх категориях:

• Стандартные - повторяющиеся, заранее согласованные действия с известным результатом и низким риском. Выполняются по чеклисту без RFC.
• Нормальные - всё, что не стандартное и не экстренное. Требуют RFC, проходят через CAB.
• Экстренные - что-то сломалось и надо чинить прямо сейчас. RFC оформляется постфактум в течение 24 часов.

RFC - Request for Change - сделали простой формой в их внутренней тикет-системе. Обязательные поля: что меняем, на каком оборудовании/системе, время окна, план отката, кто проверяет результат.

CAB по пятницам

Комитет по изменениям - Change Advisory Board - собирается раз в неделю, по пятницам в 11:00. На встречу приходят: руководитель ИТ со стороны клиента, наш инженер, в зависимости от недели - представители бизнеса или кого-то из смежных служб.

Смотрим RFC на следующую неделю: обсуждаем риски, проверяем, что окно выбрано адекватно (никто не выкатывает критическое обновление в понедельник утром), убеждаемся, что план отката реальный, а не «в крайнем случае снесём и переустановим».

Первые три встречи были тяжёлые. Инженеры воспринимали CAB как бюрократию, которая мешает работать. Один из них прямо сказал: «я за пятнадцать минут делаю то, что вы час обсуждаете». Это не неправда - обсуждение занимает время. Но это не аргумент против процесса, это аргумент за качество подготовки RFC.

Мы сделали шаблон RFC чуть подробнее в части отката - не «откатим», а «откатим так: конкретные шаги, время на откат, кто принимает решение об откате». Это и встречи ускорило, и инженеров заставило думать заранее.

CMDB - отдельная история

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

Инвентаризацию тянули частично из мониторинга - у них уже был Nagios с описанием хостов, - частично вносили руками. Связи между элементами - «этот сервер обслуживает вот эти сервисы» - документировали по ходу работы над RFC. Каждый раз, когда в RFC появлялась конфигурационная единица, которой не было в CMDB, добавляли туда. Через два месяца критичная часть инфраструктуры была покрыта.

Что получилось через три месяца

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

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

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

Пока что CAB по пятницам - это сорок минут, которые стоят своего времени.