Эксплуатация (Часть модели зрелости)

Приведена часть модели зрелости относящаяся к Эксплуатации тестовых и продуктивных сред для оценки кросс-функциональных Agile команд разработки.

Цель — иметь периодические срезы по командам, отражающие зрелость в развитии и использовании DevOps практик.

1. Среды и Инфраструктура

1.1. Инфраструктура

Уровень 1

• Используются статические среды, создаваемые и поддерживаемые вручную по запросу.

Уровень 2

• Существует документация по развертыванию и скрипты на Bash / PowerShell, частично автоматизирующие процесс.
• Документации достаточно для разворачивая “с 0”.
• Инфраструктура может частично быть создана автоматизированно.

Уровень 3

• ОС , компоненты, приложения и сервисы полностью настроены с помощью систем управления конфигураци (например, Ansible) и могут быть автоматизированно воспроизведены.

Уровень 4

• Окружение полностью описано с помощью практики IaC (Infrastructure as Code) и изменения версионируются через Git.
• Изменения проходят через Pull Request’ы по средствам CI/CD.
• Автоматически отслеживаются параметры работы конвейера для инфраструктурного кода.

Уровень 5

• Используется подход неизменяемой (с момента создания) инфраструктуры (Immutable Infrastructure).
• Тестовые окружения создаются динамически, изолировано, под каждую Фичу
• Используется подход GitOps.
• Поддержка и обсуживание только через PR в Git, любые изменения “руками” запрещены.

1.2. Оркестрация

Уровень 1

• Инфраструктура основана на физических серверах, без использования дополнительных слоев абстракции от оборудования.

Уровень 2

• Инфраструктура основана на виртуальных машинах, позволяющих разделение и изоляцию ресурсов.

Уровень 3

• Процесс изоляции и разделение ресурсов с использованием контейнеризации (например, Docker или Docker Compose) для упрощения управления и развертывания приложений.

Уровень 4

• Оркестрация контейнеров с использованием инструментов, таких как Kubernetes или Docker Swarm, обеспечивая гибкость, автоматическое развертывание и управление ресурсами.

Уровень 5

• Единообразная оркестрация контейнеров с автоматическим масштабированием, оптимизацией ресурсов и использованием подхода Service Mesh для обеспечения безопасности, наблюдаемости и сетевых возможностей между микросервисами.

2. Развертывание

2.1. Непрерывная поставка

Уровень 1

• Развертывание поставок на среды производится в ручном режиме.

Уровень 2

• Использование хранилищ бинарных объектов — артифактори (например, Nexus, Docker Hub)
• Управление зависимостями через менеджеров пакетов (например, npm)
• Настроена непрерывная сборка ( CI )

Уровень 3

• Автоматическое развертывание поставок (CI/CD) на всех средах
• Автоматически собираются параметры работы пайплайна.

Уровень 4

• Build once — одни и те же артефакты перемещаются между средами, меняются только конфигурационные параметры и инфраструктура, Build once, deploy everywhere.
• Версионирование структуры баз данных.

Уровень 5

• Применение практик с нулевым временем ожидания развертывания, таких как Blue-Green Deployment, для минимизации простоя и обеспечения непрерывной доступности приложений.

2.2. Тестирование

Уровень 1

• Ручное тестирование выполняется после развертывания поставки на тестовую среду.
• Отсутствует формализованный подход к тестированию и документированию результатов.

Уровень 2

• Автоматизированные smoke-тесты выполняются на всех средах после развертывания.
• Разработаны базовые тестовые сценарии и критерии приемки.

Уровень 3

• Smoke-тесты и имеющиеся автоматические тесты интегрированы в процесс непрерывной поставки (Continuous Deployment).
• Автоматически собираются и анализируются метрики работы автотестов.

Уровень 4

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

Уровень 5

• Применяется подход Chaos Monkey тестирования, при котором компоненты системы принудительно выводятся из строя для оценки и измерения устойчивости системы.

2.3. Откат изменений

Уровень 1

• Откат изменений и релизов выполняется вручную без автоматизации.
• Отсутствуют формализованные процедуры отката.

Уровень 2

• Разработаны и зафиксированы планы отката релизов в Confluence или другой платформе документирования.

Уровень 3

• Реализованы автоматизированные процедуры отката деплоя для большинства изменений и релизов.

Уровень 4

• Автоматизированные процедуры отката деплоя распространяются на изменения, затрагивающие значительные структуры данных, с учетом миграции и восстановления данных.
• Регулярно проводятся тестирования процедур отката для обеспечения их надежности и актуальности

Уровень 5

• Внедрение канареечного развертывания (Canary release) для постепенного внедрения изменений и возможности быстрого отката без существенных последствий для пользователей.
• Мониторинг и анализ результатов канареечного развертывания для определения успешности изменений и релизов.

3. Централизованное логирование

3.1 Логирование

Уровень 1

• Логи сохраняются локально на источниках, и не консолидируются в единой системе.
• Отсутствуют стандарты и рекомендации по логированию.

Уровень 2

• Логи частично консолидируются в централизованной системе.
• Существуют комплементарные стандарты и рекомендации по легированию.

Уровень 3

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

Уровень 4

• Сбор логов интегрирован с инфраструктурой как код (IaC) и/или цифровым двойником (Digital Twin) инфраструктуры.
• Реализована политика жизненного цикла данных логирования, включая хранение, архивацию и удаление логов.
• Собираются и анализируются метрики из всех сред (разработка, тестирование, продакшн).

Уровень 5

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

4. Непрерывный мониторинг

4.1. Мониторинг

Уровень 1

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

Уровень 2

• Созданы типовые шаблоны и профили мониторинга.
• Определены 7+-2 ключевые метрики по каждому компоненту, слою абстракции и системе в целом.
• Данные мониторинга (по приложениям, инфраструктуре, сети, БД и окружениям) консолидированы.

Уровень 3

• Стандартизированы и автоматизированы настройка систем мониторинга, добавление метрик, алертов и графиков.
• Мониторинг интегрирован с системами оповещения и рабочими чатами (ChatOps).
• Автоматизация создания заявок по инцидентам в Jira

Уровень 4

• Мониторинг интегрирован с инфраструктурой как код (IaC) и/или цифровым двойником (Digital Twin) инфраструктуры.
• Реализована политика жизненного цикла данных для мониторинга, включая хранение, архивацию и удаление данных.
• Имеется селфсервис по созданию индивидуальных дашбордов, с возможностью ими делиться

Уровень 5

• Мониторинг автоматически передает критические уведомления в систему инцидент-менеджмента и Jira.
• Система мониторинга может помочь в определении корня (первопричины) инцидента
• Есть инструкции и скрипты по устранению для часто повторяющихся типов инцидентов, и они подгружаются к описанию инцидента.
• Внедрена система обнаружения аномалий и анализа поведения системы для прогнозирования и предотвращения инцидентов.

5. Документирование

5.1. Документирование

Уровень 1

• Документирование ведется отрывочно и безсистемно.
• Отсутствуют формальные стандарты и правила для создания и поддержки документации.

Уровень 2

• Документация хранится разрозненно в разных форматах и местах.
• Начато внедрение стандартов и шаблонов для создания документации.

Уровень 3

• Документация разрабатывается в открытом формате, например Markdown или AsciiDoc.
• Документация доступна к просмотру без специализированных или проприетарных инструментов.
• Разработаны и используются базовые шаблоны и стандарты документации.

Уровень 4

• Применяются практика “Документирование как код” (хранение в Git, ревью кода, CI/CD pipeline).
• Документация собирается и публикуется автоматически в Confluence или другой централизованной платформе.
• Документация сопоставлена с версиями и ветками разработки
• Для описания окружений используется принцип Цифровых двойников (Digital Twin)

Уровень 5

• Ведется ADR (Architecture Decision Record).
• Нотации UML, C4, ER, BPMN ведутся “как код” (например, с помощью Mermaid или других инструментов).

6. Данные

6.1. Подготовка тестовых данных

Уровень 1

• Данные выгружаются и руками, непосредственно в контур(environment) по запросу.
• Отсутствует систематический подход к подготовке тестовых данных.

Уровень 2

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

Уровень 3

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

Уровень 4

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

Уровень 5

• Автоматическая подготовка и проверка данных для тестовых контуров с использованием Data pipelines, включая автоматизацию ETL-процессов и мониторинг состояния.
• Имеется версионирование наборов данных (Data set) для контроля изменений и возможности отката к предыдущим версиям.
• Применяются методы оптимизации производительности и масштабирования процессов подготовки данных

Данная матрица была улучшена с помощью GPT-4.