Сегодня много кто слышал про ITIL: ИТ процессы, инциденты, тикеты и прочие составляющие ИТ менеджмента.
Слышали? — Круто!
Нет? — ничего страшного, еще обсудим.
Сразу оговорюсь: не прочитал ни одной книги из библиотеки ITIL, не проходил курсы и, пока, не являюсь сертифицированным специалистом — поэтому просьба помидорами в меня не кидаться, а корректно и вежливо поправить, если буду в чем-то не прав.
В то же время по этим самым IT процессами (в том самом виде, в котором они задумывались авторами ITIL) мне посчастливилось проработать аж три с половиной года — поэтому всю «кухню» знаю с практической стороны и знаю, что всё это реально, черт возьми, работает не только на бумаге, но и в жизни.
Сегодня поговорим об одном из самых важных ИТ процессов в плане поддержания стабильности инфраструктуры организации — Управлении Изменениями, он же Change Management.
Change Management наиболее тесно связан со следующими процессами: Incident Management, Problem Management, Configuration Management.
Суть его заключается в контроле действий, связанных с любого рода изменениями (они же в обиходе «ченджи» от «change») в ИТ инфраструктуре. Нужно изменить конфигурацию сервера — составь план, утверди, примени, обнови документацию. Нужно ввести в эксплуатацию новый роутер — составь план, утверди, примени, обнови документацию. Нужно перенести базу данных с одного хоста на другой — … ну вы поняли.
Может показаться, что все это излишняя бюрократия, занимающая ваше драгоценное время. Отчасти — да. Однако, никто и не предлагает с места в карьер углубляться в бюрократию с самого начала. Бюрократию можно оставить крупным корпорациям, которые могут себе позволить любые издержки ради поддержания стабильности.
Что бы ни говорили эстеты ИТ менеджмента, я искренне верю, что в компаниях любого размера можно использовать методики Change Management — по-тихоньку, без фанатизма внедряя всё лучшее, что в нём есть постепенно, а не одним махом.
А начать можно с одного маленького, но очень полезного документа — т.н. Change Plan — документа, в котором описывается как будет проходить чендж. В свое время сам разрабатывал его шаблон для компании, в которой работал — документ получился очень практичным. Ниже приведу его разделы. Надеюсь пригодится:
- Описание
Что будет делаться в двух словах.
Для чего это будет делаться (если пораскинуть мозгами, то может оказаться, что и делать ничего не надо);
Кто будет участвовать.
Cсылки на документацию. Желательно на официальную, но можно и на другие проверенные источники. Документация обуславливает корректность ваших действий. И вообще ее полезно читать. - Подготовка (Pre-installation)
Все что нужно сделать до момента X — времени, на которое запланирован чендж. Важными пунктами этого раздела являются:
Согласование и Бэкап.
Для чего нужен бэкап я не буду распространяться, а вот насчет согласования уточню, что этот пункт крайне важен. Все, кого может затронуть чендж должны быть предупреждены, а ответственные лица должны дать свое согласие. Например, с 16 до 17 вы соберетесь заменить принтер, а именно в это время в бухгалтерии отправят на печать зарплатные листы… Согласитесь, будет неприятно. - Внедрение (install plan)
Все действия, которые будут выполняться в момент X. По шагам — максимально подробно: зайти на сервер такой то по SSH, выполнить команды: 1, 2, 3… И так далее.
При желании можно указать сколько времени займет та или иная операция. - Заключительные действия (Post-installation)
Проверить, что система и все остальные системы, с ней взаимодействующие, работают корректно;
Вернуть обратно все настройки, которые делались в рамках подготовки к ченджу;
Внести изменения в документацию; - План отката (Backout Plan)
Действия, которые будут выполняться в случае проблем и невозможности их устранения в приемлемые сроки. - Приложения
Если в плане много справочной информации, то здесь можно всю ее собрать. IP адреса, имена серверов, пути в файловой системе, и прочее.
Всё. С содержимым плана закончили.
Помимо очевидных плюсов у составления таких планов есть один приятный бонус: со временем их накопится столько, что добрую половину изменений можно будет выполнять по отработанной ранее схеме. При этом выполнять их сможет не только один сотрудник, но и любой человек, который более-менее в теме. Всем надо когда-то выходить в отпуск.
Несмотря на всю простоту, в 95% организаций такого рода подходы не используется даже близко. Это далеко не ITIL, но это уже кусочек от него, который сделает инфраструктуру организации более стабильной. ИТ специалист же, который применяет такие, пусть и урезанные, подходы, сможет прокачать свои скилы, которые несомненно пригодятся в карьере.
Изучайте, внедряйте.
Спасибо за внимание.
Автор: ilyamitrukov
