System Design Space

    Глава 137

    Обновлено: 14 февраля 2026 г. в 08:21

    GitOps

    Прогресс части0/17

    Как внедрять GitOps: desired state в Git, pull-based delivery, Argo CD/Flux, progressive delivery и rollback в production.

    Foundation

    Infrastructure as Code

    GitOps не заменяет IaC, а добавляет к нему непрерывную reconciliation-модель и delivery governance.

    Открыть главу

    GitOps - это операционная модель, где состояние платформы управляется через Git, а кластеры автоматически приводятся к desired state. Ключевая ценность - предсказуемые, проверяемые и воспроизводимые изменения в production.

    Модель GitOps

    • Git - единственный источник истины для желаемого состояния платформы.
    • Delivery работает в pull-модели: агент в кластере сам синхронизирует состояние из Git.
    • Любое изменение проходит через pull request, review и audit trail.
    • Дрейф между cluster state и git state детектируется автоматически и корректируется reconcile-loop.

    Building blocks

    Continuous reconcile loop (desired vs actual state)PR openedchecks + approvalsmerge -> syncapplydrift feedbackCluster stateworkloads + configRepository strategyapps + platform + overlaysPromotion flowPR path across environmentsPolicy gatessecurity + compliance checksReconciliation controllerArgo CD / Flux sync loop

    Что делает

    Разделяйте app configs, platform baseline и environment overlays, чтобы ownership между командами не конфликтовал.

    Операционный фокус

    Стандартизировать структуру каталогов и naming conventions до масштабирования команд.

    Антипаттерн

    Смешение app и platform изменений в одном слое усложняет reviews и blast radius.

    SRE

    SRE и надёжность

    GitOps снижает ручные изменения в production и улучшает трассируемость инцидентных действий.

    Открыть главу

    Operational patterns

    Вводите progressive delivery (canary/blue-green) и explicit rollback strategy для каждого сервиса.

    Для инцидентов используйте emergency branch и post-incident revert PR вместо ручного hotfix в кластере.

    Синхронизируйте secrets-процессы с GitOps: шифрование/внешние secret-store и короткоживущие credentials.

    Определите ownership: кто отвечает за платформенные overlays, а кто за app-level manifests.

    Практический чеклист

    • Все изменения деплоя воспроизводимы через PR без ручных kubectl-патчей в production.
    • Есть мониторинг drift и alerting при расхождении desired/actual state.
    • Четко определены rollback-процедуры и проверены на game day.
    • Есть согласованный branching/promotions процесс между dev/stage/prod.
    • Секреты и sensitive values не хранятся в открытом виде в Git.

    Связанные главы

    References