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

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

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

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

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

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

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

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

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