Close

Готовы к работе с ITSM на высокой скорости?

Десять рекомендаций по управлению изменениями

Как известно, управление изменениями — зачастую сложная и ресурсоемкая задача. Но все может быть иначе. При должной реализации управление изменениями в ИТ сокращает количество инцидентов, делает процессы гибкими и минимизирует нарушение работы.

Каким же образом следует реализовывать управление изменениями? Начните со следующих десяти рекомендаций.

1. Оцените устойчивость вашей организации к рискам и составьте соответствующий план

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

Чтобы иметь представление о рисках компании, нужно понимать ее обязательства в контексте закона и соответствия требованиям. Ни время простоя, в течение которого компания может продержаться на плаву, ни стоимость ресурсов, необходимых для устранения проблемы, не могут повлиять на положения законодательства. Это набор правил, которые нельзя изменить. Вам придется получить определенные разрешения. Вы должны разделять обязанности. Из-за требований SOX и GDPR некоторые действия являются обязательными, даже если они несколько замедляют процесс.

К счастью, в данном случае можно корректировать планирование. Даже в более консервативных компаниях, где строго соблюдаются иерархия и рабочие процессы, с течением времени можно проводить ревизию внутренних правил, адаптируя строгость рабочих процессов к уровню рисков.

2. Используйте оценку рисков на основе данных, чтобы непрерывно адаптировать методы управления изменениями

Для оптимизации методики управления изменениями важно отслеживать показатели, в особенности — связи между изменениями и инцидентами. Анализируя данные, можно выявить тенденции и определить типы изменений, участников команды и сервисы, которые, скорее всего, не связаны с инцидентом. Такая информация позволяет найти баланс между строгостью и риском при обработке запросов на изменение.

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

Ниже приведены практические шаги, позволяющие сделать стандартные изменения обычным порядком.

  1. Проанализируйте изменения за последние несколько месяцев.
    • Какие изменения вносятся чаще всего?
    • Какие изменения считаются стандартными?
    • На какие услуги они влияют?
    • Какие изменения оказались успешными?
    • Сколько времени понадобилось в среднем на внедрение таких изменений?
    • Какие изменения были запрошены командами разработчиков?
  2. Выберите от трех до пяти стандартных изменений в качестве кандидатов для автоматизации.
  3. В программном обеспечении службы поддержки создайте типы запросов самообслуживания, которые будут использоваться для стандартных изменений.
    • Добавьте описание с указанием предназначения и области применения стандартных запросов на изменения.
    • Укажите основные сферы, в которые вносятся изменения (например, система, приложение или сервис).
    • Создайте правила автоматизации для предварительного подтверждения изменений, смены состояния и уведомления сотрудников.
  4. Проинструктируйте сотрудников ИТ-отдела и команду разработки о том, как использовать эту новую возможность.
  5. Отследите производительность за последние несколько месяцев.
    • Подумайте, как можно улучшить имеющиеся предложения.
    • Определите, какие еще стандартные изменения можно автоматизировать.

3. Максимально упростите управление изменениями

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

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

Чем проще процесс, тем легче добиться расположения сотрудников (и сохранять его).

4. Подумайте о том, как можно изменить традиционный формат совета по изменениям (CAB)

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

Основная идея в том, чтобы сохранить все, чем полезен совет для ИТ-процессов, обеспечив при этом должное взаимодействие сотрудников, баланс между важностью изменений и связанными с ними рисками, а также сделав процедуру CAB удобной и стратегически ориентированной. Что это означает:

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

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

5. Используйте инструменты для автоматизации и совершенствования процессов

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

Как объяснил Гай Херберт, риск-аналитик в Atlassian, в своей недавней статье о соответствии требованиям и рисках, «дело в том, что большинству из нас на самом деле не нужен сложный процесс утверждения и бесконечная волокита с комитетами по соответствию требованиям... Что нам действительно нужно — это концепция сдержек и противовесов, благодаря которой изменения, не соответствующие требованиям, не вступают в силу. И многое из этого можно сделать непосредственно с помощью наших инструментов. Например, Bitbucket не позволяет нашим разработчикам отправлять в репозиторий код, над которым они работают, до тех пор пока он не пройдет рецензирование другим квалифицированным разработчиком. Bamboo запрещает выполнение нового кода, который не прошел проверку на соответствие требованиям в BitBucket».

6. Внедряйте изменения постепенно, небольшими релизами. Это упростит их интеграцию в вашу среду

Раньше релизы объединялись в пакет и запускались все одновременно. Большинству из нас понятно, что такой подход приводит к возникновению серьезных инцидентов и усложняет поиск источников проблем, когда они возникают. Небольшие, более частые релизы ограничивают область возникновения потенциального инцидента. Постепенное развертывание с этапом промежуточного тестирования небольшой группой пользователей позволяет убедиться в стабильности релиза перед его полным развертыванием.

7. Воспринимайте ITIL как рекомендации, а не жестко установленные правила

Некоторые не любят ITIL. Говорят, что положения ITIL слишком ограничивают возможности и являются устаревшими. Тем не менее ITIL предлагает много полезного ИТ-командам, включая адептов культуры DevOps. И проблема не в строгости ITIL. Проблема в том, как мы используем рекомендации.

Если воспринимать ITIL как набор строгих правил для неукоснительного следования, то, конечно, он покажется слишком ограничительным. Относитесь к ITIL как к набору рекомендаций, на базе которых ваша компания может выстраивать свои рабочие процессы. И тогда, занимаясь разработкой методов управления изменениями, вы убедитесь, что ITIL — ваш верный помощник.

Это применимо к любой среде и любым идеологическим предпочтениям. ITIL, lean, DevOps, Agile, CD... Ни одна методика, как бы вы ее ни любили, не решит все ваши проблемы одним махом. Очень часто мы ищем решение внутренних проблем, пытаясь использовать для этого систему методик или инструментов, тогда как нужно смотреть совсем в другую сторону — на культуру совместной работы.

8. Совместная работа — в приоритете

И в CAB, и в группах DevOps ведущие команды приветствуют совместную работу, открытость и обновления в реальном времени. Управление изменениями предназначено для того, чтобы координировать действия команд. Изменения, инциденты и проблемы имеют большое влияние на целый ряд команд. Это становится все очевиднее по мере роста компании.

Надлежащее управление изменениями невозможно, если нет взаимодействия. В организациях, где приветствуется открытое взаимодействие сотрудников, внедрение изменений происходит более гладко.

9. Инженерия хаоса и отказоустойчивости

Инженерия хаоса — это новый подход к проверке устойчивости, при котором выводятся из строя или отключаются компоненты продукта или сервиса. Аналогичным образом инженерия отказоустойчивости позволяет выяснить все возможные причины нарушения нормальной работы системы. Для этого систему, например, нагружают мощным трафиком или большим числом пользователей.

Оба метода позволяют выявлять проблемы и изменения, которые необходимо внести для предотвращения инцидентов. Такой упреждающий подход приносит большую пользу командам, управляющим изменениями. Он позволяет сэкономить время и бюджет, а также избежать лишних оповещений.

10. Выбирайте инструменты, знакомые и популярные среди команд разработки

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

Сотрудники Atlassian отслеживают изменения при помощи Jira Service Management. Платформа Jira объединяет команды разработчиков и операционные отделы, обеспечивая прозрачность и отслеживание контекста со времени написания кода разработчиками и до развертывания изменений.

продолжение темы
Roles and responsibilities