DevOps 文化与 SRE 初探
一、DevOps：开发与运维的协作与文化
传统模式下，开发负责写代码、运维负责上线与维护，两者之间往往有「交棒」隔阂：开发觉得运维慢、运维觉得开发乱改。DevOps 不是单纯把两个团队合并，而是强调共同目标（交付稳定、可用的系统）、共享责任（质量与稳定性人人有责）、缩短反馈环（从需求到上线再到监控，形成闭环）。文化上：打破部门墙、鼓励自动化与工具链、拥抱「小步快跑」与失败学习（blameless post-mortem）、用数据与可观测性说话。
二、自动化、反馈与持续改进
自动化：能脚本化的就脚本化——构建、测试、部署、配置、扩缩容、例行巡检。减少手工操作既提高效率，也降低人为错误；CI/CD、IaC（基础设施即代码）都是自动化的一环。反馈：发布后要有快速反馈——监控、告警、日志、用户反馈。问题越早暴露，修复成本越低；可观测性（上一章）就是反馈的基础。持续改进：根据反馈调整流程与系统，而不是「一次做完就停」。复盘、改进检查清单、优化自动化与告警，形成闭环。三者合起来就是「建流水线 → 看数据 → 改流程」的循环。
三、SRE 核心：SLO/SLI、错误预算、自动化运维
SRE 用工程手段保障系统可靠性，同时避免「为了 100% 稳定而不敢发布」。核心概念：
SLI（Service Level Indicator）：可量化的可靠性指标，如请求成功率、延迟 P99、可用性（正常时间占比）。选与用户体验直接相关的指标。
SLO（Service Level Objective）：对 SLI 的目标值，如「成功率 ≥ 99.9%」「P99 延迟 ≤ 200ms」。SLO 定得太紧会逼得团队不敢发布或疲于救火，太松则失去约束意义。
错误预算（Error Budget）：在 SLO 允许范围内的「可失败空间」。例如 SLO 99.9% 表示一个月内允许约 0.1% 的失败；这 0.1% 就是错误预算。预算没花完时可以放心发布、做变更；花完了则优先修稳定性、减少新功能发布。这样把「稳定性」和「新功能」放在同一套可衡量的框架里，避免无休止的争吵。
自动化运维：重复性工作（扩缩容、故障转移、例行巡检、部分故障处理）用自动化完成，人专注在设计、复盘与异常处理。减少 toil（枯燥、重复、手动的劳动），提高系统可扩展性与一致性。
SRE 落地要点
- 选与用户体验直接相关的 SLI，定合理的 SLO（不过紧不过松）
- 错误预算：未耗尽可发布，耗尽则优先修稳定性、控发布
- 自动化运维减少 toil，人专注设计、复盘与异常
四、从理念到落地
DevOps 与 SRE 不是买一套工具就能成，而是文化、流程、工具一起变。落地时可从这些入手：小范围试点——先在一个团队或一条流水线打通 CI/CD、可观测性与复盘习惯；统一工具链——构建、部署、监控、日志尽量统一，减少割裂；明确 SLO 与错误预算——哪怕先定一两个核心接口的 SLO，再逐步扩展；复盘与共享——故障与发布复盘写成文档、在团队内分享，把「改进项」闭环掉；减少 toil——把重复手工操作列出来，优先自动化。从理念到落地是一个持续过程，不必一步到位，但要有明确方向和下一步动作。
一句话： DevOps 强调开发与运维协作、自动化与反馈、持续改进。SRE 用 SLI/SLO 量化可靠性，用错误预算平衡发布与稳定，用自动化运维减少 toil。落地要文化、流程、工具一起变，从小范围试点和明确 SLO 开始。
五、小结
DevOps：协作与文化、自动化、反馈、持续改进。SRE：SLI（指标）、SLO（目标）、错误预算（可失败空间）、自动化运维。落地：小范围试点、统一工具链、明确 SLO、复盘与减 toil。下一章进入架构风格：单体、分层、微服务，从单体到微服务的边界与取舍。