Цели развёртывания в едином manifest¶
Требования применяются к разделу targets файла
.standards/standards.yaml и вычислению инфраструктурной применимости. Уровни
обязательности определены в корневом README.md.
INF-MAN-001. Manifest проекта¶
Уровень: MUST
Применяется к: каждому проекту, поставляемому по этому стандарту
Единый manifest должен содержать идентификатор проекта, владельца и массив
targets. Каждая цель должна объявлять среду, runtime, стабильный идентификатор
платформы, профиль доступности, заявленные отказы для HA, способ доставки,
источник deployment-конфигурации и инфраструктурные capabilities.
Обоснование¶
Явный manifest позволяет человеку и ИИ-агенту однозначно выбрать применимые требования.
Проверка¶
- валидация файла по
schemas/standards-manifest.schema.json; - запуск
scripts/standards.py validate.
Исключения¶
Не допускаются.
INF-MAN-002. Отдельное объявление каждой цели¶
Уровень: MUST
Применяется к: проекту с несколькими средами или runtime
Manifest должен описывать каждую цель развёртывания отдельно. Значения
environment, platform, runtime, availability и delivery не должны
выводиться из имени ветки, namespace, каталога или hostname.
Значение name должно быть уникальным в manifest, а каждый target должен быть
указан хотя бы одним элементом components[].targets.
Для цели high-availability массив failure_tolerance должен перечислять все
типы отказа, которые цель заявляет как выдерживаемые без нарушения SLO.
Обязательное значение worker-node является минимальной гарантией, а не
неявным обещанием устойчивости к отказу control plane, storage или availability
zone. Каждая дополнительная гарантия должна быть объявлена отдельным значением
и подтверждена проверками INF-PLT-006 и INF-RES-005.
Обоснование¶
Неявное определение профиля создаёт ошибочную применимость требований.
Проверка¶
- сопоставление целей manifest с конфигурацией deployment;
- сопоставление каждого значения
failure_toleranceс topology, runbook и результатом fault test; - негативный тест неизвестного значения профиля.
Исключения¶
Не допускаются.
INF-MAN-003. Единая зафиксированная версия стандартов¶
Уровень: MUST
Применяется к: ссылкам на корпоративные стандарты
Объект standards должен содержать один релизный тег и полный commit SHA
объединённого репозитория. Тег и SHA должны обозначать один commit; отдельные
версии архитектурного и инфраструктурного слоёв запрещены.
Обоснование¶
Изменяемая ссылка не обеспечивает воспроизводимого решения.
Проверка¶
scripts/standards.py verify-version;- сравнение commit тега с объявленным
commit_sha.
Исключения¶
Локальная разработка самого стандарта MAY временно ссылаться на commit без тега.
INF-MAN-004. Источник deployment-конфигурации¶
Уровень: MUST
Применяется к: каждой цели
Manifest должен указывать GitLab project и путь, содержащие желаемое состояние цели. Конфигурация MAY находиться вместе с приложением или в отдельном deployment/GitOps-репозитории. Для работающей версии должна восстанавливаться однозначная связь между commit приложения, release identifier image и commit deployment-конфигурации.
Обоснование¶
Разделение репозиториев не должно разрывать трассировку поставленной версии.
Проверка¶
- разрешение project/path из manifest;
- сверка работающей цели с обоими commit и release identifier image.
Исключения¶
Для local-цели commit deployment-конфигурации MAY совпадать с незакоммиченным рабочим деревом, если инструмент явно показывает это состояние.
INF-MAN-005. Обоснование ограниченного production-профиля¶
Уровень: MUST
Применяется к: production-цели с runtime compose
Manifest должен содержать risk acceptance с владельцем, причиной выбора
Compose, датой пересмотра и принятыми ограничениями доступности. Дата пересмотра
не должна быть прошедшей; validate должен отклонять истёкшую дату.
Обоснование¶
Одноузловой production runtime имеет ограничения, которые должны быть приняты осознанно.
Проверка¶
- валидация manifest;
- проверка владельца и даты в GitLab.
Исключения¶
Не допускаются.
INF-MAN-006. Семантика capability¶
Уровень: MUST
Применяется к: каждой цели
Capability должна объявляться, если target использует соответствующую
платформенную возможность или зависит от неё на критичном пути, даже когда
сервис управляется другой командой. persistent-data должна объявляться, если
данные цели нельзя восстановить из Git, image или внешнего authoritative
источника в пределах RTO. Владелец внешнего сервиса и граница выполнения
применимых требований должны быть указаны в операционном README.
Обоснование¶
Внешнее владение зависимостью не устраняет её влияние на применимость требований.
Проверка¶
- сопоставление capabilities с endpoint, PVC и архитектурой данных;
- проверка владельца и recovery contract внешней зависимости.
Исключения¶
Не допускаются.