MindMap Gallery SRE Domain: Tổng Quan và Chi Tiết
Sơ đồ tư duy này cung cấp một cái nhìn tổng quan và chi tiết về SRE (Site Reliability Engineering) Domain. Nó bao gồm các khía cạnh chính như SRE là gì, các nguyên tắc hoạt động, các công cụ và phương pháp đo lường, cũng như các dịch vụ đám mây và công cụ giám sát. Mỗi phần được phân chia thành các tiểu mục cụ thể, giúp hiểu rõ hơn về vai trò và chức năng của SRE trong việc đảm bảo độ tin cậy và hiệu suất của hệ thống.
Edited at 2024-04-03 10:24:06SRE Domain
1. 22년 SRE 업무 정의
비상대기/장애대응
장애관리 프로세스
장애모의훈련 프로세스
년 1회
자금관련
시나리오 정의
BCP 체계 수립
체계 수립
메뉴얼 업데이트
이중화가 아닌 시스템 백업으로 복원 테스트 (검증)
이중화 처리
10월 중순
이벤트 대응
사전조치
모니터링
인스던트 관리
비상체계 수립
포스트모텀 프로세스
모니터링
도구(솔루션) 최적화
Observality
Whatap
DataDog
Grafana
지표정의 및 알람
알람지표
경고알림
장애알림
각담당자 기준 설정
가용성 엔지니어닝
시스템 장애 훈련
시스템 용량 관리 체계
용량관리 기준 정하기
CPU
Memory
시스템 변경 관리 프로세스
역량강화
교육체계 수립
대상은?
어떤거?
홍보활동
문제관리
SRE 진행하는 업무 관리
리포트
SRE Daily Scrum
포스트 모텀 주관 현황
변경관리
배포 이력 관리
서비스 변경 인지
시스템 변경 작업
지표관리(SLI/SLO)
시스템 품질(성능-Performace) 기준
API Latency : 100ms / 99%
Peak Respons Time
Error Rate
Datadog
0.2%
Time to Interactive (페이지가 완전히 응답하기 까지의 시간)
3초
TPS
1.3k
동접 13만
가용성
가용률 : 99.977%
복구율(RT)): 5분
전파율(NTTN):5분
성능관리
개념과 지표항목만 정의 되어 있음 (기준이 없음)
23년 엑셀 전달
2. 운영업무
3. 루틴한 업무 프로세스
주간업무 보고
이벤트 대응
캠페인 (전파)
개발
효율적인 업무
비상대기 근무???????
업무 티켓 발행 (SRE 파트)
이벤트 대응
비상대기 결제
4. 24년 SRE 업무 정의 (신뢰성 높이기 위한 요소를 기준으로 정리)
가용성
기준을 갖는다
기준을 준수 하고 있는지 지속적으로 관리 한다
카오스 엔지니어닝
문화를 만든다
품질관리
기준을 갖는다
기준을 준수 하는지 지속적으로 관리 한다
QA팀 협업
문화를 만든다
포스트모텀
장애관리
비상대기
장애대응
프로세스 수립
이벤트관리
5. SRE 업무 정의-기술요소
프로그래밍
아키텍트
MSA
AWS EKS
CI/CD
Gitlab CI
Message Stream Driven
Kafaka
업무자동화
Slack Open API
Java 기본
파이썬
모니터링
observability
AWS CloudWatch
Grafana
OpenTelemetry
알람
AWS SNS
AWS SQS
ARS 솔루션
6. SRE 업무정의 및 로드맵
운영
장애/이슈 대응
이벤트 대응
솔루션
Tracer
사전조치
자동화
일정등록 자동화
기준에 맞게 자동 증설
이벤트 대응 조치 확인
Gen
Tracer
모니터링
시스템 변경 관리
변경 이력관리
인시던트 관리
비상대기(~11/30)
이슈
이슈 단계 세분화
주의
경고
이슈 발생
전파 프로세스
SRE 제외
프로세스 수립
장애
프로세스 수립
2일 주기 정/부
업무 공유 시스템
피음
"SRE_작업" 라벨
본인이 맡은 날에 이벤트 대응
공유 캘린더
포스터모텀
모니터링 솔루션 개발/운영
각종 자동화 동구
Observability
Metric
DataDog
APM(Tracer)
Whatap
Log
알람
Slack Bot
AutoBot
이벤트 일정 등록 및 인프라 자동 증설 Bot (~12/31)
SRE(신뢰성 엔지니어링)
SLI/SLO 지표관리(품질향상)
기준/목표
가용성
가용률 : 99.977%
복구율(RT)): 5분
전파율(NTTN):5분
성능
API Latency : 100ms / 99%
Peak Respons Time
Error Rate
Datadog
0.2%
파닥에 깔린 장애 없애기
Time to Interactive (페이지가 완전히 응답하기 까지의 시간)
3초
TPS
1.3k
동접 13만
결과
리포트 발행
캠페인 진행
카오스 엔지니어링
가용성
BCP
Cloud Service
서비스 활용
EKS
서비스 품질
성능테스트
부하테스트
전시
메인을 기준으로 첫번째 기준을 찾는다
해당 기준을 바탕으로 러프하게 전반적인 기준을 1차 통일 한다.
스트레스테스트
현실성에 맞는 기준을 찾고 타협한다
아키텍처
인프라
S/W
코드 품질
문화
인시던트(Incident) 관리
포스트 모텀
비상 대기
장애/이슈 관리
1. 현행화
필터링
SRE 또는 그 외 로 분류
SRE 기준 대응 기준 지표 분리
Result
장애
L1
L2
L3
이슈
L4(경고)
L5(주의)
SRE 파트 논의
# 12/15 SRE 비상대기 정상화 / 보완 리뷰 - SRE의 중요한 업무(50%) - 비상대기에 대한 운영체계 마련이 필요함 ㄴ 비상대기는 운영업무 X ㄴ 비상대기 지표(알람 / 수동 대응 / 접수 대응, 모니터링 시스템 지표, 모니터링 미설정, 시스템 변경 지표(작업등)) / 템플릿 마련 ㄴ 잘못된 모니터링으로 운영에 부담 제거 ㄴ 5분내 상황 판단을 할 수 있는 체계 포함 ㄴ 시스템 각각 문제들은 제대로 측정 ㄴ 지표로써 비상대기 정상 운영 여부가 판단될 수 있도록....... ㄴ 트래픽 폭증 시 특정 트래픽 분석하여, 즉시 차단할 수 있는 체계 마련 ㄴ 알람 / 개선 사항 티켓화..(자동화?) ㄴ 포스트모텀 / 개선과제 관리 - 비상대기 부가 진행을 함 - 비상대기(24시간 OP) 포함해서, 이상 발생시 누락 없이 대응(분석/개선) 및 Control Tower 역할 수행해야함. ㄴ 통합 대시보드 알람 관리 ㄴ 각 Slack 채널에 발생되는 각종 알람 / 이상 상황 대응 ㄴ 수동 Dashboard 모니터링 이상상황 대응 - 시스템이 판단해서 알람 줄 수 있도록....개선 ㄴ 이슈 / 장애 대응
OP 프로세스 점검
좀더 적극적이고 누락 없도록 가이드 업데이트
발생 알람 및 피드백에 대한 지표 수집 가이드 작성
알람 시스템 개선
2024년 알람 프로세스 개선
SRE 파트 대응 알람과 현업 알람 명확한 구분
알람 Level 화
주의
경고
불기둥 및 일시적인 기둥에 대한 사전 알람 발생 가능 혹은 사후 분석 가능한 체계
장애1
장애2
장애3
현재 비즈니스 영향도에 따른 장애 등급으로 사후 장애 판단 에서 지표의 상태값으로 장애 등급을 구분하여 사전 장애 인지에 대한 조치가 가능 하도록
전파 수준 기준 마련
담당자 전파
비상대응챔피언
2024년 알람 프로세스 개선 전 과도기 시점
SRE 알람 통합 채널 생성
모든 알람 한곳에 통합 관리
모든 알람 확인 및 F/U
필요 없는 알람 및 중복 알람 제거
분류 작업 진행
알람 처리 내역 관리 문서 작성
대응 문서를 통한 주간 지표 통계 작성 및 주간 보고
시스템 변경 지표
현행 시스템 변경 작업 티켓 프로세스 유지
보고 템플릿
주간 지표 보고
1차 회의 현길님 의견
비상대기에 대한 운영체계 마련
비상대기시 운영업무 X
현길님 비상대기 업무 중 운영업무 필요 동감
비상대기 지표
수동 대응
접수 대응
모니터링 시스템 지표
모니터링 미설정
시스템 변경 지표
템플릿 마련
잘못된 모니터리으로 운영에 부담 제거
5분내 상황 판단을 할 수 있는 체계
시스템의 문제들 제대로 측정
지표로써 비상대기 정상 운영 여부가 판단 될 수 있도록
트래픽 폭증 시 분석 및 차단 할 수 있는 체계 마련
알람 / 개선 사항 티켓화
포스트모텀 / 개선과제 관리
비상대기 부가 진행
현 프로세스 유지
비상대기 포함해서 이상 발생 누락없이 대응 및 Control Tower 역할 수행
통합 대시보드 알람 관리
각 슬랙 알람 / 이상 상황 대응
수동 모니터링 이상상황 대응
이슈/장애 대응
모니터링
모니터링 정의
White-box monitoring
지표를 통한 분석
Black-box monitoring
사용자 측면에서의 외부 테스팅을 통한
Dashboard
Alert
Node and machine
Push
시스템의 변경 및 설정
The Four Golden Signals
Callout
https://eium.lotte.com/pages/viewpage.action?pageId=373621464
Latency
Traffic
Errors
Saturation
모니터링 및 경고(알림) 생성 규칙
이 규칙은 긴급하고 실행 가능하며 적극적으로 또는 임박하게 사용자에게 표시되는 감지되지 않은 조건을 감지합니까 ?
알람 피로도(alert spam)
이 경고가 양성이라는 것을 알면서도 무시할 수 있을까요? 언제, 왜 이 경고를 무시할 수 있으며, 이 시나리오를 방지하려면 어떻게 해야 합니까?
이 경고는 사용자가 부정적인 영향을 받고 있음을 확실히 나타냅니까? 트래픽 유출이나 테스트 배포 등 사용자에게 부정적인 영향을 미치지 않고 필터링해야 하는 감지 가능한 사례가 있습니까?
이 경고에 대응하여 조치를 취할 수 있습니까? 그 조치가 긴급한 것입니까, 아니면 아침까지 기다릴 수 있습니까? 작업을 안전하게 자동화할 수 있나요? 해당 조치는 장기적인 수정이 될까요, 아니면 단기적인 해결 방법이 될까요?
다른 사람들이 이 문제로 인해 페이지를 호출하여 페이지 중 하나 이상을 불필요하게 만들고 있습니까?
알람 분류
발송자(누가)
DataDog
자빅스
Grafana
AWS
Slack Webhook
기타
결제 오류는 어떻게 보내는 가?
수신자(누구에게)
개발
시스템
SRE
지표 구분(무엇을)
Application Performance
Infra
Business
수신방식(어떻게)
Slack
SMS
ARS
전파방식 및 전파의 방법
알람 레벨
경고
W5
W4
장애
비즈니스 영향도(알람으로 설정하기 어려움)
L3
L2
L1
시스템 영향도(알람으로 설정 가능)
S3
S2
S1
Floating Topic
신규 시스템 온보딩 체크 리스트
아키텍처
아키텍처 다이어그램
서버의 종류
클라이언트가 보내는 요청의 종류
프로그래밍적으로 전송되는 클라이언트 요청의 존재 유무
머신 및 데이터센터
머신 및 대역폭, 데이터센터, N+2 이중화, 네트워크 Qos
새 도메인 이름, DNS 로드밸렁싱
용량 예측, 수용량 및 성능
HTTP 트래픽 및 대여폭 예측, 출시 직후 '최고 트래픽이 6개월 지속될 경우를 가정'
부하 테스트, 종단간 테스트, 최악의 지연응답 상황시 데이터센터별 수용량
다른 서비스에 대한 영향
저장소 용량
시스템 신뢰성 및 장애 대응
아래 사항에서 발생할 수 있는 일
머신의 중단, 랙 장애 혹은 클러스터 오프라인
두 데이터센터 간 네트워크 장애
다른 서버(관련 백엔드 포함)와 통신하는 서버의 종류
백업드 중단을 탐지할 방법, 그리고 대처 방안
클라이언트 및 사용자의 영향을 최소화하면서 작업을 종료하거나 재시작하는 방법
로드 밸런싱, 비율 제한, 타임아웃, 재시도 및 에러 처리 동작
데이터 백업 / 복구, 재난시 복구 대책
모니터링 및 서버 관리
내부 상태의 모니터링, 종단간 동작의 모니터링, 알람 관리
모니터링 서비스에 대한 모니터링
재정적으로 중요한 알림과 로그
클러스터 환경에서 서버를 운영하기 위한 팀
서버 코드에서 알림을 메일로 직접 발송하면서 메일 서버의 충돌을 유발하지 말것
보안
보안 디자인 리뷰, 보안 코드 감사, 스팸 위험도 검사, 인증, SSL
사전 출시 감시 / 접근제어, 다양항 형태의 블랙리스트
자동 및 수동 작업
서버, 데이터 및 설정의 수정을 위한 방법 및 변경 제어
릴리즈 절차, 반복적 빌드, 실제 트래픽하에서의 카나리 테스트, 단계적 배포
증가 이슈
여분의 수용량, 10배 증가, 증가 알림
확장성 병목, 선형적 증가, 하드웨어 확장, 이를 위해 필요한 변경 사항
캐싱, 데이터 샤딩/ 재샤딩
외부 의존도
써드파트 시스템, 모니터링, 네트워킹, 트래픽 용량, 출시 직후 최고 트래픽
적절한 퇴보 모드, 의도치 않게 써드파티 서비스를 과도하게 사용하는 상황을 회피하는 방안
연합 파트너, 메일 시스템, 회사 내의 다른 서비스들과의 원활한 협업
일정 및 배포 계획
반드시 준수해야할 마감일, 외부 이벤트, 월요일 혹은 금요일
해당 서비스 및 다른 서비스들의 표준 운영절차
신규 시스템 온보딩 체크 리스트
아키텍처
인프라
설계와 구현이 일치 하는가
S/W 프로세스
배치
품질
자원
모니터링
보안
정책
배포정책
개발정책
SRE Fanout
SRE 업무 정의
비상대기/장애대응
장애/이슈 대응 프로세스
대응
알람 및 팀별 모니터링을 통해 정의된 프로세스에 맞게 장애 처리
1. 장애전파
#비상대기채널 전파
2. 장애대응
장애대응 Playbook
장애대응 컨트롤 타워 프로세스
3. 해소
4. 개선
포스트모텀
지표 관리
리포트
포스트모텀
개선과제 목록
포스트모텀 목록
주간 현황
장애 목록
가용률
지표관리(SLI/SLO)
시스템 품질(성능-Performace) 기준
API Latency : 100ms / 99%
Peak Respons Time
Error Rate
Datadog
0.2%
Time to Interactive (페이지가 완전히 응답하기 까지의 시간) or LCP
3초
TPS
1.3k
동접 13만
가용성
가용률 : 99.977%
복구율(RT)): 5분
전파율(NTTN):5분
성능관리
개념과 지표항목만 정의 되어 있음 (기준이 없음)
장애모의훈련 프로세스
년 1회
시나리오 정의
BCP 체계 수립
체계 수립
메뉴얼 업데이트
이중화가 아닌 시스템 백업으로 복원 테스트 (검증)
이중화 처리
이벤트 대응
사전조치
모니터링
모니터링
솔루션 관리
Observality
Whatap
DataDog
Grafana
지표정의 및 알람
알람지표
경고알림
장애알림
각담당자 기준 설정
OP 운영
OP 가이드
전파 이슈 정의
지표 관리
비상 연락망
가용성 엔지니어닝
시스템 용량 관리 체계
용량관리 기준 정하기
CPU
Memory
변경 관리 프로세스
배포 이력 관리
서비스 변경 인지
시스템 변경 작업
문제관리
카오스 엔지니어링
솔루션
Tracer