SRE 조직 문화
SRE 조직 문화
DevOps vs SRE
둘 다 개발과 운영의 간극을 줄이는 게 목적이지만 접근 방식이 다르다.
| 항목 | DevOps | SRE |
|---|---|---|
| 개념 | 문화와 철학 | 구체적인 구현 방법 |
| 목표 | 협업과 자동화 | 신뢰성 정량화 |
| 측정 | 명확한 지표 없음 | SLI/SLO/Error Budget |
| 기원 | 커뮤니티 |
DevOps가 "무엇을 해야 한다"라면 SRE는 "어떻게 한다"다. Google이 DevOps를 구체적으로 실현하기 위해 만든 것이 SRE다.
SRE 팀 구성
| 방식 | 장점 | 단점 |
|---|---|---|
| 임베디드 SRE | 서비스를 깊이 알 수 있다 | SRE 관점이 희석될 수 있다 |
| 중앙 SRE팀 | 일관된 기준을 유지하기 쉽다 | 서비스별 컨텍스트가 부족할 수 있다 |
Toil 줄이는 자동화 전략
Toil은 수동적이고 반복적이고 자동화 가능한 작업이다.
-
빈도 × 소요 시간으로 우선순위를 정한다. 자주 하고 오래 걸리는 것부터 자동화한다
-
Runbook이 잘 정비되면 자동화하기 쉽다
-
SRE 업무의 50% 이상이 Toil이 되면 안 된다. 넘어가면 팀이 운영에만 매몰되고 개선이 멈춘다
Blameless Culture
장애가 났을 때 누구의 잘못인지 찾는 게 아니라 시스템의 문제를 찾는 문화다.
Blameless 없을 때 Blameless 있을 때 장애를 숨기거나 축소 보고 장애를 투명하게 공유 Postmortem을 형식적으로 작성 근본 원인을 깊이 파고듦 같은 장애가 반복됨 시스템이 개선됨 개인을 처벌하는 문화에서는 아무도 솔직하게 말하지 않는다. 솔직하게 말할 수 있는 환경이 먼저다.
Error Budget Policy
Error Budget을 팀 문화로 만드는 것이다.
-
Error Budget이 남아있으면 개발팀은 기능 개발에 집중한다
-
Error Budget이 소진되면 신규 기능 배포를 멈추고 신뢰성 개선에 집중한다
-
이 규칙을 개발팀과 SRE팀이 사전에 합의해둔다
SRE가 일방적으로 배포를 막으면 갈등이 생긴다. Error Budget Policy는 사전 합의로 갈등을 줄이는 도구다.
SRE 팀의 흔한 실패 패턴
패턴 설명 Ops팀 재명명 이름만 SRE로 바꾸고 아무것도 안 변함 Toil 50% 초과 SRE가 운영 업무에만 매몰됨 SLO 없는 SRE 측정 없이 감으로 운영 Blameless 없는 Postmortem 형식적인 사후 분석, 개선 없음
정리
SRE는 직함이 아니라 방식이다. 이름만 바꾼다고 SRE가 되는 게 아니다. SLO로 측정하고, Toil을 줄이고, Blameless Culture로 투명하게 공유하고, Error Budget Policy로 개발팀과 합의하는
것이 SRE 조직 문화의 핵심이다.
