사건 및 SRE 플레이 북

1) 사건이 무엇이며 SLO와 관련된 방법

사고는 SLO/서비스 기능을 위반하거나 위반 위험을 초래하는 사건입니다 (잘못된 예산은 용납 할 수 없을 정도로 빠르게 연소됩니다).
클래식 메트릭: MTTD, MTTA, MTTR, MTBF.
예산 오류 및 연소율에 따라 우선 순위 및 에스컬레이션 창이 결정됩니다.

2) 심각도 수준 (SEV) 및 기준

SEV 트리거: 5xx% 초과, p95> 임계 값, 지불 감소 스파이크, Kafka-lag> 임계 값, NodeNotReady> X min, TLS가 <7 일, DDoS 신호/누출이 만료됩니다.

3) 역할 및 책임 (RACI)

보안/개인 정보 보호-보안 또는 PII 사고가 발생할 수 있습니

IC (Incident Commander) -단독 의사 결정, 작업 흐름 관리, SEV 상태 변경.
Ops Lead (Tech Lead) - 기술 전략, 가설, 수정 조정.
통신 책임자 (Comms) - 상태 업데이트 (내부/외부), StatusPage/채팅/메일.
Scribe (Chronicler) - 타임 라인, 솔루션, 아티팩트, 그래프/로그 링크.
통화 중 엔지니어/중소기업-플레이 북 작업 실행.
FinOps/Payments-청구/PSP/비용에 영향을 줄 때.

4) 사고 수명주기

1. 사고 카드의 탐지 (경고/보고/합성) → 자동 생성.
2. 심사 (IC 할당, SEV 할당, 최소 컨텍스트 수집).
3. 안정화 (완화: 기능/롤백/속도 제한/장애) 를 끄십시오.
4. 조사 (RCA 가설, 사실 수집).
5. 서비스 복구 (SLO 검증, 관찰).
6. 커뮤니케이션 (내부/외부, 최종 보고서).
7. 사후 (무료, CAPA 계획, 소유자, 마감일).
8. 예방 (테스트/경고/플레이 북/플래그, 팀의 추가 교육).

5) 커뮤니케이션 및 "전쟁 실"

통합 사건 채널 ('# inc-sev1-YYYMMDD-hhh') 은 사실과 행동 만 가능합니다.
무선 프로토콜 스타일 명령: "IC: 롤백 버전 1을 할당합니다. 24 → ETA 10 분 ".
상태 업데이트: 15 분마다 SEV-1, 30-60 분마다 SEV-2.
상태 페이지/외부 통신-템플릿별로 Comms Lead를 통해.
금지: 평행 한 "조용한" 방, 테스트되지 않은 가설은 공통 채널로 보입니다.

6) 경고 및 SLO 번 (예: 규칙)

빠른 채널 (1-5 분) 및 느린 채널 (1-2 시간) 연소율.
다중 신호: 예산 오류, 5xx%, p95, Kafka-lag, 지불 감소율, 합성.

근본 원인을 찾으십시오-증상을 안정화시킨 후에 만 가능합니

promql
Ошибочная доля 5xx > SLO sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01

Burn-rate быстрый (пример)
(sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])))
/ (1 - SLO) > 14.4

7) 플레이 북 vs 랜북

플레이 북-사고 유형 (분기, 조건, 위험) 별 조치 시나리오.
런북 - 단계/명령의 특정 "맵" (수표, 수정, 검증).
규칙: 플레이 북은 여러 런북 (롤백, 기능 플래그, 장애 조치, 스케일링, 트래픽 차단 등) 을 나타냅니다.

8) 사건 카드 템플릿

yaml id: INC-YYYYMMDD-XXXX title: "[SEV-1] Рост 5xx на API /payments"
status: active    monitoring    resolved sev: 1 reported_at: 2025-11-03T17:42Z ic: <ФИО>
ops_lead: <ФИО>
comms_lead: <ФИО>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx=12% (обычно <0.5%), конверсия депозитов -20%"
mitigation: "откат на 1.23.4, включен rate-limit 2k rps, фича X выключена"
timeline:
- "17:42: алерт SLO burn-rate быстрый"
- "17:46: назначен IC, открыт war-room"
- "17:52: найден релиз 1.24 как кандидат"
- "18:02: откат завершен, 5xx вернулись к 0.3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "возможен очередной всплеск при включении фичи X"
next_steps: "канареечный релиз, тесты, постмортем до 2025-11-05"

9) SRE 플레이 북 템플릿 (Markdown)

markdown
Плейбук: <название>
Область/симптомы
Список детекторов, сигнатуры в метриках/логах/трассах.

Быстрая стабилизация (Triage & Mitigation)
- [ ] Ограничить трафик/включить WAF-правило/фичефлаг OFF
- [ ] Роллбэк/канареечный релиз/выкатить фикс конфигурации
- [ ] Включить деградационный режим (read-only, кэш-форс)

Диагностика (RCA hints)
- Метрики: … Логи: … Трассы: …
- Частые первопричины/чек-лист гипотез

Риски и коммуникации
- Внутренние/внешние апдейты, SLA-обязательства

Верификация
- [ ] SLO восстановлено (порог/время окна)
- [ ] Нет регресса по смежным сервисам

Последующие действия
- CAPA, задачи в backlog, обновление алертов/дашбордов/плейбука

10) 전형적인 플레이 북

10. 1 API 5xx 스파이크

안정화: 문제가있는 ficheflag를 끄십시오. 캐싱을 사용하면 릴리스를 롤백합니다.
진단: diff 릴리스, 로그 오류 (최고 예외), p95 성장, 압력 DB/캐시.
위험: 지불/백엔드의 계단식.

10. 2 자리: 복제 지연/잠금 폭풍

안정화: 무거운 일자리/보고서 중단; 마법사를 리디렉션하면 wal _ buffers/replika-sloty가 증가합니다.
진단: 긴 거래, 요청 차단, 변경 계획.
수정: 색인/힌트, 작업 재개발, 분할 쿼리.

10. 3 카프카 소비자 지연

안정화: 일시적으로 소비자 규모; 중요하지 않은 서비스의 생산 감소; 당사자/할당량을 늘리십시오.
진단: 재조정, 느린 사막화, GC 일시 중지.
검증: 지연 → 목표 값에 대한 방울 없음.

10. 4 K8 NodeNotReady/자원 폭풍

안정화: 코르 돈 + 드레인; 재분배 하중; 시끄러운 대몬 세트를 끄는 CNI/오버레이를 확인하십시오.
진단: 디스크 압력, OOM, 스로틀 링, 네트워크 드롭.
예방: 포드 중단 예산, 자원 제한/요청.

10. 5 개의 TLS/인증서 만료

안정화: 비밀/수신의 강제 업데이트; 일시적인 재정의.
진단: 신뢰의 사슬, 시계 왜곡.
예방: 자동 임신 T-30/T-7/T-1 경고.

10. 6 DDoS/비정상 트래픽

안정화: WAF/봇 규칙, 속도 제한/지리 필터, 업스트림 창고 하중.
진단: 공격 프로파일 (L3/4/7), 소스, 우산.
예방: 모든 캐스트, 오토 스케일, 캐싱, 제공 업체와의 놀이.

10. 7 지불 PSP 중단

안정화: 대체 PSP/방법으로의 스마트 라우팅; 지터로 재 시도; "소프트" UI 분해.
진단: 코드 별 스파이크 실패, API 상태/PSP 상태 페이지.

커뮤니케이션: 비즈니스 및 지원을위한 투명한 업데이트, 정확한 ND/변환

10. 8 안전 사고/PII 누출

안정화: 노드 격리/비밀 회전, 유출 차단, 법적 보류.
진단: 액세스 타임 라인, 영향을받는 피험자/필드.
통지: 관할권 요구 사항에 따른 규제 기관/파트너/사용자.
예방: DLP/세분화 향상, "최소 특권".

11) 플레이 북 자동화

ChatOps 명령: '/ic set sev 1 ', '/배포 롤백 api 1. 23. 4 ', '/feature off X'.
런북 봇: 반자동 단계 (드레인 노드, 플립 트래픽, 퍼지 캐시).
자가 치유 고리: 검출기 → 표준 완화 (속도 제한, 재시작, 스케일).
경고 및 명령에서 카드/타임 라인을 자동으로 만듭니다.

12) 플레이 북 품질: 체크리스트

• 명확한 증상 및 탐지기 (메트릭/로그/추적).
• 위험 평가를 통한 신속한 안정화 단계.
• 명령/스크립트가 최신 상태이며 준비 중입니다.
• SLO 복구 검증.
• 통신 템플릿 및 외부 업데이트 기준.
• 폐쇄 후 사후 참조 및 CAPA.

13) 사후 (흠없는) 및 CAPA

목표는 범인을 찾지 않고 배우는 것입니다.
내용: 발생한 일, 좋은 것/나쁜 것으로 밝혀진 것, 요인의 기여 (그 + 프로세스), 예방할 수있는 행동.
용어: SEV-1 - 48 시간 이내; SEV-2-3 일.
CAPA: 특정 소유자, 타이밍, 측정 가능한 효과 (MTTR 감소/MTTD 증가).

14) 법적 측면과 증거 기반

법적 보류: 로그/트랙/경고 동결, 한 번 쓰기 스토리지.
아티팩트 저장 체인: 역할 별 액세스, 무결성 제어.
규제 통지: 관할 구역의 타임 라인/템플릿 (특히 영향을받는 지불/PII).
개인 정보 보호: 파싱 중 PII 최소화 및 마스킹.

15) 사고 프로세스 성과 지표

분기 별 및 도메인 별 MTTD/MTTA/MTTR.
SEV 정확도 (과소 평가/과대 평가).
자동 완화 사고의 공유.
상위 N 시나리오의 플레이 북 범위 (> 90%).
제 시간에 CAPA를 수행하십시오.

16) 단계별 구현

1. 1 주차: SEV 매트릭스, 통화 중 역할, 일반 카드 템플릿, 전쟁 실 규정.
2. 2 주차: 상위 5 가지 증상 (5xx, DB 지연, Kafka-lag, NodeNotReady, SL) 을위한 플레이 북.
3. 3 주차: ChatOps/bots, 자동 제작 카드, 통신 템플릿/StatusPage.

4. 4 주차 이상: 안전 플레이 북, PSP 중단, 법률 보류, 정규 드릴/카오스 게임

17) "빠른" 란북의 예 (조각)

롤백 API (K8)

bash kubectl rollout undo deploy/api -n prod kubectl rollout status deploy/api -n prod --timeout=5m
Верификация:
kubectl -n prod top pods -l app=api

배수 노드

bash kubectl cordon $NODE && kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=10m

기능 플래그 OFF (예)

bash curl -X POST "$FF_URL/toggle" -H "Authorization: Bearer $TOKEN" -d '{"feature":"X","enabled":false}'

18) 미니 -FAQ

SEV-1을 언제 올릴까요?
주요 SLO/비즈니스 기능 (결제, 로그인, 게임) 이 어려움을 겪고 몇 시간 동안 예산을 "먹습니다".

더 중요한 것은 무엇입니까? RCA 또는 복구?
항상 안정화 된 다음 RCA. 안정화 시간이 주요 지표입니다.

모든 것을 자동화해야합니까?
빈번하고 안전한 단계를 자동화하십시오. 희귀/위험-반자동 및 IC 확인을 통해.

결과

강력한 사건 과정은 명확한 역할과 SEV 규칙, 자동화가있는 양질의 플레이 북/란북, 비난없는 사후 문화의 세 가지 기둥에 있습니다. 캡처 패턴, 통화 중 훈련, MTTR/잘못된 예산 측정, 탐지기 및 플레이 북을 지속적으로 개선하여 다운 타임 위험과 비용을 직접 줄입니다.