可靠性工程

1）什么是SRE，为什么需要它

可靠性工程（Site Reliability Engineering，SRE）是开发和运营交界处的一门学科，可将可靠性转化为可测量的产品属性。SRE连接用户体验度量（SLI），质量目标（SLO），错误预算，自动化和托管更改，以更快地交付价值而不会失去可持续性。

关键目标：可预测的UX、快速发布、最低停机时间和可控的拥有成本。

2） SRE原则

可靠性作为远景。优先于SLO和业务目标设定的限制。
错误预算控制更改的速度。如果预算被烧毁-关注稳定性。
自动化>手动操作。任何可重复的任务都是脚本/语句/引导线。
可测量性。只有测量的（SLI/SLO）才能改善。
Just Culture.无罪后面部表情，专注于系统原因。
Shift-left.质量，安全性，测试和可观察性是开发周期的一部分。

3）组织和角色

平台的SRE命令：共享工具，策略，pipline，GitOps，服务目录。
嵌入式SRE （embedded）：与产品团队一起工作,在SLO上实现联合目标。
职责（呼叫中）：轮换，负载限制，补偿，训练。
RACI：服务的所有者，SLO的所有者，事件中的IC，Comms Lead，Scribe。

4） SLI/SLO和错误预算（产品捆绑）

SLI：可用性，潜在性，业务运营成功，数据相关性。
SLO：窗口目标28-30天+例外。
Error Budget = 1 − SLO.政策：发布，实验，金丝雀和fichi受实际燃烧率的约束。
按队列设计：区域，提供商，VIP段-单独的SLO，以免失去异常。

5）默认可观察性

指标：成功/错误，p50/p95/p99，saturation（CPU/mem/IO/conn）。
Logs：结构化,具有查询/版本/标记的相关性。
Tracing：端到端的延迟和错误映射,热路径。
合成+RUM：外部采样和真实客户遥测。
SLO dashbords：预算下降，发行注释，金丝雀，提供商。

6）变更与发行管理

Pipline CI/CD：确定性装配、工件签名、安全扫描、合同测试。
渐进策略：金丝雀/蓝绿色/阴影；具有生命周期的幻灯片标志。
Gate's quality： policy-as-code, SLO-guardrails,退化时自动回滚。
GitOps：配置/策略作为代码,在星期三促销,审核。

7）事件和后面面孔

SEV/P级别声明,IC立即分配,SEV-1+发布冻结。
Burn-rate alerta：短而长的窗口，按区域和样本类型划分的法定人数。
花花公子：回滚，退化，收费提供商，限制/撤退。
RCA和CAPA：事实，因果关系，可测量的行动，控制点（D+14/D+30）。
知识目录：我们重新使用模板和课程。

8）可靠性测试

微服务合同测试和消费者驱动合同。
按实际模式的负载配置文件,p99 测试/GC暂停/队列尾巴。
Chaos/Resilience桉例：关闭依赖项、网络、延迟；游戏日和DR演习。
DB迁移：expand→migrate→contract，可逆性，两个版本的兼容性测试。

9）容量与成本管理（FinOps）

Capacity Units和headroom在关键路径上。
HPA/VPA/KEDA按用户指标和队列滞后。
多供应商：配额，SLO/潜伏路由，自动收发器。
单元经济学：$/1k查询，$/成功交易；优化缓存、日志、egress。

10）安全性作为可靠性的一部分

SAST/DAST/SCA，秘密搜索，SBOM，映像签名。
mTLS和访问策略（OPA/ABAC）；最低特权。
关键字/证书轮换，截止日期控制，测试到期方案。
安全事件-单独的花花公子，强制，监管通知。

11）文化和过程

SLO评论：每周/每月，债务优先于"紫罗兰"。
培训和模拟：电话培训，事件排练，混沌日。
统一标准：准备就绪检查单，通信的SLA，后太平间格式。
Alert疲劳指示器：噪音≤目标阈值,定期调谐。

12）SRE函数的成熟度量

DORA度量：降级频率，领先时间，MTTR，更改失败率。
SLO执行：绿区服务份额，燃烧率趋势。
Alert卫生：分页活动的百分比，Alert/班次的中位数，假比例。
RCA/CAPA：按时执行，系统性（非个人）原因的比例，reopen-rate。
费用：$/SLO项目，$/1K查询，自动轨道的效率。

13）"服务准备就绪"支票清单"

• 由SLI/SLO，SLO所有者和监视窗口定义。
• Dashbords和burn-rate alerta定制，有外部合成。
• 管道：签名/扫描,合同/集成测试,金丝雀/标志,自动滚动。
• DB迁移是可逆的，负载轮廓覆盖峰值。
• 事件花花公子和供应商联系；状态页面。
• Capacity headroom已确认；HPA/KEDA和提供商配额已验证。
• Configi和政治家-在Git中，周三的促销活动包括审计。
• Security：代码外秘密,mTLS/轮换, TLS时机受控。

14）反模式

«99.999％或什么都没有"-无法实现的目标→永恒的红色燃烧率。
没有金丝雀和幻想旗的发行→大爆炸。
一个监控点→虚假警报和跳过。
手动更换销售中的configs →漂移和不可操作性。
没有CAPA的后太平间→反复发生的事件。
SRE是"消防员"，没有改变建筑的权利→债务不会关闭。

15）SRE实施路线图（3-6个月的示例）

1.第1个月：服务和关键路径清单；SLI/SLO草稿；基本的dashbords和burn-rate alerta；开始呼叫。
2.第2个月：金丝雀/幻灯片，自动回滚；GitOps configs；事件花花公子目录；状态页面。
3.第3个月：合同测试，负载配置文件，DB expand/contract方案迁移；第一个游戏日。
4.4-6月份：多供应商路线，DR演习，成本优化，成熟度量标准，团队的KPI。

16）结果

SRE是一个开发操作系统：透明的质量目标（SLO），可控的变更率（错误预算），自动化和事件纪律，稳定性测试以及有意识的成本。通过这种方法，发行成为常规，可靠性成为竞争优势。