Управление изменениями с SCSM 2010. Часть 1. Введение
Поскольку в SCSM я отвечаю за решение для автоматизации процесса Change Management, то и рассказывать я буду больше всего именно о нём. Начну пожалуй, с общих организационных вопросов. Я не хочу слишком часто ссылаться на ITIL или MOF, поэтому описание это будет … скажем так: с точки зрения здравого смысла. Моего здравого смысла :-)
Для начала приведу простой пример из разряда ИТ-шных баек.
В одной крупной российской организации работал (и работает) очень опытный сетевой администратор А. Как-то ему нужно было произвести “перекоммутацию сетевых портов на сетевом устройстве”, а проще - вынуть провод из одного порта коммутатора, и переставить его в другой. В назначенное время А. идет в серверную, делает там что-то, возвращается на место …. Тут же взвывает система мониторинга, и минут через 5 на хелпдеск идут звонки пользователей о том, что сеть “лежит”. А. клянется-божится, что только вынул “назначенный провод”, … передумал, и воткнул его обратно, ничего не изменив. Вся ИТ-служба встает на уши, пытаясь обнаружить неисправность … В конце-концов, А. все-таки пошел в серверную и вернулся с виноватым видом: “Представляешь, я вынул провод, в это время меня кто-то окликнул, я обернулся, и одновременно, не глядя, ткнул этим проводом на прежнее место, и … попал в соседний порт!”… Вернул провод назад – все заработало.
Какие выводы можно сделать из этой ситуации?
- “У нас комендантский час”. Нечего проводить эксперименты и сами изменения на рабочей сети в рабочее время.
- “Покажите ваш мандат”. У потенциально опасных изменений должен быть утвержденный пошаговый план внесения изменений и отката назад в случае возникновения нештатных ситуаций.
- “Тренируйтесь на кошках”. Тестирования никто не отменял. Тестирования плана отката – в том числе.
- “Пантомима”. Перед внесением изменения неплохо провести тренировку с имитацией всех действий, в том числе проверку, все ли провода, гаечки-винтики, огнетушители-противогазы на месте :-) Забавная должна быть картина, не правда ли?
- “Правило четырех глаз”. Вносить такие изменения должны два человека. Один зачитывает очередной шаг из плана, второй его выполняет, первый контролирует результат. Если все нормально – переходят к следующему шагу, если нет – переходят на план отката.
- “Разбор полетов”, наказание невиновных и поощрение непричастных – обязателен для существенных изменений.
Конечно, такие действия для многих организаций выглядят довольно экстремальными. Но там, где от работоспособности ИТ-систем серьезно зависят доходы компании, а в некоторых случаях и жизни людей, дисциплина управления изменениями намного жестче. В этом цикле статей про Change Management в SCSM я попытаюсь использовать в качестве примера некую среднестатистическую организацию, не эксплуатирующую ядерные реакторы или оборудование для операционных в госпиталях, но тем не менее серьезно опирающуюся на ИТ в своей ежедневной деятельности.
Итак, зачем нужен процесс Change Management?
- Чтобы отфильтровать ненужные изменения
- Чтобы сделать процедуру внесения нужных изменений эффективной и безопасной.
1. Фильтрация ненужных изменений.
Профессия системного администратора – очень интересная! Так много всего хочется попробовать! А тут компанейские сервера, сетевые устройства, очень полезные книжки, интернет-форумы и блоги, которые только и говорят: “Измени настройки, и будет вам счастье!!!”. Спасибо, такого счастья вашей организации, скорее всего не надо. Изменения, которые не дают существенного улучшения в работе ИТ-систем для их пользователей, либо изменения, несущие неоправданный риск, скорее всего не должны вноситься. И первая задача процесса Change Management – убрать такие изменения из рассмотрения.
2. Эффективное и безопасное внесение необходимых изменений.
Если изменение необходимо, то внести его нужно так, чтобы потом не было мучительно больно за бесцельно прожитые годы. Это означает, что:
- Изменение должно вноситься в разумные сроки, как того требует бизнес
- Нужны процедуры для типовых видов изменений.
- Нужен анализ рисков, и их учет в этих процедурах.
- Нужен анализ последствий внесения изменения (разбор полетов) и учет ошибок.
- Нужна “политическая воля руководства” – а именно дисциплина, делающая исполнение этих правил обязательным.
Это не все. За исчерпывающим списком я отправлю вас в ITIL и MOF. Решение Change Management в SCSM помогает формализовать и автоматизировать многие из перечисленных выше пунктов. В чем SCSM не может помочь напрямую, так это в укреплении дисциплины в ИТ и воспитании воли руководства. О том как справиться с остальным – читайте в следующих статьях.
