Последний IRM — апгрейдим Siebel до IP17+

Ну всё, шутки в сторону — поговорим о вечном. В этом посте вы не найдете брызг радости или намека на легкость бытия. Потому что он для тех, кто боролся и искал, проходя каждый новый круг апгрейда 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

Последний 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.

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

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

Мораль

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

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

Автор: JetHabr

Источник