Проектирование архитектуры информационных систем

4.2.1 Метрики DevOps

Для оценки способности поставлять изменения применяются показатели DORA. В актуальной модели 2026 года используются пять показателей: время прохождения изменения от фиксации в системе контроля версий до промышленного развертывания; частота развертываний; время восстановления после неудачного развертывания; доля изменений, потребовавших немедленного вмешательства; доля незапланированных развертываний, выполняемых из-за промышленного инцидента. Первые три показателя характеризуют пропускную способность изменений, последние два — нестабильность. Метрики не должны использоваться для ранжирования отдельных сотрудников. Они описывают способность команды и системы поставки. Попытка механически увеличить частоту развертывания может привести к искусственному дроблению изменений без повышения ценности. Показатели необходимо интерпретировать в контексте конкретного приложения. Сравнение мобильного приложения, банковской системы и небольшого веб-сервиса без учета различий не дает объективного результата. DORA рекомендует применять показатели на уровне отдельного приложения или сервиса и использовать их для постоянного улучшения.

4.2.2 Расширение DevSecOps

DevSecOps представляет собой развитие DevOps, при котором безопасность интегрируется во весь поток разработки и эксплуатации, а не проверяется только перед выпуском. Традиционная модель могла предусматривать передачу почти готового продукта службе безопасности. Если обнаруживалась архитектурная уязвимость, исправление требовало значительной переработки. DevSecOps применяет принцип раннего включения безопасности. Моделирование угроз выполняется при проектировании, зависимости проверяются при сборке, программный код анализируется автоматически, контейнерные образы сканируются, а конфигурации инфраструктуры проверяются до развертывания. В конвейер могут включаться статический анализ безопасности, динамическое тестирование, анализ состава программного обеспечения, проверка секретов, сканирование инфраструктурных конфигураций и формирование перечня компонентов программного продукта. NIST рассматривает DevSecOps через интеграцию мер безопасности цепочки поставки программного обеспечения в процессы непрерывной интеграции и развертывания, охватывающие сборку, тестирование, упаковку и выпуск. Анализ состава программного обеспечения выявляет сторонние библиотеки, их версии, лицензии и известные уязвимости. Современная система может содержать значительно больше внешних компонентов, чем собственного кода, поэтому управление зависимостями является важной частью безопасности. Перечень программных компонентов, или SBOM, фиксирует состав программного продукта. Он помогает установить, какие системы затронуты обнаруженной уязвимостью библиотеки. Необходимо защищать сам конвейер поставки. Если злоумышленник получает возможность изменить сценарий сборки, подменить зависимость или опубликовать артефакт, проверка исходного кода может оказаться недостаточной. DevSecOps не должен превращаться в добавление большого количества блокирующих проверок без обратной связи. Проверки должны быть быстрыми, понятными и по возможности выполняться на рабочем месте разработчика до передачи изменения.

4.2.3 GitOps

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

4.2.4 DataOps

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

4.2.5 MLOps

MLOps представляет собой применение принципов DevOps к системам машинного обучения. Такие системы включают не только программный код, но и данные, признаки, обученную модель, параметры, вычислительную среду и процесс обучения. Обычный программный продукт изменяет поведение преимущественно после изменения кода или конфигурации. Модель машинного обучения может ухудшаться из-за изменения реальных данных даже без изменения программы. MLOps включает управление версиями данных и моделей, автоматизированное обучение, проверку качества, развертывание, мониторинг и повторное обучение. Google Cloud определяет MLOps как культуру и инженерную практику, объединяющую разработку и эксплуатацию систем машинного обучения, с автоматизацией интеграции, тестирования, выпуска, развертывания, инфраструктуры и непрерывного обучения. Конвейер машинного обучения может включать получение данных, проверку качества, подготовку признаков, обучение, оценку, сравнение с действующей моделью, регистрацию, развертывание и мониторинг. Необходимо контролировать дрейф данных, когда распределение входных сведений изменяется, и дрейф концепции, когда меняется зависимость между входными данными и целевым результатом. Например, модель прогнозирования спроса, обученная на исторических данных, может ухудшиться после изменения поведения покупателей или появления нового канала продаж. Нельзя автоматически развертывать модель только потому, что процесс обучения завершился. Она должна пройти проверку точности, устойчивости, справедливости, безопасности и соответствия бизнес-ограничениям.

4.2.6 AIOps

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

4.2.7 Platform Engineering

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

4.2.8 FinOps

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

4.2.9 Расширения DevOps как система взаимосвязанных практик

Обозначения DevSecOps, GitOps, DataOps, MLOps, AIOps и FinOps отражают расширение принципов совместной ответственности и автоматизации на разные области. Они не должны превращаться в изолированные подразделения с новыми барьерами. Если организация создает отдельную команду DevSecOps, которая только принимает запросы на проверку безопасности, она воспроизводит прежний барьер под новым названием. Цель заключается в интеграции компетенций и автоматизированных механизмов в общий поток. Аналогично MLOps не должен отделять специалистов по моделям от инженеров данных и эксплуатации. Результат зависит от совместной ответственности за всю систему.

4.3 Инструменты автоматизации проектирования информационных систем

Автоматизация проектирования информационных систем включает применение программных средств для моделирования, управления требованиями, разработки архитектуры, генерации программного кода, проектирования данных, тестирования, развертывания и документирования. Традиционно такие средства назывались CASE-средствами, то есть средствами автоматизированной поддержки программной инженерии. CASE-система может поддерживать одну или несколько стадий жизненного цикла. Верхнеуровневые CASE-средства ориентированы на обследование, анализ требований, моделирование процессов и концептуальное проектирование. Нижнеуровневые CASE-средства поддерживают детальное проектирование, программирование, тестирование и сопровождение. Интегрированные CASE-средства объединяют несколько стадий и используют общий репозиторий моделей. Современная граница между CASE-средствами, средами разработки, системами управления требованиями и DevOps-платформами становится условной. Один продукт может одновременно хранить требования, модели, исходный код, тесты и конвейеры.

4.3.1 Средства управления требованиями

Инструменты управления требованиями обеспечивают создание, классификацию, согласование, версионирование и прослеживаемость требований. Требование должно иметь идентификатор, состояние, приоритет, источник, критерии приемки и связи. Система позволяет установить, какое требование реализуется определенным компонентом и каким тестом проверяется. Для гибкой разработки требования часто хранятся в системах управления бэклогом и задачами. Примерами являются Jira, Azure DevOps, GitLab, GitHub Projects и YouTrack. Название инструмента не определяет качество требований. Карточка с формулировкой «сделать отчет удобным» остается непроверяемой независимо от используемой системы. Инструмент должен поддерживать иерархию: цели, инициативы, крупные функции, пользовательские истории, задачи и дефекты. Полезны связи между требованиями, история изменений, права доступа и отчеты. В критических проектах применяются специализированные средства управления требованиями, поддерживающие базовые линии, формальное согласование и матрицы прослеживаемости.

4.3.2 Инструменты моделирования бизнес-процессов

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

4.3.3 Инструменты системного и программного моделирования

Для моделирования программных систем применяется UML, или унифицированный язык моделирования. Он включает диаграммы классов, компонентов, последовательностей, состояний, деятельности, вариантов использования и развертывания. Официальная спецификация UML публикуется Object Management Group. Диаграмма вариантов использования показывает цели внешних участников. Диаграмма классов отражает структуру объектов и отношений. Диаграмма последовательности показывает обмен сообщениями во времени. Диаграмма компонентов описывает крупные программные элементы. Диаграмма развертывания связывает программные компоненты с техническими узлами. UML не требует создавать все возможные диаграммы. Следует моделировать только те аспекты, которые помогают принимать решения и передавать знания. Для систем, включающих программные и физические компоненты, применяется SysML, или язык системного моделирования. Он поддерживает требования, структуру, поведение, параметры и связи элементов системы. Для корпоративной архитектуры используется ArchiMate. Этот язык позволяет описывать и анализировать связи между бизнес-процессами, организацией, информационными системами и технологической инфраструктурой. Официальная спецификация позиционирует ArchiMate как открытый независимый язык моделирования корпоративной архитектуры. В корпоративной модели можно показать, какой бизнес-процесс поддерживается каким приложением, какие данные используются и на какой инфраструктуре размещаются компоненты. К инструментам моделирования относятся Enterprise Architect, Visual Paradigm, Cameo Systems Modeler, Archi и другие средства. Enterprise Architect поддерживает моделирование требований, UML, BPMN, проектирование кода, прямую и обратную генерацию, общий репозиторий и прослеживаемость. Преимуществом репозиторного средства является возможность хранить не отдельные несвязанные рисунки, а единую модель. Если один компонент используется на нескольких диаграммах, он остается одним объектом с общими свойствами.

4.3.4 Модель C4

Для визуализации программной архитектуры применяется модель C4. Она использует последовательное увеличение детализации: контекст системы, контейнеры, компоненты и код. Дополнительно могут применяться диаграммы системного ландшафта, динамики и развертывания. Диаграмма контекста показывает пользователей, систему и внешнее окружение. Она отвечает на вопрос о границах решения. Диаграмма контейнеров показывает крупные исполняемые приложения и хранилища данных. В терминологии C4 контейнером является приложение или хранилище, а не обязательно контейнер Docker. Диаграмма компонентов раскрывает внутреннее устройство отдельного контейнера. Диаграмма кода показывает классы, интерфейсы или иные элементы реализации и обычно создается только для сложных частей. Модель C4 не привязана к конкретному графическому обозначению или инструменту. Она требует ясного уровня абстракции и понятных подписей.

4.3.5 Документация как код

Современный подход «документация как код» предполагает хранение архитектурных описаний в текстовом формате вместе с программным кодом. Для диаграмм могут применяться PlantUML, Mermaid, Structurizr DSL и Graphviz. Текстовое описание удобно хранить в Git, проверять при рецензировании и автоматически преобразовывать в изображения или веб-документацию. Преимуществом является синхронизация с разработкой. Изменение архитектуры может включаться в тот же запрос на объединение, что и программный код. Однако текстовая модель не всегда удобна для сложного корпоративного моделирования. Репозиторные CASE-средства предоставляют более развитую семантику, анализ и управление связями. Выбор зависит от масштаба, аудитории и необходимости формального моделирования.

4.3.6 Инструменты проектирования данных

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

4.3.7 Инструменты проектирования программных интерфейсов

Для описания интерфейсов HTTP применяется OpenAPI. Спецификация предоставляет независимый от языка программирования формат, позволяющий людям и программным средствам понимать возможности сервиса без доступа к его исходному коду. По описанию OpenAPI можно автоматически формировать документацию, клиентские библиотеки, серверные заготовки, проверочные тесты и имитаторы сервиса. Подход «сначала контракт» предполагает согласование интерфейса до реализации. Разработчики клиента и сервера могут работать параллельно, используя утвержденное описание. Подход «сначала код» генерирует спецификацию из программных аннотаций. Он быстрее на начальном этапе, но существует риск, что описание будет отражать техническую реализацию, а не согласованный контракт. Кроме структуры запросов и ответов необходимо документировать ошибки, аутентификацию, ограничения частоты, идемпотентность, версии и правила совместимости.

4.3.8 Интегрированные среды разработки

Интегрированная среда разработки объединяет редактор, навигацию по коду, отладчик, средства сборки, рефакторинг, тестирование и анализ. К таким средам относятся IntelliJ IDEA, Visual Studio, Eclipse и другие продукты. Рефакторинг позволяет изменять внутреннюю структуру программы без изменения наблюдаемого поведения. Среда может безопасно переименовывать элементы, выделять методы, перемещать классы и обновлять ссылки. Средства статического анализа обнаруживают ошибки до выполнения. Интеграция с системой контроля версий позволяет сравнивать и рецензировать изменения. Инструмент может автоматически генерировать часть кода, но не способен самостоятельно определить правильную архитектуру. Автоматизация повышает скорость как хороших, так и плохих решений.

4.3.9 Средства управления версиями и совместной разработки

Git является основой совместной работы над программным кодом и конфигурациями. Репозиторий хранит историю, ветви и связи изменений. Платформы GitHub, GitLab, Bitbucket и Azure DevOps добавляют запросы на объединение, проверку кода, задачи, конвейеры и хранение артефактов. Проверка кода помогает выявлять дефекты, распространять знания и поддерживать архитектурные правила. Она не должна ограничиваться проверкой стиля. Необходимо анализировать корректность, безопасность, тестируемость, влияние на архитектуру и соответствие требованиям. Большие запросы на объединение сложно проверять. Небольшие изменения сокращают время обратной связи и вероятность скрытых ошибок.

4.3.10 Инструменты сборки и управления зависимостями

Системы сборки автоматизируют компиляцию, тестирование, упаковку и публикацию. Примерами являются Maven, Gradle, MSBuild, npm и другие средства. Управление зависимостями определяет версии внешних библиотек и источники получения. Для воспроизводимости необходимо фиксировать версии и защищать репозитории пакетов. Использование новейшей версии каждой библиотеки не всегда оправданно. Обновление должно сопровождаться анализом совместимости, безопасности и лицензий.

4.3.11 Средства автоматизированного тестирования

Инструменты тестирования поддерживают модульные, интеграционные, пользовательские, нагрузочные и безопасностные проверки. Модульный тест проверяет отдельный компонент. Интеграционный тест проверяет взаимодействие с базой данных, очередью или внешним сервисом. Пользовательский тест воспроизводит действия через интерфейс. Контрактный тест проверяет совместимость сервисов. Для веб-интерфейсов используются Selenium, Playwright, Cypress и другие средства. Для нагрузочного тестирования применяются JMeter, k6 и Gatling. Автоматический тест должен быть надежным, быстрым и понятным. Нестабильные тесты, случайно завершающиеся ошибкой, снижают доверие и начинают игнорироваться. Тестовая пирамида предполагает большое число быстрых нижнеуровневых тестов и меньшее число дорогих сквозных проверок. Конкретное соотношение зависит от архитектуры.

4.3.12 Средства непрерывной интеграции и поставки

К платформам автоматизации относятся Jenkins, GitHub Actions, GitLab CI/CD, Azure Pipelines, TeamCity и другие средства. Они запускают действия по событию: фиксации изменения, созданию запроса на объединение, выпуску версии или расписанию. Конвейер должен быть воспроизводимым, наблюдаемым и защищенным. Ручные скрытые действия создают зависимость от конкретного сотрудника. Секреты не должны находиться в открытом тексте сценария. Необходимо использовать хранилища секретов и ограниченные учетные данные. Артефакт, прошедший тестирование, должен продвигаться между средами без повторной непроверенной сборки. Иначе промышленная версия может отличаться от протестированной.

4.3.13 Контейнеризация и оркестрация

Docker поддерживает создание и запуск контейнерных образов. Образ должен быть воспроизводимым, минимальным и не содержать секретов. Многоэтапная сборка позволяет отделить инструменты компиляции от конечного образа. Фиксация базовой версии снижает риск непредсказуемого изменения. Kubernetes автоматизирует развертывание, масштабирование и восстановление контейнерных приложений. Он использует декларативные объекты, описывающие желаемое состояние. Вместе с Kubernetes часто применяются Helm для шаблонизации конфигураций, Argo CD или Flux для GitOps, а также системы сервисной сетки для управления взаимодействием. Сложность оркестрации должна соответствовать реальной задаче. Для небольшого монолитного приложения может быть достаточно виртуальной машины или управляемой платформы.