Привет! Меня зовут Егор Сизов, в компании «Цифра» (дивизион Непрерывные производства) я руковожу направлением «Системы управления производством».

За этот год, среди прочего, я занимался двумя крупными проектами: организацией сбора библиотеки готовых конфигураций и конвертацией конфигураций PI System в Платформу ZIIoT. 

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

Материал будет полезен прежде всего для тимлидов внедрения, архитекторов решений и руководителей.

---

Тезаурус

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

• Внедрение — адаптация ПО, которое поможет реализовать бизнес-процессы конкретного заказчика.

• Окружение — переменные микросервисов в оркестраторе. Ими управляет система развертывания.

• Конфигурация — метаданные/шаблоны в микросервисах. Их настраивают инженеры внедрения. Это не данные, генерируемые в результате работы бизнес-пользователей или системы.

---

Контекст внедрения

Технические и организационные принципы разработки ПО описаны и осмыслены во множестве методологий, подходах и работах, а вот специфика внедрения ПО остается своего рода «Terra incognita». Поэтому сначала я хочу погрузить вас в наш контекст через понятные всем термины из разработки ПО

Первый аспект

Бизнес-процессы заказчика на каждом проекте уникальны, поэтому и конфигурации системы не повторяются. Их приходится настраивать вручную (Manual Configuration). А вот в разработке с окружением микросервисов все гораздо проще — набор переменных сервисов определен, конечен и управляется конфигурацией в системе авторазвертывания (Configuration as a Code).

Второй аспект

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

Цель и мотивация

Конечная цель подхода, который я предлагаю, — адаптировать принцип Configuration as a Code к конфигурированию, как бы тавтологично это ни звучало, и сократить разрыв между языком бизнеса и языком конфигурирования, чтобы в конечном итоге снизить трудозатраты на внедрение.

---

Эмпирический опыт

В качестве эмпирического опыта я буду использовать проект импортозамещения PI System на Платформу ZIIoT на предприятии химической отрасли как наиболее наглядный и показательный для индуктивного вывода предлагаемого мной подхода

Вводные проекта

• Цель — импортозамещение PI System на Платформу ZIIoT ГК «Цифра».

• Задача — конвертация конфигураций, а не конфигурирование с нуля.

• Технически продвинутая IT-команда заказчика.

По трем этим причинам мы решили разрабатывать конвертеры конфигураций

Реализация

Мы разработали конвертеры отчетов DataLink и расчетов на библиотеке ACE из PI в ZIIoT.

Под капотом конвертеров — python с заданием параметров в JSON файле. Они являются консольными утилитами с возможностью компиляции в exe-файл.

Экономика

А что с экономикой разработки конвертеров?

Трудозатраты на разработку конвертеров в худшем случае в 2 раза проигрывают, а в лучшем — почти в 4 раза выигрывают по трудозатратам у конфигурирования вручную.

А где тогда явное преимущество разработки конвертера, если в негативном сценарии мы проигрываем в 2 раза по трудозатратам?

Выигрыш есть, но он отложен во времени, и мы уже начали его получать при тираже на другие площадки заказчика!

Выводы

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

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

---

Предлагаемый подход

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

Конфигурирование с помощью утилит

Цель 

Переход в конфигурировании от подхода Manual Configuration к Configuration as a Code.

Эффекты

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

2. Версионность подхода к конфигурированию. Можно проследить в git не только как менялась сама конфигурация, но и как менялся код утилиты, т.е. алгоритм её создания.

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

Ограничения

Подход работает, когда:

• На проекте изначально есть или требуются артефакты на языке бизнеса. Формирование артефактов с нуля только ради подачи на вход утилите нивелирует весь выигрыш в трудозатратах в сравнении с конфигурированием вручную.

• Артефакты должны иметь вид матриц, справочников, перечней.

• Файлы артефактов имеют структурированный формат (xlsx, csv и т.п.).

Конвейер поставки конфигураций

Организационная составляющая

Конвейер поставки конфигураций заключается в последовательном переносе новой версии конфигурации с dev-полигона через test на prod, где на каждом этапе конфигурация попадает на следующую среду только после тестирования и исправления багов, если они есть.

Техническая составляющая

Для реализации конвейера поставки перенос данных между полигонами с помощью бэкапирования и восстановления баз не подходит, так как он не позволяет отделить конфигурации от данных. Это приводит к появлению тестовых данных с dev-среды в prod-контуре или перетирание ими продуктивных данных.

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

И у нас такой есть!

Ключевые пользователи и эффекты

У конвейера поставки конфигураций есть два основных бенефициара:

• Руководители команд внедрения:

  • Могут организовать приемку работ по конфигурированию у инженеров внедрения с помощью версионирования конфигурации в git и имеют возможность откатить изменения.

  • Могут снизить число багов конфигурации на prod благодаря её последовательному тестированию на промежуточных средах.

• Sales/Key Account Managers:

  • Могут оперативно разворачивать проектные решения на пресейл-полигоне.

Открытые вопросы

Я мечтаю делать копию полигона за час, но в реальности все немного сложнее и существует ряд открытых вопросов

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

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

• Внедрение изменений — перестроение процессов и подходов. Для того, чтобы конвейер работал, ему прежде всего нужны dev, test и prod среды на проекте, а также организация конфигурирования не сразу на prod среде. Данный вопрос — типовая задача управления, главное только захотеть и начать внедрять изменения.

---

Если коротко

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

Автоматизация конфигурирования с помощью утилит и конвейера поставки конфигураций адаптирует принцип разработки ПО Configuration as a Code ко внедрению ПО и позволяет сократить трудозатраты на внедрение и повысить его качество.

Спасибо за внимание, обязательно оставляйте свою обратную связь в комментариях