Не так давно в посте "Почему SAP рекомендует 3-х системный ландшафт?" я описывал односистемный, двухсистемный и трёхсистемные ландшафты. В посте я показал, что трёхсистемный ландшафт является минимально достаточным для организации корректной разработки и контроля качества в SAP системе.
Таким образом, типовой SAP ландшафт (рис. 1) состоит из 3-х систем:
Остановимся на тестовой системе.
Тестовая система выполняет следующие основные функции:
Назначение тестовой системы подразумевает содержание большого объема мастер-данных. В идеале, всех данных продуктивной системы. Следовательно, при проектировании тестовой системы необходимо проработать план обновления этих данных из продуктивной системы с достаточной периодичностью. Частота обновления зависит от требований проекта, но ориентироваться можно на 1 раз в квартал.
Способы обновления могут быть следующими:
Перед обсуждением способов обновления данных остановлюсь еще на одном моменте. В идеальном мире архитектура серверов продуктивной и тестовой систем должна быть идентичной. Если бы это требование выполнялось в реальной жизни, то мой пост был бы в 2 раза короче. Но, к сожалению, в реальной жизни встречаются разные ситуации. При разной архитектуре продуктивной и тестовой систем тоже можно обеспечить приемлемое качество проекта. Протестировать разработки, перенос запросов, обучить пользователей и так далее. То есть процентов 80 запросов система покрывает. Но в данном случае обновление данных в тестовой системе имеет свои ограничения. Об этом сейчас и поговорим.
Итак, при создании тестовой системы смотрим на архитектуру оборудования, которое выделено под эти цели. Если архитектура отличается от продуктивной системы, то при создании тестовой системы придётся использовать процедуру гетерогенного копирования систем. Процедура длительная: требуется останов продуктивной системы и создание экспорта базы данных. Также в такой тестовой системе ограничен набор сценариев тестирования. Если в тестовой системе будет использоваться другая база данных, то тестирование разработок, в которых используется NativeSQL, вызывает большой вопрос. Тест производительности так же будет носить очень отдалённый характер, в силу больших различий со средой промышленной эксплуатации.
Если же архитектура идентична, то вопрос создания тестовой системы решается через гомогенное копирование. В качестве источника данных в данном случае отлично подойдёт существующая резервная копия продуктивной базы данных (offline или online + redo logs).
При периодическом обновлении мастер-данных в тестовой системе всё так же упирается в архитектуры продуктивной и тестовой систем. Если архитектуры разные, то можно использовать только следующие процедуры:
Если архитектура идентична, то проблем, конечно же, меньше. В данном случае можно использовать первые два способа, описанные выше: перенос содержимого списка таблиц и копирование манданта. Но оптимально будет использовать процедуру гомогенного копирования системы. Причем, её укороченный вариант. Только обновление данных базы данных.
Здесь я хочу плавно подвести к тому, что оптимальным вариантом при проектировании тестовой системы является выбор той же архитектуры, что и на системе промышленной эксплуатации. Хочу отметить, что я говорю про идентичность архитектуры и платформы, а не про идентичность в плане производительности. Нагрузка на тестовую систему гораздо ниже, чем на продуктивную. Следовательно, оборудование может быть "слабее". Какие плюсы мы получаем:
Если вы выполняли процедуру гомогенного копирования, то вы сможете выявить минимальное необходимое количество шагов для обновления данных из свежей резервной копии. Создавайте себе собственную инструкцию по обновлению, ищите моменты, где можно срезать углы, пишите скрипты для автоматизации действий, и тогда обновление тестовых данных не будет занимать слишком много времени.
При достаточном количестве ресурсов может быть принято решение о создании нескольких тестовых систем с разным срезом данных, под разные цели. Данные системы могут обновляться в цикле, по кругу. Пока будет обновляться одна система, другая (или другие) будут работать и обеспечивать возможность тестирования изменений перед импортом их в промышленную среду.
Автор: Шиболов Вячеслав Анатольевич
Таким образом, типовой SAP ландшафт (рис. 1) состоит из 3-х систем:
- система разработки и настройки (DEV),
- тестовая система или система контроля качества (QAS),
- продуктивная система или система промышленной эксплуатации (PRD).
 |
| Рис. 1. Трёхсистемный ландшафт. |
Остановимся на тестовой системе.
Тестовая система выполняет следующие основные функции:
- тестирование новых разработок и настроек,
- тестирование переноса изменений через транспортный запрос,
- тестирование ролей и полномочий,
- тестирование разработок на больших объемах данных, с целью решения проблем производительности,
- обучение пользователей.
Назначение тестовой системы подразумевает содержание большого объема мастер-данных. В идеале, всех данных продуктивной системы. Следовательно, при проектировании тестовой системы необходимо проработать план обновления этих данных из продуктивной системы с достаточной периодичностью. Частота обновления зависит от требований проекта, но ориентироваться можно на 1 раз в квартал.
Способы обновления могут быть следующими:
- обновление через копирование содержимого отдельных таблиц,
- обновление через копирование манданта,
- обновление через гетерогенное копирование системы,
- обновление через гомогенное копирование системы.
Перед обсуждением способов обновления данных остановлюсь еще на одном моменте. В идеальном мире архитектура серверов продуктивной и тестовой систем должна быть идентичной. Если бы это требование выполнялось в реальной жизни, то мой пост был бы в 2 раза короче. Но, к сожалению, в реальной жизни встречаются разные ситуации. При разной архитектуре продуктивной и тестовой систем тоже можно обеспечить приемлемое качество проекта. Протестировать разработки, перенос запросов, обучить пользователей и так далее. То есть процентов 80 запросов система покрывает. Но в данном случае обновление данных в тестовой системе имеет свои ограничения. Об этом сейчас и поговорим.
Итак, при создании тестовой системы смотрим на архитектуру оборудования, которое выделено под эти цели. Если архитектура отличается от продуктивной системы, то при создании тестовой системы придётся использовать процедуру гетерогенного копирования систем. Процедура длительная: требуется останов продуктивной системы и создание экспорта базы данных. Также в такой тестовой системе ограничен набор сценариев тестирования. Если в тестовой системе будет использоваться другая база данных, то тестирование разработок, в которых используется NativeSQL, вызывает большой вопрос. Тест производительности так же будет носить очень отдалённый характер, в силу больших различий со средой промышленной эксплуатации.
Если же архитектура идентична, то вопрос создания тестовой системы решается через гомогенное копирование. В качестве источника данных в данном случае отлично подойдёт существующая резервная копия продуктивной базы данных (offline или online + redo logs).
При периодическом обновлении мастер-данных в тестовой системе всё так же упирается в архитектуры продуктивной и тестовой систем. Если архитектуры разные, то можно использовать только следующие процедуры:
- копирование содержимого отдельных таблиц: позволяет обновить только один функциональный модуль или его часть. Очень медленный способ. Перенос данных выполняется через транспортный запрос. Как включить содержимое таблицы в транспортный запрос я описывал в этом посте. При повторном переносе можно воспользоваться советом из поста "Саповские секретики - III (секретик 2)" и, создавать новый запрос через копию содержимого старого запроса. Процедура возможна только в крайнем случае и только при контроле и управлении со стороны опытного функционального консультанта. Результат не всегда гарантирован. Но в практике иногда применяется.
- копирование манданта системы: возможно использование процедуры удаленного копирования манданта или экспорта/импорта манданта. Все способы описаны в этом посте. Процедура очень сильно нагружает обе системы (продуктивную и тестовую), работа в продуктивной системе должна быть минимальна, иначе высока вероятность возникновения проблем с целостностью данных.
- гетерогенное копирование системы - фактически полное удаление и установка тестовой системы по новой. Требует останова продуктивной системы на момент создания экспорта данных. Длительные временные затраты на создание копии в целом.
Если архитектура идентична, то проблем, конечно же, меньше. В данном случае можно использовать первые два способа, описанные выше: перенос содержимого списка таблиц и копирование манданта. Но оптимально будет использовать процедуру гомогенного копирования системы. Причем, её укороченный вариант. Только обновление данных базы данных.
Здесь я хочу плавно подвести к тому, что оптимальным вариантом при проектировании тестовой системы является выбор той же архитектуры, что и на системе промышленной эксплуатации. Хочу отметить, что я говорю про идентичность архитектуры и платформы, а не про идентичность в плане производительности. Нагрузка на тестовую систему гораздо ниже, чем на продуктивную. Следовательно, оборудование может быть "слабее". Какие плюсы мы получаем:
- возможность полного тестирования любых функциональностей и разработок в среде, максимально приближенной к продуктивной,
- тестовую среду, позволяющую проводить нагрузочное тестирование с выявлением узких мест в производительности разработок,
- несложную процедуру обновления данных с получением почти 100 % идентичной продуктивной среды,
- периодическое тестирование процедуры восстановления из резервной копии продуктивной системы с высчитыванием интервалов необходимых на процедуру восстановления для прогнозирования временных затрат в случае сбоя среды промышленной эксплуатации.
Если вы выполняли процедуру гомогенного копирования, то вы сможете выявить минимальное необходимое количество шагов для обновления данных из свежей резервной копии. Создавайте себе собственную инструкцию по обновлению, ищите моменты, где можно срезать углы, пишите скрипты для автоматизации действий, и тогда обновление тестовых данных не будет занимать слишком много времени.
При достаточном количестве ресурсов может быть принято решение о создании нескольких тестовых систем с разным срезом данных, под разные цели. Данные системы могут обновляться в цикле, по кругу. Пока будет обновляться одна система, другая (или другие) будут работать и обеспечивать возможность тестирования изменений перед импортом их в промышленную среду.
Автор: Шиболов Вячеслав Анатольевич
