Ну всё, шутки в сторону — поговорим о вечном. В этом посте вы не найдете брызг радости или намека на легкость бытия. Потому что он для тех, кто боролся и искал, проходя каждый новый круг апгрейда 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
Проблема Решение
Состав таблиц, колонок и индексов в БД не соответствуют метаданным в репозитории, что препятствует накату изменений схемы данных. Ручная работа по исправлению всех конфликтов.
Пользовательские серверные и браузерные скрипты, которые после апгрейда стали препятствовать успешному запуску системы. Отключение и переписывание (исправление) таких скриптов.
Объемы данных и производительность сервера БД не позволяли выполнить работы за объективное (планируемое) время.
  1. Заказать оборудование, которое будет соответствовать сайзингу под новую версию системы.
  2. Возможно, потребуется произвести тюнинг производительности системы, отладку медленных 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.

Мораль


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

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

Комментарии (0)