Что такое управление изменениями (контроль изменений) и как не превратить его в тормоз

Зачем контроль изменений

Управление изменениями — это работа, которая решает, какое изменение в ИТ-услугеУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation можно провести, кто его разрешает, когда оно пройдёт и как вернуть всё назад, если не получилось. Изменение здесь — добавление, переделка или удаление чего угодно, что способно прямо или косвенно повлиять на услугу: серверы, настройки, версии программ, документация, договоры с поставщиками 8. ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 существует ради одного: пропускать как можно больше изменений и как можно реже ломать ими работающее.

Имён у практики несколько. Управлением изменениями её зовут ГОСТ Р ИСО/МЭК 20000-1 3, FitSM 4, MOF 2 и COBIT 6. В ITIL 4 имя менялось. Книга ITIL 4 Foundation 2019 года называет практику change control — контроль изменений 8. Практическое руководство 2020 года зовёт её change enablement, «содействие изменениям», и ставит целью не сдерживать изменения, а увеличивать число успешных 1. В справочнике мы держим «контроль изменений»; почему — под катом в разделе «Что входит и что рядом».

Руководство ITIL 4 формулирует цель через три действия: оценить риски, дать разрешение, вести календарь — и всё это ради увеличения числа успешных изменений 1. MOF добавляет то, ради чего практику вообще начинают: создать среду, где изменения несут наименьший риск и меньше всего задевают организацию 2.

Больше изменений и меньше риска тянут в разные стороны, и в этом вся работа. Строгий контроль каждого шага, много согласующих и план отката на любой случай дают низкий риск — и такую скорость, с которой сегодня жить нельзя 1. Отсюда правило, которое стоит запомнить раньше всех схем: уровень контроля выбирается под риск изменения, а не назначается один на все.

Практика меряется не числом остановленных изменений, а тем, сколько прошло без вреда для работающего.

Есть и то, чего практика не ставит себе целью. Руководство ITIL 4 прямо снимает привычное требование — свести все изменения организации в одну картину: когда их сотни разом, это невозможно и не нужно 1.

Когда практика работает

Практику видно по трём признакам, и ни один из них не вычитать из регламента — только увидеть в работе.

Известно, что считается изменением, а что нет. Как проверить: есть записанная политика — что находится под контролем, какие бывают категории изменений и где проходит граница крупного воздействия на потребителей. Этого требует и ГОСТ Р ИСО/МЭК 20000-1 3.

Одинаковые изменения проходят одинаково. Как проверить: для повторяющихся работ описаны шаги, и второму такому же запросу отдельное разрешение не нужно — это и есть стандартное изменение, о нём ниже: оно идёт по заранее разрешённой процедуре, пока в неё укладывается.

Разрешение даёт тот, кто понимает риск и выгоду. Книга ITIL 4 Foundation требует, чтобы каждое изменение оценивали люди, способные понять его риски и ожидаемую пользу, и разрешали до развёртывания 8. Как проверить: по любому изменению видно, кто его разрешил и на каком основании. Комитет по изменениям, который собирается раз в неделю, этому признаку тоже отвечает — вопрос лишь в том, сколько изменений он успевает пропустить.

Что входит и что рядом

Почему «контроль изменений», а не «управление изменениями»

Название практики в нашем справочнике совпадает с тем, что делает практика: она контролирует изменения, а не производит их. Работу выполняют разработчики, инженеры, поставщики — практика говорит, при каких условиях и когда это можно. Так практику называла и книга ITIL 4 Foundation — change control 8; позднее имя change enablement из руководства 2020 года по-русски выходит «содействием изменениям», и в имя практики мы его не взяли 1.

Второе основание для такого названия — русская омонимия. «Управление изменениями» одинаково называют и работу с версиями систем, и перевод людей на новые порядки. Вторая работа живёт в ORGУправление организационными изменениями, у неё другие методы и другие показатели. Разговор, где эти две работы смешаны, обычно заканчивается спором о том, кто кому подчиняется.

Что на входе и что на выходе

Из этих двух списков видно, на чём практика держится.

• Без сведений о том, что у вас есть и как связано, оценка последствий превращается в гадание.
• Без правил приоритетаПриоритизацияВыбор задач, которыми займутся первыми, когда ресурсов не хватает на все.ITIL 4, практическое руководство по управлению инцидентами нечем объяснить, почему одно изменение ждёт, а другое идёт вне очереди.

Верно и обратное: на этой практике держатся соседи. Календарь изменений нужен не столько самой практике, сколько соседям. Служба поддержки по нему предупреждает пользователей, эксплуатация планирует дежурстваДежурствоИнженерная функция: назначенный человек отвечает за реакцию на сбои в оговорённые часы, с посчитанной нагрузкой и правом на передышку.Google. Site Reliability Engineering, главы о дежурстве и о работе с прерываниями, разбор инцидентовИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами начинается с вопроса «что вчера меняли».

Три вида изменений

ITIL 4 разводит изменения по способу прохождения, а не по размеру 1.

Стандартное. Заранее разрешённое, низкого риска, полностью описанное; проводится без отдельного разрешения 1. Разрешение получает не изменение, а процедура: риск оценивают один раз, при её написании, и пересматривают, когда меняется сама процедура 1.

Нормальное. Проходит оценку и разрешение по своей модели. Разрешающий выбирается под риск: для мелкого — тот, кто способен решить быстро, для крупного — правление или его аналог 1.

Срочное. Проводится как можно быстрее: часть шагов откладывается или пропускается, разрешающий назначен заранее и доступен в любое время 1. Срочность при этом не отменяет правил и не означает неизвестности — срочные изменения тоже поддаются описанию и автоматизации 1. Книга ITIL 4 Foundation добавляет: по возможности срочное изменение проходит те же испытания и оценку, что и нормальное, а отложить допустимо разве что часть документов 8. В ГОСТ Р ИСО/МЭК 20000-1 такие изменения называются аварийными 3, у Брукса — экстренными 7.

MOF делит изменения иначе — по силе влияния на ИТ и бизнес: важные, значительные, незначительные и стандартные 2 — и даёт ориентир, который удобно повесить на стену:

В идеальном случае не менее 80% всех изменений в эксплуатации должны быть стандартными; это и есть признак зрелости 2.

Путь стандартного изменения оттуда же: оно начинается как незначительное, значительное или важное, его тестируют, развёртывают, проверяют и описывают — и только после этого оно может стать стандартным 2.

Что такое модель изменений

Модель изменений — по ITIL 4, повторяемый способ вести изменения одного типа 1. В ней записано, кто оценивает такое изменение и кто разрешает, какие шаги обязательны, а какие можно пропустить, по каким критериям результат принимают и что из этого делает автоматика 1. Модели заводят по тому, что и где меняется: по системе или технологии, по масштабу изменения, по площадке, по заказчику, по внешним требованиям — закона или отраслевого надзора 1. Три вида изменений из раздела выше различаются как раз моделью: у стандартного разрешение встроено в процедуру, у нормального его даёт названный в модели человек или группа, у срочного модель позволяет часть шагов пропустить 1.

Модели не пишутся раз и навсегда. Для их пересмотра у практики есть отдельный процесс — улучшение моделей: он разбирает изменения за период, в первую очередь неудачные, ищет, что ещё можно стандартизировать, и сообщает обновлённую модель всем, кого она касается 1. Оба процесса практики и две модели одного из них, ручная и автоматическая, разобраны в следующем разделе.

Если вы искали не это. По запросу «модели управления изменениями» приходят и за другим — за моделями перемен в организации: как провести людей через новшество, чтобы они его приняли. Такова, например, схема из восьми стадий по Коттеру, которую DMBOK разбирает в главе про организационные изменения 10. Это отдельная практика с другими методами и показателями — ORGУправление организационными изменениями. Здесь речь о моделях, по которым проходят изменения в услугах и системах.

Как это работает

Руководство ITIL 4 выделяет два процесса: ведение жизненного цикла изменения и улучшение моделей 1. Первый идёт по каждому изменению, второй — по итогам разбора или по расписанию 1. Вход в жизненный цикл — запрос на изменение: по ГОСТ Р ИСО/МЭК 20000-1 это предложение изменить сервис, его компонент или систему управления сервисами 3; по-английски request for change, отсюда сокращение RFC, которое встретится ниже у Брукса.

Цвет шага: приём, учёт, работа с обращением техническая работа решение и полномочия проверка, разбор, улучшение

К трём строкам таблицы — оценке, планированию и закрытию — есть что добавить.

Оценка отвечает на семь вопросов. Кто инициировал; какова причина; какого результата ждут; какие риски; какие ресурсы нужны; кто отвечает за реализацию; как изменение связано с другими 5. В ITIL прежней редакции этот список звался «семь R» — по первой букве английских слов raised, reason, return, risks, resources, responsible, relationship — и без ответов на него оценка влияния считалась незавершённой 9. Список короткий и работает как проверочный: изменение, у которого нет ответа на второй и третий вопросы, дальше идти не должно.

ГОСТ Р ИСО/МЭК 20000-1 добавляет к оценке денежную сторону. Решение об утверждении и приоритете принимают, взвесив риски, коммерческую выгоду, осуществимость и финансовые последствия 3. А среди последствий ГОСТ требует проверить пять направлений 3:

• что будет с уже работающими услугами;
• что будет с потребителями, пользователями и другими заинтересованными сторонами;
• как изменение заденет политики и планы, которых требует сам стандарт;
• что будет с мощностью, доступностью, непрерывностью и информационной безопасностью;
• как оно ляжет на другие запросы на изменения, релизы и планы развёртывания.

Откат планируется до работ, а не во время. Действия по отмене или исправлению неудачного изменения должны быть запланированы и по возможности испытаны 3. Испытание отката легко пропустить, а узнают о пропуске в тот момент, когда откат понадобился. Брукс здесь строже ГОСТа: по его словам, изменение без проверенного плана возврата вообще не имеет права на существование, а неудача без такого плана — признак плохо проведённой оценки риска 7.

После неудачи проводится расследование. ГОСТ требует расследовать неудачные изменения и договариваться о действиях 3, а ITIL — разбирать их отдельно и превращать выводы в поправки к моделям 1.

Два способа вести одно и то же

Руководство ITIL 4 приводит рядом две модели одного процесса — и оговаривает, что это лишь два примера из многих возможных 1.

Ручная, для нормальных изменений. Запрос приходит от инициатора, запись создаёт владелец услуги или менеджер по изменениям. Он же оценивает последствия, риски и ресурсы, при нужде привлекая экспертов. Разрешение даёт тот, кого назначила модель, планирование ведёт координатор, после завершения изменение разбирают.

Автоматическая, для типовых изменений в программах. Запросы копятся в очереди работ команды, и команда сама решает, что берёт. Отдельное разрешение не нужно: оно уже дано моделью. Планирования почти нет — работы мелкие. Контроль реализации почти целиком автоматический: проверки, тесты, контроль версий, резервные копии и восстановление. Разбирают только неудачные изменения, остальные закрываются сами после успешных проверок.

Обе модели описывают одну практику. Организация с несколькими потоками работ обычно держит их обе и подбирает модель под тип изменения, а не наоборот.

Кто разрешает изменение

Разрешающий — по ITIL 4, человек или группа, которые отвечают за оценку изменения и решают, идти ему или нет 1; в английских текстах это change authority. Дальше ITIL 4 расходится с прежней традицией.

Прежняя традиция — комитет по изменениям, change advisory board, CAB: группа представителей ИТ, бизнеса и поставщиков, которая собирается по расписанию и рассматривает накопившиеся изменения; для срочных случаев из неё выделяют сокращённый состав 5.

ITIL 4 называет вещи своими именами: такие комитеты часто становятся узким местом, вносят задержки и ограничивают пропускную способность практики 1. Рекомендация оттуда же: определить в моделях изменений, кто разрешает какой тип, и делегировать это на подходящий уровень — командам разработки, техническим экспертам, владельцам услуг и продуктов 1. Книга ITIL 4 Foundation добавляет наблюдение: в организациях, живущих быстро, разрешение обычно децентрализуют, и лучшей приметой высокой производительности оказывается взаимная проверка коллегами 8.

ITIL 4 называет три характерные роли практики — менеджер по изменениям, координатор изменений и разрешающий — и оговаривает, что это не обязательная структура: набор ролей организация определяет сама 1. Менеджер по изменениям принимает и проверяет запросы, направляет их на оценку и разрешение по модели, сообщает решения и публикует календарь. Он же разбирает итоги и улучшает модели 1. Координатор делает то же на своём участке — по типу изменений, территории или подразделению 1. Роль здесь не должность: один человек может совмещать несколько ролей, а одну роль могут делить несколько человек 1.

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

Есть и ещё один признак того, что практика перекошена в бюрократию. Руководство ITIL 4 замечает: отдельное подразделение под контроль изменений заводят в основном там, где их много и обрабатывают руками 1.

Календарь изменений

Календарём изменений пользуются больше соседи, чем сама практика. Книга ITIL 4 Foundation перечисляет, зачем он нужен: планировать изменения, сообщать о них, избегать столкновений и распределять ресурсы, а после развёртывания — давать сведения для разбора инцидентов и проблемПроблемаПричина одного или нескольких инцидентов.ITIL и для планирования улучшений 8. ГОСТ Р ИСО/МЭК 20000-1 требует сообщать всем, кого это касается, даты развёртывания и подробности 3. FitSM говорит то же самое: вести календарь изменений, получивших утверждение, с датами развёртывания и показывать его тем, кого они касаются 4.

Что делает календарь работающим:

• в нём все изменения, влияющие на пользователей, включая работы поставщиков;
• он читается без перевода: названы услуги, а не имена серверов;
• он живёт там, где на него смотрят, а не в почтовой рассылке раз в неделю;
• по нему видно совпадения: два изменения в одном месте в одну ночь — повод развести их до, а не разбираться после.

Что должно быть в записи изменения

• что меняем — услуга и её части, а не только имя системы;
• зачем — причина и ожидаемый результат 5;
• тип и модель — стандартное, нормальное, срочное 1;
• оценка — последствия, риски, нужные ресурсы 1;
• кто разрешил — имя и дата, а не «согласовано»;
• когда — плановое окно и попадание в календарь 3;
• как откатываем — план отмены и отметка о его испытании 3;
• чем закончилось — результат, отклонения, вывод для моделей 1.

Чем автоматизируется

Оговорка из того же источника: чем выше автоматизация, тем труднее охватить взглядом всё, что происходит 1. Ответ здесь не в возврате к ручному контролю, а в уменьшении размера изменений, в стандартизации и в автоматизации 1.

Как измерять

Два показателя стоит держать рядом всегда: доля успешных изменений и срок прохождения. Поодиночке каждый улучшается простым способом — первый ужесточением, второй ослаблением контроля. Вместе они показывают то, ради чего практика существует.

Отдельная работа — периодический разбор записей на тенденции: этого требует ГОСТ Р ИСО/МЭК 20000-1 3, и именно такой разбор превращает практику из пропускного пункта в источник улучшений.

У Брукса каждая метрика идёт с двумя числами: целевым значением и опасным — порогом, за которым надо вмешиваться; в приложении про управление изменениями таких метрик двенадцать 7.

У двух показателей Брукс ставит цель, равную тревоге. Срочные изменения (у Брукса — экстренные) и изменения, не давшие ожидаемого результата: и целевое, и опасное значение — по три 7. Допуска между ними нет, и это сознательно: обе величины он не считает нормальной частью работы, которую можно держать в коридоре. Три срочных изменения — уже предел, а не запас.

Ноль стоит там, где обычно ставят проценты. Простои во время изменений — цель 0 при тревоге в 6. Неудачные изменения, у которых не было плана возвращения в исходное состояние, — 0 при тревоге в 2. Рекомендации комитета, не выполненные в срок, — 0 при тревоге в 3 7. Логика простая: пропущенный план отката — не редкая неудача, а нарушение порядка, и мерить его долей значит заранее согласиться, что часть изменений пойдёт без страховки.

Три порога Брукса ложатся на показатели из таблицы выше. Изменения, выполненные вовремя (у Брукса — завершённые к назначенному сроку), — 95% при тревоге ниже 90%; изменения, вызвавшие инциденты, — 5% при тревоге в 10%; изменения без разрешения — 15 при тревоге в 30 7. Числа эти — образцы для настройки, а не отраслевая норма. Про долю вызвавших инциденты стоит помнить отдельно: в метриках эксплуатации у Брукса стоит похожий показатель — число проблем, возникших при внедрении, — и он сам предупреждает, что эти два могут перекрываться 7. Значит, границу между практиками надо договорить заранее, иначе один случай посчитают дважды.

Удовлетворённость он предлагает спрашивать по каждому запросу на изменение, а не раз в квартал у всех сразу 7. Разница тут не в форме, а в ответе. Опрос по горячему следу говорит, каково было пройти практику именно с этим изменением. Квартальный собирает общее впечатление, в котором громче всех звучит последний неудачный случай.

Зрелость контроля изменений

✕

Где ломается чаще всего

Семь мест.

Один порядок на все изменения. Настройка почтового ящика и переезд базы данных проходят одинаковый путь. Со временем люди учатся проводить мелочь мимо процесса, и практика перестаёт видеть часть изменений — ровно то, что Брукс предлагает считать метрикой «число неавторизованных изменений» 7.

Комитет как узкое место. Заседание раз в неделю, очередь на согласование, срочные изменения в обход. ITIL называет это прямо и советует делегировать разрешение по моделям 1.

Стандартных изменений нет. Всё считается нормальным, каждое проходит оценку заново. Ориентир от 80% стандартных в эксплуатации 2 в таких организациях звучит фантастикой, хотя набирается он из одних и тех же повторяющихся работ.

Откат существует на бумаге. План отмены записан, но никогда не проверялся. ГОСТ требует испытывать его по возможности 3 — эта возможность есть чаще, чем кажется.

Календарь ведут для отчёта. В нём часть изменений, названия систем вместо услуг, обновляется он раз в неделю. Пользоваться таким календарём соседние практики перестают, и совпадения ловятся постфактум.

Неудачные изменения не разбирают. Откатили, выдохнули, забыли. Требование расследовать неудачи 3 и превращать выводы в поправки к моделям 1 остаётся невыполненным, и те же изменения падают снова.

Практику или не начинают, или усложняют до неузнаваемости. MOF замечает: одни ИТ-подразделения считают процесс настолько масштабным и трудоёмким, что не берутся за него вовсе, другие усложняют его так, что в нём никто не может разобраться 2. Лекарство у MOF то же, что у ITIL 4: уровень формализации задаётся допустимым для организации риском, а не наоборот 2.

Что говорят своды

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL держит контроль изменений отдельной практикой и строит её вокруг баланса скорости и риска: модели изменений, делегированное разрешение, уменьшение размера, автоматизация 1.

ГОСТ Р ИСО/МЭК 20000-1 требует политики, категорий, критерия крупного воздействия, оценки с учётом рисков и денег, по возможности испытанного отката, сообщения дат и периодического анализа тенденций 3. Про комитеты и роли не сказано ничего — это выбор организации.

FitSM укладывается в шесть требований PR12: единообразные регистрация и классификация, свои шаги для каждого типа, оценка, утверждение, анализ после внедрения с закрытием — и календарь изменений с датами 4.

MOF связывает изменения и конфигурации в одну функцию и добавляет ориентир по доле стандартных изменений 2.

COBIT разводит две цели: BAI06 «Управление изменениями» и отдельно BAI07 «Управление передачей и приёмкой изменений» 6.

Расхождение по существу здесь одно, и оно про разрешение. Прежняя традиция строит практику вокруг комитета 5, текущая — вокруг моделей и делегирования 1. Организация, которая ссылается на своды в споре о комитете, должна знать, на какую редакцию опирается.

Где описано

Что почитать дальше

Три соседние практики, без которых эта не работает: CFGУправление конфигурациями — на чём держится оценка последствий, RLSУправление релизами — как изменения собираются в выпуски, INCУправление инцидентами — что происходит, когда изменение всё-таки сломало работающее. А если ваш вопрос был про перемены для людей, а не для систем, — ORGУправление организационными изменениями.