Системный ландшафт

Вебинар «ADR: системный подход к проектированию ИТ-ландшафта» // КОРУС Консалтинг [1:05:18]

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

Общая информация

Системный ландшафт имеет как минимум два измерения:

1. Состав систем и приложений
2. Управление жизненным циклом системы/приложения.

В первом случае системный ландшафт описывает набор систем/приложений и их взаимодействие, например: ERP, CRM, ESB, WMS и т. д.

Во втором случае для каждой системы/приложения описывается путь прохождения изменения от разработки до продуктивного использования.

Наиболее типичным системным ландшафтом является трёхсистемный, состоящий из следующего минимального набора систем:

• DEV (development, или D) — система, в которой разработчики пишут код приложения, меняют структуры данных, в которую разворачиваются полученные от поставщика решения обновления и исправления. В ней разработчики выполняют свою часть тестирования в соответствии с принятой. В эту систему могут быть допущены поставщики и подрядчики, участвующие во внедрении. После успешного завершения этой части тестирования, разработчики или поддержка переносят изменения (код, структуры данных) в тестовую систему.
• TEST (test, T, QA, Quality Assurance, Q) — система, в которой тестировщиками и/или поддержкой проводится основное тестирование сделанных изменений. В эту систему могут быть допущены поставщики и подрядчики, участвующие во внедрении. После успешного прохождения тестирования в TEST, принимается решение о переносе в продуктивную систему.
• PROD (production, продуктив, P) — система, в которой конечные пользователи работают с реальными данными, в которой бизнес принимает решения и выполняет транзакции. В этой системе разработчики, тестировщики и поддержка не должны иметь полномочий, или они должны быть существенно ограничены. Поставщики и подрядчики, участвующие во внедрении, не могут иметь доступ в PROD.

Необходимость такого разделения продиктована следующими соображениями:

• Ошибки, возникающие на этапе разработки (развёртывания обновлений, исправлений) должны быть максимально выявлены до переноса в продуктив. Поэтому они проходят полный цикл всех видов тестирования в допродуктивных средах.
• Доступ к бизнес-данным в продуктиве могут иметь только тот круг лиц, которым они реально необходимы для работы и никто более.
• Разработка и тестирование должны быть разделены между разными сотрудниками — разработчиками и тестировщиками соответственно.
• При переносе из DEV в TEST проверяется качество переноса и подтверждается, что перенос из TEST в PROD произойдёт так же гладко.

Помимо описанного минимального ландшафта, он может быть расширен другими системами в соответствии с задачами, например:

• TRAIN(Учебная система) — система с учебными данными для обучения пользователей — периодически обновляемая из архива
• SAND(Песочница, Sandbox) — система для проверки любых идей и концепций, где можно пробовать что угодно и не бояться повредить работу коллег. В любой момент она легко восстанавливается из архива в прежнее состояние.
• GOLD(Эталон, Золотой стандарт) — иногда создаётся копия системы с эталонными настройками, чтобы можно было их изучать, копировать
• PREPROD/STAGE(предпродуктивная, стажировочная) — иногда вводится дополнительная среда перед продуктивом для выполнения дополнительных тестов, например, нагрузочного тестирования или тестирования миграции начальных данных.
• DEV2/TEST2 — применяется в случае, если компания одновременно ведёт эксплуатацию системы и проект по её доработке. В этом случае одна линейка систем используется для поддержки (если возникает срочное изменение/исправление, поддержка проводит его реализацию, развёртывание, тестирование в линейке DEV/TEST), а другая используется для разработки и тестирования новой функциональности командой проекта.

Маршрут прохождения изменений по системам от DEV в PROD может динамически меняться администратором в зависимости от текущих задач.

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

Источники

Одним из источников этой статьи является статья в википроекте «Руниверсалис» («Руни», руни.рф), называющаяся «Системный ландшафт». Материал указанной статьи полностью или частично использован в Циклопедии по лицензии CC BY-SA. Всем участникам Руниверсалиса предлагается прочитать «Обращение к участникам Руниверсалиса» основателя Циклопедии и «Почему Циклопедия?».