Реализация изменений — это центральный этап жизненного цикла изменения, обеспечивающий непосредственно эволюционное изменение ЦДП.

Для реализации изменений в ЦДП необходимо иметь единую систему изменений (ЕСУИ). Был у меня проект, в рамках которого нужно было реализовать процесс управления реализацией изменений для SAP систем на базе SAP Solution Manager для включения в качестве ALM в Единую систему управления изменениями (ЕСУИ). Тогда нашей смежной команде не удалось в процессах ЕСУИ интегрировать управление изменениями различных систем: SAP, 1С, Web в единообразный процесс. Процессы получились громоздкими, слабоуправляемыми и перегруженными различными условиями. В итоге данная система так и не была сдана в промышленную эксплуатацию. Данная статья завершает описание предлагаемых мной процессов управления изменениями, которые мы рассмотрели в первых двух статьях: https://habr.com/p/1037390/ и https://habr.com/p/1030410/. После того как мы определили необходимость изменения, проработали все детали изменения, определили ресурсы, необходимые для этого изменения, мы приступаем непосредственно к самому изменению. Процесс выполнения изменения — это не просто хаотичная разработка или набор административных действий, а структурированный, управляемый и контролируемый процесс, в рамках которого:

1. Изменяются или создаются код, конфигурации, бизнес-модели (BPMN), ролевые модели, документация.

2. Производятся различные проверки — код-ревью, проверка архитектором, экспертиза информационной безопасности.

3. Выполняется модульное и интеграционное тестирование.

4. Все изменения в ИТ-системах синхронизируются с актуальной моделью процессов ЦДП и ветками Git-а (версионирование, слияние).

5. Инициатор или владелец процесса подтверждает, что изменение достигло поставленных целей и критериев успеха.

6. Сформированный объем изменений включается в Релизный контейнер и после согласования CAB переносится в продуктивную среду.

Реализация изменений включает в себя полный цикл: от первого коммита в системе контроля версий до момента, когда изменение проверено, успешно перенесено в продуктивную среду и принято на сервис.

В зависимости от масштаба и сложности, реализация может выполняться на разных уровнях:

• Уровень Наряда — атомарная единица работы: разработчик пишет код, администратор применяет настройку, аналитик уточняет модель.

• Уровень Задания на разработку (ЗНР) — скоординированная совокупность нарядов, реализующая законченную функцию или бизнес-требование.

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

В проекте, о котором я уже говорил, нижним уровнем ЕСУИ был уровень ЗНР, далее управление передавалось в ALM системы, причем не в полной мере учитывалась специфика ALM для различных типов систем. ALM SAP не может соответствовать ALM 1С, и тем более Web. Я же предлагаю в системе ЕСУИ спуститься на уровень нарядов и постараться построить процесс управления реализацией изменения общий для всех типов систем. Попытаемся построить единый процесс, с одинаковыми статусами для всех типов систем. Каждое действие в процессе изменения должно быть зафиксировано, каждый артефакт — версионирован. Только такая реализация превращает хаотичные правки в предсказуемую и управляемую эволюцию цифрового двойника предприятия. Все изменения, производящиеся в ЦДП, выполняются в рамках нарядов.

Определим 4 Типа Нарядов:

• Наряд на общее изменение.

• Наряд на стандартное изменение.

• Наряд на срочное изменение.

• Наряд на плановое изменение.

Наряд — это документ в системе управления изменениями, который позволяет контролировать и документировать все этапы выполнения изменения и переноса этих изменений по ландшафту вплоть до продуктивной среды. Наряд в Единой Системе Управления Изменениями (ЕСУИ) обязательно должен интегрироваться с платформой, которая непосредственно управляет изменениями в ИТ-системах. Это платформы:

• SAP Solution Manager

• DevOps-инструменты на базе GitLab или GitFlic

• 1С:СППР, EDT

Существует четыре типа Нарядов:

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

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

3. Наряд на срочное изменение — Это документ, созданный из Задания на срочное исправление (ЗНСИ), обеспечивающий ускоренный, но контролируемый процесс внесения изменений для предотвращения или исправления инцидента или угрозы, когда стандартные сроки неприменимы.

4. Наряд на плановое изменение — Это документ изменения в системе управления изменениями, для осуществления контроля изменения, выполняющегося плановым порядком. Перенос изменений, произведенных в рамках документа, производится в составе Релизного контейнера согласно графику. В нашей модели используется единый тип документа «Наряд на плановое изменение», который за счет атрибута «Категория работ» позволяет учитывать специфику различных видов изменений — от разработки до управления доступом. Категория определяет набор полей, маршрут согласования и интеграцию с внешними системами, но статусная модель остается единой для всех плановых изменений.

Все наряды, кроме наряда на общее изменение, интегрируются с внешними системами управления разработкой и изменениями (ALM):

• SAP Solution Manager – для управления транспортами и жизненным циклом изменений в SAP-системах;

• DevOps-инструменты на базе GitLab или GitFlic – для микросервисной разработки и сред разработки 1С (1С:СППР, EDT) и управления задачами разработчиков.

Такая интеграция обеспечивает сквозной контроль и прослеживаемость статусов изменений на всех этапах жизненного цикла.

Наряд на общее изменение

Наряд на общее изменение создается как дочерний документ ЗНР (Задания на разработку). Наряд имеет 6 статусов:

• Создан

• В работе

• Приемка

• Реализован

• Закрыт

• Отменен

Рисунок 1. Схема процесса наряда на общее изменение.

Все документы (описания, схемы и т.д.), связанные с выполнением работ, прикрепляются к наряду. На основании предоставленных документов заказчиком производится приемка работ по наряду. Статус «Закрыт» устанавливается автоматически через некоторое время фоновым процессом, если наряд находится в статусе «Реализован». Наряд может быть отменен, если изменение стало неактуальным.

Наряд на стандартное изменение

Наряд на стандартное изменение создается как дочерний документ обращения пользователя, созданного в системе ITSM. Наряд имеет 6 статусов:

• Создан

• В работе

• Готов к импорту

• Реализован

• Закрыт

• Отменен

Рисунок 2. Схема процесса наряда стандартного изменения.

Статусы и выполняемые действия на этих статусах:

• Создан. Исполнитель проверяет заполнение полей и переводит наряд в работу либо отменяет наряд.

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

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

• Реализован. После импорта изменений в продуктив наряд по интеграции устанавливается в статус «Реализован».  Статус «Реализован» передается на уровень ЗНР.

• Закрыт. Статус «Закрыт» устанавливается автоматически через некоторое время фоновым процессом, если наряд находится в статусе «Реализован».

• Отменен. Если после создания наряда выяснилось, что он не нужен.

Наряд на срочное изменение

Наряд на срочное изменение создается как дочерний документ ЗНСИ (Задания на срочное изменение). Наряд имеет 8 статусов:

• Создан

• В работе

• Проверка

• Импорт в продуктив

• Реализован

• Документирование

• Закрыт

• Отменен

Рисунок 3. Схема процесса наряда на срочное изменение.

Статусы и выполняемые действия на этих статусах:

• Создан. Эксперт 3 линии поддержки проверяет заполнение полей, определяет исполнителя и переводит наряд в работу либо отменяет наряд. В этом статусе по интеграции создается объект во внешней системе управления изменениями.

• В работе. В этом статусе во внешней системе управления изменениями определяется исполнитель, и определенное и согласованное задание передается ему в работу. Исполнитель производит все необходимые работы.

• Проверка. Во внешней системе производится тестирование, приемка изменения и согласование на перенос в продуктив.

• Импорт в продуктив. Во внешней системе производится импорт в продуктивную систему выполненных изменений.

• Реализован. Во внешней системе выполнен импорт изменения в продуктив. Этот статус передается в ЗНСИ. Из этого статуса наряд переводится в статус Документирование.

• Документирование. Производится при необходимости импорт (если он не произошел автоматически) документов, сопровождающих настройку/разработку и прикрепленных к соответствующему документу во внешней среде в наряд ЕСУИ. Эти документы должны быть доступны для просмотра из ЗНР. При необходимости производится корректировка бизнес-модели.

• Закрыт. Статус «Закрыт» устанавливается вручную после выполненного документирования.

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

Наряд на плановое изменение

Наряд на плановое изменение создается как дочерний документ ЗНР (Задания на разработку).  Наряд имеет также 9 статусов:

• Создан

• В работе

• Готов к тестированию

• Тестирование

• Готов к импорту в продуктив

• Импорт в продуктив

• Реализован

• Закрыт

• Отменен

Рисунок 4. Схема процесса наряда планового изменения.

Статусы и выполняемые действия на этих статусах:

• Создан. Руководитель изменения проверяет заполнение полей. Проверяет достаточность информации для выполнения изменения, определяет ИТ-систему для выполнения изменения и определяет исполнителя. Руководитель изменения переводит наряд в статус «В работе» либо отменяет наряд.

• В работе. При переходе в этот статус по интеграции создается объект во внешней системе управления изменениями. Исполнитель во внешней системе приступает к работе. На этот статус наряд может быть переведен также при отрицательных результатах тестирования из статуса «Тестирование» без создания объекта.

• Готов к тестированию. Данный статус говорит о завершении работ по изменению. Изменение готово к различным видам тестирования согласно процессам в ЗНР и Релизе. При установлении этого статуса во всех нарядах одного ЗНР, ЗНР переключается автоматически в статус «Приемочное тестирование». Тестирование производится сначала на уровне ЗНР, далее на уровне Релиза. После тестирования на уровне Релиза принимается решение об импорте изменений в продуктив. Устанавливаются соответствующие статусы в Релизном контейнере, ЗНР и наряде.

• Тестирование. На этом статусе производится приемочное тестирование и тестирование в составе релиза.

• Готов к импорту в продуктив. Статус, устанавливающийся после успешного тестирования, до момента решения CAB. 

• Импорт в продуктив. На этом статусе производится импорт изменений в продуктив.

• Реализован. После успешного импорта статус наряда устанавливается в состояние «Реализован».

• Закрыт. Статус устанавливается автоматически фоновым заданием для нарядов в статусе Реализован.

• Отменен. Наряд отменяется в результате принятия решения не выполнять изменения вообще или в рамках этого наряда.

Во всех приведенных схемах процессов в качестве внешних систем подразумеваются инструменты SAP Solution Manager, GitLab или GitFlic. Интеграция различных сред с нарядами: SAP, Web, Микросервисы и 1С будет рассмотрена отдельно в следующих публикациях.