Комитет по изменениям (CAB) — один из самых нелюбимых элементов ITSM. Инженеры его боятся, бизнес не понимает, а сам комитет часто превращается в формальность: собираются, смотрят список, ставят галочки. Или наоборот — в бюрократический фильтр, где любое изменение ждёт согласования неделями. Я видел оба крайних случая. И оба — плохо. CAB должен снижать риски, а не тормозить работу. Разберём, как это сделать. Зачем вообще нужен CAB CAB — это не «ещё одно совещание». Его задача — оценить влияние изменения на сервисы, выявить риски и принять взвешенное решение: одобрить, отклонить или отправить на доработку. Когда CAB работает правильно, он: снижает количество неудачных изменений; защищает критичные сервисы; даёт прозрачность: кто, что и когда меняет. Когда CAB работает неправильно — он становится узким горлышком, и люди начинают обходить его. А это ещё хуже, чем отсутствие CAB. Три типа изменений — и три разных подхода Главная ошибка — гнать все изменения через один комитет. Так CAB тонет в рутине, а критичные изменения ждут в очереди вместе с мелкими. Стандартные изменения — типовые, низкорисковые, заранее одобренные. Например, обновление антивирусных баз или перезагрузка сервера по регламенту. Их не нужно обсуждать на CAB — они идут по заранее утверждённой процедуре. Это разгружает комитет. Нормальные изменения — требуют оценки влияния и согласования. Это основной поток CAB: доработки, обновления, интеграции. Экстренные изменения — когда нужно действовать быстро, чтобы восстановить сервис. Для них — отдельная процедура: минимальный набор согласований, но обязательная фиксация и последующий разбор (PIR). Когда эти три типа разделены, CAB занимается тем, чем должен — нормальными изменениями, а не всем подряд. Как готовить изменение к CAB CAB не должен разбираться в деталях за вас. На вход комитет получает подготовленный пакет: Описание изменения: что и зачем меняем. Анализ влияния: какие сервисы, CI и пользователи затронуты. Здесь помогает CMDB — если связи выстроены, влияние видно сразу. Риски и план отката: что может пойти не так и как откатиться. План тестирования: как проверим, что всё работает. Критерии успеха: по каким признакам поймём, что изменение удалось. Окно выполнения: когда и на сколько. Если этого нет — изменение возвращается на доработку. Это дисциплинирует и заявителей, и команду. Роли в CAB: кто должен быть, а кто — нет Часто CAB раздувается: приглашают всех, кто «может быть полезен». В итоге — долгие обсуждения и размытая ответственность. Кто должен быть: Владелец процесса Change Management — ведёт комитет. Представитель инфраструктуры / эксплуатации. Представитель разработки — если изменение затрагивает приложения. Представитель ИБ — если есть требования безопасности. Владелец затронутого сервиса — по необходимости. Кто не должен быть: все подряд «для информации». Лучше — рассылка протокола после. Метрики CAB Без метрик CAB — это вера. Вот что стоит измерять: Доля успешных изменений (без откатов и инцидентов). Количество откатов и их причины. Среднее время согласования — не затягивает ли CAB. Доля экстренных изменений — если растёт, значит, нормальный процесс не работает. Доля изменений, вернувшихся на доработку — показатель качества подготовки. Эти метрики показывают, ускоряет CAB или тормозит. Как автоматизировать CAB CAB не обязан быть офлайн-совещанием. В ITSM-системе (SimpleOne, Jira Service Management и др.) можно: автоматически собирать пакет изменения; маршрутизировать согласование по типам изменений; фиксировать решения и план отката; вести реестр изменений и связывать с CMDB; формировать протокол и отчётность. В проекте ITAM/ITSM на SimpleOne мы выстраивали маршруты согласования изменений, чтобы стандартные изменения не попадали на комитет, а нормальные — проходили с полным пакетом. Это сократило нагрузку на CAB и ускорило согласования. Чек-лист: как внедрить CAB с нуля Разделите изменения на стандартные, нормальные и экстренные. Определите состав CAB и регламент работы. Введите обязательный пакет для норм