资源介绍
SRE 基础概念
定义：SRE 是一套将软件工程方法应用于 IT 基础设施和运营的原则与实践，旨在创建高可靠性和可扩展性的软件系统。
起源：2003 年由 Google 提出，最初为解决大规模系统的可靠性问题，后逐渐被广泛采用。
定位：作为开发与运营之间的桥梁，与 DevOps 有相似原则但实践不同，部分组织中两者为独立团队，部分则角色重叠。
核心原则：
可观测性（通过监控识别系统漏洞）
自动化（消除手动重复任务）
服务级别目标（SLO）、服务级别协议（SLA）等指标设定
度量（定义指标衡量系统性能）
风险管理（识别潜在故障并减轻影响）
事件管理（建立明确的事件处理标准）
变更管理（规范开发和测试人员的变更发布流程）
SRE 在软件开发生命周期（SDLC）中的作用
传统模型局限：瀑布模型为线性流程，各阶段孤立，难以应对需求变化；早期敏捷方法虽解决部分问题，但开发与运营团队仍存在隔阂。
SRE 的融入：
规划阶段：提供生产环境的实际数据（如流量、可扩展性等），辅助需求分析和设计。
设计阶段：分享客户负载等洞察，助力架构设计，如推荐合适的数据库和服务器容量。
测试阶段：参与测试评审，进行负载和混沌测试，识别潜在问题。
部署与监控阶段：监控生产环境，处理技术工单，快速排查和解决问题。
SRE 的核心支柱
SLO、SLI 和 SLA：
SLI（服务级别指标）：定量衡量服务可靠性的实际数据，如吞吐量、延迟等。
SLO（服务级别目标）：组织内部设定的系统运行标准。
SLA（服务级别协议）：对客户承诺的服务可靠交付标准，包括 uptime、响应性等。
监控：收集系统指标以了解性能，包括主动监控和被动监控，常用工具如 ELK、Prometheus、Grafana 等。
应急响应：即事件管理系统，包括事件识别、记录、分类、优先级划分和响应等阶段，确保及时处理用户请求和故障。
变更管理：规划、测试和部署代码或配置变更，控制变更风险，确保系统质量。
SRE 与 DevOps 的关系
共同点：
结构化方法（明确各阶段任务、角色和流程）
自动化（减少手动工作，提高效率）
质量控制（确保部署到生产环境的代码质量）
度量（通过指标衡量性能）
变更管理（规范变更流程）
构建有效的 SRE 解决方案
构建可扩展、可靠和可用的系统：
可扩展性：通过水平扩展（增加节点）和垂直扩展（提升现有节点资源）实现，需根据场景选择合适方式。
可靠性：通过设计评审、代码审查、测试（单元测试、回归测试等）和自修复能力（自动检测和修复问题）确保。
可用性：通过分布式系统、数据复制、地理分布和定期维护实现系统持续可用。
容量规划和成本管理：
容量类型：软件和硬件容量、劳动力容量、产品容量。
规划策略：滞后策略（需求增加后再扩容）、领先策略（提前预估需求并扩容）、匹配策略（结合前两者）。
成本管理：使用开源软件、按需缩放基础设施、合理管理劳动力等。
测试的重要性：包括单元测试、功能测试、性能测试、混沌测试等，可确保系统质量、安全性，节省成本并提升客户满意度。
监控和可观测性工具：选择合适的工具（如 Prometheus、Grafana 等），实现对系统的实时监控和问题排查。
事件管理流程：建立完善的事件记录、分类、优先级划分和响应流程，使用先进工具实现自动化。
自动化减少工作负担：自动化手动重复任务，如自动告警、自动恢复等，提高效率并减少人为错误。
CAMS 模型：
文化（Culture）：建立共同的愿景、目标和标准，促进团队协作。
自动化（Automation）：消除重复工作，提高生产力。
度量（Measurement）：通过指标评估绩效，识别改进空间。
分享（Sharing）：促进团队成员间的知识共享和透明沟通。
反模式（Anti-patterns）
软件工程中的反模式：
spaghetti 代码（结构混乱的代码）
黄金锤子（过度依赖一种工具解决所有问题）
船锚（保留不必要的代码）
死代码（不再使用但未移除的代码）
上帝对象（一个对象负责过多功能）
复制粘贴编程（未经修改地复制代码）
SRE 中的常见反模式：
告警配置错误（如错误的告警对象、重复告警）
工单处理不当（如低优先级告警创建工单）
无自动化修复（手动处理可自动化的问题）
无变更管理流程（随意进行系统变更）
不切实际的期望（如追求 100% 可用性）
无无责事后分析（聚焦于指责而非解决问题）
反模式的类型及解决方法：涉及服务设计、监控可观测性、发布部署、变更管理等多个方面，需通过识别问题、制定标准和流程等方式解决。
成功的 SRE 实践案例
避免告警疲劳：在项目规划和实施阶段，合理配置告警，避免不必要的告警干扰。
提高可观测性：通过在代码中集成合适的指标，使用有效的监控工具，实现对系统的全面观测。
通过自动化减少人工工作：如自动化数据同步、自动故障转移等，提高效率。
实施根本原因分析（RCA）：对问题进行深入分析，从根源上解决，避免重复出现。
建立强大的事件管理：明确事件处理流程，确保及时响应和解决问题。
SRE 早期参与 SDLC：从规划阶段就融入 SRE，提供生产环境视角，优化系统设计。
SRE 最佳实践
软件设计和代码：遵循良好的设计原则，进行代码审查，编写测试用例，做好文档记录等。
DevOps 和 SRE 的核心价值：两者都强调协作、自动化、度量和反馈循环，共同致力于构建稳定可靠的系统。
业务与 SRE：SRE 通过度量系统性能、管理事件等方式，帮助业务实现目标，提高客户满意度。
SRE 工具包
事件管理工具：如 ServiceNow、PagerDuty 等。
变更管理工具：如 ServiceNow、Jira 等。
告警和监控工具：如 ELK、Prometheus 等。
发布和部署工具：如 Jenkins、Ansible 等。
混沌测试工具：如 Litmus、Chaos Monkey 等。
SRE 的日常工作和职业发展
技能要求：软件编码（Python、Java 等）、自动化 / 脚本编写、ITIL 知识、CI/CD 管道设计、云计算知识等。
职责：监控系统、排查问题、处理事件、进行变更管理、参与系统设计等。
职业路径：可从软件开发者、测试人员、DevOps 工程师等转型，需不断学习相关技能和工具。
SRE 的未来
随着云原生技术的发展，SRE 的作用将更加重要，聚焦于系统可靠性。
技术栈不断演进，SRE 需持续学习新工具和框架。
与 DevOps 的协作将更加紧密，可能形成统一团队。
人工智能将在 SRE 中发挥更多作用，如自动识别故障根源等。
注重多元化和包容性，促进团队协作和创新。Site Reliability Engineering Handbook