Notes

DevOps와 SRE 역할 구분

DevOps와 SRE를 경쟁 개념이 아니라 software delivery와 production reliability를 다루는 보완적 접근으로 정리하고, SLI/SLO/SLA, Error Budget, Toil, Incident Response, Observability까지 설명한다.

Published: Jun 3, 2026
Updated: Jun 3, 2026
Area: Cloud Infrastructure
Type: concept
Series: DevOps Explained
Category: Notes

DevOpsSREReliabilitySLOSLIError BudgetObservabilityIncident Response

개요

DevOps와 SRE는 같은 목표를 향하지만, 초점과 구현 방식이 다르다.

짧게 정리하면 다음과 같다.

DevOps:
  development와 operations의 협업을 통해
  software delivery lifecycle을 빠르고 안정적으로 만드는 문화와 practice

SRE:
  software engineering 방식으로
  production reliability, incident response, automation, observability를 체계화하는 discipline

DevOps는 “개발과 운영이 함께 빠르게 전달하자”에 가깝고, SRE는 “그 빠른 전달이 production reliability를 망치지 않도록 engineering discipline으로 운영하자”에 가깝다.

DevOps:
  어떻게 더 빠르고 자주 build/test/deploy할 것인가?

SRE:
  그렇게 배포된 system이 실제 사용자 환경에서 안정적으로 동작하는가?

핵심은 둘 중 하나를 선택하는 것이 아니다. DevOps delivery flow 안에서 reliability를 어떻게 engineering discipline으로 관리할 것인지가 중요하다.

DevOps와 SRE는 경쟁 관계가 아니다

DevOps와 SRE를 비교할 때 가장 먼저 피해야 할 오해는 “둘 중 하나를 선택해야 한다”는 생각이다.

잘못된 질문:
  DevOps를 할 것인가, SRE를 할 것인가?

더 나은 질문:
  DevOps delivery flow 안에서 reliability를 어떻게 engineering discipline으로 관리할 것인가?

DevOps는 넓은 문화와 조직 운영 방식이다. 개발팀과 운영팀 사이의 장벽을 낮추고, build, test, deploy, monitor 과정을 자동화하며, software delivery 속도와 품질을 높이는 것을 목표로 한다.

SRE는 그중 특히 production reliability를 정량화하고, 반복 운영 작업을 자동화하며, incident response와 observability를 체계화하는 더 구체적인 운영 engineering practice다.

DevOps:
  culture + collaboration + automation + delivery speed

SRE:
  reliability engineering + SLO/Error Budget + incident response + toil reduction

따라서 두 개념은 경쟁 관계가 아니라 보완 관계다.

DevOps:
  delivery system을 빠르고 반복 가능하게 만든다.

SRE:
  production feedback을 data로 수집하고 reliability를 지킨다.

둘의 결합:
  빠르게 배포하되, 안정성을 data로 관리한다.

DevOps의 중심 질문

DevOps의 중심 질문은 다음이다.

어떻게 development와 operations가 함께
더 빠르고 안정적으로 software를 전달할 것인가?

DevOps는 다음 영역을 다룬다.

- source code management
- continuous integration
- automated testing
- container image build
- continuous delivery / deployment
- infrastructure automation
- monitoring
- feedback loop
- collaboration culture

DevOps 관점에서 중요한 것은 software delivery lifecycle 전체다.

Plan
  -> Code
  -> Build
  -> Test
  -> Release
  -> Deploy
  -> Operate
  -> Monitor
  -> Feedback

DevOps는 development와 operations가 분리된 handoff 구조를 줄인다.

전통적 구조:
  개발팀이 code 작성
  운영팀에 배포 요청
  장애 발생 시 책임 경계 모호

DevOps 구조:
  개발과 운영이 lifecycle 전체를 함께 책임
  자동화된 pipeline으로 반복 작업 축소
  운영 feedback을 개발에 반영

DevOps의 중요한 결과물은 다음과 같다.

영역	예시
CI	test 자동화, build 검증, image build
CD	deployment automation, GitOps sync, rollback pipeline
IaC	Terraform, Kubernetes manifest, Helm values
Collaboration	PR review, change visibility, shared ownership
Feedback	monitoring, logs, incident learning

즉, DevOps는 software를 빠르게 전달하기 위한 delivery system을 만든다.

SRE의 중심 질문

SRE의 중심 질문은 다음이다.

이 system이 production에서 실제로 안정적으로 동작하게 하려면
무엇을 측정하고, 무엇을 자동화하고, 어떤 risk를 허용할 것인가?

SRE는 단순한 운영팀이 아니다. SRE는 운영 문제를 software engineering 문제로 본다.

반복되는 장애 대응?
  runbook만 만들지 말고 자동화한다.

alert가 너무 많음?
  alert rule을 정리하고 SLO 기반으로 재설계한다.

배포할수록 장애가 늘어남?
  error budget으로 release velocity를 제어한다.

원인 분석이 매번 늦음?
  observability, tracing, logging, postmortem을 개선한다.

SRE의 관심사는 다음과 같다.

- production reliability
- SLI / SLO / SLA
- error budget
- incident response
- postmortem
- observability
- toil reduction
- capacity planning
- automation
- emergency response

DevOps가 delivery lifecycle 전체를 다룬다면, SRE는 production reliability를 engineering discipline으로 다룬다.

DevOps:
  빠르게 전달하는 방법

SRE:
  빠르게 전달된 system이 안정적으로 동작하게 만드는 방법

차이 1: Development와 Implementation의 관점

DevOps와 SRE는 system을 바라보는 위치가 다르다.

구분	DevOps	SRE
중심 위치	개발과 delivery lifecycle	production 운영과 reliability
주 관심사	build, test, deploy, monitor 자동화	availability, latency, incident, error budget
주 질문	“어떻게 빠르게 전달할 것인가?”	“어떻게 안정적으로 유지할 것인가?”
feedback	운영 feedback을 개발에 연결	production data를 분석해 reliability 개선
주요 산출물	CI/CD pipeline, IaC, deployment automation	SLO, alerting, runbook automation, postmortem

DevOps가 “software를 만들어 사용자에게 전달하는 흐름”을 다룬다면, SRE는 “그 software가 실제 운영 환경에서 어떤 reliability 특성을 가지는지”를 다룬다.

DevOps:
  feature를 빠르게 전달한다.

SRE:
  feature 전달 속도가 reliability를 망치지 않게 한다.

차이 2: Skill Set과 사고방식

DevOps와 SRE는 사용하는 기술이 많이 겹친다.

공통 기술:
  Linux
  networking
  scripting
  cloud
  Kubernetes
  CI/CD
  monitoring
  automation
  incident response

하지만 사고방식에는 차이가 있다.

DevOps engineer는 delivery flow를 자동화하는 데 집중하는 경우가 많다.

DevOps engineer 관심사:
  pipeline이 빠르게 도는가?
  test가 자동화되어 있는가?
  배포가 반복 가능하고 안전한가?
  infrastructure가 code로 관리되는가?
  개발자가 쉽게 배포할 수 있는가?

SRE는 production reliability를 분석하고 개선하는 데 집중한다.

SRE 관심사:
  사용자가 실제로 장애를 경험하고 있는가?
  SLO를 지키고 있는가?
  error budget을 얼마나 썼는가?
  alert가 actionable한가?
  같은 incident가 반복되는가?
  toil을 automation으로 줄일 수 있는가?

즉, DevOps는 delivery system을 개선하고, SRE는 production system의 reliability를 개선한다.

차이 3: Automation의 대상

둘 다 automation을 중요하게 본다. 하지만 자동화의 대상이 다르다.

구분	DevOps Automation	SRE Automation
주요 대상	build, test, deploy, release	incident response, remediation, failover
목적	delivery 속도와 반복 가능성 향상	reliability 향상과 toil 감소
예시	CI/CD pipeline, IaC, GitOps sync	auto-remediation, alert routing, capacity automation
실패 대응	rollback pipeline, deployment strategy	SLO breach 대응, incident automation
관심 metric	deployment frequency, lead time	availability, latency, error rate, MTTR

예를 들어 DevOps automation은 다음과 같다.

code push
  -> test 자동 실행
  -> image build
  -> registry push
  -> Kubernetes manifest update
  -> Argo CD sync

SRE automation은 다음과 같다.

latency SLO breach
  -> alert 발생
  -> recent deploy correlation
  -> traffic shift 또는 rollback
  -> incident ticket 생성
  -> postmortem template 생성

또는 다음과 같은 automation도 SRE에 가깝다.

disk usage 90% 초과
  -> log rotation 실행
  -> temporary scale-out
  -> capacity ticket 생성
  -> dashboard에 event 기록

핵심은 DevOps가 “delivery 자동화”에 더 가깝고, SRE가 “reliability 자동화”에 더 가깝다는 점이다.

SRE의 핵심 개념: SLI, SLO, SLA

DevOps와 SRE를 구분할 때 SRE의 중요한 언어가 SLI, SLO, SLA다.

SLI

SLI는 Service Level Indicator다. 실제로 측정하는 지표다.

SLI 예시:
  availability
  request success rate
  p95 latency
  p99 latency
  error rate
  throughput
  freshness
  durability

예를 들어 API service라면 다음과 같은 SLI를 사용할 수 있다.

HTTP 2xx/3xx response 비율
p95 latency < 300ms
5xx error rate
successful checkout transaction rate

SLI는 사용자가 체감하는 reliability를 표현해야 한다. CPU 사용률이나 memory 사용률도 중요하지만, 사용자가 직접 경험하는 것은 보통 request success, latency, data freshness 같은 지표다.

SLO

SLO는 Service Level Objective다. 목표값이다.

SLO 예시:
  30일 기준 request success rate 99.9% 이상
  p95 latency 300ms 이하
  monthly availability 99.95% 이상

SLO는 SRE와 product team, business stakeholder 사이의 신뢰 계약에 가깝다.

SLO가 너무 높으면:
  release 속도가 느려지고 비용이 증가

SLO가 너무 낮으면:
  사용자 경험이 나빠짐

좋은 SLO:
  사용자가 체감하는 reliability와 business risk를 반영

SLO는 alert와 release decision의 기준이 되어야 한다. 단순히 dashboard에 표시하는 숫자가 아니라, 실제 운영 의사결정에 연결되어야 한다.

SLA

SLA는 Service Level Agreement다. 보통 외부 고객과의 계약적 약속이다.

SLA:
  고객에게 약속한 availability, latency, support 조건
  위반 시 보상 또는 penalty가 있을 수 있음

SLI, SLO, SLA의 관계는 다음과 같이 정리할 수 있다.

용어	의미	예시
SLI	실제 측정 지표	request success rate
SLO	내부 또는 외부 목표값	30일 기준 99.9% success
SLA	계약적 약속	99.9% 미만이면 credit 제공

SRE는 이 세 가지를 기반으로 reliability를 정량적으로 관리한다.

Error Budget: DevOps와 SRE를 연결하는 핵심 장치

SRE의 가장 중요한 개념 중 하나가 error budget이다.

Error budget은 허용 가능한 실패량이다.

예를 들어 availability SLO가 99.9%라면, 0.1%의 실패는 허용된다.

SLO:
  99.9% availability

Error budget:
  0.1% unavailable time 또는 failed request

이 error budget은 feature velocity와 reliability 사이의 균형을 잡는 장치다.

error budget이 충분히 남아 있음:
  새로운 feature release 가능
  실험적 변경 가능

error budget을 많이 소모함:
  release freeze 또는 제한
  reliability 개선 우선
  incident 원인 해결

이를 DevOps와 연결하면 다음과 같다.

DevOps:
  빠르게 release하고 싶다.

SRE:
  빠르게 release하되, error budget 안에서 하자.

즉, error budget은 “속도 vs 안정성” 논쟁을 감정이 아니라 data로 바꾼다.

DevOps Metric과 SRE Metric의 차이

DevOps와 SRE는 metric도 다르게 본다.

DevOps에서는 delivery performance가 중요하다.

DevOps metric:
  deployment frequency
  lead time for changes
  change failure rate
  mean time to recovery
  build success rate
  test coverage
  pipeline duration

SRE에서는 user-facing reliability가 중요하다.

SRE metric:
  availability
  latency
  error rate
  saturation
  SLO compliance
  error budget burn rate
  MTTA
  MTTR
  incident frequency
  alert noise
  toil percentage

물론 둘은 겹친다. 예를 들어 MTTR은 DevOps와 SRE 모두 중요하게 본다. 하지만 해석의 초점이 다르다.

DevOps 관점:
  장애가 나도 빠르게 복구 가능한 delivery system인가?

SRE 관점:
  사용자 impact를 최소화하고 같은 장애가 반복되지 않는 reliability system인가?

좋은 조직은 두 metric을 함께 본다.

delivery speed만 보면:
  빠르게 장애를 만들 수 있음

reliability만 보면:
  release가 느려질 수 있음

둘을 함께 보면:
  빠르게 전달하되, reliability budget 안에서 운영 가능

Toil: SRE가 줄이려는 반복 운영 작업

SRE에서 중요한 개념이 toil이다.

Toil은 수동적이고 반복적이며, 자동화 가능하고, 장기적으로 가치가 낮은 운영 작업을 의미한다.

toil 예시:
  매일 같은 로그 확인
  수동 restart
  반복적인 ticket 처리
  수동 scale 조정
  매번 같은 장애 runbook 실행
  손으로 certificate 갱신

SRE는 toil을 줄이는 데 집중한다.

toil이 많으면:
  engineer가 innovation보다 반복 운영에 묶임
  장애 대응 품질이 사람에 따라 달라짐
  실수가 늘어남
  team burnout이 증가

toil을 줄이면:
  automation 증가
  운영 일관성 증가
  reliability 개선
  engineer가 더 높은 수준의 문제 해결에 집중 가능

Toil reduction은 단순히 편의를 위한 자동화가 아니다. 운영 안정성과 팀 지속 가능성을 위해 필요하다.

Incident Response와 Postmortem

SRE는 incident response를 매우 중요하게 본다.

DevOps에서도 장애 대응은 중요하지만, SRE는 이를 더 체계적인 engineering loop로 만든다.

incident 발생
  -> detection
  -> triage
  -> mitigation
  -> communication
  -> root cause analysis
  -> postmortem
  -> action item
  -> automation 또는 architecture 개선

SRE에서 중요한 것은 “누가 잘못했는가?”보다 “system이 왜 이 실패를 허용했는가?”다.

나쁜 postmortem:
  담당자 실수로 장애 발생
  주의하자

좋은 postmortem:
  어떤 guardrail이 없었는가?
  어떤 alert가 늦었는가?
  어떤 rollback path가 없었는가?
  어떤 test가 실패를 잡지 못했는가?
  같은 장애를 자동으로 막으려면 무엇을 바꿔야 하는가?

SRE는 incident를 단순 처리 대상으로 보지 않는다. Incident는 system design과 operation process를 개선하는 signal이다.

Postmortem의 결과는 action item으로 이어져야 한다.

좋은 action item:
  alert rule 개선
  rollback 자동화
  test case 추가
  deployment guardrail 추가
  capacity threshold 조정
  runbook 자동화

Observability: SRE의 눈

SRE가 production reliability를 다루려면 observability가 필요하다.

Monitoring은 “정해진 것을 감시”하는 데 가깝고, observability는 “예상하지 못한 문제도 system signal을 통해 이해”하는 데 가깝다.

SRE가 보는 대표 signal은 다음이다.

Metrics:
  latency
  traffic
  errors
  saturation
  CPU/memory
  queue depth

Logs:
  request log
  error log
  audit log
  deployment event

Traces:
  distributed request path
  service-to-service latency
  DB query time
  external API call latency

DevOps pipeline에서 배포가 성공했다고 해도, SRE 관점에서는 다음 질문을 해야 한다.

배포 후 error rate가 증가했는가?
p95/p99 latency가 악화되었는가?
SLO burn rate가 급증했는가?
특정 region이나 tenant만 실패하는가?
rollback이 필요한가?

Observability는 SRE의 눈이다. Observability가 없으면 SLO도, error budget도, incident response도 제대로 작동하기 어렵다.

DevOps와 SRE가 충돌하는 지점

DevOps와 SRE는 보완적이지만, 실제 조직에서는 충돌할 수 있다.

가장 흔한 충돌은 release velocity vs reliability다.

Product/DevOps:
  이번 주 feature를 배포해야 한다.

SRE:
  지난주 장애로 error budget을 많이 소모했다.
  지금은 reliability 개선이 우선이다.

이때 error budget이 없다면 논쟁은 감정적이 된다.

개발팀:
  운영팀이 배포를 막는다.

운영팀:
  개발팀이 안정성을 무시한다.

하지만 SLO와 error budget이 있으면 논쟁이 data 기반으로 바뀐다.

SLO:
  99.9% availability

현재 error budget:
  85% 소진

정책:
  error budget 80% 이상 소진 시
  신규 feature release 제한
  reliability fix 우선

이 구조에서 SRE는 release를 무조건 막는 조직이 아니다. SRE는 acceptable risk 안에서 빠른 delivery가 가능하도록 guardrail을 만드는 조직이다.

DevOps와 SRE를 조직에 적용하는 방식

조직에서 DevOps와 SRE를 적용하는 방식은 여러 가지다.

DevOps Team + SRE Team 분리

DevOps team:
  CI/CD platform
  infrastructure automation
  deployment pipeline

SRE team:
  SLO
  incident response
  observability
  reliability automation

장점은 역할이 명확하다는 것이다.

단점은 다시 silo가 생길 수 있다는 것이다. DevOps와 SRE가 서로 다른 ticket queue로만 소통하면 협업 효과가 줄어든다.

Product Team 안에 SRE 역할 포함

product team:
  developer
  QA
  DevOps engineer
  SRE

장점은 feedback loop가 짧다는 것이다.

단점은 SRE practice 표준화가 어려울 수 있다는 것이다.

Platform Team + Embedded SRE

platform team:
  golden path
  CI/CD template
  observability platform
  Kubernetes platform

embedded SRE:
  product team에 reliability practice 적용

이 구조는 cloud-native 조직에서 현실적인 방식이 될 수 있다.

Platform team은 공통 도구와 guardrail을 만들고, SRE는 product team의 reliability 목표와 운영 개선에 관여한다.

Kubernetes 환경에서 DevOps와 SRE

Kubernetes 환경에서는 DevOps와 SRE의 역할이 더 중요해진다.

DevOps는 다음을 자동화한다.

- container image build
- Helm/Kustomize manifest 관리
- GitOps repo update
- Argo CD sync
- environment promotion
- infrastructure as code

SRE는 다음을 관리한다.

- SLO 기반 service health
- pod restart / CrashLoopBackOff 분석
- ingress error rate
- HPA scaling behavior
- node pressure
- deployment rollback
- alert fatigue 개선
- capacity planning

Kubernetes에서 SRE가 자주 보는 signal은 다음이다.

Kubernetes-level:
  pod restart count
  CrashLoopBackOff
  readinessProbe failure
  livenessProbe failure
  HPA event
  node pressure
  pending pod
  OOMKilled

Application-level:
  HTTP 5xx
  p95/p99 latency
  request success rate
  database timeout
  queue lag
  user transaction failure

DevOps가 Kubernetes에 “어떻게 안전하게 배포할 것인가”를 다룬다면, SRE는 Kubernetes에서 “배포된 system이 실제로 안정적인가”를 다룬다.

Homelab/k3s 관점에서 이해하기

k3s, Longhorn, MetalLB, Traefik, Nexus, Argo CD, Tekton 같은 환경에서도 DevOps와 SRE의 차이는 그대로 적용된다.

DevOps 관점에서는 다음이 중요하다.

- app image를 어떻게 build할 것인가?
- Nexus registry에 어떻게 push할 것인가?
- Helm values나 manifest를 어떻게 Git에 저장할 것인가?
- Argo CD로 어떻게 sync할 것인가?
- dev/prod 환경을 어떻게 나눌 것인가?

SRE 관점에서는 다음이 중요하다.

- Traefik ingress error rate가 증가하지 않는가?
- Longhorn volume attach/detach 지연이 service downtime에 어떤 영향을 주는가?
- Nexus PVC가 꽉 차면 어떤 alert가 오는가?
- MetalLB VIP 이동 시 client impact는 어느 정도인가?
- app 배포 후 p95 latency와 5xx rate는 정상인가?
- node 장애 시 어떤 service가 degraded 되는가?

즉, homelab에서도 DevOps는 delivery pipeline을 만들고, SRE는 reliability signal과 incident response를 설계한다.

DevOps:
  배포가 자동으로 되게 만든다.

SRE:
  자동 배포된 service가 안정적으로 운영되는지 확인하고,
  문제가 반복되지 않도록 system을 개선한다.

DevOps와 SRE가 함께 있을 때의 이상적인 흐름

좋은 구조에서는 DevOps와 SRE가 하나의 loop로 연결된다.

1. Developer가 code push
2. DevOps pipeline이 build/test/image scan 수행
3. GitOps repo update
4. Argo CD가 cluster에 sync
5. SRE observability가 service health 측정
6. SLO와 error budget 확인
7. 문제가 있으면 rollback 또는 mitigation
8. postmortem과 action item 생성
9. DevOps pipeline 또는 application code 개선
10. 다음 release에 반영

이 흐름에서 DevOps와 SRE는 서로 다른 역할을 한다.

DevOps:
  delivery system을 빠르고 반복 가능하게 만든다.

SRE:
  production feedback을 data로 수집하고 reliability를 지킨다.

둘의 결합:
  빠르게 배포하되, 안전하게 운영한다.

자칫 실수하기 쉬운 부분

SRE를 운영팀 이름만 바꾼 것으로 보는 경우

SRE는 단순히 “운영팀의 새 이름”이 아니다. 핵심은 software engineering으로 operations problem을 해결하는 것이다.

운영팀 이름 변경:
  ticket 처리
  수동 장애 대응
  반복 작업 유지

SRE:
  SLO 정의
  error budget 운영
  toil 자동화
  incident postmortem
  reliability engineering

DevOps를 CI/CD 도구 도입으로만 보는 경우

DevOps는 Jenkins, Tekton, GitHub Actions 같은 도구만 의미하지 않는다.

도구:
  CI/CD를 가능하게 하는 수단

DevOps:
  개발과 운영이 lifecycle 전체를 함께 책임지는 방식

SRE가 배포를 막는 조직이라고 생각하는 경우

SRE의 목적은 배포를 막는 것이 아니라, reliability risk를 data로 관리하는 것이다.

SRE의 역할:
  release를 금지하는 gatekeeper가 아니라
  acceptable risk 안에서 빠른 delivery가 가능하게 하는 guardrail

SLO 없이 alert만 많이 만드는 경우

Alert가 많다고 reliability가 좋아지는 것은 아니다.

나쁜 alert:
  모든 CPU spike 알림
  actionable하지 않은 warning
  user impact와 무관한 noise

좋은 alert:
  SLO 위반 가능성
  user-facing error 증가
  즉시 action이 필요한 signal

Error budget을 형식적으로만 두는 경우

Error budget은 dashboard 장식이 아니다. Release decision과 reliability investment에 실제로 연결되어야 한다.

error budget이 소진되었는데도 계속 feature release:
  SLO가 의미 없어짐

error budget이 충분한데도 release를 과도하게 막음:
  innovation 속도 저하

Toil을 개인의 성실함으로 해결하려는 경우

반복 운영 작업을 계속 사람에게 맡기면 team burnout과 human error가 늘어난다.

나쁜 접근:
  담당자가 더 꼼꼼하게 보자.

좋은 접근:
  반복 작업을 자동화하자.
  alert를 줄이고 actionable하게 만들자.
  runbook을 executable하게 만들자.

실무 검증 포인트

DevOps와 SRE를 함께 운영할 때는 다음을 확인해야 한다.

검증 포인트	확인 질문
역할 구분	DevOps와 SRE의 책임이 명확한가?
Delivery pipeline	build/test/deploy가 자동화되어 있는가?
Observability	metrics, logs, traces가 service health를 설명하는가?
SLI	사용자가 체감하는 reliability indicator를 정의했는가?
SLO	service별 reliability target이 있는가?
Error budget	release decision에 실제로 반영되는가?
Alert quality	alert가 actionable하고 user impact와 연결되는가?
Incident response	on-call, escalation, communication 절차가 있는가?
Postmortem	blame이 아니라 system improvement로 이어지는가?
Toil reduction	반복 운영 작업을 자동화하고 있는가?
Capacity planning	traffic growth와 resource saturation을 예측하는가?
Deployment safety	rollback, canary, feature flag가 있는가?
Kubernetes signal	pod, ingress, HPA, node 상태를 관찰하는가?
Feedback loop	production data가 development backlog로 연결되는가?

Mental Model

DevOps와 SRE의 관계는 다음 mental model로 이해할 수 있다.

DevOps:
  software delivery lifecycle을 빠르고 반복 가능하게 만든다.

SRE:
  production reliability를 측정하고 지킨다.

DevOps metric:
  deployment frequency
  lead time
  change failure rate
  MTTR

SRE metric:
  SLI
  SLO
  error budget
  availability
  latency
  error rate
  saturation

둘의 결합:
  빠르게 배포하되,
  reliability budget 안에서 운영한다.

더 짧게 정리하면 다음과 같다.

DevOps는 빠르게 전달하는 방법을 다룬다.
SRE는 빠르게 전달된 system이 안정적으로 동작하게 만드는 방법을 다룬다.

정리

DevOps는 development와 operations의 협업과 자동화를 통해 software delivery를 빠르고 안정적으로 만드는 practice이고, SRE는 software engineering과 reliability metric을 사용해 production system을 안정적으로 운영하고 반복적인 operations task를 자동화하는 discipline이다.

핵심은 다음과 같다.

DevOps와 SRE는 경쟁 관계가 아니라 보완 관계다.
DevOps는 software delivery lifecycle 전체를 빠르고 안정적으로 만드는 데 집중한다.
SRE는 production reliability를 정량화하고 engineering으로 개선하는 데 집중한다.
DevOps는 build, test, deploy, release automation에 강하다.
SRE는 SLO, error budget, incident response, toil reduction, observability에 강하다.
SLI는 실제 측정 지표이고, SLO는 목표값이며, SLA는 계약적 약속이다.
Error budget은 release velocity와 reliability 사이의 균형을 data로 관리하는 장치다.
Toil은 수동적이고 반복적이며 자동화 가능한 운영 작업이다.
Incident response는 단순 복구에서 끝나지 않고 postmortem과 action item으로 이어져야 한다.
Observability는 SRE가 production system을 이해하기 위한 핵심 기반이다.
Kubernetes 환경에서는 DevOps가 배포 자동화를, SRE가 service health와 reliability signal을 관리한다.
Homelab에서도 DevOps는 delivery pipeline을 만들고, SRE는 장애 signal과 반복 문제 개선을 다룬다.

운영 관점에서는 다음처럼 정리할 수 있다.

DevOps:
  build, test, deploy, monitor를 자동화해 delivery 속도를 높인다.

SRE:
  SLO, error budget, observability, incident response, toil reduction으로 reliability를 지킨다.

둘의 결합:
  빠르게 배포하되, 안정성을 data로 관리한다.