Site Reliability Engineering

개요

SRE(Site Reliability Engineering)는 운영 문제를 사람이 반복적으로 처리하는 방식에서 벗어나, software engineering과 automation으로 해결하려는 운영 discipline이다.

SRE는 단순히 장애가 발생했을 때 서버를 재시작하는 역할이 아니다. 또한 CI/CD pipeline을 만드는 DevOps 역할과 완전히 동일하지도 않다. SRE는 production system의 reliability, availability, latency, performance, capacity를 지속적으로 관리하고, 수동 운영 작업을 자동화하며, 장애가 반복되지 않도록 시스템을 개선하는 역할이다.

핵심을 한 줄로 정리하면 다음과 같다.

SRE = Software Engineering applied to Operations

즉, SRE는 운영을 감과 경험에만 의존하지 않고, 지표와 코드, 자동화, incident process, postmortem, capacity planning으로 다루는 접근이다.

---

SRE가 필요한 이유

현대 소프트웨어 시스템은 점점 더 빠르게 변경되고, 더 복잡해지고 있다. CI/CD가 보편화되면서 배포 빈도는 늘어났고, Kubernetes, microservices, message queue, database, cache, external API, cloud infrastructure가 얽히면서 장애 원인도 단순하지 않게 되었다.

기존 운영 방식은 대략 다음과 같은 흐름에 의존하는 경우가 많았다.

서비스 장애 발생
  -> 운영자가 alert 확인
  -> 서버 또는 cluster 접속
  -> log 확인
  -> process 또는 pod 재시작
  -> ticket 업데이트
  -> 개발팀에 원인 분석 요청
  -> 비슷한 장애가 다시 발생

작은 시스템에서는 이런 방식이 어느 정도 동작할 수 있다. 그러나 시스템 규모가 커질수록 수동 운영은 한계에 부딪힌다.

문제	설명
변경 빈도 증가	배포가 자주 일어나면서 change-related incident 가능성이 증가한다.
시스템 복잡도 증가	microservices, container, Kubernetes, external dependency가 많아진다.
원인 추적 어려움	하나의 요청이 여러 service와 infrastructure layer를 통과한다.
수동 대응 한계	사람이 매번 log를 보고 재시작하는 방식은 scale에 맞지 않는다.
운영 지식 단절	개발자는 production behavior를 모르고, 운영자는 code context를 모를 수 있다.
reliability 기준 부재	어느 정도 안정성이 충분한지 정량적 기준이 없을 수 있다.

SRE는 이 문제를 다음 질문으로 바꾼다.

장애가 왜 발생했는가?
어떻게 더 빨리 감지할 수 있는가?
어떤 지표가 사용자 영향을 가장 잘 나타내는가?
어떤 반복 작업을 자동화할 수 있는가?
어떤 구조적 개선이 재발을 줄이는가?
어느 정도 reliability가 충분한가?

SRE의 목적은 장애 대응 속도를 높이는 데서 끝나지 않는다. 장애를 측정하고, 자동화하고, 학습하고, 다시 발생하지 않도록 시스템을 바꾸는 것이다.

---

SRE의 기본 정의

SRE를 operational discipline으로 정의하면 다음과 같다.

SRE는 production system의 reliability를 유지하기 위해 software engineering, automation, monitoring, incident response, capacity planning을 적용하는 운영 방식이다.

SRE가 다루는 역할은 다음과 같이 정리할 수 있다.

역할	설명
Reliability 관리	서비스가 사용자가 기대하는 수준으로 동작하도록 관리한다.
Operations 자동화	반복적이고 수동적인 운영 작업을 code와 automation으로 대체한다.
Incident response	장애 감지, triage, mitigation, postmortem을 체계화한다.
Monitoring / Observability	metrics, logs, traces, events를 통해 시스템 상태를 파악한다.
Capacity planning	traffic 증가와 resource saturation에 대비한다.
Change risk 관리	배포가 reliability에 주는 영향을 측정하고 제어한다.
Feedback 제공	production data를 개발팀에 전달해 제품과 architecture 개선으로 연결한다.

SRE는 기존 operations를 없애는 개념이 아니다. 기존 operations가 다루던 문제를 더 체계적이고 engineering-oriented한 방식으로 해결하는 개념이다.

---

DevOps와 SRE의 관계

DevOps는 개발과 운영의 협업을 강화하고, build-test-deploy-monitor 흐름을 자동화해 software delivery를 빠르고 안정적으로 만드는 문화와 실천 방식이다.

SRE는 그 DevOps 흐름 안에서 production reliability를 구체적으로 책임지는 engineering practice다.

DevOps:
  개발과 운영 사이의 벽을 낮추고
  delivery pipeline을 빠르고 안정적으로 만든다.

SRE:
  production system이 실제로 안정적인지 측정하고
  장애 대응과 운영 작업을 자동화하며
  reliability 기준을 engineering한다.

둘은 경쟁 관계가 아니다. DevOps가 delivery flow를 만든다면, SRE는 그 flow가 production reliability를 깨뜨리지 않도록 계기판과 guardrail을 만든다.

구분	DevOps	SRE
중심 관심	개발과 운영의 협업, delivery pipeline	production reliability, 운영 자동화
주요 질문	어떻게 더 빠르게 build/test/deploy할 것인가?	어느 정도 안정성이 필요하고, 지금 그 기준을 만족하는가?
자동화 초점	CI/CD, deployment, test automation	incident response, toil reduction, auto-remediation
주요 지표	deployment frequency, lead time, change failure rate	SLI, SLO, error budget, MTTR, availability
결과물	pipeline, deployment workflow, GitOps flow	SLO document, alert, runbook, postmortem, reliability backlog

---

SRE가 집중하는 Reliability 영역

SRE는 production system을 여러 reliability 관점으로 나누어 본다.

Availability

Availability는 사용자가 서비스를 사용할 수 있는지를 나타낸다. 단순히 process나 pod가 살아 있는지만으로 availability를 판단하면 안 된다. 사용자가 실제 요청을 보냈을 때 기대한 응답을 받을 수 있어야 한다.

예를 들어 HTTP API라면 다음과 같은 지표를 사용할 수 있다.

availability = successful requests / total requests

Kubernetes에서 pod가 Running 상태여도 application이 정상 응답하지 않으면 사용자 관점의 availability는 낮을 수 있다. 따라서 SRE는 infrastructure 상태보다 service-level health를 더 중요하게 본다.

Latency

Latency는 요청이 처리되는 데 걸리는 시간이다. 평균 latency만 보는 것은 위험하다. 일부 느린 요청이 평균에 가려질 수 있기 때문이다.

SRE에서는 보통 p95, p99 latency를 함께 본다.

p95 latency:
  전체 요청 중 95%가 이 시간 이하로 처리됨

p99 latency:
  전체 요청 중 99%가 이 시간 이하로 처리됨

예를 들어 평균 latency가 100ms라도 p99 latency가 5초라면 일부 사용자는 심각한 지연을 경험하고 있을 수 있다.

Performance

Performance는 latency뿐 아니라 throughput, CPU usage, memory usage, database query time, cache hit ratio, queue depth 등을 포함한다.

SRE는 성능 문제를 단순히 “서버가 느리다”로 보지 않는다. 어느 layer에서 병목이 발생했는지 나누어 본다.

Client
  -> Load balancer
  -> Ingress
  -> API service
  -> Cache
  -> Database
  -> External API

각 layer에서 latency와 error가 어떻게 분포하는지 확인해야 실제 병목을 찾을 수 있다.

Capacity

Capacity는 현재 시스템이 traffic과 workload를 감당할 수 있는지를 의미한다.

Kubernetes 환경에서는 다음 지표를 확인할 수 있다.

지표	의미
CPU usage	실제 CPU 사용량과 throttling 가능성
Memory usage	memory pressure 또는 OOM 가능성
Pod restart count	application crash 또는 probe 실패 가능성
HPA scaling event	자동 확장 동작 여부
Node allocatable	cluster 전체 여유 resource
Queue length	처리 대기 중인 작업량
Database connection count	DB saturation 가능성
Disk I/O	storage bottleneck 가능성

Capacity planning은 장애가 발생한 뒤 대응하는 것이 아니라, traffic 증가 전에 saturation을 예측하고 대비하는 작업이다.

---

50/50 Rule과 SRE의 시간 배분

SRE에서 중요한 원칙 중 하나는 50/50 rule이다. 이는 SRE가 전체 시간을 incident response와 수동 운영에만 쓰지 않고, 상당한 시간을 automation과 reliability engineering에 확보해야 한다는 원칙이다.

50%:
  incident response
  customer escalation
  production issue investigation
  reliability problem solving

50%:
  automation
  tooling
  monitoring improvement
  runbook automation
  toil reduction
  reliability engineering

이 원칙의 핵심은 SRE가 하루 종일 장애 대응만 하는 팀이 되어서는 안 된다는 것이다.

만약 SRE가 대부분의 시간을 반복적인 장애 대응과 수동 운영에 사용한다면, 그 팀은 reliability engineering을 할 시간이 없다. 이 경우 SRE는 점점 고급 운영팀처럼 변하고, 시스템은 근본적으로 개선되지 않는다.

따라서 SRE 조직은 반복 운영 작업을 줄이고, automation과 preventive engineering에 시간을 확보해야 한다.

---

Toil: SRE가 줄여야 하는 반복 운영 작업

Toil은 반복적이고, 수동적이고, 자동화 가능하며, 장기적인 가치를 축적하지 않는 운영 작업이다.

예시는 다음과 같다.

Toil 예시	문제점	SRE식 개선
매번 pod를 수동 재시작	반복적이고 원인 해결이 아님	livenessProbe, auto-remediation, root cause fix
장애 때마다 log를 수동 grep	시간 소모, 재현성 낮음	centralized logging, trace correlation
ticket을 매번 수동 생성	incident 기록 누락 가능	alert 기반 incident ticket 자동 생성
storage full을 수동 정리	장애 이후 대응	saturation alert, retention policy, cleanup job
deploy 실패 후 수동 rollback	대응 지연	automated rollback, canary analysis
같은 runbook을 매번 반복	사람 의존	runbook automation

Toil을 줄이는 목적은 단순히 일을 편하게 하는 것이 아니다. SRE가 반복 작업에 시간을 빼앗기면 reliability engineering, capacity planning, automation, architecture improvement 같은 고부가가치 작업을 할 수 없다.

다만 모든 toil을 즉시 없앨 수는 없다. 우선순위는 다음 기준으로 정하는 것이 좋다.

1. 자주 발생하는가?
2. 장애 영향이 큰가?
3. 사람이 처리할 때 실수 가능성이 높은가?
4. 자동화했을 때 재사용 가능성이 큰가?
5. 자동화가 오히려 위험을 키우지 않는가?

---

Monitoring과 Observability

SRE는 production system을 감으로 운영하지 않는다. 반드시 측정 가능한 지표를 기반으로 판단한다.

Monitoring은 이미 알고 있는 failure mode를 감지하는 데 강하다.

CPU usage > 90%
error rate > 5%
pod restart count 증가
disk usage > 85%

Observability는 시스템 외부에서 수집한 signals를 통해 내부 상태를 추론하는 능력이다.

대표적인 signal은 다음과 같다.

Signal	설명
Metrics	latency, error rate, throughput, resource usage 같은 수치형 지표
Logs	application event와 error message
Traces	요청이 여러 service를 통과하는 경로
Events	deployment, scaling, restart, node pressure 같은 상태 변화

SRE는 dashboard를 많이 만드는 것에 집중하지 않는다. 중요한 것은 사용자 경험과 직접 연결되는 지표를 정의하고, 그 지표가 악화될 때 빠르게 대응할 수 있는 alert과 runbook을 만드는 것이다.

---

SLI, SLO, SLA

SRE를 실무적으로 이해하려면 SLI, SLO, SLA를 구분해야 한다.

용어	의미	예시
SLI	Service Level Indicator, 실제 측정 지표	request success rate, p95 latency
SLO	Service Level Objective, 내부 reliability 목표	30일 동안 success rate 99.9% 이상
SLA	Service Level Agreement, 외부 계약	99.5% 미만이면 보상 제공

예를 들어 결제 API가 있다면 다음처럼 정의할 수 있다.

SLI:
  successful payment requests / total payment requests

SLO:
  rolling 30 days 기준 success rate >= 99.95%

SLA:
  monthly availability가 계약 기준 미만이면 service credit 제공

주의할 점은 SLI가 infrastructure metric이 아니라 사용자 경험과 연결되어야 한다는 것이다. Kubernetes cluster가 정상이어도 결제 요청이 실패하면 사용자는 장애를 경험한다. 반대로 특정 pod가 몇 번 재시작되었더라도 사용자가 영향을 받지 않았다면 service-level reliability는 유지될 수 있다.

---

Error Budget

SRE에서 release velocity와 reliability 사이의 균형을 잡는 핵심 장치가 error budget이다.

SLO가 100%가 아니라면, 그 차이는 허용 가능한 실패량이다.

예를 들어 30일 기준 availability SLO가 99.9%라면 error budget은 다음과 같다.

30 days = 30 * 24 * 60 = 43,200 minutes
SLO = 99.9%
Error budget = 0.1%

허용 가능한 downtime = 43,200 * 0.001 = 43.2 minutes

Error budget은 release decision에 사용할 수 있다.

Error budget 상태	의사결정
충분히 남아 있음	feature release를 계속 진행 가능
빠르게 소모 중	risky change를 줄이고 reliability work 우선
거의 없음	release freeze 또는 change restriction 검토
초과 소모	reliability fix, incident review, architecture 개선 우선

이 방식은 개발팀과 운영팀의 감정적 충돌을 줄인다.

개발팀:
  빠르게 release하고 싶다.

SRE:
  reliability를 지켜야 한다.

Error budget:
  지금 release를 계속해도 되는지 정량적으로 판단한다.

Error budget은 문서로만 존재하면 의미가 없다. 실제 release decision, reliability prioritization, incident review에 연결되어야 한다.

---

100% Reliability가 목표가 아닌 이유

SRE는 100% availability를 무조건 목표로 하지 않는다.

Reliability가 높을수록 항상 좋은 것처럼 보일 수 있지만, 실제로는 그렇지 않다. 100%에 가까운 reliability를 추구하면 다음 비용이 증가한다.

• infrastructure 비용
• redundancy 비용
• engineering complexity
• release 속도 저하
• change approval 부담
• operational overhead
• architecture 복잡도

모든 서비스가 같은 reliability를 요구하지도 않는다.

서비스	적절한 reliability 관점
결제 승인 API	매우 높은 availability와 낮은 latency 필요
로그인 API	높은 reliability 필요
내부 관리자 통계 페이지	일시 지연을 어느 정도 허용 가능
배치 리포트 생성	몇 분 지연이 허용될 수 있음
실시간 알림 서비스	latency와 delivery success 중요
추천 결과 갱신	eventual consistency를 허용할 수 있음

따라서 SRE는 “가능한 한 안정적으로”가 아니라, 사용자와 비즈니스에 필요한 만큼 안정적으로를 목표로 한다.

이 관점이 있어야 release velocity와 reliability 사이의 균형을 잡을 수 있다.

---

Incident Response

SRE는 장애 대응을 체계화한다. 장애는 피할 수 없으므로, 중요한 것은 장애를 얼마나 빨리 감지하고, 얼마나 빠르게 완화하고, 얼마나 정확하게 학습하는가이다.

일반적인 incident response 흐름은 다음과 같다.

Detect
  -> Triage
  -> Mitigate
  -> Resolve
  -> Postmortem
  -> Follow-up action

각 단계는 다음 의미를 가진다.

단계	설명
Detect	alert, user report, synthetic check로 문제 감지
Triage	severity, 영향 범위, 관련 service 파악
Mitigate	rollback, traffic shift, scaling, feature flag off 등 사용자 영향 완화
Resolve	근본 원인 제거
Postmortem	장애 timeline, 원인, 대응, 개선점 정리
Follow-up	test, alert, runbook, architecture 개선 task 생성

중요한 것은 SRE의 장애 대응이 개인 비난으로 끝나지 않는다는 점이다. 성숙한 SRE 문화에서는 blameless postmortem을 통해 “누가 실수했는가”보다 “왜 시스템이 그 실수를 production 장애로 이어지게 허용했는가”를 본다.

예를 들어 장애 원인이 잘못된 config 배포였다고 해도, SRE는 다음 질문을 던진다.

왜 config validation이 없었는가?
staging에서 재현되지 않은 이유는 무엇인가?
canary 배포가 있었다면 영향이 줄었는가?
rollback은 자동화되어 있었는가?
alert은 사용자 신고보다 먼저 울렸는가?
runbook은 충분히 명확했는가?
같은 실수를 막기 위한 guardrail은 무엇인가?

---

Root Cause Analysis와 Predictive Failure

SRE는 현재 장애를 고치는 것에 머물지 않는다. 장애의 원인을 분석하고, 비슷한 장애가 반복되지 않도록 구조를 개선한다.

현재 장애:
  왜 지금 문제가 생겼는가?

반복 장애:
  왜 비슷한 문제가 계속 생기는가?

잠재 장애:
  어떤 지표가 악화되면 곧 문제가 생길 수 있는가?

구조적 개선:
  어떤 자동화와 architecture 변경이 필요한가?

예를 들어 memory leak이 있는 서비스가 있다고 가정해보자.

단순 운영 방식은 다음과 같다.

OOM 발생
  -> pod 재시작
  -> 정상화

SRE 방식은 더 깊게 들어간다.

OOM 발생
  -> memory usage time series 확인
  -> request pattern과 상관관계 분석
  -> heap dump 또는 profile 분석
  -> alert threshold 조정
  -> liveness/readinessProbe 적정성 검토
  -> resource limit 재조정
  -> memory leak fix 개발팀에 feedback
  -> 재발 방지 test 추가

SRE는 immediate fix와 long-term prevention을 모두 다룬다.

---

Automation: SRE의 핵심 실행 방식

SRE는 operations task를 자동화한다. 자동화의 목적은 단순히 사람이 편해지는 것이 아니다.

자동화는 다음을 가능하게 한다.

• 빠른 대응
• 일관된 대응
• 실수 감소
• 대응 기록 보존
• 운영 scale 확장
• 반복 장애 감소
• 운영자의 cognitive load 감소

Kubernetes 환경에서 SRE 자동화는 다음처럼 구현될 수 있다.

문제	자동화 후보
pod 비정상 상태 반복	livenessProbe, restart policy, alert rule
readiness 실패 후 traffic 유입	readinessProbe 개선, rollout gate
특정 version 배포 후 error rate 증가	canary analysis, automated rollback
node disk pressure	cleanup job, eviction threshold alert
traffic peak 시 latency 증가	HPA, queue-based scaling
DB connection saturation	connection pool limit, saturation alert
반복 incident ticket	alert-to-incident 자동 생성
runbook 반복 실행	ChatOps 또는 workflow automation

SRE 자동화에서 중요한 점은 자동화가 항상 안전해야 한다는 것이다. 무조건 자동 복구를 넣으면 오히려 장애를 키울 수 있다.

예를 들어 error rate가 높다고 자동 rollback을 수행하는 것은 유용할 수 있다. 하지만 rollback이 database migration과 충돌하면 더 큰 문제가 생길 수 있다. 따라서 자동화에는 guardrail, rollback safety, approval policy, blast radius 제한이 필요하다.

---

AIOps와 SRE

AIOps는 operations data에 AI/ML을 적용해 anomaly detection, event correlation, incident prioritization, root cause analysis를 돕는 접근이다.

SRE 관점에서 AIOps는 다음 문제를 줄이는 데 도움을 줄 수 있다.

문제	AIOps 활용 가능성
alert noise	유사 event grouping
root cause 탐색	event correlation
장애 예측	anomaly detection
incident 우선순위	impact 기반 severity 판단
반복 장애	historical pattern 분석
운영 데이터 과부하	metrics/logs/traces 통합 분석

다만 AIOps가 SRE를 대체하는 것은 아니다. AIOps는 SRE가 사용할 수 있는 도구에 가깝다. SLO 설계, error budget policy, incident process, automation safety, architecture 개선은 여전히 engineering judgment가 필요하다.

---

Kubernetes 환경에서 SRE가 보는 것

Kubernetes를 운영할 때 DevOps 관점은 주로 배포 흐름에 집중한다.

Git push
  -> CI
  -> image build
  -> registry push
  -> Helm chart update
  -> Argo CD sync
  -> Kubernetes deploy

SRE 관점은 배포된 서비스가 안정적으로 동작하는지에 집중한다.

Service SLO
  -> SLI metric
  -> alert rule
  -> error budget
  -> incident response
  -> capacity planning
  -> reliability improvement

Kubernetes SRE가 주로 확인하는 항목은 다음과 같다.

영역	확인 지표
Workload health	pod restart count, readiness failure, CrashLoopBackOff
Traffic	request rate, error rate, p95/p99 latency
Resource	CPU, memory, disk, network usage
Scaling	HPA event, replica count, pending pod
Node health	node pressure, kubelet error, disk pressure
Deployment safety	rollout status, canary metric, rollback readiness
Storage	PVC usage, I/O latency, attach/detach failure
Dependency	DB latency, cache hit ratio, external API error
Control plane	API server latency, scheduler queue, etcd health
User impact	successful transaction rate, failed user journey

SRE는 단순히 pod가 살아 있는지 보지 않는다. 사용자 관점에서 service가 목표한 수준으로 동작하는지를 본다.

---

좋은 Alert의 기준

SRE에서 alert는 많을수록 좋은 것이 아니다. 잘못된 alert는 alert fatigue를 만든다. 운영자가 중요하지 않은 알림을 계속 받으면, 진짜 장애 알림에도 둔감해질 수 있다.

좋은 alert는 다음 조건을 만족해야 한다.

조건	설명
User impact와 연결	사용자가 실제로 영향을 받거나 곧 받을 가능성이 있어야 한다.
Actionable	알림을 받은 사람이 취할 수 있는 조치가 있어야 한다.
Severity 명확	urgent, warning, info 구분이 명확해야 한다.
Runbook 연결	대응 절차가 문서화되어 있어야 한다.
Noise 낮음	자주 울리지만 의미 없는 alert는 제거해야 한다.
SLO 기반	error budget burn rate와 연결되면 더 좋다.

예를 들어 CPU 90% alert는 항상 좋은 alert가 아니다. CPU가 90%여도 service latency와 error rate가 정상이라면 즉각 대응이 필요하지 않을 수 있다. 반대로 CPU가 50%여도 p99 latency가 급증하고 error rate가 증가하면 사용자 영향이 클 수 있다.

SRE는 infrastructure metric보다 service-level symptom을 우선해야 한다.

---

SRE가 개발팀에 제공하는 Feedback

SRE는 production data를 개발팀에 전달한다. 이 feedback은 단순한 “버그가 있습니다” 수준이 아니다.

예를 들어 다음과 같은 형태가 될 수 있다.

최근 7일 동안 checkout API의 p99 latency가 3배 증가했다.
증가는 version v1.8.3 배포 이후 시작되었다.
DB query time이 전체 latency 증가의 70%를 차지한다.
cache hit ratio가 92%에서 61%로 감소했다.
rollback 후 latency가 정상화되었다.
해당 변경에 대한 integration test와 load test 추가가 필요하다.

이런 feedback은 개발팀이 감이 아니라 production data를 기반으로 개선할 수 있게 만든다.

SRE의 feedback은 다음 산출물로 연결될 수 있다.

Feedback 유형	후속 작업
latency 증가	profiling, query optimization, caching 개선
error rate 증가	regression test, circuit breaker, retry policy 점검
resource saturation	resource request/limit 조정, scaling policy 개선
반복 incident	runbook automation, architecture 개선
alert noise	alert threshold 조정, grouping, suppression
배포 후 장애	canary, rollback, feature flag 개선

---

SRE의 실무 산출물

SRE가 실제로 만드는 산출물은 다양하다.

산출물	설명
SLO document	서비스별 reliability 목표
SLI dashboard	사용자 관점 service health dashboard
Error budget report	release risk와 reliability 상태
Alert rule	SLO 위반 또는 burn rate 감지
Runbook	장애 대응 절차
Postmortem	장애 timeline, 원인, 개선 action
Automation script	반복 운영 작업 자동화
Capacity plan	traffic 증가에 따른 resource 계획
Production readiness checklist	배포 전 reliability 검증 기준
Reliability backlog	구조적 안정성 개선 작업 목록

이 산출물의 목적은 문서를 늘리는 것이 아니다. production reliability를 반복 가능하게 관리하는 것이다.

---

SRE가 팀에 들어오면 바뀌는 것

SRE가 제대로 작동하면 조직의 운영 방식은 다음처럼 바뀐다.

Before	After
장애가 나면 사람이 수동 조치	장애 감지, 완화, 복구 절차가 자동화/표준화
alert가 많고 의미가 불명확	user impact와 SLO 중심 alert
배포 속도와 안정성이 감정적으로 충돌	error budget 기반 의사결정
장애 후 개인 책임 추궁	blameless postmortem과 system improvement
운영 지식이 사람 머릿속에 있음	runbook, dashboard, automation으로 codify
반복 장애가 계속 발생	reliability backlog로 구조적 개선
resource 부족을 장애 후에 인지	capacity planning과 saturation alert

즉, SRE는 운영을 사람의 경험과 반응에 의존하는 상태에서 측정 가능하고 자동화 가능한 engineering system으로 바꾼다.

---

SRE를 잘못 도입하는 방식

장애 처리 전담팀으로 만드는 경우

SRE에게 모든 production incident를 던지고, 개발팀은 기능 개발만 계속하면 SRE는 금방 병목이 된다. 이 경우 SRE는 reliability engineering을 하지 못하고 ticket 처리팀이 된다.

좋은 구조는 개발팀도 자기 서비스의 production ownership을 갖고, SRE는 reliability framework, automation, observability, incident process를 함께 만드는 것이다.

SLO 없이 Alert만 늘리는 경우

SRE를 한다고 alert rule만 많이 만들면 상황이 나빠질 수 있다. SLO 없이 만든 alert는 user impact와 연결되지 않는 경우가 많고, alert fatigue를 유발한다.

먼저 해야 할 일은 alert를 늘리는 것이 아니라 다음을 정의하는 것이다.

이 서비스의 사용자는 무엇을 성공으로 보는가?
어떤 요청이 실패하면 사용자에게 치명적인가?
어느 정도 latency까지 허용 가능한가?
얼마나 자주 실패해도 되는가?

100% Availability를 목표로 잡는 경우

모든 서비스에 100% availability를 요구하면 비용과 복잡도가 폭증한다. SRE에서는 서비스별로 적절한 SLO를 정하고, error budget을 통해 release velocity와 reliability를 균형 있게 관리해야 한다.

Toil을 측정하지 않는 경우

SRE가 실제로 반복 작업에 얼마나 시간을 쓰는지 측정하지 않으면 자동화 우선순위를 잡기 어렵다. 어떤 작업이 반복되고, 얼마나 시간이 들고, 자동화 가능한지를 기록해야 한다.

---

DevOps, SRE, Platform Engineering의 연결

현대적인 조직에서는 DevOps, SRE, Platform Engineering이 함께 등장한다.

개념	주요 관심
DevOps	개발과 운영의 협업, CI/CD, delivery pipeline
SRE	reliability, SLO, incident response, automation
Platform Engineering	개발자가 쉽게 배포·운영할 수 있는 self-service platform

이 셋은 서로 대체 관계가 아니다.

Platform Engineering:
  개발팀이 쉽게 사용할 수 있는 platform 제공

DevOps:
  그 platform을 통해 빠르고 안정적으로 delivery

SRE:
  production reliability 기준과 운영 guardrail 제공

Kubernetes 기반 platform에서는 다음처럼 나눌 수 있다.

Platform Team:
  cluster, ingress, registry, CI/CD template, observability stack 제공

DevOps Practice:
  GitOps, CI/CD, Helm chart, deployment automation 구성

SRE Practice:
  SLO, alert, incident response, error budget, capacity planning 운영

---

Kubernetes Homelab에 SRE 관점 적용하기

개인 Kubernetes homelab이나 k3s 환경에서도 SRE 관점을 적용할 수 있다. 규모가 작더라도 원리는 같다.

예를 들어 개인 서비스가 있다면 다음을 정할 수 있다.

Service:
  개인 블로그 또는 내부 API

SLI:
  HTTP 2xx/3xx 비율
  p95 latency
  uptime check 성공률

SLO:
  최근 30일 availability 99% 이상

Alert:
  5분 동안 error rate 10% 초과
  p95 latency 2초 초과
  pod CrashLoopBackOff 발생
  disk usage 85% 초과

Runbook:
  ingress 확인
  pod 상태 확인
  recent deployment 확인
  rollback 절차
  storage 상태 확인

작은 환경에서도 다음 습관을 들이면 SRE적으로 운영할 수 있다.

• 장애가 났을 때 조치만 하지 말고 timeline을 기록한다.
• 같은 장애가 반복되면 runbook 또는 automation을 만든다.
• uptime만 보지 말고 사용자 요청 성공률과 latency를 본다.
• 배포 전후 metrics를 비교한다.
• secret, token, internal hostname은 기록에서 제거한다.
• 수동 복구 절차를 점진적으로 자동화한다.

---

운영 검증 포인트

SRE 관점에서 Kubernetes 서비스를 운영할 때는 다음을 확인해야 한다.

검증 포인트	확인 질문
SLI 정의	사용자 경험과 직접 연결되는 지표가 있는가?
SLO 정의	어느 정도 reliability가 충분한지 명확한가?
Error budget	release decision에 실제로 사용되는가?
Alert 품질	user impact와 연결되고 actionable한가?
Runbook	장애 대응 절차가 문서화되어 있는가?
Postmortem	장애 후 재발 방지 action이 생성되는가?
Toil 관리	반복 수동 작업이 측정되고 자동화되는가?
Capacity	traffic 증가 전에 saturation을 예측할 수 있는가?
Deployment safety	canary, rollback, feature flag 같은 안전장치가 있는가?
Secret 관리	token, password, internal hostname이 log나 문서에 노출되지 않는가?

---

정리

SRE는 빠르게 복잡해지는 소프트웨어 운영 환경에서 reliability와 performance를 유지하기 위해, 운영 문제를 software engineering과 automation으로 해결하는 역할이다.

핵심은 다음과 같다.

• SRE는 운영 문제를 software problem으로 바라본다.
• SRE는 장애 대응자가 아니라 reliability engineer다.
• SLI, SLO, SLA는 reliability를 정량화하는 기본 언어다.
• Error budget은 release velocity와 reliability의 균형을 잡는 장치다.
• 100% reliability는 항상 좋은 목표가 아니다.
• Toil reduction은 SRE가 engineering 시간을 확보하기 위한 핵심 활동이다.
• Incident response는 detect, triage, mitigate, resolve, postmortem, follow-up으로 체계화되어야 한다.
• Kubernetes 환경에서 SRE는 pod 상태보다 service-level reliability와 user impact를 우선해야 한다.
• 좋은 alert는 많아야 하는 것이 아니라 actionable하고 SLO와 연결되어야 한다.
• SRE는 production feedback을 개발팀에 전달해 구조적 개선으로 연결한다.

SRE의 본질은 다음 네 가지로 압축할 수 있다.

Measure:
  SLI, SLO, metrics로 reliability를 측정한다.

Automate:
  반복 운영 작업과 장애 대응을 자동화한다.

Respond:
  incident를 빠르게 감지하고 완화한다.

Improve:
  postmortem과 production feedback으로 시스템을 개선한다.

결국 SRE는 운영을 사람의 반복 대응에 맡기는 것이 아니라, 측정 가능하고 자동화 가능하며 지속적으로 개선되는 engineering system으로 만드는 discipline이다.