플랫폼을 운영하면서 완전 Hardware 이슈를 제외하고 전반적인 운영업무를 진행했었다. 온콜을 정해서 운영하진 않았지만, 암묵적인 온콜이었다. 조금의 경험을 하고 구글의 SRE 가 어떤식으로 On-Call 에 대응하는지를 읽으니 아주 재미있었다.

이 책을 읽으면서 배워야 하는 부분은, 구글은 이렇게 하는구나 정도로 시야를 넓힐 수 있는 부분에 집중해야할 것 같다.

소개

구글에서의 여러 주요 서비스들 (검색, 광고, 메일 등)은 해당 서비스들의 성능과 신뢰성을 책임지는 전담 SRE 팀이 있음
SRE 는 Ops 와는 다르게 문제를 해결하기 위한 엔지니어링적 접근법을 강조함!
- 운영과 관련된 것들이지만, 소프트웨어 엔지니어링 솔루션 없이는 다루기 어려운 것들임
  - → 어떤 예시가 있을까?
SRE 는 앞서 나온 것 처럼 50%의 엔지니어링 업무 + 50%의 운영업무를 수행함
- 운영 50% 중에서 25%는 온콜, 25%는 일반 운영업무

비상 대기 엔지니어의 삶

비상 대기 시에 엔지니어는 수 분 이내에 프로덕션 환경에서 필요한 운영 작업을 수행할 수 있어야 함.
매우 중요한 서비스는 5분 이내, 아닐 경우는 30분 이내
사용자에게 노출되는 경우에는 분기별로 99.99%의 가용성을 반드시 확보해야함
- 허용되는 다운타임은 분기별로 13분 정도
- 서비스의 SLO 에 따라서 다르긴 함.

Post Moterm
- 뒤의 장에서 좀 더 자세하게 다룸.
- 장애 상황을 분석할 때 사람을 중심으로 하는 것이 아니라 사건을 중심으로 분석하고 회고함.
- →
  - 큰 가치를 제공함
  - 누군가를 비난하는 것이 아니라, 프로덕션 환경의 장애를 시스템적으로 분석하고 가치를 만듬.
  - 사람의 실수를 줄이는 최고의 방법 중 하나는 자동화를 할 수 있는 부분을 선별하는 것

사람은 본인이 직면한 도전에 대해 크게 두 가지 방향으로 생각함
- 1) 직관적, 자동화적, 그리고 신속한 대응
- 2) 합리적, 집중적, 그리고 계획적이며 경험에 기반한 행위
SRE 운영에서도 장애 상황에서 1,2번에 따라 대응방식이 다름
둘 다 장점이 있지만 일반적으로 후자의 경우가 더 나은 결과를 도출해내며 계획에 따른 장애 조치가 가능함
감을 믿으면 데이터에 근거한 지원이 제대로 이루어지지 않을 수도 있음.

목표치
- → 목표치가 정량화 되어야함. 일일 티켓의 수는 5개 미만 같은 예시
모니터링
- 호출 알림은 서비스의 SLO를 위협하는 증상이 발생하는 경우에만 보내져야함
- 그리고 대응 조치가 가능한 것들이어야 함
- 동시에 여러번 발생하고 관련된 것들은 묶어서 발신해야함
운영 업무의 부족 대응
- 운영 업무가 너무 없으면, 자만하거나 SRE 들간의 지식 간의 차이가 벌어질 수 있음
- →
  - 구글에서는 Disaster Revocery Training (DiRT) 를 열어서 며칠에 걸쳐 인프라스트럭쳐 시스템과 개별 시스템에 대한 테스트를 수행함
    - 1년에 특정 주를 잡아서 수행함.
    - ref. https://queue.acm.org/detail.cfm?id=2371516
  - 넷플릭스의 Chaos Engineering
    - ref. https://medium.com/@Netflix_Techblog/the-netflix-simian-army-16e57fbab116