사후 복구 플레이북: 복구 후 복구 조치를 강화하는 방법

사후 복구 플레이북이 필요한 이유

결함 검토(사후 분석)가 완료된 후 팀에서는 일반적으로 원인 분석과 개선 항목 목록을 작성합니다. 하지만 문제는 이 목록이 위키에 게시되어 몇 달이 지난 후에도 아무도 그 목록을 기억하지 못한다는 것입니다. 다음 사고가 발생하면 나는 여전히 채팅 기록을 뒤지며 동료들에게 "지난번에 어떻게 회복했습니까? "라고 묻습니다.

사후 복구 플레이북은 백업에서 반복 가능한 복구 작업을 추출하고 이를 누구나(신규 근무자 포함) 따를 수 있는 단계 매뉴얼로 형식화합니다. 근본 원인 분석을 대체하지는 않지만 "느린 복구" 문제를 해결합니다. - Google의 SRE 사례에 따르면 플레이북 서비스를 사용하면 MTTR(평균 복구 시간)을 50% 이상 줄일 수 있습니다.

그러나 많은 사람들이 플레이북을 작성할 때 함정에 빠지게 됩니다. 실제로 실행 가능한 단계를 추출하지 않고 리뷰 보고서의 전체 텍스트를 복사하는 것입니다. 결과적으로 플레이북은 누구도 읽거나 사용하지 않는 또 하나의 문서가 됩니다.

검토 입력: 복구 조치를 취하기에 적합한 콘텐츠는 무엇인가요?

모든 검토 결론이 플레이북이 될 수 있는 것은 아닙니다. 다음 조건을 충족하는 작업만 작성할 가치가 있습니다.

• 검증 가능: 실행 후 즉시 효과를 확인할 수 있습니다(예: 서비스 다시 시작, 트래픽 전환, 버전 롤백 등).
• 결정론적: 여러 사람이 동일한 조건에서 실행하면 결과가 일관됩니다.
• 제한됨: 트리거 조건이 지정됩니다(예: "P99 지연이 3분 동안 500ms를 초과하는 경우").

예: 검토 결과 "데이터베이스 연결 풀이 고갈되어 요청이 대기열에 추가되었습니다"라는 사실이 발견되었습니다. 근본 원인은 코드에서 연결이 닫히지 않았기 때문입니다. 근본 원인 자체는 수정 작업이며 개발 반복에 맡겨집니다. 그러나 복구 조치는 다음과 같습니다: "연결 풀 사용량이 2분 동안 90%를 초과하면 자동으로 연결 풀의 상한을 200으로 확장하고 경보를 트리거하여 DBA에 개입하도록 알립니다." 이 작업은 플레이북에 기록될 수 있습니다.

일반적인 실패 시나리오는 팀이 "코드 검토 강화" 및 "단위 테스트 적용 범위 증가"와 같은 장기적인 개선 항목을 복구 조치로 간주하는 것입니다. 이는 중요하지만 플레이북의 일부는 아니며 개선 백로그의 일부입니다.

복구 조치 강수: 검토 보고서를 단계로 변환하는 방법

복구 작업을 추출할 때 목록보다는 '작업 흐름' 방식으로 정리하는 것이 좋습니다. 예를 들면:

步骤 1：确认影响范围
  - 登录 Grafana 查看全局错误率面板
  - 如果错误率 > 5%，转步骤 2；否则继续监控 10 分钟
步骤 2：执行回滚
  - 切换到上一次稳定版本标签（v2.3.1）
  - 确认部署后错误率下降至 < 1%
  - 如果回滚失败（如版本冲突），转步骤 3
步骤 3：切换流量到冷备集群
  - 修改 DNS 记录指向备用集群 IP
  - 等待 TTL 过期后验证可用性

重点在于：写清楚判断条件和备选路径。很多团队只写了“执行回滚”，但回滚本身可能失败，没有 fallback 计划就会卡住。

另一个容易失败的地方是：步骤中缺少“负责人”。比如“重启服务”这个动作，谁有权限操作？值班 SRE 还是开发工程师？在 playbook 里明确“由 on-call 工程师发起，需要安全审计授权”可以减少推诿。

告警与负责人：当 playbook 和监控联动

Playbook 不能孤立存在，它必须与告警体系绑定。做法是：在 playbook 头部标明触发此 playbook 的告警规则。例如：

告警名称：HighErrorRate
告警条件：服务错误率 > 2% 持续 5 分钟
负责人（Role）：On-Call SRE（主）, 后端服务负责人（备）
切换条件：On-Call SRE 10 分钟内未响应，自动升级给后端负责人

"확인 대기"로 인한 지연이 발생하지 않도록 담당자와 업그레이드 조건을 명확하게 기재하세요. 실제 사례: 한 팀의 플레이북에 "DBA에 문의"라고 썼지만 담당 DBA가 누구인지는 표시하지 않았습니다. 결과적으로 통화가 완료되는 데 20분이 걸렸습니다. 개선 후 플레이북에 "Enterprise WeChat Robot @DBA Duty Group"을 직접 작성하고, 5분 동안 응답이 없으면 자동으로 전화가 걸리는 규칙을 삽입합니다.

사람 외에 도구 입구도 명확하게 적어야 합니다. 예를 들어 "롤백 실행" 작업의 경우 "CI/CD 플랫폼 사용"만 쓸 수는 없지만 "Jenkins(주소: xxx)에 로그인하고 '마지막 안정 버전으로 롤백' 매개변수화된 빌드를 선택"해야 합니다.

다음 연습: 플레이북이 좀비 문서가 되는 것을 방지하는 방법

플레이북의 최악의 적은 사용되지 않습니다. 정기적인 훈련만이 유일한 해결책입니다.

훈련 빈도는 서비스의 중요성과 변경 빈도에 따라 달라집니다. 내 제안은 다음과 같습니다

• 핵심 결제 서비스: 월간 안내
• 일반 API 서비스: 분기별
• 내부 도구: 연 2회

훈련은 전체 흐름 스트레스 테스트일 필요는 없지만 탁상 훈련일 수 있습니다. 팀 구성원은 플레이북 주위에 모여 누락되거나 불분명한 부분을 찾기 위해 단계를 구두로 안내합니다.

실패 시나리오: 많은 팀 훈련은 비정상적인 조건을 시뮬레이션하지 않고 단지 "읽기"에 불과합니다. 보다 효과적인 접근 방식은 훈련 중에 플레이북에 기록되지 않은 결함 지점(예: 알람 채널 자체가 연결 해제되거나 롤백 버전 번호가 잘못 기록되는 등)을 의도적으로 생성하고 실무자가 이를 우회하는 방법을 알고 있는지 관찰하는 것입니다.

각 연습 후에 플레이북 버전 번호를 업데이트해야 하며 변경 사항을 팀 그룹에 발표해야 합니다. Git을 버전 관리에 사용할 수 있습니다. 각 제출 기록에는 "이번 연습에서는 특정 단계에서 판단 조건이 부족한 것을 발견하여 보완했습니다."라고 명시되어 있습니다.

일반적인 오해와 경계

1. **플레이북은 자세할수록 좋나요? ** 아니요. 20단계보다 긴 플레이북은 실행 중에 포커스를 잃는 경향이 있습니다. 10단계 이내로 제어하고, 필요하다면 하위 플레이북('롤백 하위 프로세스', '확장 하위 프로세스' 등)으로 분할하는 것이 좋습니다.
2. **플레이북은 한번 작성하면 변경되지 않나요? ** 불가능한. 이는 각 주요 사고 검토 후 및 분기별 훈련 후에 개정되어야 합니다.
3. **플레이북은 대규모 팀에만 적합합니까? **소규모 팀도 필요합니다. 혼자 일할 때 플레이북은 잊어버리는 것을 방지하는 보험입니다.

시나리오 사례: 일회성 결제 시간 초과 복구 프로세스의 플레이북화

검토가 끝났다고 가정해 보겠습니다. 지불 주문 인터페이스는 Redis 단축키로 인해 캐시 사태를 일으키고 복구 작업은 수동으로 단축키를 지우고 흐름을 제한하는 것입니다.

추출된 플레이북 조각:

告警条件：支付下单接口 P99 延迟 > 3s
步骤：
1. 登录 Redis-cli，执行 `메모리 사용량 결제:hot_order` 确认热 key 内存占用
2. 如果占用 > 100 MB，执行 `DEL 결제:hot_order` 清除缓存（注意：会短暂增加 DB 压力）
3. 同步在网关层对 /payment/order 接口限流 50%（跳转 Nginx 限流配置页）
4. 观察 2 分钟，如果 P99 恢复 < 1s，结束；否则转步骤 5（回滚版本）
责任人：On-Call SRE

이 플레이북은 "확인을 위해 개발팀에 먼저 연락하는" 단계를 생략하고, 담당자가 직접 실행할 수 있습니다.