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

승인 기능 다음에 생긴 문제

Operational Catalog override에 preview, draft와 승인 단계를 붙인 뒤 다음 질문이 남았다.

승인된 변경을 실제 운영 저장소와 배포 과정까지 어떻게 연결할 것인가?

Platform이 승인 즉시 현재 설정 파일을 바꾸면 구현은 단순하다. 하지만 RCA 플랫폼은 장애를 분석하는 시스템이다. 분석 결과나 추천 조치가 자기 자신 또는 진단 대상 환경을 직접 수정하기 시작하면 장애 시점의 안전 경계가 무너질 수 있다.

그래서 승인 이후의 변경은 GitOps PR로 넘기고, Platform은 생성과 상태를 추적하되 직접 배포하지 않는 방향을 선택했다.

적용 범위를 일부러 좁혔다

GitOps 연동의 직접 대상은 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이나 변경 티켓을 남긴다. Git merge가 배포 성공과 같지 않다는 점을 상태 모델에 반영했다.

중복 PR을 막는 방법

같은 Draft에 대해 사용자가 버튼을 여러 번 누르거나 두 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를 통해 주입한다. Web Console과 Audit에는 원문이 노출되지 않는다.

Production profile에서는 다음 설정을 시작 단계에서 확인한다.

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

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

RCA 플랫폼이 찾아낸 원인이 맞더라도 운영 환경 변경에는 별도의 맥락이 필요하다. 배포 중인 작업, 유지보수 시간, 다른 장애와 조직 승인 정책은 Evidence만으로 알 수 없다.

GitOps PR은 자동화를 포기한 것이 아니라 자동화의 경계를 리뷰 가능한 지점에 둔 것이다.

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

이렇게 책임을 나누면 RCA 플랫폼은 운영자에게 다음 단계를 제공하면서도 자기 판단으로 환경을 바꾸지 않는다.

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