SRE 귀찮게 안하기 - 하는 일

[귀찮게하기/DevOps-SRE] - DevOps와 SRE 귀찮게 안하기 - DevOps 와 SRE

[귀찮게하기/DevOps-SRE] - DevOps 귀찮게 안 하기 - DevOps가 하는 일

 

여기까지만 하고 나는 SRE와 DevOps를 구분하지 않으려고 한다. SRE로 말하든 DevOps로 말하든..

-> DevOps나 SRE나 결국 서비스를 안정적으로 배포하는 데에 찬성하는 조직이자 역할이라고 생각한다.

 

 

 

 

SRE가 일하는 방법

원칙을 가지고 일하게 됨

 

SRE 원칙

• 서비스에 대한 명확한 정의
• 가용성
  • 정의
  • 목표
• 장애 대응 계획
• 모니터링
• 효율성
• 성능
• 대기 시간
• 장애에 대한 공동 책임

 

SRE 라고 하는 것은 거의 구글이 만들었다고 해도 될 만큼 Google 문화가 유명하다.

 

 

Google SRE 원칙

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

 

SRE가 하는 일

 

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)
  • 대부분 장애는 하나의 절대적이고 단순한 원인이 아니라, 여러 원인과 상황들의 시너지 효과로 인해서 촉발되고 확산되기 때문에 장애를 회고하는 과정을 통해서 여러 개선 포인트를 도출
  • 때로는 그 과정이 길고, 복잡하고, 고통스러울 때도 있지만, 비슷한 장애를 두 번 이상 겪는 것보다는 훨씬 적은 비용과 노력이 들어감

 

 

SRE를 도와주는 방법

 

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

 

 

 

참고링크

https://sre.google/books/

https://bcho.tistory.com/1325