32 lines
2.3 KiB
Markdown
32 lines
2.3 KiB
Markdown
---
|
|
id: P-REINFORCE-AUTO-SREE-001
|
|
category: "10_Wiki/💡 Topics/AI"
|
|
confidence_score: 0.97
|
|
tags: [auto-reinforced, sre, site-reliability-engineering, devops, automation, error-budget, monitoring]
|
|
last_reinforced: 2026-04-20
|
|
---
|
|
|
|
# [[SRE|SRE]]
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> "운영에 영혼을 불어넣는 코딩: '시스템 좀 잘 돌아가게 해봐'라는 막연한 운영을 소프트웨어 엔지니어링 문제로 치환하여, 장애 복구부터 배포까지 모든 삽질을 자동화 코드로 해결하는 구글식 무정지 운영 철학."
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
사이트 신뢰성 엔지니어링(Site-Reliability-Engineering, SRE)은 소프트웨어 엔지니어링 방법론을 IT 운영에 적용한 분야입니다.
|
|
|
|
1. **3대 핵심 지표**:
|
|
* **SLI (Service Level Indicator)**: 성공률, 지연 시간 등 측정 가능한 수치.
|
|
* **SLO (Service Level Objective)**: "99.9% 성공하자" 같은 구체적 목표값. (Quality-Control와 연결)
|
|
* **Error Budget**: SLO를 달성하고 남은 '실패해도 되는 여유분'. (이 예산 내에서 무리한 혁신 시도 가능).
|
|
2. **왜 중요한가?**:
|
|
* 개발(속도)과 운영(안정)이 싸우지 않게 '데이터'로 중재하며, 사람이 잠자는 동안에도 코드가 스스로 시스템을 고치게 만들기 때문임. (Efficiency와 Reliability의 합의)
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
|
- **과거 데이터와의 충돌**: 과거에는 장애가 0이어야 한다는 '결벽증 정책'이었으나, SRE 정책은 "장애는 반드시 난다"는 전제 정책 하에 '얼마나 빨리 복구할 것인가'와 '어느 정도의 실패 정책(Error budget)을 허용할 것인가'라는 실용적 정책으로 전환함(RL Update).
|
|
- **정책 변화(RL Update)**: 이제는 단순 자동화 정책을 넘어 AI가 로그 정책을 읽고 장애 징후 정책을 5분 전에 감지해 미리 방어하는 'AIOps 기반 SRE 정책'이 실현되고 있음.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- [[Quality-Control|Quality-Control]], [[Efficiency|Efficiency]], [[Reliability|Reliability]], [[Standard-Operating-Procedure|Standard-Operating-Procedure]], [[Management|Management]]
|
|
- **Modern Tech/Tools**: Prometheus, Grafana, Terraform, Ansible, Kubernetes.
|
|
---
|