Практика ITIL для небольшой компании. Change Management

Сегодня много кто слышал про ITIL: ИТ процессы, инциденты, тикеты и прочие составляющие ИТ менеджмента.
Слышали? — Круто!
Нет? — ничего страшного, еще обсудим.

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

В то же время по этим самым IT процессами (в том самом виде, в котором они задумывались авторами ITIL) мне посчастливилось проработать аж три с половиной года — поэтому всю «кухню» знаю с практической стороны и знаю, что всё это реально, черт возьми, работает не только на бумаге, но и в жизни.

Сегодня поговорим об одном из самых важных ИТ процессов в плане поддержания стабильности инфраструктуры организации — Управлении Изменениями, он же Change Management.

Change Management наиболее тесно связан со следующими процессами: Incident Management, Problem Management, Configuration Management.

Суть его заключается в контроле действий, связанных с любого рода изменениями (они же в обиходе «ченджи» от «change») в ИТ инфраструктуре. Нужно изменить конфигурацию сервера — составь план, утверди, примени, обнови документацию. Нужно ввести в эксплуатацию новый роутер — составь план, утверди, примени, обнови документацию. Нужно перенести базу данных с одного хоста на другой — … ну вы поняли.

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

Что бы ни говорили эстеты ИТ менеджмента, я искренне верю, что в компаниях любого размера можно использовать методики Change Management — по-тихоньку, без фанатизма внедряя всё лучшее, что в нём есть постепенно, а не одним махом.

А начать можно с одного маленького, но очень полезного документа — т.н. Change Plan — документа, в котором описывается как будет проходить чендж. В свое время сам разрабатывал его шаблон для компании, в которой работал — документ получился очень практичным. Ниже приведу его разделы. Надеюсь пригодится:

  1. Описание
    Что будет делаться в двух словах.
    Для чего это будет делаться (если пораскинуть мозгами, то может оказаться, что и делать ничего не надо);
    Кто будет участвовать.
    Cсылки на документацию. Желательно на официальную, но можно и на другие проверенные источники. Документация обуславливает корректность ваших действий. И вообще ее полезно читать.
  2. Подготовка (Pre-installation)
    Все что нужно сделать до момента X — времени, на которое запланирован чендж. Важными пунктами этого раздела являются:
    Согласование и Бэкап.
    Для чего нужен бэкап я не буду распространяться, а вот насчет согласования уточню, что этот пункт крайне важен. Все, кого может затронуть чендж должны быть предупреждены, а ответственные лица должны дать свое согласие. Например, с 16 до 17 вы соберетесь заменить принтер, а именно в это время в бухгалтерии отправят на печать зарплатные листы… Согласитесь, будет неприятно.
  3. Внедрение (install plan)
    Все действия, которые будут выполняться в момент X. По шагам — максимально подробно: зайти на сервер такой то по SSH, выполнить команды: 1, 2, 3… И так далее.
    При желании можно указать сколько времени займет та или иная операция.
  4. Заключительные действия (Post-installation)
    Проверить, что система и все остальные системы, с ней взаимодействующие, работают корректно;
    Вернуть обратно все настройки, которые делались в рамках подготовки к ченджу;
    Внести изменения в документацию;
  5. План отката (Backout Plan)
    Действия, которые будут выполняться в случае проблем и невозможности их устранения в приемлемые сроки.
  6. Приложения
    Если в плане много справочной информации, то здесь можно всю ее собрать. IP адреса, имена серверов, пути в файловой системе, и прочее.


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

Несмотря на всю простоту, в 95% организаций такого рода подходы не используется даже близко. Это далеко не ITIL, но это уже кусочек от него, который сделает инфраструктуру организации более стабильной. ИТ специалист же, который применяет такие, пусть и урезанные, подходы, сможет прокачать свои скилы, которые несомненно пригодятся в карьере.

Изучайте, внедряйте.
Спасибо за внимание.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 32

    +1
    Какой лёгкий текст! Для меня лично как нельзя кстати. Спасибо. А где ещё можно почитать про практики ITIL, на доступном для понимания языке. А то как подумаешь про пять томов технической литературы, мозг сразу блокируется.
      +2
      На ютубе есть очень хорошие видео от Charles Sturt University. Они очень короткие и легки для понимания. Если тема интересна можно смотреть по паре в день. Ссылка: www.youtube.com/playlist?list=PL017C0B75EE2FA714&feature=plcp
        0
        Спасибо!
      0
      В свободном доступе по большому счету только общая информация, но для понимания её обычно хватает. Можно немного найти по фразе «itil resources free». Если есть конкретные или общие вопросы — задавайте, м.б. следующим постом на них отвечу :)
        0
        Простому смертному (не сервис менеджеру, а скорее инженеру) как правило наиболее интересно посмотреть service support и service delivery, aka ITSM (service management). Для общих представлений хватит и введения. В свое время очень неплохо работала книга «введение в ит сервис менеджмент» Потоцкого. Она недешевая, но денег стоила. Не знаю есть ли сейчас что подобное поновее, но и та книга актуальности не потеряла. В 3й версии itil стал на мой взгляд чуть попонятнее и пологичнее, разьве что(книга по 2й)
          0
          Также не помешает понимание такого этапа — как Service Operation — то, что мы каждый день используем в жизни. Это service support, только более широко и развернуто
        0
        На пункте три хотелось бы остановится. Если описывать максимально подробно, то по факту это будет двойная работа — либо просто отписка.
        Работал в компании в которой применялся(пытались применять) практику управления изменениями и вот данный момент, всех очень напрягал, т.к. вместо того, чтобы взять и сделать. Надо было сначала заполнить бумажек, с «масимально подробным» описанием, а потом уже что-то делать. Это удручало, особенно когда задачи были похожи, но всегда чем-то отличались.
          0
          Обычно описывается очень подробно. Если задача большая — то разбивается на несколько подзадач и каждая описывается подробно. Цель — по данному документу всегда можно восстановить что и зачем делалось. Если отписывать абы как — то аудит таких изменений будет просто кошмарным.
          Также далеко не всегда изменения по данному документу будет производить тот кто его писал, поэтому описывается все вплоть до конректных комманд — чтобы было легко возпроизвести «постороннему» человеку.
            0
            Зависит от задачи и требований. В общем случае — чем подробнее, тем лучше, но здравый смысл никто не отменял. Обычное требование — план должен быть достаточно детализированным, чтобы любой специалист с надлежащей квалификацией мог его внедрить. В технические детали можно углубиться, если нужно, но предполагается что специалист знает КАК делать, соответственно нужно описать ЧТО делать.

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

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

            Случай с бакапом — реален. При внедрении в плане не было явным образом указано что бакап надо проверить глазами и мозгом, а система мониторинга облажалась, и на деле живого бакапа не было уже сколько дней, хотя статусы были ОК. В результате небольшой человеческой ошибки (был удален не тот файл с очень похожим имем — ошибиться как пить дать) достаточно большая база данных была нагнута в неподъемное состояние. Результат — эпический факап на совершенно ровном месте. Был бы подробный план, прроверили бы бакап, и все бы решилось в рамках окна и проблемы не было бы вообще — просто внедрение бы перенесли.
            А все просто было — инженер, который делал внедрение застрял в пробке и торопился. Мелочь просто напросто вылетела из головы, а быстрый взгляд на репорты мониторинга создал иллюзию того, что все хорошо.

            Еще один важный момент — change window. Окно нужно не для того, чтобы формально ограничить вас во времени, а чтобы ограничить время в течение которого fuckups are possible. Если в это время что то происходит плохое — это нормальная ситуация. Если вне этого окна — это уже самодеятельность\безответственность\плохое планирование со всеми вытекающими последствиями для профессионального имижда.

            Еще нельзя недооцивать важность disaster recovery, но это уже другая история.
              0
              [ремарка по поводу случая с бекапом]
              Ситуации разные конечно бывают. Но файлик вместо удаления лучше было бы сначала переименовать(а ещё лучше скопировать и удалить старый, чтобы удостоверится что нет открытых дескрипторов). :)

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

              [в целом по комментарию]
              Идея понятна. Видимо я пока не был в той ситуации, когда можно было бы это на практике применять. Видимо у нас пока ну совсем маленькая для ITIL компания.
              Вот, например, установка патчей на Оракл. Вроде бы с каждым из них идет инструкция, как его ставить, но через раз идя по этой инструкции что-нибудь всё равно можно сломать. И получается ситуация, что план есть, всё по нему сделано, а результат отличается от ожидаемого.
              +1
              Еще важный момент забыл. Наличие change management снимает с внедряющей стороны львиную долю ответственности, в случае если что то будет упущено и чендж повлияет на что то, что выпало из поля зрения. В сложных системах это запросто. Когда все одобрения получены, это значит что все кто их давал исели возможность подумать о том, на что из их области ответственности, в которой они ориентируются гораздо лучше внедряющей пати, этот чендж может повлиять (не только в случае успеха, но и в случае неудачи или осложнений), и должны быть к этому готовы во время окна (читай хотя бы один инженер их соседней команды должен быть по крайней мере в городе).

              Внедряющему остается продумать свою часть — все остально не на его совести.
                0
                Спасибо за коммент. Подписываюсь под каждым пунктом.
                Да, в маломальски средней компании уже можно использовать и Change Windows и апруверов и Disaster Recovery.
                Что мне нравится в ITIL — это логичность. До любого процесса можно дойти самостоятельно и внедрить без боли. Поэтому, когда знакомишься с методиками, в голове возникает только одна мысль: «Хм, Ну да. А что можно иначе?»… тем и обоснована её популярность.
                  0
                  Хорошую тему подняли, полезную, и редко обсуждаемую. В западных мирах это само собой разумеющиеся вещи, в русскоговорящем мире пока не так проникло.
                  ITIL тем и хорош, что он library. Это же не навязчивая методология, не «панацея» от всех болезней, а по сути просто сборник практик. Иными словами — сборник граблей и их возможных решений. Не вникать в него — по свти подписывать себя на многократное наступление на те самые грабли. Не продуктивно, как минимум.
              0
              О, это — один из самых важных пунктов. Если все на самом деле просто, то все шаги заполняются за пять-десять минут. Если же всё сложнее, то это знак к тому, что стоит записать шаги по пунктам, чтобы ничего не забыть. К слову сказать, если шаги продуманы качественно, то время применения изменений сокращается в разы, потому, что можно мозг практически отключить и сконцентрироваться на мониторинге ситуации, а не думать о том, что делать дальше.
              Естественно, Change Management ради Change Management — это бред, и очень хорошо, когда это понимают и руководство и технари. Главное — чтобы работа шла хорошо.
                0
                Хорошее описание «в двух словах», что более чем похвально, учитывая Ваше «не читал» и «не учился». Знание того, что люди, со временем, сами приходят к таим вещам — меня очень радует, что вселяет уверенность в ИТ-будущем, но истинная ценность ITIL во взаимном согласовании всех процессов и грамотной их организации.
                К примеру, не имея внятного каталога сервисов (в том числе и поддерживающих), с описанными процессами, методиками, метриками и т.д. — невозможно даже представить вменяемый SLA или OLA. Библиотека, главным образом, отвечает на вопрос «как делать», а не «что делать». Понимание «что-делать» придет, после (или во время изучения), само.

                PS.В ближайшее время выложу все книги ITIL v3 в PDF (на буржуйском) + учебный курс в PowerPoint(на русском) + видеозапись пройденых курсов.
                  0
                  Сообщите, когда выложите. А то v3 видел только урывками. Интересно было бы почитать. А я пока подпишусь…
                    +2
                    Ну, собственно вот архивчик (перегнал все в PDF для удобства). Все книги на буржуйском + учебный план на русском, с иллюстрациями.
                      0
                      Прекрасно, огромное Вам спасибо. Скачал.
                        0
                        Пожалуйста.
                        Видео на обработке пока.
                  0
                  Спасибо за статью. Очень интересная и важная тема. Только знающий человек тут подсказал, то что вы описываете ближе скорее к управлению релизами, а не изменениями. Управление изменениями это процесс внесения изменений в продукт. От поступления запроса на изменение, до непосредственно самих изменений. А управление релизами, это уже применение этих изменений в продуктивной среде.
                    0
                    Строго говоря, Change — это любое изменение в любом CI (Configuration Item).
                    CI — элемент Configuration Management — процесса в рамках которого ведется учет всех элементов инфраструктуры — серверов, АТС, лицензий на софт, процессов, контрактов… и связей всего этого хозяйства друг с другом.
                    CI характеризует каждую единицу инфраструктуры в разумных деталях.
                    Если это сервер, то в документации записано, что он «такой-то модели», «имеет такой-то IP», имеет связь с такой-то СХД, привязан к такому-то контракту и так далее. В общем это отдельная тема.
                    Если говорить о Release Management. Слышал о нем, как части ITIL… не готов прокомментировать. Ретируюсь :)
                    0
                    В первый пункт плана также не помешает добавить оценку такого понятия как «Impact» — какое влияние на жизнеспособность бизнес функций имеет данное изменение. Исходя из «влияния» можно описать приоритет (срочность) данного изменения.

                    Данный момент позволит нам избежать всевозможных недоразумений и негодований со стороны начальства по результатам проведенного изменения, т.к. оно заранее будет знать, чем данный чейндж для него чреват
                      0
                      Спасибо за статью. Хороший ответ тем скептикам, кто уверен что «у нас такое не работает», что это бесполезный «тренд» и т.д. Именно на таких простых, жизненных ситуациях становится понятной цель применения ITSM подхода. Тем более, что внедрив однажды что-то простое, со временем понимаешь, что это можно улучшить, процесс по сути своей, бесконечный
                        0
                        На самом деле скептики не так уж и не правы. ITIL в исходном виде действительно не работает у нас (Россия) и тому множество причин (в том числе и законодательно запрещены некоторые подходы), но это не означает, что нельзя адаптировать методику. Если есть понимание цели, есть знание путей достижения, то ничего не мешает использовать те или иные подходы, облегчая тем самым достижение цели, и повышая качество результата.
                          0
                          думаю что в исходном виде он нигде не работает :) ITIL это сбор рекомендаций и методик, а как внедрять зависит уже от поставленных процессов в компании
                            0
                            Itil не может работать или не работать, потому что это не методология. А использовать чужой опыт или наступать на грабли самому — каждый решает сам, за свои деньги :)
                          0
                          Большое спасибо за материал. Вроде бы мало, но весомо. Жду новых материалов от Вас в том же духе.
                            +1
                            Некоторое время назад на ИНТУИТе опубликовали курс про ITIL v3.1 — www.intuit.ru/department/itmngt/itil_dpo/
                              0
                              спасибо, записался.

                              Вы проходили этот курс? Как впечатления?
                                0
                                Я его сейчас прохожу. Пока только на первых лекциях.
                                Впечатления пока хорошие, материал доступный для понимания.
                                  0
                                  А я уже прошёл, за неделю наверное до этого поста. Впечатления на 4+. Слишком уж сухо и без примеров подан материал (хотя в ITIL наверное по-другому и не получится). Ну и заметил вроде несколько косячков в вопросах. Имея под рукой «святое пятикнижие» на английском могу сказать, что в курсе есть все основные темы, но в оригинале информации конечно больше — но для «первого прохода» по теме очень даже рекомендовал бы. А уже потом читать полный вариант.
                                    0
                                    Вот-вот, я сейчас на 4й главе курса и понимаю, что без наглядных примеров это все очень тяжело воспринимается. Но и гугление тоже, надо сказать, не помогает с примерами, то ли жмут все, то ли действительно по ITIL мало кто смог организовать работу ;)

                              Only users with full accounts can post comments. Log in, please.