# SRE (Site Reliability Engineering)

## 1. 개요
**SRE(Site Reliability Engineering, 사이트 신뢰성 공학)**는 소프트웨어 엔지니어링 방법론을 시스템 운영에 적용하여, 서비스의 가용성, 성능, 신뢰성을 체계적으로 관리하고 확장하는 구글(Google)의 운영 방식이다.

SRE는 전통적인 IT 운영(Ops) 팀이 겪는 수동 작업의 한계와 개발(Dev) 팀과의 갈등을 해결하기 위해 탄생했다. 핵심 철학은 **"소프트웨어 엔지니어가 운영 업무를 수행하는 것"**이며, 이는 운영 문제를 단순한 관리의 대상이 아닌 해결해야 할 '소프트웨어 문제'로 정의하고 자동화와 코드화를 통해 해결하려는 접근 방식을 취한다.

## 2. SRE의 핵심 원칙과 개념
SRE는 데이터에 기반한 의사결정을 위해 정량적인 지표를 사용한다. 가장 핵심이 되는 개념은 SLI, SLO, 그리고 에러 예산이다.

### 2.1. SLI, SLO, SLA
*   **SLI (Service Level Indicator):** 서비스 수준 지표. 서비스의 상태를 측정하는 구체적인 정량적 측정값이다. (예: HTTP 요청의 성공률, 응답 지연 시간)
    *   구글이 제안하는 **4가지 핵심 지표(Golden Signals: 지연 시간, 트래픽, 오류, 포화도)**를 기준으로 SLI를 설정하는 것이 일반적이다.
*   **SLO (Service Level Objective):** 서비스 수준 목표. SLI에 대해 달성하고자 하는 목표 수치이다. (예: "최근 30일간 HTTP 성공률 99.9% 유지")
*   **SLA (Service Level Agreement):** 서비스 수준 협약. SLO를 달성하지 못했을 때 고객에게 제공하는 보상 체계를 포함한 법적/비즈니스적 계약이다.

| 구분 | SLI (Indicator) | SLO (Objective) | SLA (Agreement) |
| :--- | :--- | :--- | :--- |
| **정의** | 무엇을 측정하는가? | 어느 정도가 목표인가? | 달성 못 하면 어떻게 하는가? |
| **성격** | 측정 지표 (Metric) | 내부 목표 (Target) | 외부 계약 (Contract) |
| **예시** | 응답 시간 (Latency) | 99%의 요청이 200ms 이내 | 가동률 99% 미만 시 이용료 환불 |
| **대상** | 엔지니어 | SRE 및 개발 팀 | 고객 및 비즈니스 파트너 |

### 2.2. 에러 예산 (Error Budget)
에러 예산은 `100% - SLO`로 계산되는 허용 가능한 장애 범위이다. 예를 들어 SLO가 99.9%라면, 에러 예산은 0.1%가 된다.
*   **의미:** 100%의 신뢰성은 불가능하며 비용 효율적이지 않다는 전제하에, 허용된 범위 내에서의 실패를 인정한다.
*   **활용:** 에러 예산이 남아있다면 새로운 기능을 빠르게 배포(Release)할 수 있지만, 예산을 모두 소진했다면 신규 기능 배포보다 시스템 안정성 개선 및 기술 부채 해결 작업에 우선순위를 둔다.

## 3. 주요 활동 및 실천 방안
SRE의 목표는 시스템의 신뢰성을 높이면서도 개발 속도를 유지하는 것이다.

### 3.1. Toil(반복적 수동 작업)의 제거
**Toil(토일)**이란 서비스 운영 중 발생하는 다음과 같은 특성을 가진 작업을 의미한다.
*   **수동적:** 사람이 직접 개입하여 수행해야 함
*   **반복적:** 동일하거나 유사한 작업이 계속해서 발생함
*   **자동화 가능:** 기계적인 규칙으로 대체할 수 있음
*   **전략적 가치 낮음:** 수행 후에도 시스템의 영구적인 개선이 이루어지지 않음

SRE는 전체 업무 시간의 50% 이상을 Toil 제거를 위한 자동화 개발에 할당하는 것을 원칙으로 한다.
*   **Toil의 예:** 수동 서버 재시작, 단순 설정 변경 티켓 처리, 반복적인 데이터 백업 확인.
*   **해결책:** 
    *   **Infrastructure as Code (IaC) 도입:** Terraform, AWS CloudFormation, Ansible, Pulumi 등을 통해 인프라 설정을 코드화하여 수동 설정을 제거.
    *   **셀프 서비스 포털 구축:** 개발자가 직접 리소스를 생성/변경할 수 있는 환경 제공.
    *   **자동 복구 스크립트 작성:** 장애 감지 시 자동으로 재시작하거나 롤백하는 시스템 구축.

### 3.2. 가용성 및 성능 최적화
*   **Capacity Planning:** 트래픽 예측을 통해 리소스를 효율적으로 할당하고 병목 지점을 제거한다.
*   **Load Balancing:** 트래픽을 분산하여 단일 장애점(SPOF, Single Point of Failure)을 제거한다.
*   **Cascading Failure 방지:** 서킷 브레이커(Circuit Breaker)나 지수 백오프(Exponential Backoff) 알고리즘을 적용하여 연쇄 장애를 차단한다.

## 4. 장애 관리와 포스트모템 (Post-mortem)
SRE는 장애를 피할 수 없는 상수로 받아들이며, 장애 발생 후 어떻게 학습하느냐에 집중한다.

### 4.1. 비난 없는 문화 (Blameless Culture)
장애의 원인을 특정 개인의 실수로 돌리지 않고, **"왜 시스템이 개인의 실수를 허용했는가?"**라는 구조적 문제에 집중한다. 비난이 시작되면 엔지니어는 실수를 숨기게 되며, 이는 더 큰 장애로 이어지기 때문이다.

### 4.2. 포스트모템 보고서 템플릿 예시
장애 복구 후 작성하는 사후 분석 보고서의 표준 구조는 다음과 같다.

```markdown
# [Post-mortem] 서비스 결제 모듈 응답 지연 장애

## 1. 요약 (Summary)
- 발생 일시: 2023-10-27 14:00 ~ 15:30 (KST)
- 영향 범위: 전체 결제 요청의 약 30% 실패 및 지연
- 심각도: Critical
- 한 줄 요약: DB 커넥션 풀 부족으로 인한 API 응답 지연 및 타임아웃 발생

## 2. 타임라인 (Timeline)
- 14:00 : 모니터링 알람 발생 (Latency 증가)
- 14:10 : SRE 팀 상황 인지 및 원인 분석 시작
- 14:30 : DB 커넥션 수 급증 확인 및 임시 증설
- 15:00 : 서비스 정상화 확인
- 15:30 : 상황 종료 및 보고

## 3. 근본 원인 분석 (Root Cause Analysis)
- 신규 프로모션 이벤트로 인해 트래픽이 평소 대비 5배 증가함.
- 결제 모듈의 DB 커넥션 풀 설정값이 고정되어 있어 증가한 트래픽을 수용하지 못함.
- 커넥션 대기 시간이 길어지며 상위 API 서버의 스레드 풀까지 고갈됨.

## 4. 재발 방지 대책 (Action Items)
- [ ] **인프라 개선:** DB 커넥션 풀 동적 확장 설정 적용 및 최대치 상향 (담당: Infra팀, 기한: 11/05)
- [ ] **자동화 도입:** 트래픽 급증 시 CPU/Memory 기반 자동 스케일 아웃(Auto-scaling) 임계치 최적화 (담당: SRE팀, 기한: 11/02)
- [ ] **회복력 강화:** 서킷 브레이커 도입을 통해 DB 지연 시 즉시 Fallback 응답을 반환하여 장애 전파 차단 (담당: Dev팀, 기한: 11/15)
- [ ] **모니터링 강화:** 커넥션 풀 사용률 80% 도달 시 사전 경고 알람 설정 (담당: SRE팀, 기한: 11/01)
```

## 5. DevOps와의 관계 및 차이점
DevOps와 SRE는 상호 보완적인 관계이다. 흔히 **"DevOps는 철학(What)이고, SRE는 그 철학을 구현하는 구체적인 방법론(How)"**이라고 정의한다.

| 비교 항목 | DevOps | SRE |
| :--- | :--- | :--- |
| **성격** | 문화적/철학적 운동 | 엔지니어링 실천 방법론 |
| **핵심 목표** | 개발과 운영의 벽 허물기 | 시스템 신뢰성 및 가용성 확보 |
| **접근 방식** | 협업, CI/CD, 문화 개선 | SLI/SLO 설정, 에러 예산, 자동화 |
| **장애 관점** | 빠른 배포와 빠른 복구 | 정량적 신뢰성 측정과 체계적 분석 |

## 6. SRE 도입을 위한 도구 및 생태계
SRE를 실현하기 위해서는 관측 가능성(Observability)과 자동화 도구가 필수적이다.

**관측 가능성(Observability)**이란 내부 상태를 외부 출력(로그, 메트릭, 트레이스)을 통해 이해할 수 있는 능력을 의미하며, SRE의 핵심 기반이 된다.

*   **모니터링 및 시각화 (Metrics):**
    *   **Prometheus:** 시계열 데이터 수집 및 알람 시스템.
    *   **Grafana:** 수집된 데이터를 대시보드 형태로 시각화.
*   **로깅 및 분석 (Logs):**
    *   **ELK Stack (Elasticsearch, Logstash, Kibana):** 대량의 로그 데이터를 수집, 저장, 검색.
*   **분산 추적 (Traces):**
    *   **Jaeger / Zipkin:** 마이크로서비스 간의 요청 흐름을 추적하여 병목 지점 파악.
*   **오케스트레이션 및 인프라:**
    *   **Kubernetes (K8s):** 컨테이너 배포, 확장, 관리를 자동화하는 표준 플랫폼.
    *   **Terraform:** 코드로 인프라를 관리하는 IaC 도구.

## 7. SRE 성과 측정 지표
SRE 팀의 성과는 단순히 "장애가 없었는가"가 아니라, 시스템의 안정성과 효율성을 얼마나 개선했는가로 측정한다.

1.  **MTTR (Mean Time To Repair):** 장애 발생 시점부터 복구 완료까지 걸리는 평균 시간. (낮을수록 좋음)
2.  **MTBF (Mean Time Between Failures):** 장애 발생 간의 평균 시간. 시스템의 안정성을 나타냄. (높을수록 좋음)
3.  **Toil Reduction Rate:** 전체 업무 시간 중 수동 작업(Toil)이 차지하는 비중의 감소율.
4.  **SLO Compliance Rate:** 설정한 SLO를 준수한 비율 및 에러 예산 소진 속도.

## 8. 도입 시 일반적인 문제와 해결책

| 일반적인 문제 | 원인 | 해결책 |
| :--- | :--- | :--- |
| **개발 팀과의 갈등** | 에러 예산 소진 시 배포 중단에 대한 거부감 | SLO 설정 단계부터 개발 팀과 합의하고, 데이터 기반의 의사결정 프로세스 구축 |
| **Toil의 지속 발생** | 당장의 장애 복구에 급급해 자동화 시간을 확보하지 못함 | 경영진의 지지를 통해 SRE 업무 시간의 50%를 자동화 개발에 할당하는 쿼터제 도입 |
| **지표 설정의 어려움** | 무엇을 SLI로 잡아야 할지 모르는 모호함 | 사용자 경험(User Journey)을 분석하여 가장 핵심적인 가치를 주는 지표부터 단계적으로 설정 |
| **비난 문화의 잔재** | 장애 발생 시 책임 소재를 찾는 조직 문화 | 포스트모템의 목적이 '처벌'이 아닌 '학습'임을 명시하고, 리더가 먼저 자신의 실수를 공유하는 문화 조성 |