설정 버전 제어

1) 버전을 구성하는 이유

설정은 실행 가능한 정책입니다. 라우팅, 제한, 기능 플래그, 액세스, 데이터 스키마를 정의합니다. 버전 제어는 변경 사항을 반복 가능하고 관찰 가능하며 가역적으로 만듭니다. MTTR 및 변경 실패율을 줄이고 "매직 판매" 를 제거하며 보안 및 규정 준수에 대한 감사를 제공합니다.

2) 구성 분류

인프라 (IaC): 클러스터, 네트워크, LB, DB, 대기열.
서비스: 응용 프로그램 매개 변수, 리소스, 한계, 타임 아웃, 배상.
제품/비즈니스 논리: 관세, AB 실험, 컨텐츠 규칙.
데이터/DataOps: 계약 체계, SLA 신선도, 변환.
보안: 액세스 정책, 역할, 키/인증서 (비밀 자체가 리포 외부에 있음).
관찰 가능성: SLI/SLO, 경고, 대시 보드.

규칙: 시스템의 동작에 영향을 미치는 모든 것은 구성이며 버전에 따라 살아야합니다.

3) 원칙 수정

1. GitOps: 진실의 유일한 원천은 저장소입니다. PR 및 자동 파이프 라인을 통한 변경.
2. 선언: 단계 스크립트가 아닌 대상 상태에 대한 설명.
3. 아티팩트의 불변성: 확실하게 구체화 된 스냅 샷.
4. 스키마 및 검증: JSON/YAML 스키마, 엄격한 유형 캐스팅, 필요한 필드.
5. 코드: 'env' 와 같은 환경-폴더/오버레이 (devs/stage/prod), 차이점은 미미하고 명백합니다.
6. 이데올로기 및 롤백: 구성 릴리스를 되돌리거나 롤백합니다.
7. 감사 및 추적 성: 저자, 이성, 티켓/RFC, 서명 변경.

4) 검증 전략

• 메이저 - 호환되지 않는 스키마/정책 변경.
• MINOR-새로운 필드/규칙, 이전 버전과의 호환성.
• PATCH-체계를 변경하지 않고 값을 수정합니다.
• 태그 릴리스 및 릴리스 메모: 변경된 사항, 롤백 방법, 체크 포인트.
• 피닝/잠금 파일: 종속성 버전 (모듈, 차트) 을 수정합니다.
• 매트릭스 버전: X 응용 프로그램의 아티팩트는 Y 설정 (서비스 카탈로그의 매트릭스) 과 호환됩니다.

5) 리포지토리 조직

config-repo/
policies/     # общие политики (RBAC, SLO, алерты)
services/
checkout/
schema/    # JSON/YAML схемы конфигов base/     # дефолтные значения overlays/
dev/
stage/
prod/
data-contracts/  # схемы данных, SLA свежести releases/     # теги, changelog, артефакты валидации tools/      # линтеры, генераторы, тесты

지점: 트렁크 기반 (주) + 짧은 지형 지점. 필수 CI만으로 PR을 통해 병합하십시오.

6) 검증 및 테스트

스키마: 각 변경 사항은 스키마 검증 (필요한, 에넘, 범위) 을 통과합니다.
정적 라인터: 형식, 키, 복제, 금지 된 필드.
호환성 테스트: 설정 + 서비스/차트 버전이 샌드 박스에서 올라갑니다.
테스트 실행: 건식 응용 프로그램, "What-if" diff 대상 상태.
코드 별 정책: 입학 규칙 (Rego/CEL) -누가 변경할 수 있습니까?

7) 풀기 및 롤백 구성

점진적 전달: SLO- 가드 레일로 카나리아 1% → 5% → 25%.
배치 게이트: 활성 SEV-1이없고, 경고가 녹색이며, 서명이 유효하며, 롤백이 준비되었습니다.
롤백: '반복 태그 vX. Y.Z '또는 이전 스냅 샷으로 전환; 롤백 명령은 런북에 문서화되어 있습니다.
릴리스 주석: 설정 버전은 사고와 빠르게 관련되도록 메트릭/로그로 게시됩니다.

8) 동적 및 원격 구성

원격 설정/기능 플래그: 다시 시작하지 않고 매개 변수 변경; 모든 플래그는 GitOps에도 있습니다.
경계: 어떤 매개 변수가 동적으로 변경 될 수 있습니까 (화이트리스트 목록).
캐시 및 일관성: TTL, 버전, 원자 세트 교체 (2 상 게시).
안전한 난간: 런타임 변경을위한 제한 및 범위, SLO를 떠날 때 자동 롤백.

9) 비밀과 민감한 데이터

비밀을 리포지토리에 보관하지 마십시오. 구성에서는 링크/플레이스 홀더 만 있습니다.
필요한 경우 구성 파일의 암호화: 비밀/키 관리자와의 통합.
회전 및 JIT: 작업 기간 동안 액세스가 발행됩니다. 행동의 흔적은 불변입니다.
현장 마스킹: 검증 결과 PII/비밀이 설정에 들어가는 것을 금지합니다.

10) 환경 관리

기본 + 오버레이: 개발/스테이지/prod의 차이점은 최소화되고 투명합니다.
아티팩트 프로모션: 스테이지를 통과 한 것과 동일한 스냅 샷이 prod로 홍보됩니다.
시간 창: 의무 변경 시점에는 구성 요소의 변경이 발생하지 않습니다. 위험이 높은 경우-RFC 및 유지 보수 창.

11) 드리프트 감지 및 제거

컨트롤러는 대상 상태를 실제 상태와 비교하고 diff를보고합니다.
드리프트 경고: 중요한 불일치에 대해서만 페이지; 다른 것은 티켓입니다.
자동 치료: 해결시-대상 상태로 돌아갑니다.
감사 매뉴얼 편집: "kubectl 편집/ssh" → 프로세스 사고 및 CAPA.

12) 설정 카탈로그 및 소유권

서비스 카탈로그: 소유자, SLO, 관련 정책, 스키마, 버전, 호환성.
RACI: 누가 제공하는지, 누가 검토하고, 승인하는지; 위험이 높은 CAB.
투명성: 각 항목에는 버전 기록이 있으며 PR/티켓/AAR에 대한 링크가 있습니다.

13) 성숙도 지표

적용 범위: GitOps 서비스/정책의% (대상 95%).

리드 타임 설정 변경: PR에서 prod로 중간

실패율 변경: 롤백/사고가있는 설정 릴리스의 비율.
드리프트 속도: 불일치 수/주 및 제거 시간.
롤백 시간: 이전 버전으로의 중간 복구.
감사 완전성: 완전한 증거가있는 변경 사항의 비율 (유효성 검사기, 드라이 런, 리뷰).

14) 점검표

설정을 변경하기 전에

• 티켓/RFC와 변경 소유자가 있습니다.
• 계획과 린터가 검증되었습니다.
• 런북에 롤백 계획과 명령이 있습니다.
• 게이트: 녹색 테스트, 유효한 서명, 활성 SEV-1 없음.
• 고위험의 경우 유지 보수 창이 할당됩니다.

긴장을 풀는 동안

• 카나리아 및 SLO- 가드 레일이 활성화되어 있습니다.
• 릴리스 주석이 게시됩니다.
• 채널에 에코 메시지가 있습니다. MW 규칙에 의해 경고 노이즈 억제.

나중에

• 관찰 창이 통과되고 SLO 녹색입니다.
• 총계 및 증거 (차트 전/후, 드라이 런 보고서) 가 티켓에 첨부됩니다.
• 필요에 따라 회로도/문서를 업데이트했습니다.

15) 미니 템플릿

15. 1 설정 다이어그램 (YAML 스키마, 단편)

yaml type: object required: [service, timeouts, retries]
properties:
service: { type: string, pattern: "^[a-z0-9-]+$" }
timeouts:
type: object properties:
connect_ms: { type: integer, minimum: 50, maximum: 5000 }
request_ms: { type: integer, minimum: 100, maximum: 20000 }
retries:
type: object properties:
attempts: { type: integer, minimum: 0, maximum: 10 }
backoff_ms: { type: integer, minimum: 0, maximum: 5000 }

15. 2 기본 설정 + 오버레이 prod

yaml services/checkout/base/config.yaml service: checkout timeouts: { connect_ms: 200, request_ms: 1500 }
retries: { attempts: 2, backoff_ms: 200 }
limits:  { rps: 500 }
features:
degrade_search: false psp_a_weight: 80 psp_b_weight: 20

yaml services/checkout/overlays/prod/config.yaml limits:  { rps: 1200 }
features:
psp_a_weight: 70 psp_b_weight: 30

15. 3 입학 정책 (아이디어)

yaml allow_change_when:
tests: passed schema_validation: passed active_incidents: none_of [SEV-0, SEV-1]
rollback_plan: present signed_by: ["owner:team-checkout","platform-sre"]

15. 4 설정 릴리스 카드

Release: checkout-config v2.3.1
Scope: prod EU
Changes: psp_b_weight 20→30, request_ms 1500→1300
Risk: Medium (маршрутизация платежей)
Canary: 1%→5%→25% (30/30/30 мин), guardrails: success_ratio, p95
Rollback: tag v2.3.0

16) 반 패턴

"라이브" 에는 버전과 기록이없는 플래그가 있습니

GitOps의 과거 편집 ("빠르게 비틀림").
설정 저장소의 비밀/PII.
다이어그램 부족 및 정적 검사.
환경의 강력한 발산 (기본 단위 prod).
서버의 드리프트 및 수동 편집을 무시합니다.
출시 메모 및 롤백 계획이없는 태그.

17) 구현 로드맵 (4-6 주)

1. 네드. 1: 컨피그의 인벤토리; 별도의 카탈로그, 상위 10 개 서비스 체계.
2. 네드. 2: CI에서 라인터/검증 및 드라이 런을 포함하고; 녹색 점검없이 합병 금지.
3. 네드. 3: GitOps 롤 + 카나리아; 원격 측정의 버전 주석.
4. 네드. 4-코드 정책 및 롤백 패턴을 입력하십시오. 드리프트 경고.
5. 네드. 5-6: 서비스의 90% 를 커버합니다. 오버레이에 대한 env 차이를 줄입니다. 성숙도 지표를 추가하고 설정 변경 사항을 매주 검토하십시오.

18) 결론

구성 버전 제어는 Git뿐만 아니라 시스템입니다. 교환 및 검증, GitOps 및 액세스 정책, 카나리아 및 롤백, 드리프트 감지 및 전체 감사 설정이 관리 아티팩트로 전환됩니다. 결과는 각 릴리스에 대한 빠르고 안전한 변경, SLO 예측 가능성 및 팀 신뢰성입니다.