55 lines
2.7 KiB
Markdown
55 lines
2.7 KiB
Markdown
---
|
||
title: "SRE"
|
||
type: concept
|
||
tags: [SRE, Site-Reliability-Engineering, DevOps, Automation, Cloud-Transformation]
|
||
last_updated: 2026-04-28
|
||
---
|
||
|
||
## Definition
|
||
|
||
SRE (Site Reliability Engineering，站点可靠性工程) 是一种通过软件工程思维解决运维问题的方法论。其核心理念是打破传统运维与产品开发之间的壁垒，通过自动化、可靠性测量和系统性方法提高服务质量。SRE 起源于 Google，现已被广泛应用于云原生和企业 IT 环境。
|
||
|
||
## Core Principles
|
||
|
||
### 1. 将错误视为学习机会
|
||
SRE 将故障和错误视为改进系统的机会，而非单纯追究责任。通过 Post-mortem 和 CAPA 流程从事故中提取根本原因。
|
||
|
||
### 2. 拥抱风险
|
||
SRE 接受服务存在固有风险，通过 Error Budget 和 SLO 量化可接受的可靠性水平，在创新速度与稳定性之间取得平衡。
|
||
|
||
### 3. 消除 toil（重复性手工劳动）
|
||
Toil 是指那些手动、重复性、可自动化、缺乏持久价值且随规模线性增长的工作。SRE 团队应将 toil 控制在 50% 以下，其余时间用于系统性改进和功能开发。
|
||
|
||
### 4. 自动化一切可自动化的
|
||
通过 IaC（基础设施即代码）和 CI/CD Pipeline 将变更实现完全自动化，减少人工审批环节和出错概率。
|
||
|
||
### 5. 可测量性优先
|
||
所有系统行为都需要可观测性指标支撑（SLI/SLO/SLA），通过监控和告警实现问题的早期发现。
|
||
|
||
## SRE Team Collaboration Model
|
||
|
||
SRE 团队在云转型项目中与产品团队在三个阶段协作：
|
||
|
||
| 阶段 | 说明 | SRE 职责 |
|
||
|------|------|----------|
|
||
| Build（构建） | 产品基础设施搭建阶段 | 定义技术架构、共享 IaC 模块、定义 SLO/SLR |
|
||
| Early Live Support（早期上线支持） | Build 与 BAU 之间的过渡阶段 | 完成 Go-Live Checklist（监控覆盖、支持模型、事件响应流程） |
|
||
| BAU（日常运维） | 持续运营阶段 | 周/双周/月度指标汇报、持续改进 |
|
||
|
||
## Key Metrics
|
||
|
||
- **SLI (Service Level Indicator)**：服务等级指标，直接测量的系统指标（如可用性、延迟）
|
||
- **SLO (Service Level Objective)**：服务等级目标，SLI 的目标值（如 99.9% 可用性）
|
||
- **Error Budget**：错误预算，SLO 允许范围内的错误配额，用于指导发布节奏
|
||
- **Toil**：重复性手工劳动，应控制在 50% 以下
|
||
|
||
## Relationship with DevOps
|
||
|
||
SRE 是 DevOps 理念的具体实现形式之一。DevOps 强调打破开发与运维的边界，SRE 则通过量化指标（Error Budget、SLO）和自动化工具将这一理念落地。
|
||
|
||
## Sources
|
||
|
||
- [[ctp-topic-30-managing-change]]
|
||
- [[ctp-topic-41-nfrs-and-error-budgets]]
|
||
- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]
|