Ну всё, шутки в сторону — поговорим о вечном. В этом посте вы не найдете брызг радости или намека на легкость бытия. Потому что он для тех, кто боролся и искал, проходя каждый новый круг апгрейда Siebel. Начиная с 2013 года, Oracle проводит кампанию по принципиальной модернизации CRM-системы. На текущий момент мы уже пережили семь (c IP13 до IP19) инновационных пакетов изменений (Innovation Packs). До 2013 года релизы выпускались раз в 2–3 года, последние 5–6 лет обновления Siebel публиковались намного чаще, выдерживая четкий график: минорные релизы (patchset) выходили ежемесячно, принципиально новые версии (major) — ежегодно и зачастую это означало для клиента необходимость глобальной переработки или даже «перевнедрения» своей системы. Для упрощения апгрейдов Siebel вендор разработал IRM (Incremental Repository Merge) — функционал облегчающий процесс установки новых версий c пакетами инноваций. О нем и пойдет речь.

Принцип IRM

Для того чтобы обновить систему на новую версию c Innovation Pack, необходимо обновить репозиторий системы. Для этого нужно произвести объединение с репозиторием новой версии.
Репозиторий — это метаданные системы, т.е. схемы всего, что является ее функционалом. За время проекта, разработчики-консультанты заказчика (потребителя Siebel) вносят в репозиторий тысячи изменений. Однако в поставке релиза от Oracle эти изменения отсутствуют, а сам вендор, дорабатывая систему, добавляет новые метаданные и вообще может полностью переработать ту или иную схему объектов.

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

Задачи, решаемые в ходе апгрейда Siebel

1. Подготовка репозиториев и сред к объединению.
   
2. Непосредственное объединение на среде обновления (DEV) (IRM).
   
3. Анализ и разрешение конфликтов.
   
4. Применение изменений к среде обновления.
   
5. Регрессионное тестирование.
   
6. Исправление всех дефектов, появившихся в ходе обновления.
   
7. Миграция со среды обновления на препродакшн и далее на продакшн.
   

В чем польза перехода на IP17+

1. Новый движок: OpenUI – возможность более глубокой настройки интерфейса, повышающей юзабилити системы.
   
2. Функционал анализа поведения пользователей в системе (Usage Pattern Tracking) позволит создать уникальный UX.
   
3. Кросс-браузерная поддержка: IE больше не ограничение — теперь можно работать в Edge, Firefox, Chrome и Safari.
   
4. Средство WebTools (Composer) дает возможность вносить изменения в интерфейс и в бизнес-логику cистемы из браузера, не требуя перезагрузки сервера, т.е. без даунтайма. Прототипирование разработки происходит быстрее.
   
5. Технология CI/CD, автоматизация переноса патчей, параллельная разработка, автотестирование.
   
6. Поддержка технологии интеграции REST, которая хорошо применима при интеграции с клиентскими порталами.
   
7. Отраслевые инновации: от построения красивых аналитических дешбордов на популяроной библиотеке JS до технологий Big Data и Machine Learning.
   

Залог успешного апгрейда

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

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

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

Критические конфликты — это расхождения по объектам между репозиторием клиента и новым репозиторием.

Если с самого начала проекта следовать методологии Oracle, последующие апгрейды потребуют минимальных затрат. Но, к сожалению, очень часто лучшие практики от Oracle приносятся в жертву при выполнении тех или иных требований заказчика. Например, таблицы системы иногда изменяют напрямую через БД, что не фиксируется в репозитории Siebel. Или изменяют пользовательские ключи (UK), размерности и тип стандартных колонок стандартных таблиц, что Oracle настоятельно рекомендует не делать. Это приводит к невозможности автоматического перестроения таблицы в процессе миграции на продуктив и потребует множества ручных манипуляций с таблицами и данными. Кроме того, изменение стандартных ключей и колонок может повлиять на работоспособность новых процессов, разработанных под новую версию Siebel.
Поэтому важно, чтобы система внедрялась под контролем сертифицированных специалистов с большим опытом внедрения.

Однако самое главное в проекте апгрейда — грамотное планирование процесса, в ходе которого необходимо решить сразу несколько вопросов.

Инфраструктура решения

• Кто будет заниматься настройкой инфраструктуры:
  
  • развертывать серверы
  • ставить ОС
  • настраивать ДБО
• Описание среды обновления. Где будем делать IRM?
• Описание среды тестирования. Как будем тестировать (в т.ч. внешние системы и интеграцию)?
• Описание среды внедрения. Будем обновлять текущий продуктив или настроим параллельную production-среду?

Детальный план проекта (с учетом распределения ответственности между заказчиком и исполнителем)

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

План тестирования

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

План внедрения

• Составить чек-лист работ по внедрению апгрейда в продуктив.
• Составить план отката (да-да!;), в случае если произойдет авария при апгрейде.

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

1. Отчет о конфигурации (ошибки или нарушения в конфигурации бизнес-логики)
   
2. Отчет об интеграции (ошибки или нарушения в интеграционных объектах)
   
3. Отчет о скриптах (ошибки или нарушения в программируемых модулях)
   
4. Ошибки в процессах (ошибки в workflow и автоматизированных функциях)
   

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

Наиболее значимые проблемы при апгрейде Siebel

Проблема	Решение
Состав таблиц, колонок и индексов в БД не соответствуют метаданным в репозитории, что препятствует накату изменений схемы данных.	Ручная работа по исправлению всех конфликтов.
Пользовательские серверные и браузерные скрипты, которые после апгрейда стали препятствовать успешному запуску системы.	Отключение и переписывание (исправление) таких скриптов.
Объемы данных и производительность сервера БД не позволяли выполнить работы за объективное (планируемое) время.	Заказать оборудование, которое будет соответствовать сайзингу под новую версию системы. Возможно, потребуется произвести тюнинг производительности системы, отладку медленных SQL и т.п.
Отсутствие сценариев тестирования и другой документации на систему.	Написание новой документации.
Неактуальный репозиторий в продуктивной среде.	Работы по актуализации репозитория.
«Мусорная» конфигурация серверной инфраструктуры: включены неиспользуемые компоненты системы, не документированы изменения параметров сервера и профилей предприятия.	Провести полную ревизию инфраструктуры, документировать конфигурацию системы, отключить неиспользуемые серврные компоненты.
В системе применялись пользовательские ActiveX, которые на новой версии становятся не поддерживаемыми, т.к. Oracle отказался от поддержки этого фреймворка.	Переписать ActiveX для использования DISA (новая технология Siebel).
Устаревшие версии OS и БД.	Планирование работ по обновлению ПО инфраструктуры.
Проблема с сертификатами.	Для HTTPS нужен подписанный сертификат, который проходит валидацию системы.
Модернизации системы шифрования, переход на AES.	Потребует перешифровать все ранее зашифрованные данные (пароли и т.п.).
Обучение пользователей интерфейсу OpenUI.	Несмотря на то, что интерфейс сохранил принципы Siebel, в отдельных случаях может потребоваться переобучение персонала.
Перевод встроенной отчетности на Oracle BI Publisher.	Применимо к более старым версиям системы, где используется Actuate Reports.
PL\SQL-пакеты перестали работать после апгрейда.	Пересмотреть и отладить.

Последний IRM, или Как обновится до самой последней версии Siebel (IP19)

За прошедшие 2 года в системе Siebel произошли большие изменения, которые повлекли за собой и изменение подхода к обновлению системы.

Ключевые изменения связаны с выходом IP17 в 2017 году и его последующими обновлениями

• Переработана модель данных системы, вендор отказался от SRF-файлов компиляции, используемых при старте сервера. Появился Runtime Repository, который позволяет вносить изменения в конфигурацию системы без ее перезагрузки.
  
• Siebel Web Server превратился в самостоятельный компонент Siebel, с этого момента более не требуются компоненты типа IIS и Apache от сторонних производителей. Siebel WebServer получил название Application Interface (AI), он работает на базе Tomcat-контейнера. Все подключения к AI осуществляются только по HTTPS, т.е. весь трафик по умолчанию зашифрован. AI имеет полную поддержку REST как входящих запросов, так и исходящих (технология REST дает большую гибкость в установке доработок на систему и в процессе апгрейда репозиториев).
  
• Модернизирован компонент Gateway (теперь он называется Dynamic Gateway). Особо стоит упомянуть о переработанной внутренней межкомпонентной балансировке. За нее теперь отвечает Gateway (Gateway Elastic Load Balancer), что делает систему балансировки нагрузки более гибкой — ранее эту функцию выполнял сервер приложений.
  
• Система официально поддерживает БД Oracle 12 (поддержка БД Oracle 11g завершена).
  

В 2018 году Oracle сменил релизную политику для Siebel CRM

• Все будущие нововведения и исправления будут поставляться как обновления, то есть патчсеты, устанавливаемые из дистрибутива на текущую версию (начиная с IP17). Они будут содержать нововведения, ранее обозначенные вендором в стратегии развития системы.
  
• Наименования патчсетов станут более понятными, т.к. версии выходят ежемесячно: например, номер 18.4 будет означать «Апрель 2018 года».
  
• Новая модель поставки начнется именно с версии 18.4. Последней версией по старой модели стала 17.6. Чтобы перейти с 17.6 на 18.4 нужно будет всего лишь установить дистрибутив (как патч, а не как апгрейд IRM). Последующие ежемесячные обновления могут содержать функционал, для которого потребуется произвести загрузку небольшого пакета изменений через специальную утилиту. Причем все обновления будут кумулятивные.
  
• В связи с изменением модели клиенты, перешедшие на IP17, более не столкнуться с проблемой отсутствия патча для их версии системы. При этом существенно упрощается процесс апгрейда системы снижается стоимость поддержки, ускоряется внедрение инновационного функционала.
  
• Для перехода, например, на версию 19 с ранних версий Siebel (до 17) необходимо будет реализовать стандартный апгрейд на версию 17, а далее — с применением новой модели обновлений.
  

Изменения в подходе к апгрейду до IP17+

При проектировании инфраструктуры и проведении сайзинга нужно учитывать новую серверную инфраструктуру IP17. Требования к железу будут повышены, т.к. Runtime Repository требует больше ресурсов. Отказоустойчивая балансировка новых компонентов Application Interface и Gateway рекомендует 3 компоненты вместо 2. Потребуется пересмотреть и перенести конфигурацию серверов и серверные профили предприятия на новую архитектуру IP17.

Также необходимо будет перенести все веб-артефакты, такие как HTML-шаблоны, JS, CSS и т.п., на новый веб-сервер Application Interface. Кстати, все веб-артефакты со временем переедут в репозиторий системы.

Следующие шаги — обновление операционной системы и БД до поддерживаемых версий (нужно свериться с вкладкой сертификации ПО для Siebel на Oracle Support) и выпуск корректного сертификата HTTPS.

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

Если параллельно с апгрейдом до IP17+ вы разрабатываете новый функционал на вашей текущей версии системы, то его необходимо будет повторно протестировать и актуализировать сопроводительную документацию. А разработчиков и администраторов — обучить работе с технологией Workspace, утилитой Migration Tool и новой Management Console управления инфраструктурой Siebel.

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

Source Version***	Target Version	Upgrade	IRM	Approach	Description
17.0 – 17.6 18.4-18.12 19.1-19.x	19.x		V	Single Step Incremental Upgrade	Apply the 19.x update. In some cases, depending on the content in the Update to uptake, an IRM (Incremental Repository Merge) process may be required.
16.0 – 16.x 15.0 – 15.x 8.2.2.0 – 8.2.2.4 8.1.1.0-8.1.1.14 SIA 8.2.1.x SIA 8.2.x SIA 8.1.1.0-8.1.1.7 SEA	19.x	V		Two Step Upgrade	Install 17.0 binaries Perform a full database upgrade (Development Upgrade + Production Upgrade) > Post upgrade, the New Customer repository generated through 3-way repository merge contains all the release content of 17.0. Apply the 19.x update
8.0.x SIA / SEA 7.8.2.x SIA / SEA 7.7.2.x SIA 7.5.3.x SIA	19.x	V		Three Step Upgrade	Perform full upgrade to 8.1.1 SIA base release Perform IRM patch from 8.1.1 SIA to 17.0 Apply the 19.x update
7.5.3.x SEA 7.7.2.x SEA	19.x	V		Three Step Upgrade	Perform full upgrade to 8.1.1 SEA base release Perform full upgrade patch from 8.1.1 SEA to 17.0 Apply the 19.x update

*** For more information on SEA and SIA Siebel CRM releases, please refer to My Oracle Support article 1514115.1.

Мораль

Очевидно, что подобные проекты требуют привлечения опытных консультантов (куда ж без них), которые способны предусмотреть и обойти подводные камни, грамотно спланировать такой процесс апгрейда, при котором заказчик не окажется у разбитого корыта. Т.е. минимизировать и даже исключить риски длительного простоя системы, потери данных, критических ошибок в бизнес-процессах после апгрейда. Например, неправильный выбор ключа таблицы может повлечь за собой широкомасштабную переработку процессов в системе — и тогда простое обновление рискует превратиться в проект на несколько месяцев.

Максим Чугункин, руководитель группы системной архитектуры «Инфосистемы Джет»