Ну всё, шутки в сторону — поговорим о вечном. В этом посте вы не найдете брызг радости или намека на легкость бытия. Потому что он для тех, кто боролся и искал, проходя каждый новый круг апгрейда 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
- Подготовка репозиториев и сред к объединению.
- Непосредственное объединение на среде обновления (DEV) (IRM).
- Анализ и разрешение конфликтов.
- Применение изменений к среде обновления.
- Регрессионное тестирование.
- Исправление всех дефектов, появившихся в ходе обновления.
- Миграция со среды обновления на препродакшн и далее на продакшн.
В чем польза перехода на IP17+
- Новый движок: OpenUI – возможность более глубокой настройки интерфейса, повышающей юзабилити системы.
- Функционал анализа поведения пользователей в системе (Usage Pattern Tracking) позволит создать уникальный UX.
- Кросс-браузерная поддержка: IE больше не ограничение — теперь можно работать в Edge, Firefox, Chrome и Safari.
- Средство WebTools (Composer) дает возможность вносить изменения в интерфейс и в бизнес-логику cистемы из браузера, не требуя перезагрузки сервера, т.е. без даунтайма. Прототипирование разработки происходит быстрее.
- Технология CI/CD, автоматизация переноса патчей, параллельная разработка, автотестирование.
- Поддержка технологии интеграции REST, которая хорошо применима при интеграции с клиентскими порталами.
- Отраслевые инновации: от построения красивых аналитических дешбордов на популяроной библиотеке JS до технологий Big Data и Machine Learning.
Залог успешного апгрейда
IRM определяет набор расхождений в объектах и свойствах, которые присутствуют в оригинальном репозитории, в версии заказчика и в новой версии. Функционал позволяет на основе решения разработчика выбрать способ объединения объектов и на последнем этапе запустить эффективный процесс миграции обновленного репозитория со среды обновления на продуктив.
В ходе объединения возникают конфликты, то есть расхождения свойств объекта текущего репозитория с тем же объектом репозитория новой версии.
Некритические конфликты — это расхождения по объектам, которые не были затронуты заказчиком, т.е. расхождения между оригинальным репозиторием и новым. 99% таких конфликтов решаются в пользу нового репозитория.
Критические конфликты — это расхождения по объектам между репозиторием клиента и новым репозиторием.
Если с самого начала проекта следовать методологии Oracle, последующие апгрейды потребуют минимальных затрат. Но, к сожалению, очень часто лучшие практики от Oracle приносятся в жертву при выполнении тех или иных требований заказчика. Например, таблицы системы иногда изменяют напрямую через БД, что не фиксируется в репозитории Siebel. Или изменяют пользовательские ключи (UK), размерности и тип стандартных колонок стандартных таблиц, что Oracle настоятельно рекомендует не делать. Это приводит к невозможности автоматического перестроения таблицы в процессе миграции на продуктив и потребует множества ручных манипуляций с таблицами и данными. Кроме того, изменение стандартных ключей и колонок может повлиять на работоспособность новых процессов, разработанных под новую версию Siebel.
Поэтому важно, чтобы система внедрялась под контролем сертифицированных специалистов с большим опытом внедрения.
Однако самое главное в проекте апгрейда — грамотное планирование процесса, в ходе которого необходимо решить сразу несколько вопросов.
Инфраструктура решения
- Кто будет заниматься настройкой инфраструктуры:
- развертывать серверы
- ставить ОС
- настраивать ДБО
- Описание среды обновления. Где будем делать IRM?
- Описание среды тестирования. Как будем тестировать (в т.ч. внешние системы и интеграцию)?
- Описание среды внедрения. Будем обновлять текущий продуктив или настроим параллельную production-среду?
Детальный план проекта (с учетом распределения ответственности между заказчиком и исполнителем)
- Нужно учесть, что потребуется «заморозка» работ по внедрению нового функционала на продуктив.
- В т.ч. нужно учесть, что потребуется произвести переустановку всех пакетов функционала, которые ушли в продуктив после начала проекта апгрейда.
План тестирования
- Нужно составить сценарии регрессионного тестирования.
- Обозначить ответственных и определить команду тестировщиков как CRM, так и внешних систем.
План внедрения
- Составить чек-лист работ по внедрению апгрейда в продуктив.
- Составить план отката (да-да!;), в случае если произойдет авария при апгрейде.
Отдельно имеет смысл провести полный аудит системы (или даже заказать его у вендора), чтобы выяснить какие нарушения методологии и технические ошибки реализации допустил разработчик. Аудит проводится сертифицированными специалистами Oracle, результаты фиксируются в виде «фирменных» протоколов Oracle Siebel:
- Отчет о конфигурации (ошибки или нарушения в конфигурации бизнес-логики)
- Отчет об интеграции (ошибки или нарушения в интеграционных объектах)
- Отчет о скриптах (ошибки или нарушения в программируемых модулях)
- Ошибки в процессах (ошибки в workflow и автоматизированных функциях)
Дело в том, что в модифицированном функционале возможны ошибки. На этапе регрессионного тестирования объединенного решения нужно будет точно понимать, какая ошибка появилась в результате объединения, а какая была изначально.
Наиболее значимые проблемы при апгрейде Siebel
| Проблема | Решение |
|---|---|
| Состав таблиц, колонок и индексов в БД не соответствуют метаданным в репозитории, что препятствует накату изменений схемы данных. | Ручная работа по исправлению всех конфликтов. |
| Пользовательские серверные и браузерные скрипты, которые после апгрейда стали препятствовать успешному запуску системы. | Отключение и переписывание (исправление) таких скриптов. |
| Объемы данных и производительность сервера БД не позволяли выполнить работы за объективное (планируемое) время. |
|
| Отсутствие сценариев тестирования и другой документации на систему. | Написание новой документации. |
| Неактуальный репозиторий в продуктивной среде. | Работы по актуализации репозитория. |
| «Мусорная» конфигурация серверной инфраструктуры: включены неиспользуемые компоненты системы, не документированы изменения параметров сервера и профилей предприятия. | Провести полную ревизию инфраструктуры, документировать конфигурацию системы, отключить неиспользуемые серврные компоненты. |
| В системе применялись пользовательские 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.
Мораль
Очевидно, что подобные проекты требуют привлечения опытных консультантов (куда ж без них), которые способны предусмотреть и обойти подводные камни, грамотно спланировать такой процесс апгрейда, при котором заказчик не окажется у разбитого корыта. Т.е. минимизировать и даже исключить риски длительного простоя системы, потери данных, критических ошибок в бизнес-процессах после апгрейда. Например, неправильный выбор ключа таблицы может повлечь за собой широкомасштабную переработку процессов в системе — и тогда простое обновление рискует превратиться в проект на несколько месяцев.
Максим Чугункин, руководитель группы системной архитектуры «Инфосистемы Джет»