운영 변경을 직접 실행하지 않고 GitOps PR로 추적하기

승인 기능 다음에 생긴 문제

Operational Catalog override에 preview, draft, 승인 단계를 붙인 뒤 운영 저장소와 연결할 방법을 정했다.

Platform이 승인 즉시 설정을 수정하면 분석 결과가 진단 대상이나 Platform 자체를 바꿀 수 있었다. 실제 변경은 외부 리뷰와 배포 절차를 거치게 하려고 했다.

승인된 변경은 GitOps PR로 넘기고 Platform에서는 생성 상태와 결과를 추적하도록 했다. 직접 배포하는 기능은 넣지 않았다.

적용 범위를 일부러 좁혔다

연동 대상은 catalog_override_draft로 제한했다. 일반 RCA 권장 조치를 Kubernetes manifest 변경으로 자동 변환하지는 않았다.

구성한 흐름은 다음과 같다.

Catalog override preview
  → Draft 저장
  → ADMIN 또는 APPROVER 승인
  → OPERATOR가 PR 생성 확인
  → 외부 저장소에 Draft PR/MR 생성
  → 리뷰와 병합
  → 외부 배포 결과 기록
  → 필요 시 rollback reference 기록

운영 기준 파일처럼 입력과 결과를 확인할 수 있는 변경부터 연결했다. DiskPressure 감지로 이미지 정리 Job이나 노드 변경 PR을 자동 생성하는 범위는 포함하지 않았다.

GitHub·GitLab·Gitea를 같은 모델로 추적하기

Provider별 API와 webhook 형식은 달랐다. Platform 안에서는 공통 GitOps change 모델로 관리했다.

• GitHub와 Gitea: Draft Pull Request
• GitLab: Draft Merge Request
• 공통 정보: branch, commit, 원격 번호, URL, open/merged/closed 상태

배포 결과는 PR이 병합된 뒤에만 기록할 수 있도록 했다.

pending → in_progress → succeeded | failed → rolled_back

verification_result에는 canary와 checksum 확인 결과를, rollback_reference에는 rollback PR이나 변경 티켓을 남기게 했다. 병합과 배포 성공을 서로 다른 상태로 기록한 것이다.

중복 PR을 막는 방법

반복 클릭이나 여러 Platform 인스턴스의 동시 요청을 고려했다. 원격 API를 호출하기 전에 DB의 Draft와 Provider 조합을 unique key로 선점하도록 했다.

같은 요청은 기존 change를 반환하게 했다. 원격 호출이 실패하면 failed 상태를 남기고, 운영자가 원인을 확인하도록 했다. 자동 재시도로 별도 PR이 생기지 않게 하려는 처리다.

Webhook delivery ID도 중복 저장하지 않았다. 같은 이벤트가 다시 오면 409 Conflict로 거절하고 Audit event를 남겼다.

Webhook과 Secret 경계

GitHub와 Gitea의 raw request body는 HMAC-SHA256 signature를 검증했고, GitLab secret token은 constant-time 비교를 사용했다.

Repository token과 webhook secret은 DB에 저장하지 않고 Kubernetes Secret, Docker 환경 변수 또는 외부 Secret Manager로 주입하도록 했다. Console과 Audit에도 원문을 노출하지 않았다.

Production profile 시작 시 다음 설정을 확인하도록 했다.

• 지원 Provider인지
• API URL이 HTTPS인지
• Repository 경로 형식이 맞는지
• Token과 webhook secret이 설정됐는지
• 변경 파일 경로와 base branch가 명확한지

왜 자동 병합과 자동 배포를 하지 않았나

원인 분석이 맞더라도 실제 변경에는 배포 중인 작업, 유지보수 시간, 다른 장애, 조직 승인 정책을 함께 고려해야 했다. Evidence만으로 판단할 수 없는 부분이었다.

그래서 변경안을 리뷰하고 적용하는 책임을 다음처럼 나눴다.

• Platform: 근거와 변경안을 구조화
• 승인자: 변경 필요성과 위험 검토
• Git Provider: 코드 리뷰와 변경 이력
• 배포 시스템: 실제 적용과 canary
• Platform: 결과와 rollback reference 추적

Platform은 변경안과 결과를 추적하고, 실제 환경 변경은 외부 리뷰와 배포 절차에서 수행하도록 했다.

프로젝트 저장소: Kubernetes Cluster Infra RCA Platform