운영 변경을 직접 실행하지 않고 GitOps PR로 추적하기
RCA 플랫폼이 운영 환경을 직접 수정하지 않으면서도 승인된 변경을 GitOps PR과 배포 결과로 끝까지 추적하도록 만든 과정을 정리했습니다.
TOPIC COLLECTION
DevOps
12 posts클러스터마다 다른 임계값과 운영 카탈로그를 분리하기
Collector 선택, Rule 활성화, 권장 조치와 임계값을 코드에서 분리해 운영 카탈로그와 클러스터별 override로 관리한 이유를 정리했습니다.
RCA 보고서를 증거 번들로 내보내고 무결성을 검증하기
RCA 결과를 화면의 JSON으로 끝내지 않고, 근거와 타임라인을 함께 보존하는 증거 번들과 무결성 검증 구조로 확장한 과정을 정리했습니다.
Flyway, Incident, Audit까지 묶어 운영 플랫폼으로 다듬기
Spring Boot와 React 기반으로 구조를 전환한 뒤, Flyway migration, incident 관리, audit event, metric, retention을 추가하면서 RCA 플랫폼을 운영 도구답게 다듬은 과정을 정리했습니다.
React 19와 TypeScript로 Web Console 다시 구성하기
Spring Boot 기반 Platform으로 전환한 뒤, Web Console을 React 19, TypeScript, Vite, Bootstrap 5 기반으로 다시 구성하면서 고민했던 점을 정리했습니다.
FastAPI를 버리고 Spring Boot로 통합한 이유
초기 FastAPI 기반 Backend에서 Spring Boot 3.5.15와 Java 21 기반 통합 Platform으로 전환하면서, 왜 기술 스택을 바꾸게 되었는지 정리했습니다.
RCA 플랫폼을 관리 가능한 형태로 다듬기
Docker Compose로 실행 구조를 묶은 뒤, cluster 삭제, RCA report export, README 정리까지 진행하면서 프로젝트를 실제로 관리 가능한 플랫폼 형태로 다듬은 과정을 정리했습니다.
Docker Compose로 RCA 플랫폼 실행 구조 묶기
Backend, Web Console, DB, migration 흐름을 Docker Compose로 묶으면서 로컬에서도 RCA 플랫폼 전체 구조를 실행하고 검증할 수 있게 만든 과정을 정리했습니다.
RCA 결과를 운영자가 이해할 수 있게 만들기: Web Console 설계
RCA report가 생성되더라도 운영자가 근거를 따라가며 이해할 수 없다면 실무에서 쓰기 어렵습니다. Web Console을 붙이면서 report 목록, 상세 화면, policy 판단, 에러 표시를 어떻게 설계했는지 정리했습니다.