Планирование отката релиза

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

На одном из курсов ITIL RCV (Release, Control and Validation), был затронут интересный и жизненный вопрос. Почему в момент развёртывания релиза при появлении каких-либо проблем никто не знает, что нужно делать, а сама деятельность превращается в беготню?  Вроде бы при проектировании услуги вместе с остальной документацией должен был быть разработан план отката, и при планировании развёртывания должны были предусмотреть все варианты. Но почему-то этого не было сделано.

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

Полное отсутствие плана отката, либо его представление в виде шаблона без детализации. Отсутствие его содержательной части («В каком случае?», «Куда бежим?» и «Как делаем?») в головах сотрудников, ответственных за развёртывание.

Недоступность авторизующих лиц, ведь для ответа на вопрос «В каком случае начинаем работу по пунктам плана отката?» нам нужен триггер. И желательно — с необходимыми полномочиями. Тот самый предводитель, способный взять на себя ответственность, принять управленческое решение, вмешаться при появлении критичных отклонений.

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

Отсутствие тестирования плана отката. Когда мы учимся ходить, то, сделав первые шаги, с каждым разом проходя все дальше и дальше, мы оттачиваем это умение на ежедневной основе. Походка формируется на всю жизнь. В случае информационных технологий закрепления «навсегда» не происходит. Ответ на вопрос «Как делаем?» сегодня может не совпадать с ответом на тот же вопрос вчера.

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

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

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Release Control and Validation

Учебный курс: преобразование и контроль ИТ-услуг, управление изменениями, релизами и конфигурациями, а также построение CMDB — в ITIL и на практике.
 

Узнайте больше!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ЯНВ
29