Что такое план отката
Портал №1 по управлению цифровыми
и информационными технологиями
Так или иначе, мы все занимаемся изменениями. В такой профессиональной области работы, как информационные технологии, отлично проявляется динамика по разным направлениям. Разработка новых продуктов, добавление мощностей к сервисным активам, установка «заплаток» на пользовательских станциях. Всё это — ежедневные задачи ИТ-подразделений. Их быстрое выполнение необходимо для обеспечения нужд бизнеса.
На одном из курсов ITIL RCV (Release, Control and Validation), был затронут интересный и жизненный вопрос. Почему в момент развёртывания релиза при появлении каких-либо проблем никто не знает, что нужно делать, а сама деятельность превращается в беготню? Вроде бы при проектировании услуги вместе с остальной документацией должен был быть разработан план отката, и при планировании развёртывания должны были предусмотреть все варианты. Но почему-то этого не было сделано.
В дальнейшем обсуждении были рассмотрены следующие сложности, встречающиеся на практике:
Полное отсутствие плана отката, либо его представление в виде шаблона без детализации. Отсутствие его содержательной части («В каком случае?», «Куда бежим?» и «Как делаем?») в головах сотрудников, ответственных за развёртывание.
Недоступность авторизующих лиц, ведь для ответа на вопрос «В каком случае начинаем работу по пунктам плана отката?» нам нужен триггер. И желательно — с необходимыми полномочиями. Тот самый предводитель, способный взять на себя ответственность, принять управленческое решение, вмешаться при появлении критичных отклонений.
Наличие новых транзакций, затрудняющих возвращение к базовому состоянию. В одних случаях нет возможности остановить изменяемую ИТ-систему, в других остановка не является необходимостью. Если мы разворачиваем какой-то конкретный модуль, то остальные элементы могут продолжать функционировать, обрабатывая потоки данных. В этом случае пропадает ясность «куда бежать», так как откат назад может привести к потерям из-за нарушения целостности данных.
Отсутствие тестирования плана отката. Когда мы учимся ходить, то, сделав первые шаги, с каждым разом проходя все дальше и дальше, мы оттачиваем это умение на ежедневной основе. Походка формируется на всю жизнь. В случае информационных технологий закрепления «навсегда» не происходит. Ответ на вопрос «Как делаем?» сегодня может не совпадать с ответом на тот же вопрос вчера.
Я вижу следующие меры необходимые для предпринятия. Мы планируем шаги для восстановления после неудачного развертывания в момент проектирования услуги. А на стадии преобразования привлекаем авторизующих лиц и тестируем план отката назад в наиболее схожей среде с продуктивной. Требуется зафиксировать появившиеся отклонения, которые послужат для дальнейшей корректировки в восстановительных работах. После чего мы производим повторное тестирование с учётом прошлых недочётов.
Интересно, что было упущено из виду, и с какими еще сложностями сталкиваются различные сервис-провайдеры. А также какие меры, для их преодоления применяются на практике. В связи с чем коллеги, приглашаю вас к дискуссии как на нашем портале, так и в учебном центре Cleverics.
Практика ITIL для небольшой компании. Change Management
Сегодня много кто слышал про ITIL: ИТ процессы, инциденты, тикеты и прочие составляющие ИТ менеджмента.
Слышали? — Круто!
Нет? — ничего страшного, еще обсудим.
Сразу оговорюсь: не прочитал ни одной книги из библиотеки ITIL, не проходил курсы и, пока, не являюсь сертифицированным специалистом — поэтому просьба помидорами в меня не кидаться, а корректно и вежливо поправить, если буду в чем-то не прав.
В то же время по этим самым IT процессами (в том самом виде, в котором они задумывались авторами ITIL) мне посчастливилось проработать аж три с половиной года — поэтому всю «кухню» знаю с практической стороны и знаю, что всё это реально, черт возьми, работает не только на бумаге, но и в жизни.
Сегодня поговорим об одном из самых важных ИТ процессов в плане поддержания стабильности инфраструктуры организации — Управлении Изменениями, он же Change Management.
Change Management наиболее тесно связан со следующими процессами: Incident Management, Problem Management, Configuration Management.
Суть его заключается в контроле действий, связанных с любого рода изменениями (они же в обиходе «ченджи» от «change») в ИТ инфраструктуре. Нужно изменить конфигурацию сервера — составь план, утверди, примени, обнови документацию. Нужно ввести в эксплуатацию новый роутер — составь план, утверди, примени, обнови документацию. Нужно перенести базу данных с одного хоста на другой — … ну вы поняли.
Может показаться, что все это излишняя бюрократия, занимающая ваше драгоценное время. Отчасти — да. Однако, никто и не предлагает с места в карьер углубляться в бюрократию с самого начала. Бюрократию можно оставить крупным корпорациям, которые могут себе позволить любые издержки ради поддержания стабильности.
Что бы ни говорили эстеты ИТ менеджмента, я искренне верю, что в компаниях любого размера можно использовать методики Change Management — по-тихоньку, без фанатизма внедряя всё лучшее, что в нём есть постепенно, а не одним махом.
А начать можно с одного маленького, но очень полезного документа — т.н. Change Plan — документа, в котором описывается как будет проходить чендж. В свое время сам разрабатывал его шаблон для компании, в которой работал — документ получился очень практичным. Ниже приведу его разделы. Надеюсь пригодится:
Всё. С содержимым плана закончили.
Помимо очевидных плюсов у составления таких планов есть один приятный бонус: со временем их накопится столько, что добрую половину изменений можно будет выполнять по отработанной ранее схеме. При этом выполнять их сможет не только один сотрудник, но и любой человек, который более-менее в теме. Всем надо когда-то выходить в отпуск.
Несмотря на всю простоту, в 95% организаций такого рода подходы не используется даже близко. Это далеко не ITIL, но это уже кусочек от него, который сделает инфраструктуру организации более стабильной. ИТ специалист же, который применяет такие, пусть и урезанные, подходы, сможет прокачать свои скилы, которые несомненно пригодятся в карьере.
Изучайте, внедряйте.
Спасибо за внимание.
Практика ITIL для небольшой компании. Change Management
Сегодня много кто слышал про ITIL: ИТ процессы, инциденты, тикеты и прочие составляющие ИТ менеджмента.
Слышали? — Круто!
Нет? — ничего страшного, еще обсудим.
Сразу оговорюсь: не прочитал ни одной книги из библиотеки ITIL, не проходил курсы и, пока, не являюсь сертифицированным специалистом — поэтому просьба помидорами в меня не кидаться, а корректно и вежливо поправить, если буду в чем-то не прав.
В то же время по этим самым IT процессами (в том самом виде, в котором они задумывались авторами ITIL) мне посчастливилось проработать аж три с половиной года — поэтому всю «кухню» знаю с практической стороны и знаю, что всё это реально, черт возьми, работает не только на бумаге, но и в жизни.
Сегодня поговорим об одном из самых важных ИТ процессов в плане поддержания стабильности инфраструктуры организации — Управлении Изменениями, он же Change Management.
Change Management наиболее тесно связан со следующими процессами: Incident Management, Problem Management, Configuration Management.
Суть его заключается в контроле действий, связанных с любого рода изменениями (они же в обиходе «ченджи» от «change») в ИТ инфраструктуре. Нужно изменить конфигурацию сервера — составь план, утверди, примени, обнови документацию. Нужно ввести в эксплуатацию новый роутер — составь план, утверди, примени, обнови документацию. Нужно перенести базу данных с одного хоста на другой — … ну вы поняли.
Может показаться, что все это излишняя бюрократия, занимающая ваше драгоценное время. Отчасти — да. Однако, никто и не предлагает с места в карьер углубляться в бюрократию с самого начала. Бюрократию можно оставить крупным корпорациям, которые могут себе позволить любые издержки ради поддержания стабильности.
Что бы ни говорили эстеты ИТ менеджмента, я искренне верю, что в компаниях любого размера можно использовать методики Change Management — по-тихоньку, без фанатизма внедряя всё лучшее, что в нём есть постепенно, а не одним махом.
А начать можно с одного маленького, но очень полезного документа — т.н. Change Plan — документа, в котором описывается как будет проходить чендж. В свое время сам разрабатывал его шаблон для компании, в которой работал — документ получился очень практичным. Ниже приведу его разделы. Надеюсь пригодится:
Всё. С содержимым плана закончили.
Помимо очевидных плюсов у составления таких планов есть один приятный бонус: со временем их накопится столько, что добрую половину изменений можно будет выполнять по отработанной ранее схеме. При этом выполнять их сможет не только один сотрудник, но и любой человек, который более-менее в теме. Всем надо когда-то выходить в отпуск.
Несмотря на всю простоту, в 95% организаций такого рода подходы не используется даже близко. Это далеко не ITIL, но это уже кусочек от него, который сделает инфраструктуру организации более стабильной. ИТ специалист же, который применяет такие, пусть и урезанные, подходы, сможет прокачать свои скилы, которые несомненно пригодятся в карьере.
Изучайте, внедряйте.
Спасибо за внимание.
10 ключевых практик ITIL 4
Предыдущая редакция методологии ITIL 3 описывает вопросы управления сервисом вокруг процессов. В новой версии ITIL 4 процессы заменяются на практики. Изменения коснулись не только формулировок. Практики стали глубже и рассматриваются в контексте создания ценности для бизнеса. Они учитывают связи с процессами, персоналом, их ключевыми компетенциями, технологиями и другими аспектами. Это позволяет добиться более целостного подхода к управлению услугами.
В статье остановимся на специфике 10 ключевых практик ITIL 4 и разберем:
Постоянное улучшение
В рамках ITSM все действия необходимо направлять на предоставление качественных услуг и на их постоянное улучшение. Это возможно благодаря регулярному анализу результатов, управлению проблемами и управлению знаниями как возможности переиспользовать опыт и решать вопросы быстрее.
В ITIL 4 идеи постоянного улучшения развиваются и интегрируются в сами практики управления услугами. При этом большое внимание уделяется регулярности и ускорению цикла «действие – реакция».
Управление инцидентами
Практика управления инцидентами направлена в первую очередь на более быстрое устранение прерванного доступа к услугам и исправление их качества в соответствии с приоритетами бизнеса.
В ITIL 4 одна из самых популярных практик получает дополнительное развитие: описаны принципы роения для решения сложных инцидентов (устранение инцидента самоорганизующимися командами), детализируется приоритизация и для инцидента в целом, и для инцидента, применительно к устраняющей его команде. Инциденты теперь воспринимаются как часть общего бэклога по услуге, для их устранения приемлемы «безопасные эксперименты» в инфраструктуре.
Управление проблемами
Практика управления проблемами помогает предотвращать и устранять возможность возникновения инцидентов или повторяющихся проблем за счет выявления взаимосвязей и принятия мер по устранению коренных причин.
ITIL 4 добавил практике управления проблемами глубины. Теперь анализируются проблемы по процессам, продуктам, поставщикам и персоналу, и они встроены в общий бэклог по услуге. Доступ к регистрации карточки проблемы может быть ограничен, к их обработке применяются методы управления рисками.
Управление запросами на обслуживание
Практика управления запросами на обслуживание помогает проводить обработку запросов пользователей на новое оборудование или любые другие стандартные услуги.
В ITIL 4 уделяется внимание максимальной стандартизации запросов на обслуживание, автоматизации их исполнения и сильному влиянию практики на общую удовлетворенность потребителей услуг.
Поддержка изменений
Практика поддержки изменений позволяет проводить любые изменения в услугах как можно быстрее, включая оценку рисков и потенциального воздействия простоя. Это помогает избегать внесения изменений в критические периоды деятельности и сводить к минимуму любое воздействие незапланированных изменений.
В ITIL 4 уделяется внимание поддержке изменений при внедрении и снижению риска их отторжения. Сами запросы на изменения рассматриваются как часть общего бэклога по услуге, большой поток изменений должен управляться современными методами: CI/CD (непрерывная интеграция и доставка), DevOps, Agile. При этом важен баланс между эффективностью, пропускной способностью и рисками.
Управление знаниями
Цель практики управления знаниями — повышать эффективность и удобство использования информации и знаний в компании. Управление знаниями позволяет получать нужные данные вовремя, в удобном формате и в соответствии с политикой доступа.
ITIL 4 добавил в практику обучение и целенаправленный поиск знаний в организации, ввел понятие «Абсорбционная способность организации». Сами знания рассматриваются как актив и могут быть явными или неявными (по модели SECI).
Управление событиями и мониторингом
В рамках этой практики происходит наблюдение за событиями (определенными изменениями в системе), их запись и формирование отчетов по ним. Управление событиями помогает заранее предупреждать появление сбоев и поддерживать в компании высокий уровень доступности услуг без прерываний.
ITIL 4 уделяет большее внимание задаче мониторинга, что даже отразилось в названии практики. Описывается реактивный (классический) и проактивный (упреждающий) мониторинг, вводится понятие «Модель здоровья услуги». Например, мониторинг полного пути транзакции от запроса клиента до выполнения.
Управление уровнем услуг
Практика управления уровнем услуг помогает установить четкие цели по предоставлению услуг и отслеживать их соблюдение по отчетам. Включает бизнес-услуги и данные по уровням обслуживания.
ITIL 4 значительно расширил практику и повысил уровень стандартизации. Фокус практики направлен на осмысление результатов предоставления услуг. Понятие «Соглашение об уровне услуг» объединило как SLA, так и OLA (его больше нет как отдельного объекта). Понятие «качество» учитывает подразумеваемые требования к услуге, UX-услуги, отзывы и оценку качества от специалистов. Для поддержки сбора информации о качестве предоставления услуг выделена практика управления изменениями и отчетами.
Управление конфигурациями услуг
В рамках практики управления конфигурациями услуг собирается информация об активах, технологиях и сотрудниках организации. Основная цель — ведение подотчетных записей, оценка рисков, формирование взаимозависимостей.
Управление ИТ-активами
Эта практика тесно связана с управлением конфигурацией. Однако основная цель управления активами — оптимизация стоимости владения активом и затрат на его обслуживание.
ITIL 4 рассматривает новые виды активов — знания. Сама практика теперь не является частью управления конфигурациями, а выделена как самостоятельная.
Управление изменениями – о целях процесса и его внедрении
Изменения – неотъемлемая часть большинства действий, связанных с ИТ. Если компания развивается или просто поддерживает уровень предоставляемых услуг, невозможно управлять и обслуживать ИТ статично. Часто контроль за изменениями выполняется формально, но если вы осуществляете переход на сервисную модель и глубокое внедрение ITSM, то без процесса управления изменениями не обойтись.
Цель управления изменениями
Главная цель управления изменениями заключается в повышении доступности ИТ-услуг, особенно тех, которые критичны для стабильной работы и роста бизнеса. Внедрение процесса управления изменениями позволяет свести к минимуму проблемы, возникающие при неудачных изменениях и приводящие к сбоям в предоставлении услуг. Вариант «ничего не трогать, пока работает» нежизнеспособен, так как для нормального функционирования инфраструктуры требуются периодические изменения (ремонт, модернизация, обновление и т. д.). А чтобы контролировать эти действия и не допускать катастрофичных последствий, необходимо внедрить управление изменениями.
Что такое управление изменениями
ITIL выделяет следующие типы изменений:
В зависимости от типа изменения отличаются сценарии их применения:
Нормальные изменения – основа управления изменениями
Нормальные изменения больше других отслеживаются и просматриваются, потому что именно они составляют основную массу и важность управления изменениями. Экстренные изменения должны появляться как можно реже, так как они связаны с возможной деградацией сервиса, а это недопустимо. Стандартные же изменения не требуют рассмотрения и согласования советом, выполняются по заранее утвержденным процедурам и совершенно прозрачны.
Последовательность событий при нормальном изменении:
Перечень этих шагов необходимо внести в организационные требования при проведении изменений, так как они составляют основу процесса управления изменениями.
Внедрение управления изменениями
На первый взгляд внедрение процесса управления изменениями может показаться сложным, особенно если развитие ITSM в вашей компании только началось. Вот несколько шагов, которые позволят его упростить и сделают понятнее:
Оценка внедрения управления изменениями
Чтобы оценить эффективность внедрения управления изменениями, воспользуйтесь следующими метриками:
В данном материале мы разобрали важность процесса управления изменениями и подсказали вам первые шаги, которые необходимо сделать для его внедрения. Чтобы внедрение стало более легким, быстрым и эффективным, рекомендуем воспользоваться готовыми ITSM-инструментами платформы ServiceNow.
Чтобы испытать все возможности и преимущества популярной и успешной сервисной платформы ServiceNow уже сейчас, а также получить консультацию по внедрению процесса управления изменениями, вы можете обратиться к специалистам компании «ИТ Гильдия» – официального сертифицированного партнера ServiceNow.
Подписывайтесь на блог компании «ИТ Гильдия» – официального сертифицированного партнера ServiceNow, чтобы следить за новыми статьями, которые позволят вам достигнуть успеха, внедряя платформу.