一、DevOps与SRE介绍及其示例
1.1、DevOps是什么？
DevOps（Development(开发) Operations(运维)）的组合词，是一套融合文化理念、流程方法与技术工具的实践体系，核心是打破开发与运维壁垒，通过协作、自动化与持续反馈实现软件快速、高质量交付；属于方法论指导或理念。
从应用上来讲【DevOps】是一系列的工具链（从构建、编码、测试、打包、发布、配置、监控等）的基本原则和实践的方法论或理念。
|--------|------------------------|---------------|---------------------------------------------------------------------------------------------------------------------------------------------|
| 序号 | DevOps | 核心 | 说明 |
| 1 | DevOps的核心 | 文化协作 | 打破部门隔阂墙，倡导开发、运维、测试等角色共享责任、跨职能协作，形成"共同对软件全生命周期负责"的文化，减少推诿扯皮、提升效率。 |
| 2 | DevOps的核心 | 自动化 | 以工具链自动化替代重复的手工操作，覆盖代码构建、测试、打包、部署、监控等环节，降低人为错误、缩短交付周期。 |
| 3 | DevOps的核心 | 持续反馈 | 通过CI/CD、实时监控与日志分析，在软件生命周期各个阶段获取快速反馈，及时发现并修复问题，保障交付质量。 |
| 4 | DevOps的核心 | 快速响应 | 基于敏捷与迭代思想，快速适配市场变化和用户需求，加速产品上市与迭代节奏。 |
| ||||
| 序号 | DevOps | 关键实践 | 说明 |
| 1 | DevOps关键实践 | 持续集成(CI) | 开发频繁提交代码到共享仓库，触发自动化构建、单元测试与代码质量检查，快速发现集成问题，避免"集成地狱"。常用到的工具有： 《1》【Git(版本控制)】； 《2》【Jenkins】； 《3》【GitLab CI/CD】； 《4》【GitHub Actions（自动化构建测试）】。 |
| 2 | DevOps关键实践 | 持续交付/ 部署(CD) | 持续交付：代码通过CI后，自动打包为可部署品，准备手动或自动部署到生产环境，保持"随时可发布"状态。 持续部署：在持续交付基础上，自动化完成从测试到生产环境的是不是，实现"代码提交即上线"，适用于成熟稳定的业务场景。 |
| 3 | DevOps关键实践 | 基础设施即代码 (IaC) | 以代码定义服务器、网络、配置等基础设施，通过版本控制与自动化部署(如：Terraform、Ansible)实现环境一致性与快速复制，避免"配置漂移"。 |
| 4 | DevOps关键实践 | 容器化与编排 | 用Docker封装应用与依赖，用K8s（Kubernetes）实现容器的自动部署、扩容与缩容、自愈，提升环境一致性与运维效率。 |
| 5 | DevOps关键实践 | 监控与可观测性 | 通过Prometheus（指标）、ELK Stack（日志）、Jaeger（链路追踪）等工具，实时监控系统性能、错误与用户行为，快速定位并解决问题。 |
| 6 | DevOps关键实践 | DevSecOps | 将安全嵌入DevOps全流程，通过自动化安全扫描(如：代码安全检查、容器镜像漏洞扫描等操作)实现"安全左移"，在开发早期就尽可能的规避风险。 |
| ||||
| 序号 | DevOps | 核心阶段 | 说明 |
| 1 | DevOps核心 阶段与工具 | 版本控制 | 工具：【Git】【SVN】。 主要用于代码存储、版本追踪、协作开发。 |
| 2 | DevOps核心 阶段与工具 | CI/CD | 工具：【Jenkins】【GitLab CI】【GitHub Actions】【JMeter（性能测试 + 接口测试）】。 自动化构建、测试、部署流水线 |
| 3 | DevOps核心 阶段与工具 | 容器化 | 工具【Docker、Podman、K8s】。 应用封装、环境隔离、编排管理。 |
| 4 | DevOps核心 阶段与工具 | 配置管理 | 工具：【Ansible】【Chef】【Puppet】。 自动化服务器配置与环境一致性。 |
| 5 | DevOps核心 阶段与工具 | 监控告警 | 工具：【Prometheus】【Grafana】【ELK】。 指标采集、可视化、日志分析、告警。 |
| 6 | DevOps核心 阶段与工具 | 安全扫描 | 工具：【SonarQube、Trivy】。 代码质量、安全漏洞、镜像漏洞检查。 |
[DevOps的核心]
1.2、SRE是什么？
SRE（Site Reliability Engineering 站点可靠性工程），是由Google在2003年提出来的；核心是用软件工程方法解决运维问题，保障大规模分布式系统的高可用、低延迟与可扩展，平衡稳定性与迭代速度。【简单的说：SRE是DevOps的具体可落地实践过程(即：告诉你具体的方法和实践流程)】。
|--------|--------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| SRE是融合软件开发与系统管理能力，以自动化、可观测性、数据驱动决策为核心，通过SLA、SLO、SLI量化可靠性，设定"错误预算"来平衡发布速度与稳定性，不追求100%可靠，而是计划故障并高效应对。 SRE团队主要承担的职责有【可用性改进】【延迟优化】【性能优化】【效率优化】【变更管理】【监控】【紧急事务处理】【容量规划与管理】八个内容；总结起来就是提升服务质量（即要制定一个针对用户的服务质量目标）。 |||
| 序号 | SRE的核心实践 | 说明 |
| 1 | SLI | SLI是指【服务质量/水平指标】(Service Level Indicator)；是用来描述一个服务有多好算达到好的标准；对业务来说是最重要的指标。通常从【延迟】【可用性】【吞吐率】【成功率】这些角度来制定SLI。 【SLI的五个关注点】 《1》要测量的指标是什么？ 《2》测量时的系统状态？ 《3》如何汇总处理测量的指标？ 《4》测量指标能否准确描述服务质量？ 《5》测量指标的可靠度(trustworthy)？ 比如：对于网络来说，一个常见的SLI是【请求正常响应的时间是多少(如：TCP请求延迟小于200ms；pod在1分钟内交付)。 |
| 2 | SLO | SLO是指【服务水平目标】(Service Level Object)；是用来衡量一个SLI指标在一段时间内达到好的标准的比例；是围绕SLI构建的目标。通常是一个百分比，并与一个时间范围挂钩（如：月度、季度、年度等）若脱离了时间的度量，SLO的意义就不大了（如：99%的pod在1分钟内交付。每月99.99%的TCP请求延迟(SLI)小于200ms）。 SLO通常用一连串的9来度量（如： 《1》90%【1个9的正常运行时间】(意味着10%的停机时间，也就是说在过去30天里停机了3天)。 《2》99%【2个9的正常运行时间】(意味着在过去30天中有1%=30*1%*24=7.2小时的停机时间)。 《3》99.9%【3个9的正常运行时间】(意味着在过去30天中有0.1%=30*0.1%*24*60=43.2分钟的停机时间)。 《4》99.95%【3.5个9的正常运行时间】(意味着在过去30天中有0.05%=30*0.05%*24*60=21.6分钟的停机时间)。 《5》99.99%【4个9的正常运行时间】(意味着在过去30天中有0.01%=30*0.01%*24*60=4.32分钟的停机时间))。 《6》99.999%【5个9的正常运行时间】(意味着在过去30天中有0.001%=30*0.001%*24*60*60=25.92秒的停机时间))。 ）。 |
| 3 | SLA | SLA是指【服务水平协议】(Service Level Agreement)；是用于SLO定义的目标比例没有完成时，服务方要赔多少钱。通常来说，SLA的协议会具体白纸黑字形成有法律效力的合同，常用于服务供应商和外部客户之间(如：阿里云和阿里云的使用者)。 区别SLO与SLA的一个简单方法是问"若SLO没有到达时，有什么后果？"若没有定义明确的后果，那么我们就肯定是在讨论一个SLO，而不是SLA。 |
| 4 | 错误预算 | 允许的停机/故障阈值，预算内可快速迭代，超预算则优先恢复稳定性。 |
| 5 | 自动化 | 将部署、扩容缩容、监控、故障恢复等运维工作代码化，减少人工操作。 |
| 6 | 可观测性 | 构建日志、指标、链路追踪体系，快速定位问题。 |
| 7 | 混沌工程 | 主动注入故障（如：关闭实例），验证系统容错能力，提前发现隐患。 |
| 8 | 事后复盘 | 故障后无指责复盘，沉淀改进措施，避免重复发生。 |
[SRE的核心实践]
1.3、应用实例
假设我的博客网站【coffeemilk.blog.csdn.net】设置的监控指标是正常请求响应数，从2025年9月1日到2025年12月31日，请求数据如下：
《1》9月，总请求数目16000，错误响应100；
《2》10月，总请求数目20000，错误响应160；并因为故障宕机30分钟；
《3》11月，总请求数目30000，错误响应160；
《4》12月，总请求数目36000，错误响应200；
则计算出来的SLI、SLO、SLA如下：
**SLI：**1-(100+160+160+200)/(16000+20000+30000+36000)=99.39%。
**SLO：**1-(30/(30+31+30+31)*24*60)=99.983%。
**SLA：**假如是给第三方做的网站，并签订了协议SLO达不到99.99%，就赔偿多少钱，那么根据上面计算出的这个SLO，再根据签订的SLA协议，算出具体的补偿金额，则是SLA。
二、监控方法论
目前业界比较流行的监控方法论有【Google的黄金指标】【RED方法】【USE方法】。
2.1、Google的黄金指标
|--------|-----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Google的四个黄金指标着眼于【服务监控】，这四个指标是【延迟】【流量】【错误】【饱和度】。 |||
| 序号 | Google的黄金指标 | 说明 |
| 1 | 延迟 | 表示服务请求所花费的时间。 比如：用户获取商品列表页面调用的某个接口，花费 30 毫秒。注意成功请求的延迟和失败请求的延迟的区别。 延迟较高通常不是好现象，这表示请求的响应时间较长，多数情况下这也意味着系统性能不佳，用户体验不好。 |
| 2 | 流量 | 表示系统承载的用户或交易的量级。 流量对于不同类型的系统而言可能代表不同的含义，比如： 《1》对基于Web的HTTP应用，此类指标可能表现为TPS或者QPS。 《2》RPC 服务的话就是每秒 RPC Call 的数量。 《3》如果是数据库，可能用数据库系统的事务量来作为流量指标。 流量指标通常可用来展现当前系统的负载状态和不同时段的负载情况。 |
| 3 | 错误 | 表示当前系统发生错误的评价维度，错误一般可以分成显式错误和隐式错误。 比如： 《1》HTTP请求返回了 500 错误码，说明这个请求是失败的，这就属于显式错误。 《2》而某些情况下，HTTP尽管返回200，但返回的内容不符合预期，那么这种就是隐式错误，也认为是请求失败。 此类指标可以用来衡量系统的运行质量。 |
| 4 | 饱和度 | 表示当前资源使用的饱和情况。通常情况下，资源达到饱和状态，服务的性能就会下降。 比如：磁盘的写性能是100M/s，如果此时I/O饱和度已经很高，那么并发场景下必然有些I/O操作会处于阻塞状态。此外，CPU 使用率也可以作为饱和度指标。 这类指标可以用来衡量系统资源使用率。 |
[Google的黄金指标]
2.2、RED方法
|--------|-----------------------|-----------------|
| RED方法是由在Google的4类黄金指标基础之上提出的，它重点关注【应用请求相关的3个关键指标】，希望由此涵盖Web服务（也是占比最高的服务类型）的相关问题。这3个关键指标详细介绍如下： |||
| 序号 | RED方法关注指标 | 说明 |
| 1 | （Request）Rate | 请求速率，每秒请求数。 |
| 2 | （Request）Errors | 错误，每秒错误请求数。 |
| 3 | （Request）Duration | 延迟，每个请求的延迟分布情况。 |
| 三个英文单词取首字母组成 RED 方法，可以简单看做是 Google 四个黄金指标的简化版。 RED方法是以请求为中心，聚焦用户在使用Web服务时所应关注的重点，通过这三项指标，我们就能监测到 通常情况下影响客户使用体验的关键信息。 RED方法，主要适用于关注与请求相关的指标数据，适合云原生应用及微服务应用架构下的应用。 |||
[RED方法]
2.3、USE方法
|--------|--------------|------------------------------------------------------------------------------------------------------------------------------------------|
| USE 是【使用率（Utilization）】【饱和度（Saturation）】【错误（Error）】的缩写，主要用于分析资源问题。 这里的资源主要是指传统意义上的物理服务器组件（如：CPU、硬盘、内存等），但现在很多人已经扩展了资源的范围，把一些软件资源也包含在内。如下是我们对使用率、饱和度、错误的详细介绍： |||
| 序号 | USE方法的内容 | 说明 |
| 1 | 资源使用率 | （如：CPU、内存、网络、磁盘I/O等）都属于资源。 如果某项资源使用率持续较高，那么通常说明其存在一定的性能瓶颈。 |
| 2 | 饱和度 | 表示当前资源使用的饱和情况。通常情况下，资源达到饱和状态，服务的性能就会下降。 比如：磁盘的写性能是100M/s，如果此时I/O饱和度已经很高，那么并发场景下必然有些I/O操作会处于阻塞状态。此外，CPU 使用率也可以作为饱和度指标。 这类指标可以用来衡量系统资源使用率。 |
| 3 | 错误 | 与错误相关的指标统计信息。 （如：调用失败次数、或通过 ifconfig 看到的 errors、dropped 包量）。还有很多错误是以系统错误日志的方式暴露的，没法直接拿到某个统计指标，此时可以进行日志关键字监控。 |
[USE方法]
三、需要监控哪些指标
3.1、需要监控哪些指标？
要监控的指标有很多，根据业务架构与应用逻辑，将监控做了一个分类，如下图是一个完整的监控系统要监控的几个分类：
|--------|-----------|------------------------------------------------------------------------------------------------------------------|
| 序号 | 监控的分类 | 说明 |
| 1 | 业务监控 | 这类监控指标非常重要，它代表着业务系统是否正常，同时也是管理层非常关注的，因为业务系统代表企业营收或者直接与客户项目相关。 核心业务指标异常，一定是故障，业务指标异常代表着最终用户体验受损，或者造成公司直接资产损失。 |
| 2 | 应用监控 | 是指【对应用程序的监控】谷歌的四个黄金指标、RED方法主要就是针对应用监控的。主要监控应用的性能指标。 |
| 3 | 组件监控 | 常见的【web】【数据库】【中间件】【容器】等系统统称为组件，因此组件监控涉及十分广泛。 |
| 4 | 资源监控 | 资源监控【主要针对硬件设备和网络】： 《1》硬件设备分为：服务器、网络设备。 《2》网络监控分为：连通性监控、质量监控、流量监控。 |
[需要监控哪些指标？]
3.2、监控与可观测性
|--------|---------------|--------------------------------------------------------------------------------------------------------------------------------|
| 监控的本质就是收集、分析和使用信息来观察一段时间内监控对象的运行进度，并且进行相应的决策管理的过程，监控侧重于观察特定指标。 |||
| 随着云原生时代的到来，我们对监控提出了更多的要求： 《1》通过监控了解数据趋势：要知道系统在未来的某个时刻可能出现问题、预知问题。 《2》通过监控了解系统的资源情况，为服务扩容缩容提供数据支撑。 《3》通过监控来给系统把脉，感知到哪里需要优化（如：一些中间件参数的调优）。 《4》通过监控来洞察业务，提供业务决策的数据依据，及时感知业务异常。 要实现这些功能，就需要【可观测性】可观测性是云原生时代必须具备的能力。 |||
| 可观测性是指在软件系统中，通过度量、监控和分析系统的各个组件行为，以便于了解系统的状态、性能和问题的能力。 可观测性的重要性在于它可以帮助开发人员及时发现问题，快速定位问题，并在问题发生时采取相应的措施，以减少系统的故障率和维护成本。此外，可观测性还有助于开发人员了解系统的实际运行情况，以便于对系统进行优化和升级。 |||
| 序号 | 可观测性的重要组件 | 说明 |
| 1 | 聚合指标 | 指的是【将多个指标数据聚合到一个单独的指标中以简化数据】。 如：将多个节点的CPU利用率聚合为一个单一的平均值。聚合指标允许我们更轻松地理解系统的整体性能。同时聚合指标还可以帮助我们快速识别潜在的问题并了解系统中哪些部分可能需要更多的资源。 |
| 2 | 事件日志 | 指的是【一组事件的记录；这些事件可以提供系统的历史记录和状态变化】。 如：错误、警告和信息性事件都可以记录在事件日志中。事件日志对于诊断和调试问题非常有用，因为它们提供了对系统活动的详细记录。还可以发现系统中无法预知的行为。 |
| 3 | 链路追踪 | 指的是【一种用于跟踪分布式系统中请求的过程，以了解请求的路径以及请求在每个服务器中花费的时间】。 这有助于识别分布式系统中的性能瓶颈和瓶颈来源。链路追踪还可以帮助我们诊断分布式系统中出现的错误和问题，因为它提供了有关请求在哪个组件中失败的信息。 |
| |||
| 【可观性】的作用： 《1》可清晰的了解性能瓶颈有哪些？ 《2》请求需要接受的服务有哪些？ 《3》请求执行过程与系统行为之间的差异性。 《4》请求失败的原因。 《5》每一个微服务将如何处理请求？ |||
[监控与可观测性]
3.3、分布式系统是什么？
|--------|-----------------------------|------------------------------------------------------------------------------------------------------------|
| **【分布式系统】是由多台通过网络连接的自治计算机节点组成，通过协同工作共同完成任务，对外呈现为统一整体的系统，核心价值是【解决单机在性能、可扩展性、可靠性上的瓶颈】**广泛应用于互联网、金融、云计算等领域。 |||
| 序号 | 分布式系统核心特征 | 说明 |
| 1 | 多节点自治 | 每个节点有独立计算、存储能力；可自主运行、通过网络消息传递进行协作。 |
| 2 | 资源共享 | 共享数据、存储、外设等资源，提供利用率，对外提供统一访问接口。 |
| 3 | 无全局时钟 | 节点本地时钟无法精确同步，难以确定跨节点事件绝对先后顺序，需要靠逻辑时钟等机制协调。 |
| 4 | 故障独立性 | 节点可能独立宕机、网络分区、系统需具备容错能力（如：冗余备份、故障转移）。 |
| 5 | 透明性 | 用户/应用无需感知内部节点分布、故障、迁移等细节，由系统屏蔽底层复杂度。 |
| |||
| 序号 | 分布式系统关键挑战 | 说明 |
| 1 | 一致性与可用性权衡 | 分布式系统一致性(Consistency)、可用性(Availability)、分区容错性(Partition Tolerance)三者不可兼得，需要根据场景取舍（如：金融选择CP、电商选择AP）。 |
| 2 | 分布式事务 | 跨节点事务需要保证ACID（可使用2PC、3PC、TCC、SAGA、本地消息表方案）需要平衡一致性与性能。 |
| 3 | 网络不可靠 | 存在延迟、丢包、乱序、分区等问题；需要通过超时重试、幂等设计、熔断降级操作应对。 |
| 4 | 容错与故障处理 | 需检测节点、网络故障，实现自动切换(如：主从切换)、数据恢复等操作，避免单点失效。 |
| 5 | 性能与开销 | 节点通信、数据同步带来额外开销，需通过分片、缓存、异步通信优化吞吐量与延迟。 |
| |||
| 序号 | 分布式系统主流架构 | 说明 |
| 1 | 主从架构 (Master-Slave) | 主节点负责决策、任务分配与数据写入；从节点执行任务、数据备份与读请求。 优势：架构清晰、易于管理。 劣势：主节点可能成为瓶颈或单点故障。 |
| 2 | 对等架构 (P2P) | 所有节点地位平等，无中心节点，共同承担计算、存储、路由（如区块链、BitTorrent）。 优势：高容错、去中心化。 劣势：一致性协调复杂、性能易受节点数量影响。 |
| 3 | 微服务架构 | 按业务功能拆分为独立服务，各服务独立部署、扩展、迭代，通过API/消息队列通信（如：Netfilx、阿里电商后端）。 优势：技术异构、灵活扩展、故障隔离。 劣势：分布式复杂度高、需治理服务注册、熔断、链路追踪等。 |
| 4 | 分层架构 | 按职责分层（如：接入层、业务层、数据层），层间松耦合、便于维护与扩展（如：Web应用的三层架构：表现层、业务逻辑层、数据访问层）。 |
| |||
| 序号 | 分布式系统典型技术 | 说明 |
| 1 | 通信与协调 | 远程调用：RPC(GRPC)、HTTP/REST； 消息队列：Kafka、RabbitMQ(解耦异步通信)； 协调服务：ZooKeeper、ETCD（分布式锁、配置管理、节点发现）。 |
| 2 | 数据存储与一致性 | 分布式数据库：TiDB、Spanner（分布式事务、水平扩展）。 NoSQL集群：MongoDB分片、Redis Cluster（高吞吐、高可用）。 一致性协议：Paxos、Raft（解决分布式共识）。 |
| 3 | 容错与高可用 | 负载均衡：Nginx、HAProxy（分流请求、避免单点过载）。 服务网格：lstio（流量治理、熔断、重试）。 容器编排：Kubernetes（自动部署、扩容缩容、故障自愈）。 |
| |||
| 序号 | 分布式系统应用场景 | 说明 |
| 1 | 互联网服务 | 电商：京东、淘宝、拼多多等； 社交：微信、Facebook等； 视频：B站、抖音、快手、Netflix等； 支撑高并发、海量数据处理与全球访问。 |
| 2 | 金融科技 | 银行核心系统； 支付平台（支付宝、PayPal）； 需要高可用、强一致性与灾备能力。 |
| 3 | 云计算与大数据 | 阿里云、华为云、AWS等云平台； Hadoop、Spark等大数据框架，通过分布式计算处理PB级数据。 |
| 4 | 分布式存储 | 分布式文件系统（HDFS）； 对象存储（S3、OSS）; 解决海量数据存储于高吞吐访问。 |
| |||
| 总结：分布式系统通过【分而治之】的思想，将复杂任务拆解到多个节点并行处理，同时通过冗余与容错机制保障可靠性，是支撑现代大型系统的核心技术；需在一致性、可用性、性能间平衡，结合业务场景选择合适的架构与技术栈。 |||
[分布式系统是什么？]