[SRE] 12. Effective Troubleshooting
굉장히 흥미로웠던 장 중 하나였음.
구글에서는 실제로 Production 환경에서 어떤 식으로 트러블 슈팅을 하는지에 대해서 알 수 있었고, 추후 운영 업무에서 도움이 될 수 있는 부분이 많았음.
처음에 나오듯이 Trouble shooting 이라는 것은 필수적인 기술이지만, 설명하는 것은 굉장히 어렵다. 하지만 구글에서는 해당 장애 조치 능력 또한 학습과 가르침이 가능한 부분이라고 믿음.
일반적으로 1) 장애 조치를 범용적으로 수행, 2) 시스템에 대한 탄탄한 이해 를 바탕으로 문제해결을 하는데, 첫번째 방법만으로는 효율적이지 않고, 효과가 없음
이론
장애 해결에서의 통상적인 문제
- 관련이 없는 증상을 들여다보거나 시스템의 지표의 의미를 잘못 이해. 결과만 쫒는 행동임
- 시스템의 변경이나 입력 값 혹은 환경에 대한 잘못된 이해.
- → 첫 번째, 두 번째 문제를 해결하려면, 시스템에 대해 더 많이 이해하고 분산 시스템에서 사용되는 공통 패턴에 대해 경험을 더 쌓아야함
- 가능성이 희박한 가설을 세우거나, 과거에 발생한 문제의 원인과 결부시킴
- → 논리적 오류를 피해야 함
- 사실은 우연히 발생했거나 혹은 동일한 원인에 의해 발생한 관련 현상들을 계속해서 쫒아다니는 행위
즉, 이런 문제들을 피하기 위해서는 장애에 대해 이해하는 것이 가장 먼저 수행해야하는 작업임
실전
문제 보고
- 모든 문제 해결은 문제에 대한
보고에서부터 시작함 - 효과적인 문제 보고는 아래와 같음
- 실제로 기대한 동작은 무엇인지
- 현재는 어떻게 동작하는지
- 문제가 되는 동작을 어떻게 재현할 수 있는지
- 일정한 양식으로 구성되어야 함
- 구글에서는 어떻게 전달 받든, 모든 이슈에 대해 버그를 오픈하는 것이 일반적
우선순위 판단
- 문제 보고 다음 단계는
대처 방법을 찾는 것 우선 시스템이 가능한 정상적으로 동작하게 만들어야 함- ex. 버그로 인해 데이터 복구가 불가능할 정도로 손상을 입었다면, 방치하는 것보다 큰 손실을 막기 위해 시스템 중단을 해야 함.
문제 관찰
- 시스템 모니터링 (시계열 데이터)
- 로그
진단
단순화하기와 범위 좁히기
- 각 단계마다 테스트 데이터를 입력하고 올바른 결과가 출력되는지 확인하는 것은 효과적임
- 하지만 너무 오래 걸리는 큰 시스템이라면
Binary Search!
무엇이, 어디서, 왜를 고민하기
- 증상, 이유, 어떤 지점에서의 이슈, 해결책.. 이런 방향으로 디버깅하기
가장 마지막으로 수정된 부분에 주목하기
테스트와 조치
- 어떤 것이 실제로 문제를 일으킨
근본 원인인지를 파악해야 함 - 실험적이지만, 가설을 하나씩 넣어보거나 혹은 하나씩 제거해 나가는 방법을 사용할 수 있음
- 또한 작업들과 결과에 대해서 꼼꼼히 기록해야함
부정적인 결과의 마법
- 부정적인 결과는 무시해서도 안 되고 평가절하 해서도 안된다.
- 부정적인 결과로 끝난 실험 역시 결론이다.
- → 결과가 잘 나오지 않았다고 하더라도, 잘 정리하고 모아두면 (마이크로 벤치마크, 문서화된 안티 패턴들, 프로젝트 포스트모텀 등) 나중에 새로운 실험들에 도움이 됨.
- 자신의 결과를 공표하자
- → 실패하더라도, 모든 사람들에게 이야기 하면서 배워나가야함
처방
- 해당 원인이
실제 문제의 원인인지를 증명해야 함 - 문제를 유발하는 요소들을 발견했다면 시스템에서 어떤 문제가 발생했는지, 문제를 어떻게 추적해냈는지, 어떻게 해결했는지 그리고 재발을 어떻게 방지할 수 있는지에 대한 노트를 작성 해야함
- → 포스트모텀 문서를 작성해야함
사례 연구
- 앱 엔진 사례
- Dapper
- a Large-Scale Distributed Systems Tracing Infrastructure
- Frontend 리버스 프록시가 요청을 받은 시점부터 앱의 코드가 응답을 리턴하기까지 전 과정을 추적하면서 요청을 처리하는 각 서버들이 발행하는 RPC 요청을 살펴봄
- ref. https://storage.googleapis.com/pub-tools-public-publication-data/pdf/36356.pdf
- Dapper