Содержание курса

В предыдущих частях мы рассмотрели основные слои архитектуры, отправляясь от Бизнес-процессов и производственных ресурсов к порождаемым ими Информационным потокам, которые собираются и обрабатываются в слое Прикладных решений и плавно подошли к технологическому слою, обеспечивающему весь комплекс в физическим воплощением.

Техническая архитектура предприятия (ETA - Enterprise Technical Architecture) – это совокупность программно-аппаратных средств, методов и стандартов, поддерживающих эффективное функционирование приложений, и обеспечивающих стабильность, масштабируемость, безопасность.

С другой стороны, можно констатировать, что основное предназначение технологической архитектуры – это обеспечение надежных ИТ-сервисов(услуг), предоставляемых в рамках всего предприятия в целом и координируемых централизованно ИТ службой.

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

Как и для прочих слоев архитектуры, для технического характерно применение приемов универсализации. Внедрение на предприятии единых стандартов, выбранных технологий, регламентированных рамками принятой технологической архитектуры, позволяет получить следующие преимущества:

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

    Во-вторых, прикладные системы легче интегрировать между собой, когда они имеют много общих технических аспектов, и используются на постоянной основе большинством сотрудников ИТ службы;

    В-третьих, предприятие может получить экономию на масштабах, приобретая технологии ограниченного количества поставщиков (например, скидки на лицензии);

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

Поэтому основная цель описания технологической архитектуры состоит в определении перечня принципов, стандартов и регламентов, которые устанавливают правила выбора и использования технических элементов Информационной системы (далее ИС).

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

Можно использовать и более детальный способ деления, например, акцентирование на архитектурных компонентах (сервисах), в каждом из которых выделяется определенное количество технологических "строительных блоков". Это:

  • Аппаратная инфраструктура. Аппаратные средства, серверы, сети, ЦОД (Dell, Cisco, NetApp);

  • Вычислительные платформы и облака. Среды размещения и вычисления (AWS, Azure, Kubernetes);

  • Платформы данных. Хранение и обработка данных (Oracle, PostgreSQL, Hadoop);

  • Платформы приложений (NET, Java EE, Node.js);

  • Интеграционные решения. Обеспечение взаимодействия между системами (Kafka, MuleSoft, Nginx);

  • ПО промежуточного слоя. Прослойка между приложениями и инфраструктурой;

  • Инструменты и пайплайны DevOps. Автоматизация, тестирование, деплой (Jenkins, GitLab, Docker);

  • Безопасность и доступ. Средства защиты, шифрования (Keycloak, AD, Splunk);

  • Мониторинг и управление Наблюдение и контроль ИТ-сред (Zabbix, Grafana, Prometheus).

В то же время необходимо понимать, что использование разнообразных технологий на предприятии – это неизбежная ситуация в силу многих причин, начиная с технологических и заканчивая организационными, а в последнее время продиктовано еще и политическими аспектами. К тому же ИТ-индустрия является инновационной и ИТ инфраструктура все больше становится «интеллектуальной» параллельно с тем, что она все больше тяготеет к интеграционным решениям. Это продиктовано бурным развитием и развертыванием приложений нового типа таких как электронный маркетинг, электронная коммерция, электронные помощники, с использованием искусственного интеллекта и прочее. Для этих новаций требуются новые инфраструктурные сервисы.

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

Так чаще всего, некоторые из технологий координируются и эксплуатируются централизованно, другие – на уровне отдельных подразделений.

Для этого, ИТ-сервисы, которые требуются для предприятия в целом, обеспечиваются общекорпоративной и публичной ИТ инфраструктурой. Инфраструктура же уровня отдельного направления - ориентирована на более специфические технологии соответствующих подразделений.

5.1.   Стандарты технологической архитектуры

Поскольку одним из ключевых преимуществ использования технологической архитектуры задекларировано ее направленность на унификацию используемых технологий, то рассмотрим роль стандартов в данном контексте.

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

Строго говоря, принято различать стандарты де-юре, т.е. разработанные и поддерживаемые официальными органами по стандартизации, такими как Международная организация по стандартизации – ISO, и стандарты де-факто, основанные на существующем широком распространении технологии, методологии или продукта.

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

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

  • Общие принципы. Стандарты, подходы, архитектурные принципы (Cloud First, Security by Design);

  • Технологический стек. Список утверждённых технологий для разработки, интеграции, аналитики;

  • Модель инфраструктуры. Схема размещения вычислительных ресурсов (ЦОД, облака, сети);

  • Интеграционная архитектура. Описание протоколов, API, очередей сообщений;

  • Архитектура данных и хранения. Описание типов БД, DWH, репликаций;

  • Безопасность. Принципы аутентификации, авторизации, защиты каналов;

  • Управление и мониторинг. Средства эксплуатации, DevOps, мониторинг, SLA;

  • План развития (Roadmap). Целевые шаги по модернизации технологий.

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

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

Когда мы говорим о технологических шаблонах, то речь идет не о конкретных моделях аппаратного или программного обеспечения, а скорее о схемах взаимодействия компонент между собой. Эти представления помогают понять: как они совместно обеспечивают работу с системой клиента, использующего компьютер? Какие роли играет каждый компонент? Какие типы коммуникаций необходимы между ними?

Важность использования шаблонов для описания и проектирования архитектуры предприятия в целом обусловлена следующими причинами:

1)  Повышается вероятность получения адекватно работающей физической реализации архитектуры;

2)  Обеспечивается преимущество многократного использования в рамках предприятия разработанных шаблонов, связанных с решением различных проблем;

3)  Использование шаблонов изолирует логический уровень от физического уровня архитектуры. Это позволяет проектировать долговременно работающие модели и придает гибкость, поскольку при последующем переиспользовании можно не изменять постоянные конструкции, а лишь реализовывать их на новых технологических решениях.

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

Каждый такой шаблон может объединять конкретное прикладное ПО, операционную систему, сервер СУБД, аппаратную платформу или несколько распределенных платформ, интерфейсы, метаданные и т.п. Типичными примерами являются шаблон Business-to-Business для взаимодействия с Клиентами/Поставщиками. Применение таких решений значительно облегчает задачу реализации новых элементов информационных систем.

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

Основные типы инфраструктурных шаблонов:

Тип шаблона

Назначение

Пример реализации

Серверный шаблон

Описание конфигурации виртуальной машины (ОС, диски, сеть)

VMware Template, AWS AMI

Облачный шаблон (IaaC)

Кодовое описание облачной инфраструктуры

Terraform, AWS CloudFormation

Шаблон окружения

Полная среда (сеть, сервер, БД, сервисы)

Terraform + Ansible

Шаблон БД

Готовая конфигурация СУБД, резервирования, бэкапа

RDS Snapshot, SQL Template

Шаблон безопасности

Набор политик IAM, шифрование, Firewall

AWS Security Group, Azure Policy

Шаблон контейнерной платформы

Kubernetes-кластер, namespace, ingress и monitoring

Helm Chart, Kustomize

Шаблон мониторинга / логирования

Настроенные метрики и алерты

Grafana Dashboard, Prometheus Config

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

5.2.  Оценка состояния технологической архитектуры

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

Основные цели оценки:

  1. Определить текущее состояние (AS-IS). Собрать объективную картину ИТ-инфраструктуры.

  2. Сопоставить с целевой архитектурой (TO-BE). Понять, где есть разрывы и несоответствия.

  3. Выявить узкие места и риски. Определить уязвимые или устаревшие компоненты.

  4. Оценить затраты на поддержку (TCO). Понять, что дорого в эксплуатации.

  5. Построить план модернизации. Определить приоритеты инвестиций.

  6. Повысить надёжность и безопасность. Снизить вероятность инцидентов и простоев.

Для того чтобы качественно провести оценку важно правильно выбрать критерии оценки. Например, это может быть:

  • Техническое состояние. Физическое и логическое состояние компонентов (Современно / Устарело)

  • Совместимость. Насколько соответствует корпоративным стандартам (Соответствует / Нет)

  • Масштабируемость. Возможность роста без доработок (Высокая / Ограниченная)

  • Экономическая эффективность (TCO). Стоимость владения и обслуживания (Высокая / Средняя / Низкая)

  • Безопасность. Соответствие нормам ИБ, резервирование, защита (Соответствует / Требует обновления)

  • Поддерживаемость. Наличие специалистов и обновлений от вендора (Поддерживается / Устарело)

  • Соответствие целевой архитектуре. Насколько соответствует планам развития ИТ (Полное / Частичное / Нет)

Пример оценки состояния технологической архитектуры:

Компонент

Текущее состояние

Проблемы / риски

Оценка (1–5)

Рекомендации

1

Серверная инфраструктура

70% оборудования старше 5 лет

Высокий риск отказов

2

Замена оборудования, переход в облако

2

Сеть и маршрутизаторы

Работает стабильно

Нет резервирования на филиалах

3

Внедрить резервные каналы

3

Хранилище данных (SAN)

Недостаточная производительность

Медленные отклики BI-систем

2

Модернизировать дисковые массивы

4

Система резервного копирования

Не охватывает облачные сервисы

Частичное покрытие

3

Централизовать резервное копирование

5

DevOps-инструменты

Jenkins, GitLab

Разрозненные пайплайны

4

Унификация CI/CD-процессов

6

Безопасность

Используется AD, SIEM внедрено частично

Не покрыт облачный сегмент

3

Внедрить IAM и централизованный SIEM

Как и для прочих слоев архитектуры, на основании оценки, можно определить уровень зрелости технологической инфраструктуры:

  1. Реактивный. Нет стандартов, инфраструктура хаотична (Разные серверы, нет мониторинга);

  2. Управляемый. Есть базовые процессы и учёт активов (Инвентаризация, ручное сопровождение);

  3. Оптимизированный. Автоматизация части процессов (Использование шаблонов, резервирование);

  4. Проактивный. Инфраструктура стандартизирована и автоматизирована (IaC, CI/CD, централизованный мониторинг);

  5. Инновационный. Используются облака, DevOps, гибридные модели (Cloud-first, автоматическое масштабирование).

Понимая текущее состояние уровня развития можно идентифицировать проблемы и риски. На основании этой информации составить приоритизированный план модернизации и оценить возможные затраты. Результатом этой работы выступает Дорожная карта развития.

В следующей части мы рассмотрим подходы формирования Архитектуры предприятия.

Комментарии (0)