В этом посте вы не найдете брызг радости или намека на легкость бытия. Потому что он для тех, кто боролся и искал, проходя каждый новый круг апгрейда 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?
Проблема 1: состав таблиц, колонок и индексов в БД не соответствуют метаданным в репозитории, что препятствует накату изменений схемы данных. Решение: ручная работа по исправлению всех конфликтов.
Проблема 2: пользовательские серверные и браузерные скрипты, которые после апгрейда стали препятствовать успешному запуску системы. Решение: отключение и переписывание (исправление) таких скриптов.
Проблема 3: Объемы данных и производительность сервера БД не позволяли выполнить работы за объективное (планируемое) время. Решение:
- заказать оборудование, которое будет соответствовать сайзингу под новую версию системы;
- возможно, потребуется произвести тюнинг производительности системы, отладку медленных SQL и т.п.
Проблема 4: отсутствие сценариев тестирования и другой документации на систему. Решение: написание новой документации.
Проблема 5: неактуальный репозиторий в продуктивной среде. Решение: работы по актуализации репозитория.
Проблема 6: «мусорная» конфигурация серверной инфраструктуры: включены неиспользуемые компоненты системы, не документированы изменения параметров сервера и профилей предприятия. Решение: Провести полную ревизию инфраструктуры, документировать конфигурацию системы, отключить неиспользуемые серврные компоненты.
Проблема 7: в системе применялись пользовательские ActiveX, которые на новой версии становятся не поддерживаемыми, т.к. Oracle отказался от поддержки этого фреймворка. Решение: переписать ActiveX для использования DISA (новая технология Siebel).
Проблема 8: устаревшие версии OS и БД. Решение: планирование работ по обновлению ПО инфраструктуры.
Проблема 9: проблема с сертификатами. Решение: для HTTPS нужен подписанный сертификат, который проходит валидацию системы.
Проблема 10: модернизации системы шифрования, переход на AES. Решение: потребует перешифровать все ранее зашифрованные данные (пароли и т.п.).
Проблема 11: обучение пользователей интерфейсу OpenUI. Решение: несмотря на то, что интерфейс сохранил принципы Siebel, в отдельных случаях может потребоваться переобучение персонала.
Проблема 12: перевод встроенной отчетности на Oracle BI Publisher. Решение: применимо к более старым версиям системы, где используется Actuate Reports.
Проблема 13: 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.
Мораль
Очевидно, что подобные проекты требуют привлечения опытных консультантов (куда ж без них), которые способны предусмотреть и обойти подводные камни, грамотно спланировать такой процесс апгрейда, при котором заказчик не окажется у разбитого корыта.
Т.е. минимизировать и даже исключить риски длительного простоя системы, потери данных, критических ошибок в бизнес-процессах после апгрейда. Например, неправильный выбор ключа таблицы может повлечь за собой широкомасштабную переработку процессов в системе — и тогда простое обновление рискует превратиться в проект на несколько месяцев.
Максим Чугункин, руководитель группы системной архитектуры «Инфосистемы Джет»