Оглавление

Спецификации проекта

Обоснование проекта

Краткое описание обновляемой инсталляции

График проекта

Greenfield vs. Brownfield

Oracle vs. SAP HANA

Организация двойного ландшафта

Реализация. «Превратности метода»

Апгрейд

Хроника апгрейда

Стабилизация

Заключение

В данной статье мы хотели бы поделиться опытом обновления SAP Solution Manager (далее – SolMan) на версию 7.2 в группе компаний Северсталь, где SolMan является не просто инструментом для обновления SAP-систем и поставки стандартных сервисов SAP, а одной из самых больших инсталляций, как по масштабам используемого функционала, так и по количеству пользователей, на территории региона СНГ.

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

Спецификации проекта

Обоснование проекта

Главным обоснованием проекта послужил выход из поддержки (Mainstream Maintenance) версии 7.1 с 31.12.2017г., что само по себе не очень критично, т.к. режим Extended Maintenance означает, что корпорация SAP будет исправлять ранее известные ошибки, а финансовые риски могут наступить только при обнаружении новых.

Еще одним поводом стало предложение по реализации текущих запросов на изменение на базе новой версии SAP Solution Manager, т.к. с обновлением версии ключевых компонент SAP BASIS и SAP ABAP c версии 7.02 на 7.40 возникал вопрос адаптации реализуемых изменений версии 7.1 для версии 7.2.

Краткое описание обновляемой инсталляции

Исходная версия: 7.1 SP14

Целевая версия: 7.2 SP05

Исходная\Целевая версия БД: ORACLE 11.2.0.3.0

Продуктивная эксплуатация c 2008 г. (обновление на версию 7.1 в 2013 г.)

Используемые модули: IT Service Management (ITSM), Change Request Management (ChaRM), Solution Documentation (SolDoc), Technical Monitoring (TechMon), Business Process Monitoring (BPMon), Test Management, Job Scheduling Management (JSM)

Кол-во конечных пользователей: ~15.000

Кол-во консультантов по поддержке: ~500

Кол-во управляемых систем: ~200

База обращений: ~1.000.000 (~10.000 ежемесячно)

База документов изменений: ~50.000 (~1500 ежемесячно)

График проекта

Проект содержал 3 фазы:

• Дизайн (обоснование, планирование, проектирование, организация ландшафта) – июль-октябрь 2017 г.
• Реализация (установка нот, тестирование и исправление ошибок, сам апгрейд) – ноябрь 2017 г. - начало марта 2018 г.
• Стабилизация (эксплуатация в продуктивном режиме) – март-май 2018 г.

Greenfield vs. Brownfield

Во время обсуждения подходов по реализации данного проекта прорабатывался вариант перехода на 7.2 на базе новой инсталляции (greenfield), однако окончательный выбор был сделан в пользу апгрейда текущей инсталляции (brownfield).

За Greenfield:

• Полный back-to-standard;
• Экономия трудозатрат на апгрейде;
• Возможность более быстрого и предсказуемого старта с параллельной эксплуатацией, где переход на версию 7.2 практически отсекался бы переключением управляемых систем на новую инсталляцию.

Против Greenfield:

• Дополнительные трудозатраты на повторение базисных и прикладных настроек;
• Дополнительные трудозатраты на миграцию транзакционных данных (обращения пользователей и контент по управлению документацией);
• Дополнительные трудозатраты на миграцию основных данных (пользователи, роли и их присвоения, бизнес-партнеры и т.д.);
• Дополнительные трудозатраты на перепроектирование и реализацию Z-разработок;
• Дополнительные трудозатраты на переключение всех управляемых систем на новую инсталляцию;
• Рекомендация инженеров SAP обновлять версию посредством апгрейда текущей инсталляции.

Oracle vs. SAP HANA

На момент проработки обоснования проекта обсуждался вопрос о переходе на SAP HANA. После оценки всех «за» и «против» было решено остаться на Oracle.

За SAP HANA:

• Повышенная репутация проекта (в силу инновационности SAP HANA);
• Потенциальное повышение производительности;
• Инструментарий формирования отчетности

Против SAP HANA:

• Особые требования к аппаратному обеспечению для SAP HANA;
• Потенциальные риски дополнительных трудозатрат на адаптацию Z-разработок;
• Потенциальные риски дополнительных трудозатрат на возможные исправления ошибок по результатам конверсии БД.

Организация двойного ландшафта

По опыту проектов c двойным ландшафтом, где Solution Manager являлся инструментом организации и синхронизации изменений между проектным ландшафтом и ландшафтом поддержки, системный ландшафт самого Solution Manager было решено организовать аналогичным образом (Рис.1.)

Рис 1. Организация системного ландшафта самого Solution Manager

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

После апгрейда продуктивной системы система разработки D71 была выведена из эксплуатации;  проектный ландшафт стал ландшафтом поддержки. Такой подход в нашей