Prompt Engineering Patterns for SRE Playbooks and Postmortems

개요

Site Reliability Engineering(SRE) 플레이북 생성 및 사후 부검(postmortem) 작성 과정에서 Prompt Engineering 패턴을 활용하여 문서화 부채를 줄이고 실제 사고 대응 시 유용한 문서를 만드는 방법을 설명합니다.

주요 내용

* Prompt Engineering을 SRE 워크플로우의 재사용 가능한 인프라로 취급: 단순히 일회성 ChatGPT 질의가 아닌, 체계적으로 관리되고 업데이트되는 프롬프트 패턴을 활용합니다.
* 일반적인 프롬프트의 한계: SRE 맥락에서는 시스템 토폴로지, 심각도, 구조화된 출력 계약이 부족하여 실질적인 도움을 주기 어렵습니다.
* 필요한 사전 조건: Python 3.11+, openai==1.30.0, tiktoken==0.7.0 라이브러리 설치, GPT-4o API 접근 권한, JSON 객체 응답 포맷 활용, 토큰 길이 제한 설정이 필요합니다.
* 패턴 1: 플레이북 생성을 위한 구조화된 컨텍스트 주입 (Structured Context Injection for Playbook Generation)
* 서비스 메타데이터(이름, 종속성, SLO, 알려진 장애 모드, 네임스페이스)를 YAML 프론트매터 형식으로 프롬프트에 주입하여 LLM이 서비스 환경을 이해하도록 합니다.
* response_format={"type": "json_object"}를 사용하여 JSON 구조화된 응답을 보장합니다.
* tiktoken을 사용하여 API 호출 전 토큰 수를 계산하고 컨텍스트 길이 초과 오류를 방지합니다.
* 긴 로그 파일을 직접 주입하기보다 오류 수준 이벤트 및 주요 타임스탬프로 사전 필터링하는 것이 중요합니다.
* 패턴 2: 2단계 사후 부검 합성 (Two-Step Postmortem Synthesis)
* 단일 프롬프트로 타임라인 추출과 근본 원인 분석(RCA)을 수행하는 대신, 두 단계로 분리하여 정확도를 높입니다.
* 1단계: 원시 로그 및 Slack 스레드에서 시간순 타임라인 추출 (JSON 배열 형식).
* 2단계: 추출된 타임라인을 사용하여 Google SRE 형식의 사후 부검 문서 합성.
* 중요 보안 고려 사항: PII, 내부 호스트명, IP 주소를 제거하는 검증(sanitization) 함수를 반드시 사용해야 합니다.
* 패턴 3: LLM-as-Reviewer를 통한 플레이북 검증 (Runbook Validation with LLM-as-Reviewer)
* LLM을 비평가 역할로 설정하여 기존 플레이북의 격차 분석을 생성합니다.
* "악마의 대변인(devil's advocate)" 지시를 포함시켜 부분적인 네트워크 장애 발생 시 각 단계가 어떻게 문제를 일으킬 수 있는지 시뮬레이션하도록 합니다.
* 이 패턴은 인간 검토보다 더 많은 간극을 발견할 수 있습니다.
* 프롬프트 엔지니어링의 검증 및 테스트:
* 동일한 플레이북 생성 프롬프트를 여러 번 실행하여 출력 일관성을 검증합니다.
* 생성된 kubectl 및 gcloud 명령은 실제 프로덕션 환경에 적용하기 전에 반드시 dry-run 또는 스테이징 클러스터에서 검증합니다.
* LLM-as-judge 패턴을 사용하여 생성된 결과의 완성도, 정확성, 실행 가능성을 평가하고 점수를 부여할 수 있습니다.
* 프롬프트 관리: 플레이북과 마찬가지로 프롬프트 템플릿도 Git에 버전 관리하고 PR을 통해 검토하며, 사고 발생 후 업데이트하는 등 코드처럼 관리해야 합니다.

시사점

SRE 플레이북 및 사후 부검 작성을 위한 Prompt Engineering 패턴은 LLM의 구조화된 출력 능력과 SRE 환경의 컨텍스트를 결합하여, 3 AM에도 신뢰할 수 있고 실행 가능한 문서를 생성함으로써 운영 효율성과 안정성을 크게 향상시킬 수 있습니다.