회복성 및 배포 안전은(는) 무엇을 하나요?
개요
문제는 발생합니다. 우리의 자세는 '모든 실패를 예방하는 것'이 아니라 작게 실패하고, 빠르게 복구하며, 매번 배우는 것입니다. 신뢰성은 실패가 없는 상태가 아니라, 실패가 발생했을 때 블래스트 반경이 제한되고 복구 시간이 짧은 상태를 의미합니다.
배포 안전 — 모든 배포는 롤백 가능하고 점진적으로 노출되어야 함
- 아티팩트는 불변이며 승격(promote)되며, 다시 빌드되지 않습니다. CI에서 한 번 빌드된 단일 이미지는 콘텐츠 다이제스트로 식별되어 프리뷰 → 스테이징 → 프로덕션으로 변경되지 않은 상태로 이동합니다. 환경마다 다시 빌드하는 것은 테스트하지 않은 것을 배포하는 것입니다.
- 태그는 가변 포인터이며, 다이제스트가 정체성입니다. 태그는 덮어쓰여질 수 있으며 조용히 다른 곳을 가리킬 수 있습니다. 콘텐츠 다이제스트는 그렇지 않습니다. 각 환경은 자신이 검증한 다이제스트를 기록하며, 프로덕션은 하위 환경에서 검증된 다이제스트만 실행합니다. 따라서 '우리가 테스트한 바로 그 것'은 누군가가 기억해야 하는 규율이 아니라 파이프라인이 강제하는 속성입니다.
- 프로덕션 배포 전에는 사람의 결정이 필요합니다. 단일 관리자의 경우 이는 의도적인 일시 중지와 감사 기록이지, 직무 분리가 아닙니다. 어떤 경우인지 명시하고, 과장하지 마십시오.
- 실행 중인 버전은 배포 시점에 주입되며, 이미지에 빌드되어서는 안 됩니다. 빌드 인자로 빌드된 버전은 릴리스 스탬프를 찍기 위해 재빌드를 강제하며, 재빌드는 바로 승격이 피하고자 하는 것입니다.
- 인프라가 별도 리포지토리에 있을 때는 확장/축소(expand/contract) 방식으로 조정합니다. 인프라가 먼저 확장(추가적, 하위 호환)되고, 이후 배포에서 애플리케이션이 새로운 기능을 사용하며, 더 이상 라이브 아티팩트가 예전 구조에 의존하지 않을 때만 인프라가 축소됩니다. 이는 스키마 변경과 동일한 규율입니다(
zero-downtime-migrations참조). 불변 조건: 아직 활성화되지 않은 인프라 변경을 필요로 하는 애플리케이션 아티팩트를 절대 배포하지 마십시오. 이 조건이 지켜지면 각 리포지토리는 독립적으로 롤백 가능하며, 이것이 두 리포지토리가 동기화되지 않았을 때 롤백을 처리 가능하게 만듭니다. - 롤백할 수 있을 때만 롤포워드(roll forward)하십시오. 위험한 변경을 배포하기 전에 롤백 경로가 존재하고 테스트되어 있어야 합니다. "이것을 어떻게 되돌릴까?" 라는 질문은 인시던트 중이 아니라 계획 단계에서 답해야 합니다.
- 롤백은 이전에 정상이었던 다이제스트를 재배포하는 것입니다. 해당 다이제스트는 여전히 레지스트리에 있고 불변이므로, 롤백은 역방향 승격입니다. 절대 재빌드가 아니며, "예전 그대로" 재빌드하는 것도 아닙니다.
- 점진적 노출. 새 버전은 점진적으로(헬스 게이트 롤아웃, 지원되는 경우 카나리) 사용자에게 도달하므로, 잘못된 릴리스가 모든 사람이 아닌 일부에게만 피해를 줍니다.
- 스키마 변경은 코드 배포와 분리되며 확장/축소 방식을 따릅니다(
zero-downtime-migrations참조). 배포는 절대 동시에 파괴적인 마이그레이션을 필요로 해서는 안 됩니다. - 배포 준비 체크리스트가 프로덕션 게이트 역할을 합니다: 관찰 가능성 확보, 롤백 검증, 마이그레이션 확장 안전 확인, SLO 위반 없음.
인시던트 대응 — 실패는 학습 입력
- 심각도에 따라 분류하고 비례적으로 대응하며, 적절한 사람을 참여시킬 수 있는 알려진 경로를 확보하십시오.
- 모든 사용자 대상 인시던트에 대해 무결점 포스트모템을 작성하십시오. 작성된 타임라인, 기여 원인(시스템적, 개인적이 아닌), 구체적인 행동 항목을 포함합니다. 질문은 "시스템의 어떤 부분이 이를 허용했는가"이지, "누가 잘못했는가"가 아닙니다.
- 행동 항목은 추적되며 잊히지 않습니다. 향후 고려 사항 문서(
recording-decisions참조)로 이어져 실제 작업이 됩니다. - 에러 예산이 의사결정을 지배합니다. 신뢰성이 소진되었을 때는 예산이 회복될 때까지 신뢰성 작업이 기능 작업보다 우선합니다.
빠른 참조
| 위험한 배포 전 | 확인 사항 |
|---|---|
| 아티팩트 | CI에서 한 번 빌드되고 다이제스트로 승격됨, 스테이징이 검증한 동일 아티팩트 |
| 게이트 | 프로덕션 전에 기록된 사람의 결정 |
| 롤백 | 경로가 존재하고 테스트됨 |
| 노출 | 점진적/카나리, 한 번에 전체 아님 |
| 스키마 | 확장 안전, 코드 배포와 분리 |
| 관찰 가능성 | 문제가 발생 중인지 알 수 있는가? |
이 규모를 언제 적용할 것인가
로컬/출시 전 프로젝트는 지금 이 규칙을 작성하고, 첫 번째 실제 사용자와 함께 활성화합니다. 이러한 속성은 이식 가능합니다(한 번 빌드, 테스트한 것을 승격, 프로덕션 전에 결정, 롤백 가능) — 그러나 메커니즘은 그렇지 않습니다. 다이제스트 승격은 컨테이너 호스트에서 의미가 있지만 정적 사이트에서는 대부분 무의미하며, 관리형 플랫폼은 프리뷰 환경과 즉각적인 롤백을 무료로 제공할 수 있습니다. 프로젝트의 전달 스킬에 메커니즘을 명시하고, 속성은 여기에 유지하십시오. 스택 메커니즘(k8s 프로브, 카나리, PR별 환경): cloud-delivery-aks.
전체 근거: engineering-constitution/references/engineering-constitution.md에 번들된 헌법 제12조.