Деплой и инфра
Капстоун deployment: выкатите production-конвейер
Вы собрали каждую стадию цепочки по отдельности. Капстоун — скомпоновать их в один релиз, переживающий деплой под живым трафиком — и доказать это, намеренно доведя каждый шов до предела и показав, что контракт держится. Это тот артефакт, на который вы укажете новому сотруднику, объясняя, как сервис на самом деле выкатывается.
Превратите весь трек в один воспроизводимый конвейер: соберите неизменяемый образ, объявите объекты k8s, выберите и настройте стратегию rollout с реальными health-gate, инжектите секреты в runtime, поставьте впереди L7-балансировщик с draining и закодифицируйте всё как IaC — затем продемонстрируйте релиз без простоя, включая изменение схемы и откат.
Спроектируйте и выкатите полный production-конвейер деплоя для небольшого stateful HTTP-сервиса (API на реляционной БД) и докажите, что он переживает релиз без простоя — включая миграцию БД и откат — при непрерывном трафике.
- Единый репозиторий (или каталог), где terraform/helm apply с чистого состояния пересоздаёт весь работающий сервис — digest образа, объекты, probes, проводку секретов, LB и конфиг rollout — без единой ручной правки kubectl.
- Трейс релиза под живой нагрузкой, показывающий, что error rate держится на базлайне, а p99-латентность не скачет на переключении; readinessProbe показан падающим при старте pod и проходящим только когда пул к БД открыт.
- Доказательство, что изменение схемы выкачено через expand-contract: три деплоя (expand, migrate/dual-write, contract) различимы, а откат, выполненный между ними, корректно обслуживает, потому что ни одна промежуточная схема не сломала N-1 совместимость.
- Доказательство, что в образе нет секрета (docker history чист) и что секреты разрешаются только в runtime; заметка о том, как k8s Secret защищён помимо base64 (шифрование at-rest или внешний менеджер).
- Однастраничное описание архитектуры, называющее каждую стадию, контракт на каждом шве и какая настройка его обеспечивает — документ, который читает новый сотрудник, чтобы понять, как сервис выкатывается.
- Добавьте CI/CD-конвейер, который собирает образ, сканирует его на CVE, прогоняет IaC plan, гейтит merge на чистой проверке drift против живого кластера и промоутит в prod только после того, как canary автоматически прошёл свой metric-gate.
- Добавьте автоматический детект drift: IaC plan по расписанию, алертящий на любой diff между объявленным и фактическим состоянием, и policy/admission-проверку, отклоняющую внеполосные правки kubectl.
- Проведите fault-drill: убейте pod посреди запроса, протухните зависимость readiness и примените намеренно несовместимую миграцию на ветке — покажите, что draining, probe и дисциплина expand-contract каждый предотвращают видимую пользователю аварию, и зафиксируйте сигналы, поймавшие плохую миграцию до prod.
- Реализуйте progressive delivery с автоматическим canary-контроллером (Argo Rollouts / Flagger), который сдвигает трафик ступенями, следит за golden signals и авто-откатывается при пробое метрики — затем спровоцируйте авто-откат и зафиксируйте доказательства.
Это тот цикл, который гоняет каждый реальный релиз: соберите неизменяемый артефакт, объявите объекты, сделайте «готов» равным «обслуживает» реальным probe, выберите стратегию rollout, чей успех гейтится метрикой, держите схему N-1 совместимой через expand-contract, чтобы rollout оставался обратимым, делайте draining запросов в полёте на L7 при сотрудничестве SIGTERM, инжектите секреты в runtime и защищайте их помимо base64, и закодифицируйте всё как IaC, чтобы среда, которую вы протестировали, была той, что вы выкатили. Скомпоновать стадии — и проинженерить каждый шов между ними — один раз на игрушечном сервисе и есть то, что делает production-версию мышечной памятью.