Изменения без аварий: как управлять рисками в ИТ-инфраструктуре

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

Задача управления изменениями не в том, чтобы запретить рискованные работы или усложнить их согласование. Процесс нужен для другого: заранее понять, что именно изменится, какие ИТ-сервисы могут быть затронуты, кто отвечает за проведение работ и как вернуть систему в рабочее состояние, если результат окажется неудачным.

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

Какие изменения действительно нужно контролировать

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

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

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

Оценка риска до начала работ

Главная ошибка — оценивать изменение только по сложности технических действий. Простая настройка одного параметра может повлиять на десятки систем, если компонент используется несколькими сервисами.

Перед согласованием необходимо определить:

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

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

CMDB помогает увидеть последствия

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

CMDB позволяет связать изменение с конкретными конфигурационными единицами: серверами, приложениями, базами данных, сетевыми устройствами и другими объектами. Через связи между ними можно определить, какие сервисы окажутся под риском.

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

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

Когда нужен CAB

CAB — Change Advisory Board, или консультативный совет по изменениям. В него могут входить представители ИТ-подразделений, владельцы сервисов, специалисты по информационной безопасности и другие участники, чьи зоны ответственности затрагивает планируемая работа.

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

При этом не стоит отправлять на CAB каждую заявку. Типовые низкорисковые изменения должны проходить быстрее. Если совет собирается для согласования рутинных операций, сроки растут, а сам процесс перестает помогать управлять рисками.

Зачем нужен календарь изменений

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

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

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

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

План отката должен появиться до изменения

Фраза «если что-то пойдет не так, разберемся» — плохой сценарий управления изменениями.

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

Для некоторых изменений полный возврат невозможен. Например, после преобразования большого объема данных восстановление предыдущей версии может потребовать отдельной процедуры. Такие ограничения важно зафиксировать при оценке риска и учесть при выборе окна.

Как работать с аварийными изменениями

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

Ускоренная процедура не означает отсутствие контроля. Нужно зафиксировать причину срочности, ответственного, затрагиваемые объекты, план действий и доступный вариант восстановления. Согласование может выполняться ограниченным кругом специалистов, способных оперативно принять решение.

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

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

Где заканчивается изменение и начинается релиз

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

Например, новая функция приложения проходит как изменение. В релиз вместе с ней могут войти обновление базы данных, исправления ошибок, документация и другие согласованные доработки.

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

Что анализировать после внедрения

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

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

Такая статистика позволяет корректировать правила оценки риска. Если определенный тип изменений регулярно приводит к сбоям, необходимо изменить процедуру тестирования, согласования или развертывания, а не просто усиливать контроль всех операций.

Управление изменениями в ИнфраМенеджер

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

Связь с CMDB помогает оценивать потенциальное влияние до начала работ, а календарь — видеть пересечения с другими запланированными изменениями. История выполненных действий сохраняет контекст для последующего анализа инцидентов и оценки качества процесса.

8