운영 플레이 북
1) 플레이 북이란 무엇이며 런북과 어떻게 다른가
런북은 일반적인 작업/경고 ("하나, 둘, 셋") 에 대한 선형 단계별 명령입니다.
플레이 북은 포크가있는 시나리오에 대한 결정 트리입니다. 다른 증상 → 다른 가설 → 다른 행동 분기. 선택 기준, 게이트 조건 및 대체 지점이 포함됩니다.
플레이 북의 목적은 불확실성 하에서 MTTA/MTTR 및 즉흥 수준을 줄이는 것입니다.
2) 플레이 북이 먼저 필요한 곳
사건: SLO 하락 (가용성/대기 시간/성공), 비즈니스 SLI 실패 (결제 전환/성공).
변경 사항: 릴리스, 마이그레이션, 기능 플래그, 구성 요소 (카나리아/롤백).
유지 보수 창: 데이터베이스/브로커 업그레이드, 인증서 회전.
제공자: PSP/KYC/CNC/IDP-성능 저하 및 스윙.
보안: 키 손상, 의심스러운 활동.
DataOps: 신선도 지연, 회로 드리프트, 파이프 라인 저하.
3) 플레이 북 표준 (최소 구성)
1. 카드: ID, 버전/날짜, 소유자 (팀/역할), 서비스/지역/임차인, 관련 정책/표준.
2. 목적 및 출시 조건: 우리가 보호하는 SLO/SLI, 경고/트리거가 적용 가능합니다.
3. 증상은 가설: 대응 테이블, 잘못된 가설을 신속하게 차단하는 방법.
4. 의사 결정 트리: 포크, 보안 게이트, 정지/계속 기준.
5. 동작: 런북에 명령/링크가있는 단계 블록 '및.
6. 커뮤니케이션: 템플릿 업데이트 (Impakt → Diagnostika → Deystviya → Sled. 업데이트), 채널 및 주파수.
7. 롤백/폴백: 명확한 백아웃 계획, 한계 및 UX 분해 플래그.
8. 완료 기준: 지표, 관찰 시간 창.
9. 증거: 저장해야 할 사항 (로그, 그래프, 스크린 샷, 티켓 ID).
10. 변화의 역사: 변경 로그, 알려진 한계.
4) 플레이 북 분류법 (예: 카탈로그)
INC- 사고 (SLO/SLI, 공급자, 인프라).
REL- 릴리스, 롤백, 구성/플래그.
MW- 유지 보수 창 (DB/큐/인증/OS).
SEC- 보안 (액세스, 키, 의심스러운 행동).
DATA- - 신선도/품질/체계.
PROV- 외부 제공 업체 (PSP/KYC/CNC/이메일/SMS).
5) 수명주기 및 소유권
1. 개시: 사고/시뮬레이션/변경을 기반으로합니다.
2. 초안: 저자 = 서비스 소유자; 검토: SRE/보안/데이터 (도메인 별).
3. 파일럿: 탁상/게임 데이; 통과 시간 및 결함 기록.
4. 출판: repo (Docs-as-Code), 버전, 태그, 대시 보드 링크.
5. 업데이트: RCA/CAPA에 따르면 적어도 분기당 한 번; SLA 신선도.
6. 보관/고갈: 관련성 교체/손실의 경우.
6) 도구와의 통합
경고 → 플레이 북: 각 페이지 규칙은 정확히 하나의 기본 플레이 북을 참조합니
ChatOps: '/재생 시작 <id> '는 카드를 열고 증거를 수정하며 업데이트 타이머를 설정합니다.
CMDB/카탈로그: 서비스에는 관련 플레이 북, 소유자, SLO, 대시 보드 목록이 있습니다.
GitOps: 플레이 북과 런북은 Git에 살고 있으며 PR 리뷰와 린터가 있습니다.
7) 플레이 북 품질 지표
작동 성: 실행의 90% 이상이 무의식적으로 증가하지 않고 특정 작업을 수행합니다.
타임 투 퍼스트 액션: 페이지에서 첫 번째 의미있는 단계까지 1 분 또는 2 분.
적용 범위: 바운드 플레이북이 있는% 페이지 알림 (100% 대상).
신선도: 플레이 북의 비율이 90 일보다 신선합니다.
결함 속도: 100 개의 플레이 북에 대한 리뷰/시뮬레이션에 대한 의견.
재사용: 플레이 북이 실제로 적용된 횟수 (및 그 결과).
8) 반 패턴
의사 결정 트리가없는 20 페이지의 "Playbook Encyclopedia".
결과에 대한 기대없이 명령 ("실행 X" -무엇을 변경해야합니까?).
백 아웃 계획과 한계는 없습니다. 문제가 확대 될 위험이 있습니다.
통신 채널/간격은 표시되지 않습니다-PR 위험의 증가.
소유자/업데이트 날짜가없는 플레이 북-아무도 그 관련성을 믿지 않습니다.
하나의 매개 변수 대신 수십 개의 유사한 플레이 북.
9) 플레이 북 미니 템플릿 (YAML 아이디어)
yaml id: INC-PAY-001 name: "Payment Success Down"
version: 2. 4 (2025-10-15)
owner: team-payments@sre scope: [prod, region: eu, tenants: all]
goal: "Restore success_ratio ≥ 98% without violating SLA"
triggers:
- alert: slo. burn. payment_success_ratio
- external_status: psp-a partial outage symptoms:
- "5xx growth in payments-api"
- "p95 latency> 400ms on PSP-A"
decision_tree:
- if: "quorum(eu,us) confirms drop AND PSP-A status=partial"
then:
- action: "Reduce PSP-A weight to 30%"
runbook: rb://payments/traffic-shift guardrails: ["success_ratio improving 10m", "p95<300ms"]
- action: "Enable degrade_payments_ux"
runbook: rb://payments/feature-flags
- action: "Status update (30m) by template"
comms: statuspage://payments else:
- action: "Check database/cache/queue"
runbook: rb://payments/diag-stack fallback:
- action: "Failover на PSP-B 70%"
guardrails: ["fraud_rate stable", "chargeback risk noted"]
rollback:
- condition: "PSP-A green 60m"
- steps:
- "Weight of PSP-A 30→70→80 (every 30 m at green SLI)"
evidence:
- "SLI screenshots, p95/5xx graphs, links to logs/trails"
completion:
- "success_ratio ≥98% during 30 m, no burn in 6 h"10) 준비된 예 (조각)
A) 지불: "한 지역에서 공급자가 분해됩니다"
증상: TR 코호트의 성공 _ 비율 감소, PSP-A 타임 아웃 증가.
솔루션: TR에 대한 PSP-A의 무게를 줄이고, UX를 저하시키고, 예산
백 아웃: 60 분의 녹색 SLI에서 웨이트 회복.
B) DB: "성장 p99 및 연결 오류"
증상: p99 TP, 연결 재설정 오류, 성장 대기 이벤트.
솔루션: 읽기 전용 스크립트 활성화, 쓰기 제한, 필요한 경우 스케일 풀/복제품-핫 페일 오버.
백아웃: 매개 변수 롤백, 복제 프라임.
C) 캐시: "Miss rate TH → 데이터베이스로드"
증상: 미스율> 40%, CPU DB의 성장.
솔루션: 퇴거 정책 균형, 메모리/샤딩 증가, 일시적으로 읽기 활성화, 핫 키의 RPS 제한.
백 아웃: 정책을 반환하고 문제가있는 파편을 재현하십시오.
D) CNC: "지역 콘텐츠 저하"
증상: 한 국가에서 대기 시간/시간 초과 증가, RUM 불만.
솔루션: 라우팅 맵/GSLB 변경, 문제가있는 POP 우회, TTL 감소, 원점 차폐 활성.
Comms: 영향력있는 지리로 상태 업데이트.
E) KYC: "실패한 식별"
증상: 낙하 승인률, 공급 업체 _ 오류 증가.
솔루션: 트래픽의 일부를 대체 제공 업체로 전환하고 규칙의 심각성을 줄이고 (정책의 틀 안에서) VIP에 대한 수동 검토를 시작하십시오.
준수: 모든 변경 사항 로그, 필요한 경우 위험/법적 알림.
11) 커뮤니케이션 (템플릿 업데이트)
Impact: EU payment success drop (-3. 1% to SLO, 25 min).
Diagnosis: confirmed by quorum; PSP-A partial outage; p95 = 420ms.
Action: PSP-A weight reduced to 30%, degrade-UX included; next update 18:30 UTC.12) 플레이 북 작성자 점검표
- 대상, 소유자, SLO/SLI 및 트리거가 지정되었습니다.
- 표에는 "증상의 가설" 과 의사 결정 트리가 있습니다.
- 예상 결과 및 보안 게이트가있는 실행 가능한 단계.
- 백아웃/폴백 및 리턴 조건이 설명되어 있습니다.
- 통신 템플릿 및 업데이트 빈도.
- 대시 보드/알림/로그 검색/트레일에 연결합니다.
- 필요한 증거 섹션 및 완료 기준.
- 버전, 날짜, SLA 신선도, 이력 변경.
13) 검토 점검표
- Playbook은 탁상용/게임 당일에 재생할 수 있습니다.
- 단계는 안전하며 (제한/카나리아/자동 롤백) 비밀은 공개되지 않습니다.
- 역할과 에스컬레이션이 분명합니다. IC/Comms가 표시됩니다.
- 인접한 플레이 북과의 중복 없음; 매개 변수가 제거됩니다.
- 언제 멈추고 폴백/롤백으로 이동해야하는지 분명합니다.
- 문서는 한 번의 클릭으로 경고에서 사용할 수 있습니다.
14) 구급차 및 재사용
'값에서 변수 (지역, 공급자, 임계 값) 를 수행하십시오. '.
일반적인 단계 (예: "공급자의 가중치 감소", "저하 가능 -UX") 는 별도의 런북으로 발행해야합니다.
템플릿의 지원 생성기: 'plb 뉴 타입 = INC-서비스 = 결제'.
15) 구현 로드맵 (4-6 주)
1. 페이지 알림 → 각 기본 플레이 북에 매핑합니다.
2. 템플릿: YAML/Markdown 구조, 체크리스트 및 라인터 승인.
3. 상위 5 개 시나리오 (결제/DB/CNC/KYC/캐시) → 탁상으로 쓰기/롤백.
4. 통합: 경고, ChatOps 명령, 증거 봇의 링크.
5. 드릴: 한 번에 하나의 플레이 북을 매주 미니 드릴; AAR → uluchsheniya.
6. 신선도 SLA 및 분기 별 리뷰; 품질 지표 보고서.
16) 결론
플레이 북은 "무엇을해야합니까?!" 의 혼란을 해석하는 포크와 난간이있는 운영 시나리오입니다. 예측 가능한 일련의 결정으로. 플레이 북이 표준화되고 경고와 통합되고 정기적으로 훈련되면 팀은 더 빨리 대응하고 위험이 통제되며 비즈니스는 착취의 안정성과 성숙도를 봅니다.