SRE란

SRE ( Site Reliability Engineering )

시스템, 서비스 및 제품에서 적절한 수준의 안정성을 지속적으로 달성할 수 있도록 지원하는 소프트웨어 엔지니어링 기술
- 애플리케이션을 빌드하고 유연하게 배포하고, 이를 모니터링할 수 있는 플랫폼이 필요한데, SRE의 역할은 이러한 플랫폼을 개발하고, 이 플랫폼 위에서 개발자들이 스스로 배포,운영을 하는 것이 목표
DevOps적용에 따라 개발팀은 속도와 변화(기능 추가 또는 개선)를, 운영팀은 안정성(대기시간, 스파이크)과 무중단을 중요시 하므로 이를 적절히 중재, 관리하기 위하여 SRE가 등장
- “ class SRE implements Devops “
- 최종 목표
  - we want systems that are automatic, not just automated.
  - 개발부서 스스로 배포, 운영을 하는 것이 종착지
    - 개발 부서가 스스로 배포, 운영을 할 수 있게 플랫폼 또는 파이프라인 구성

목표

적절한 안정성 달성– 시스템 및 서비스 장애로 인해 발생하는 기업이나 조직의 신뢰도 하락, 금전적 피해 등 비즈니스 악영향을 최소화

지속 가능한 운영 방식 수립

– 시간이 지나도 지속되는 운영 방식을 구현하여 사람들이 업무에 최선을 다할 수 있도록 지원

자동화
- we want systems that are automatic, not just automated.
  - Automated : Like “Shell script”. 실패하면 사람이 수동으로 고쳐야함 → 낮은수준의 자동화
  - Automatic : Like “Kubernetes” 자체적으로 판단해서 뭔가 액션을 취함 → 쿠버네티스는 etcd를 유지함
새로운 것이 낫다는 확신이 들 때, 이전 것을 버릴 수 있는 용기
서비스 운영이 안정성을 찾았을 때, 개발 작업에 참여 가능한 능력

(‣)

Metric & Monitoring

정량적 모니터링 지표 정의 및 모니터링 시스템 설계 그리고 분석
- 서비스에 대한 지표 설정 SLI(Service Level Indicator)
- 각 지표에 대한 안정성 목표 설정 SLO ( Service Level Objective)
- 각 지표들은 이해 당사자들이 각각 원하는 방식으로 대시보드에서 제공
- 지표들로부터 분석하여 인사이트를 얻어냄
  - 장애가 나는 지표
  - 개선할 수 있는 지표
  - 데이터 기반 의사결정
장애 탐지
- 다양한 모니터링 지표를 통해 실시간으로 서비스 이상 징후를 확인
- 필요에 따라 모니터링 지표나 알람을 세분화/고도화하여 문제가 되는 지점을 정확하게 찾기
- 여러 시스템 지표는 물론이고, 비즈니스 지표까지 함께 장애 탐지에 사용
- 장애에 의한 영향도를 빠르고 정확하게 확인

Capacity Planning

서비스를 운영하는데 필요한 리소스 파악 및 확보
- 이벤트, 새로운 기능 등과 같은 비정상적인 리소스 사용 예측
- 효율적인 리소스 운영을 위한 튜닝 및 안정성 최대화

Change Management

Continuous Integration
- 시스템 변경에 따른 에러 최소화
- 휴먼 에러 최소화
Continuous Delivery(Deployment)
- 점진적인 배포(카나리 배포, 롤링 업데이트)
- 배포 장애 시, 빠른 파악
- 장애 시, 빠른 롤백
버전 관리, 코드 관리, 테스트 등과 같은 프로세스 정리

Emergency Response

MTTF(Mean Time to failure) : 마지막 장애로부터 동작한 시간
MTTR(Mean time to recover) :장애가 발생부터 복구까지 걸린 시간
장애를 막는 것의 어려움 > 장애를 복구하는 것의 어려움
- 장애 요인은 수많아서 장애를 원천 차단하는 것은 불가능
- 장애를 빠르게 복구하는 것이 더 중요함
장애 복구 매뉴얼화 및 자동화
- 주기적인 Playbook 기반 장애 복구 모의훈련
- 장애 탐지 - 알람 - 리커버리 (자동화 필요)

Culture

Error budget : 특정 시스템이 일정 시간 동안 허용되는 장애 시간
- 일정 시간 동안 에러가 발생하여 허용 이상의 장애 시간을 써버린다면 기능 개발을 멈추고 안정성을 올리는 개발을 진행함
- 비즈니스적으로 기능 개발이 필요하다면 전체 조직은 장애가 일어났을 때, 비난 보다 장애 분석하고 책임을 나누어야함
장애 리뷰와 장애 재발 방지 작업
- 예시 : https://techblog.woowahan.com/2700/
- Root Cause를 찾아서 개선하고, 장애 리뷰 과정에서 도출된 여러 시스템 취약점들을 개선(Postmoterm)
- 대부분 장애는 하나의 절대적이고 단순한 원인이 아니라, 여러 원인과 상황들의 시너지 효과로 인해서 촉발되고 확산되기 때문에 장애를 회고하는 과정을 통해서 여러 개선 포인트를 도출
- 때로는 그 과정이 길고, 복잡하고, 고통스러울 때도 있지만, 비슷한 장애를 두 번 이상 겪는 것보다는 훨씬 적은 비용과 노력이 들어감

안정성 확보 활동세부 계획

조직의 SILO 최소화	- 시스템 안정성에 대한 책임 공유
- 개발과 운영 사이의 간극 최소화
장애에 대한 반응	- 서로 비난하지 않는 문화, 장애 발생 후 회고(조직 간 효율적 협업을 위한 포스트모텀 문화)
- 가용성의 적절한 관리를 위한 Error Budget 개념 도입
점진적 변화 수행	– MTTR 최소화를 위한 카나리 배포, 롤링 업데이트 적용
매뉴얼 기반 자동화	- 자동화를 통해 사람이 운영에 직접 관여를 최소화
- 수동 작업량 측정 및 조절, Toil 기반 관리
지표 관리	- 측정 가능한 모든 지표를 정량적으로 관리하여 표현
- 시스템 지표 뿐 아니라 작업 시간, 장애 시간 등 모든 것을 데이터화