Перейти к содержанию

Операционные процедуры

Требования применяются к эксплуатации и обслуживанию production-целей, включая инфраструктурные действия во время инцидентов. Уровни обязательности определены в корневом README.md.

INF-OPS-001. Runbook критичного отказа

Уровень: MUST

Применяется к: production-цели

Для недоступности, деградации, неуспешного deployment, исчерпания ресурсов, ошибки сертификата и отказа критичной зависимости должен существовать runbook с условиями запуска, диагностикой, безопасными действиями, проверкой восстановления, способом отмены опасного шага и маршрутом эскалации. Команды должны указывать target/namespace и начинаться с read-only диагностики, если немедленное изменение не является условием безопасности.

Обоснование

Предварительно проверенные действия уменьшают время и риск восстановления.

Проверка

  • tabletop exercise;
  • выполнение процедур в non-production.

Исключения

Один параметризованный runbook MAY покрывать несколько проектов.

INF-OPS-002. Аварийный доступ

Уровень: MUST

Применяется к: production-платформе

Break-glass доступ должен быть персональным, ограниченным по времени, аудируемым и использоваться только при недоступности штатного маршрута. Credential должен ротироваться после применения.

Обоснование

Общий постоянный административный token не позволяет установить исполнителя.

Проверка

  • rehearsal выдачи и отзыва;
  • review audit trail и ротации.

Исключения

Не допускаются.

INF-OPS-005. Плановое обслуживание

Уровень: MUST

Применяется к: production platform, data service или Docker host

Обновление, reboot, certificate rotation и storage maintenance должны иметь окно, владельца, impact, pre-check, порядок действий, критерий остановки, rollback и post-check. Потребители должны уведомляться согласно заявленному окну недоступности.

Обоснование

Штатная операция без stop criteria превращается в неуправляемый инцидент.

Проверка

  • review последнего maintenance change;
  • rehearsal rollback и post-check.

Исключения

Emergency maintenance MAY начаться без предварительного окна по процессу incident response.

INF-OPS-006. Периодический review доступа

Уровень: MUST

Применяется к: production GitLab, cluster, data service и backup storage

Владелец должен по численному расписанию проверять пользователей, groups, service accounts, deploy tokens, runner и agent authorization, RBAC и break-glass identities. Уволенная, сменившая роль или неиспользуемая identity должна отзываться в установленный срок.

Обоснование

Минимальные права при создании со временем становятся избыточными.

Проверка

  • отчёт последнего review и выборочная сверка identity;
  • тест отзыва и отсутствия активных orphan credentials.

Исключения

Не допускаются.

INF-OPS-003. Управление инцидентом

Уровень: MUST

Применяется к: production-инциденту

Инфраструктурная запись инцидента, управляемого по architecture:OPS-INC-001OPS-INC-004, должна дополнительно связывать каждое значимое решение и изменение среды с ID инцидента, target, runtime revision, GitLab job или GitOps commit и audit event. Она не должна задавать отдельную severity или второй жизненный цикл инцидента.

Обоснование

Структурированная запись сохраняет контекст и предотвращает конфликт действий.

Проверка

  • review выборки инцидентов;
  • сопоставление emergency changes с Git.

Исключения

Не допускаются.

INF-OPS-004. Проверка после изменения

Уровень: MUST

Применяется к: изменению production

После deployment, rollback, восстановления backup или аварийного изменения исполнитель должен проверить health, пользовательский результат, телеметрию и поставленную версию.

Обоснование

Успех команды не доказывает восстановление сервиса.

Проверка

  • наличие post-deployment job или checklist;
  • контролируемый ложноположительный ответ инструмента.

Исключения

Не допускаются.