런북

프로덕션 인시던트가 발생하면 팀에는 런북이 있습니다. 파드 재시작, 데이터베이스 페일오버, 스케일링 작업 등 일반적인 장애에 대한 단계별 절차서입니다. 문제는 새벽 3시에 올바른 런북을 찾아 압박감 속에서 정확히 실행하는 것입니다. CloudThinker 런북이 그 간격을 메워줍니다. RCA 조사 중 AI 에이전트는 연결된 런북 소스를 자동으로 검색하고, 관련 절차를 찾아 복구 명령을 실행합니다. 파괴적인 작업에 대해서는 정책 기반 승인 제어를 통해 사람이 개입할 수 있도록 보장합니다.

수동 업로드 및 연결된 저장소가 포함된 런북 소스 대시보드

---

​

런북 작동 방식

---

​

런북 소스 연결

Deep Response Engine > Runbooks로 이동하여 소스를 관리하세요. CloudThinker는 네 가지 소스 유형을 지원하며, 각각 다른 워크플로에 적합합니다.

Confluence 구성으로 새 런북 소스 추가

​

Confluence

Confluence 지식 베이스를 연결하여 에이전트가 위키 페이지에서 운영 절차를 검색할 수 있도록 합니다. 설정:

1. 런북 페이지에서 소스 추가를 클릭합니다
2. 이름을 입력합니다 (예: “SRE 런북”)
3. 소스 유형으로 Confluence를 선택합니다
4. Atlassian 연결을 선택합니다 (연결 > Atlassian에서 설정)
5. 검색 범위를 특정 스페이스 키로 제한합니다 (선택 사항, 예: SRE)
6. 페이지를 필터링할 레이블을 추가합니다 (예: runbook, incident-response)
7. 소스 추가를 클릭합니다

에이전트 검색 방식: RCA 중 에이전트는 Confluence의 CQL 쿼리 언어를 사용하여 구성된 스페이스 및 레이블 필터 내에서 인시던트 컨텍스트와 일치하는 페이지를 찾습니다.

​

GitHub

에이전트가 런북 마크다운 파일이 포함된 GitHub 저장소를 참조하도록 설정합니다. 설정:

1. 소스 추가를 클릭합니다
2. 소스 유형으로 GitHub를 선택합니다
3. GitHub 연결을 선택합니다 (연결에서 설정)
4. 런북이 포함된 저장소를 선택합니다
5. 브랜치를 설정합니다 (기본값: main)
6. 검색 범위를 제한할 경로 접두사를 설정합니다 (선택 사항, 예: docs/runbooks/)
7. 매칭할 파일 패턴을 구성합니다 (기본값: *.md)
8. 소스 추가를 클릭합니다

에이전트 검색 방식: 에이전트는 GitHub API를 사용하여 경로 및 패턴 필터에 맞는 파일을 나열하고 읽은 후, 현재 인시던트와의 관련성을 분석합니다.

​

GitLab

GitHub와 동일한 워크플로로, GitHub 연결 대신 GitLab 연결을 사용합니다. 설정:

1. 소스 추가를 클릭합니다
2. 소스 유형으로 GitLab을 선택합니다
3. GitLab 연결을 선택합니다
4. 저장소, 브랜치, 경로 접두사, 파일 패턴을 선택합니다
5. 소스 추가를 클릭합니다

에이전트 검색 방식: 에이전트는 GitLab API를 사용하여 저장소에서 매칭 파일을 검색하고 가져옵니다.

​

수동 업로드

절차가 외부 시스템에 저장되지 않은 경우 마크다운 런북 파일을 직접 업로드합니다. 설정:

1. 런북 페이지에서 런북 업로드를 클릭합니다
2. .md 파일을 드래그 앤 드롭합니다 (파일 최대 20개, 각 5MB)
3. 확인 전 필요한 경우 파일 이름을 수정합니다
4. 업로드 확인을 클릭합니다

업로드 후 CloudThinker는 마크다운의 코드 블록에서 쓰기 명령 (kubectl apply, aws 변경, helm install 등)을 자동으로 추출합니다. 추출된 명령은 명령어별 권한의 기반이 됩니다.

---

​

명령어별 권한

수동 런북은 고유한 안전 기능인 명령어별 권한 제어를 제공합니다. 마크다운 파일을 업로드하면 CloudThinker의 AI가 코드 블록을 분석하여 모든 쓰기/변경 명령을 추출합니다. 이를 통해 에이전트가 자율적으로 실행할 수 있는 항목을 세밀하게 제어할 수 있습니다.

파드 CrashLoopBackOff 런북에 대한 명령어별 권한 제어

​

작동 방식

1. 자동 추출: 업로드 후 시스템이 모든 코드 블록을 파싱하여 인프라를 변경하는 셸 명령을 식별합니다 (예: kubectl set resources, kubectl rollout restart, kubectl delete)
2. 읽기 전용 명령 제외: kubectl get, kubectl describe, kubectl logs 같은 명령은 추출되지 않으며, 에이전트는 항상 읽기 전용 명령을 실행할 수 있습니다
3. 각 명령에 권한 부여: 추출된 모든 쓰기 명령은 기본적으로 승인 필요 상태로 시작합니다

​

권한 수준

​

명령 관리

런북 세부 정보 대화상자에서:

• 모든 권한 일괄 설정: “모두 다음으로 설정…” 드롭다운을 사용하여 모든 명령을 허용, 승인 필요, 또는 거부로 일괄 변경합니다
• 개별 권한 변경: 명령 옆의 드롭다운을 클릭하여 권한 수준을 조정합니다
• 명령 추가: 새 명령 패턴을 입력하고 Enter 키를 눌러 목록에 추가합니다
• 명령 제거: 삭제 아이콘을 클릭하여 정책에서 명령을 제거합니다
• 전체 명령 보기: 확장 화살표를 클릭하여 여러 줄이나 긴 명령의 전체 내용을 확인합니다

---

​

승인 워크플로

RCA 중 에이전트가 관련 런북을 찾고 정책이 승인을 요구하는 경우 다음 흐름이 진행됩니다:

​

승인 흐름

1. 에이전트가 런북 발견: 조사 중 에이전트가 소스를 검색하여 매칭 절차를 식별합니다
2. 정책 평가: 시스템이 런북 및 해당 명령에 대해 워크스페이스 승인 정책을 확인합니다
3. 알림 전송: 승인이 필요한 경우 구성된 모든 채널로 알림이 전송됩니다:
   • 이메일: 런북 제목, 소스 링크, 정책 사유
   • Slack: 인시던트 컨텍스트가 포함된 인터랙티브 알림
   • 인앱: 인시던트의 배지로 대기 중인 승인 표시
4. 승인 또는 거부: 승인을 클릭하여 에이전트가 진행하도록 하거나, 거부를 클릭하여 실행을 차단합니다
5. 에이전트 계속 진행: 승인 시 에이전트가 런북 명령을 실행합니다. 거부 시 에이전트는 런북을 실행하지 않고 조사를 계속합니다

​

승인 상태

​

실행 상태

승인 후 각 실행은 결과를 추적합니다:

​

실행 내역 보기

런북 페이지의 실행 내역 탭으로 전환하여 인시던트 전반에 걸친 모든 런북 실행 내역을 확인합니다. 다음 작업을 수행할 수 있습니다:

• 런북 제목으로 검색
• 정책 결정, 승인 상태, 실행 결과 확인
• 어떤 인시던트에 어떤 런북이 사용되었는지 추적

---

​

모범 사례

소스 구성:

• 소스 이름을 설명적으로 지정합니다 (예: “K8s 긴급 런북”, “데이터베이스 페일오버 절차”)
• 경로 접두사와 파일 패턴을 사용하여 검색 범위를 집중적이고 빠르게 유지합니다
• Confluence의 경우 레이블을 사용하여 도메인별로 런북을 분류합니다 (예: kubernetes, database, networking)

권한 전략:

• 확신이 생길 때까지 모든 명령에 대해 승인 필요 (기본값)로 시작합니다
• 검증된 저위험 명령은 점진적으로 허용으로 변경합니다 (예: 스케일링 작업, 로그 수집)
• 파괴적인 명령(삭제, 드롭, 강제)은 영구적으로 승인 필요로 유지합니다
• 자동화해서는 안 되는 명령에는 거부를 사용합니다 (예: 프로덕션 데이터베이스 삭제)

런북 품질:

• 셸 언어 힌트(```bash)가 있는 명확한 코드 블록으로 마크다운 런북을 작성합니다
• 최상의 추출 결과를 위해 한 줄에 하나의 명령을 사용합니다
• 각 절차를 언제 사용해야 하는지에 대한 컨텍스트를 포함합니다 — 에이전트가 런북을 인시던트에 매칭하는 데 사용합니다
• 런북을 집중적으로 유지합니다: 모든 것을 다루는 단일 문서보다 파일당 하나의 절차가 더 효과적입니다

---

​

다음 단계