对于SRE一词，想必大家已经不陌生了，满世界都在讲SRE，但是SRE到底是个什么角色？负责哪些工作呢？今天来给大家解惑一下。
SRE最早是由Google提出的概念，其大概的意思就是：以标准化、自动化、可扩展驱动维护，用软件开发解决运维难题。这个岗位面世的时候，其根本要解决的问题就是打破传统研发人员快速迭代而引发的业务不稳定性，用以保证业务维护侧重的服务质量以及稳定性之间的平衡。
不同公司的SRE定位是不同的，可能某些公司的运维岗位也是SRE，因此，不能以偏概全，国内的SRE基本是以岗位来区分的，比如，有负责网络的SRE，有负责DBA的SRE，有专门负责业务的SRE，还有什么安全SRE等等。就谷歌所提到的SRE的理解来讲，基本都是以服务质量稳定为基线的维护工程师，只是对于SRE的要求是苛刻的，下面是我的个人理解：
第一：技能全面，比如网络、操作系统、监控、CICD、研发等，对于研发能力，可能不需要你精通，但是你需要具备可以使用一门语言完成某个功能的设计、开发与迭代。
第二：打破传统运维思想壁垒，以产品角度思维贯穿整个业务架构服务质量为前提的沟通协调能力。
第三：始终以软件工程解决问题为方向的规划之路。
第四：很强的Trouble Shooting与思考、抽象能力，这三个能力在SRE工作当中是至关重要的，是时间与实践积累的最终成果。
综上所述，国内现在的SRE，大致可以分成俩个层级，PasS-SRE和业务SRE，前者主要是维护平台基建服务质量为主的SRE，后者主要是维护业务服务质量稳定性为主的SRE，业务SRE比较像业务运维。
上面的定义只适合大厂，对于还没有传播SRE文化，SRE的岗位是比较模糊的，其定位可能就是一个运维开发工程师，要解决的问题也是全面的、多元化的。在推广SRE文化以及建设SRE工作守则的时候，需要对当前的业务架构、技术架构有全面的了解，并合理的对基建做好设计、规划、调整，这样，SRE文化才会被更好的推行下去。
下面的都是由网上整理而来，因为SRE的工作范围是由谷歌最早提出以及实践过的，所以，他的工作范围就如下所示，万变不离其宗，在这里其实有一个很核心的关键点，那就是基建的稳定性决定了SRE的工作效率，因此，我们在建设SRE文化与工作职责的时候，也要把基建的一些因素考虑进去。
以下为《SRE谷歌运维解密》一书当中已经提到了关键点：
可观测性系统
故障响应
测试与部署
容量规划
自动化软件开发
用户支持
Oncall
制定可交付的SLI/SLO/SLA
故障复盘
可观测性系统
在任何有一定规模的企业内部，一旦推行起来整个SRE的运维模式，那么对于可观测性系统的建设将变得尤为重要，而在整个可观测性系统中，通常我们会分为如下三个方面：
指标监控：即各种指标监控，比如基础资源指标，服务性能指标，业务的调用指标。
日志：各种设备以及服务的运行日志监控。
调用链：业务层面的调用链分析，通常在分布式系统中帮助运营、开发以及运维人员快速识别整体调用的瓶颈点
一整套的可观测系统，它能确保你洞察系统，跟踪系统的健康状态、可用性以及系统内部发生的事情。
对于整个可观测系统的建设，需要注意如下两点：
确定质量标准是什么，并确保系统持续逼近或保持在质量标准极限范围内
系统地关注这项工作—而不应该只是随机地查看一下系统
在整个企业级可观测系统中，我认为至少应该包括如下几个特征：
完备指标采集：可以对接企业内大部分的设备与技术栈相应的监控指标；同时，支持常见设备的监控指标体系，可以快速接入监控设备和指标，避免所有设备监控都是从头构建；对于日志数据的采集支持
海量设备支持：企业IT系统数量和规模越来越大，因此监控系统比以前需要监控海量设备监控。
监控数据存储和分析：监控数据是运维分析、运维自动化和智能化的基础，因此海量监控数据存储以及基于监控数据的可视化分析是一个监控系统的基本能力。
可观测系统是整个运维体系的基础，它需要提供整个运维体系的数据化支持。
因此，一个企业级的可观测性系统应该是平台化的。一方面可以通过配置或者开发实现更多 运维指标的接入；另一方面，亦可对接更多的专业运维工具，整合并打通多元的运维数据，为更多运维场景提供数据服务。从整体上，可观测性系统为企业运维提供了一个数据基础，让我们对事故响应以及容量预测等方面更多使用数据而非凭借以往经验和拍脑袋做出决策。
故障响应
如果有什么东西出了故障，该如何提醒大家并做出回应？工具可以帮助解决这个问题，因为它可以定义提醒人类的规则。
故障响应是建立在使用可观测性系统构建的数据之上，并借助反馈循环，来帮助我们加强对服务的监控。
故障响应通常包含如下几个动作:
关注: 不论是主动发现瓶颈点或异常点，还是通过可观测性系统被动暴露瓶颈点，我们都应该进行主动关注
交流: 及时将观察到风险点通知到相关方，并告知影响面以及相关的补救措施
恢复: 三方达成一致后，根据补救措施进行修复相关风险点和异常点
需要注意的是，如果在前期整个可观测性系统能够做好，通常故障应当始于一个简单的告警信息或一个报障电话，因此，通常情况下，可观测系统做的足够好仅能起到追溯和排查的作用，但是无法起到及时发现的作用，此时就需要依赖于各个观测数据进行计算和评估告警，以及时将相关的告警通知到相关人，以暴露风险点。
告警只是整个故障响应的第一个环节，解决的是故障如何发现的问题，而大多数的故障响应工作都是关于定义处理策略和提供培训的，以便人们在收到警报时知道该怎么做，通常这部分更多的是过去历史经验和运维经历的总结和沉淀，包括经验的一些抽象和工具化沉淀，以保证故障响应的效率和普遍化(即不依赖人为经验)。
而对于整个告警系统来说，需要确保的是告警的有效性，否则，整个报警系统很有可能沦落为垃圾数据制造机，告警有效性意味着需要满足如下两个需求：
告警及时性: 系统有问题需要及时通过告警信息告知运维处理人员及时处理告警;
告警准确性: 只要有告警信息系统必然出现问题(对于很多企业可能存在大量的无用告警，比如磁盘问题，mem等相关问题，当然这里涉及到了自动化、业务形态、告警阈值的问题);
在整个运维过程中，我们经常会发现有大量的无关紧要的告警信息，让运维人员的注意力迷失在告警海洋当中，而通常非运维领域的领导会关注整个告警的响应程度，因此，抑制和消除无效的告警，让运维人员不被告警风暴所吞没，也是告警管理中重点建设的内容。
通常情况，在我们的各个可观测系统构建完成后，可以通过整合到监控平台中的各种监控数据，应用趋势预测、短周期检测、间歇性恢复、基线判断、重复压缩等算法和手段实现告警压缩收敛，强化告警的有效性。
同时，面向一线的运维人员，我们需要根据同一个系统或设备的多个监控指标进行综合性建模和分析，汇总成一个健康度的分值，给予一线运维人员系统的基于健康度的系统分层评价体系，真实、直观反映系统运行状态，实现问题快速定位。
比如，通过基础资源的多个指标进行综合加权计算来整体评估该资源的利用率；通过一个应用关联的全部资源的资源利用率以及应用的运维架构整体建模分析来计算一个分值来整体评估该应用的健康程度。
这个过程如果做得成熟一些，可以根据内部已有的解决方案和告警进行闭环打通，一个简单的场景就是，当磁盘满时，告警会首先触发一次标准化的磁盘巡检，并进行相关的可丢弃数据的删除，如果依然无法解决该报警，下次可直接关联到一线运维进行人工干预，之后进行标准化经验总结。
测试与部署
测试与部署对于整个稳定性和可靠性的主要出于一个预防的作用，预防是指尝试限制发生的事故数量，并确保在发布新代码时基础架构和服务能够保持稳定。
作为一个长期从事运维工作的人，可能内心中最为恐惧的莫过于新应用版本发布。因为除了硬件和网络设备损坏这个属于天灾级别的概率事件外，新应用版本发布的第二天通常是停机与事故的高危期。所以，对于一些量级较大的产品通常会在节假日以及重要活动前夕进行封网操作，以避免新版本上线而导致的业务bug出现。
而测试是在成本和风险之间找到适当的平衡活动。如果过于冒险，你们可能就会疲于应付系统失败；反过来说，如果你太保守，你就不能足够快地发布新东西，让企业在市场上生存下来。
在错误预算比较多（即在一段时间内故障导致系统停机时长较少）的情况下，可以适当减少测试资源并放宽系统上线的测试和条件，让业务可以有更多的功能上线，以保持业务的敏态；在错误预算比较少（即在一段时间内故障导致系统停机时长较多）的情况下，则要增加测试资源并收紧系统上线的测试，让系统的潜在风险得到更多有效的释放，避免系统停机保持系统的稳态。这种敏态与稳态之间的平衡，需要整个运维与开发团队来共同承担。
除了测试外，应用发布也是一项运维团队通常要承担的责任。SRE其中的一个原则是将一切可以重复性劳动代码化和工具化；此外，应用发布的复杂程度往往与系统的复杂程度成正比。因此在应用系统上规模企业，往往已经着手基于自动化框架构建自动化的应用发布过程。
通过自动化发布工具，我们可以构建流水线实现部署的过程中所有的操作（如编译打包、测试发布、生产准备、告警屏蔽、服务停止、数据库执行、应用部署、服务重启等）全部自动化。
容量规划
容量规划是关于预测未来和发现系统极限的，容量规划也是为了确保系统可以随着时间的推移得到完善和增强。
规划的主要目标是管理风险和期望，对于容量规划，涉及到将容量扩展到整个业务；所关注的期望是人们在看到业务增长时期望服务如何响应。风险是在额外的基础设施上花费时间和金钱来处理这个问题。
容量规划首先是对未来预测性的分析与判断，其预测的基础正是海量的运维数据。因此，容量规划除了有相应的架构和规划团队外，一个全面的运维数据中心是实现系统容量规划的必须设施。
容量趋势预警和分析将综合地从各种运维监控、流程管理等数据源中收集、整理、清洗并结构化地存储各种运维数据，将这些来自于各种工具的运维数据打通融合并且构建各种数据主题。
应用这些数据主题的数据用于帮助运维人员对问题进行评估，包括：
当前的容量是多少
何时达到容量极限
应该如何更改容量
执行容量规划
运维平台除了可以提供必要的数据支持外，还需要提供必要的数据可视化支持能力。运维数据可视化提供了一些必要的能力保障运维人员可以更好地利用其中的运维数据评估容量。
首先，运维平台需要有极强的数据检索能力。运维平台存储着海量的运维数据，运维人员为了尝试建立和验证一个探索性场景的时候，往往多次反复检索和查询特定数据。如果运维数据分析平台的数据查询很慢或者查询角度很少的情况下，运维人员建立场景的时间就会拖得很长甚至进行不下去。因此，运维人员可通过平台可以实现关键字、统计函数、单条件、多条件、模糊多维度查找功能，以及实现海量数据秒级查询，才能更有效帮助运维人员更便捷分析数据。
其二，平台需要强大的数据可视化能力。人们常说“千言万语不及一图”，运维人员经常会通过各系统的运维数据进行统计分析并生成各类实时报表，对各类运维数据（如应用日志、交易日志、系统日志）进行多维度、多角度深入分析、预测及可视化展现，将他们分析的预测结果和经验向他人表达和推广。
自动化工具开发
SRE不仅涉及运营，还涉及软件开发，当然这部分指的是和运维以及SRE领域相关的工具和平台开发。在Google的SRE体系中，SRE工程师将花费大约一半的时间来开发新的工具和服务，这些工具的一部分用于自动化一些手动任务，而其他部分用于来不断填补和修复整个SRE体系内部的其他系统。
通过编写代码把自己和其他人从重复的工作中解放出来，如果我们不需要人类来完成任务，那么就编写代码，这样人类就不需要参与其中了。
SRE从内心上鄙视重复性的工作，将从原有的人工加被动响应，转变为更高效、更为自动化的运维体系。
自动化运维框架：
自动化运维工具的优势和必要性:
提高效率: 由程序自动化操作，有效地降低运维人力资源的投入，也让运维人员的精力得以释放并投向更为重要的领域。
-
操作的标准化: 将原来许多复杂、易错的手工操作实现统一运维操作入口，实现运维操作白屏化，提升运维操作的可管理性；
同时，减少由于运维人员情绪带来手工误操作，避免“从删库到跑路”这样的悲剧的发生。
运维经验能力的传承: 运维自动化工具将原来许多运维团队积累的经验以代码方式总结为各种运维工具，实现自动化和白屏化的运维操作。运维团队的后来者，可以有效地继承、重复使用并优化它们。这种代码化的工作传承，将个人能力转变为团队能力，并减少人员流动带来对工作的影响。
构建自动化运维体系就必须以运维场景为基础，这些运维场景是在本企业内反复迭代和打造，是企业中最常用的运维场景。
比如常见的运维场景：软件安装部署、应用发布交付、资产管理、告警自动处理、故障分析、资源申请、自动化巡检等等。因此，整个自动化运维体系建设时也应支持多种不同类型的自动化作业配置能力，通过简单的脚本开发、场景配置和可视化定制流程实现更多运维场景的实现。
用户支持
用户体验这一层要说的是，作为SRE来讲，从用户的角度来保证业务的稳定性和可用性才是最终目标。这个才传统意义上的运维人员是不会关注这一点的，因为大家通常只会考虑到我底层运维的系统或底层资源是否稳定，但实际上整个业务的稳定才是SRE需要关心的问题，而业务的稳定性和可用性通常需要站在用户的角度来模拟和衡量整体的可用性和可靠性。
在前面提到的所有SRE相关的工作范畴，无论是监控、事故响应、回顾、测试与发布、容量规划以及构建自动化工具，无非都是为了提供更好的系统用户业务体验而服务的。因此，我们在运维的过程中无不需要注意关注系统的用户体验。
而在实际运维工作中，我们往往可以通过应用日志、监控数据、业务探测等业务相关的用户体验信息。在运维数据平台中，通过这些用户体验监测数据之间的关联和串联，重现用户的最终业务调用链路以及各应用环节对性能数据的关系。最终形成从业务用户体验数据入手，逐步实现系统运行状态数据、设备运行状态数据链路的打通，让运维体系实现以最终用户体验为中心的目标。
这些用户体验的信息，对于运维团队掌握客户整体的用户体验情况、系统可用性的监测以及系统针对性的优化提供着无可替代的作用。
其实，SRE运维体系更为强调以用户的体验为核心，以自动化和运维数据为手段，实现应用业务连续性保障，从这个点出发，我们会发现和以往的传统运维还是有很大的区别的，我们不再仅仅是单纯的安装和部署工程师，我们需要通过一系列的技术手段来不断保障上层业务的稳定性和可靠性。
Oncall
Oncall 简单来说就是要保证线上服务的正常运行。典型的工作流程是：收到告警，检查告警发出的原因，确认线上服务是否有问题，定位到问题，解决问题。
收到告警并不总意味着真正的问题，也有可能告警设置的不合理。告警和监控面板并不是一个静态的配置，它应该是每天都在变化的，时刻在调整的。如果发现没有标志真正线上问题的告警发了出来，就应该修改告警规则。如果发现当前的监控无法快速定位问题，应该调整监控面板，添加或者删除监控指标。业务在发展，请求量在变化，某些阈值也需要不断地调整。
定位问题没有一概而论的方法了，需要根据看到的实时监控数据，结合自己的经验，然后做推测，然后使用工具验证自己的推测，然后确定问题的根因。
但是解决问题是可以有方法论的，叫做 SOP，标准操作流程。即：如果出现了这种现象，那么执行那种操作，就可以恢复业务。SOP 文档应该提前制定，并且验证其有效性。
需要注意的是上述定位问题、解决问题并没有顺序关系。一个经常犯的错误是，在出现故障的时候，花了很长时间定位到故障的根因，然后再修复。这样花的时间一般会比较长。正确的做法是先根据现象看现有的 SOP 能否恢复业务。比如说当前错误只发生在某一个节点上，那么就直接下线这个节点，具体的原因后面再排查。恢复当前的故障永远是第一要务。但是恢复操作也要经过测试，比如猜测可以通过重启解决问题的话，可以先重启一台做测试，而不是一次性将所有服务重启。大部分情况是需要临场分析的，是一个紧张又刺激的过程。
故障到底多久恢复算好？出现多少故障是可以容忍的？怎么检测服务的稳定性到底如何？我们使用 SLI/SLO 来衡量这些问题。
制定可交付的SLI/SLO/SLA
SLO 和 SLA 是大家常见的两个名词：服务等级目标和服务等级协议。
云计算时代，各大云服务提供商都发布有自己服务的 SLA 条款，比如 Amazon 的 EC2 和 S3 服务都有相应的 SLA 条款。这些大公司的 SLA 看上去如此的高大上，一般是怎么定义出来的呢？
说 SLA 不能不提 SLO，这个是众所周知的，但是还有一个概念知道的人就不多了，那就是 SLI（Service Level Indicator），定义一个可执行的 SLA，好的 SLO 和 SLI 是必不可少的。
另外必须要提到的是，SLI/SLO/SLA主要是为服务指定的，如果没有服务作为依托关系，那这些概念也就失去了原有的意义。
下面是一个 SLA 在制定过程中需要考虑到的一些问题：
例如：设计一个可用率的时候，并不是说达到了”4个9“为标准就足够了，因为我们需要考虑如下问题：
如何定义这个可用率？比如我们以可用率 > 99.9% 为目标，有一个服务部署了 5 个 区域, 那么有一个 区域 挂了，其余的 区域 是可用的，那么可用率被破坏了吗？这个可用率是每一个 区域 的还是所有的 区域 一起计算的？
可用率计算的最小单位是什么？如果 1min 内有 50s 没有达到可用率，那么这一分钟算是 down 还是 up？
可用率的周期是怎么计算的？按照一个月还是一个周？一个周是最近的 7 天还是计算一个自然周？
如何设计与规划 SLI 和 SLO 监控？
如果错误预算即将用完，有什么处理措施？比如减少发布以及配置变更？
Service
什么是服务？
简单说就是一切提供给客户的有用功能都可以称为服务。
服务一般会由服务提供者提供，提供这个有用功能的组织被称为服务提供者，通常是人加上软件，软件的运行需要计算资源，为了能对外提供有用的功能软件可能会有对其他软件系统的依赖。
客户是使用服务提供者提供的服务的人或公司。
SLI
SLI 是经过仔细定义的测量指标，它根据不同系统特点确定要测量什么，SLI 的确定是一个非常复杂的过程。
SLI 的确定需要回答以下几个问题：
要测量的指标是什么？
测量时的系统状态？
如何汇总处理测量的指标？
测量指标能否准确描述服务质量？
测量指标的可靠度 (trustworthy)？
-
常见的测量指标有以下几个方面：
-
性能
响应时间 (latency)
吞吐量 (throughput)
请求量 (qps)
实效性 (freshness)
-
可用性
运行时间 (uptime)
故障时间 / 频率
可靠性
-
质量
准确性 (accuracy)
正确性 (correctness)
完整性 (completeness)
覆盖率 (coverage)
相关性 (relevance)
-
内部指标
队列长度 (queue length)
内存占用 (RAM usage)
-
因素人
响应时间 (time to response)
修复时间 (time to fix)
修复率 (fraction fixed)
下面通过一个例子来说明一下：hotmail 的 downtime SLI
错误率 (error rate) 计算的是服务返回给用户的 error 总数
如果错误率大于 X%，就算是服务 down 了，开始计算 downtime
如果错误率持续超过 Y 分钟，这个 downtime 就会被计算在内
间断性的小于 Y 分钟的 downtime 是不被计算在内的。
-
测量时的系统状态，在什么情况下测量会严重影响测量的结果
测量异常 (badly-formed) 请求，还是失败 (fail) 请求还是超时请求 (timeout)
测量时的系统负载（是否最大负载）
测量的发起位置，服务器端还是客户端
测量的时间窗口（仅工作日、还是一周 7 天、是否包括计划内的维护时间段）
-
如何汇总处理测量的指标？
计算的时间区间是什么：是一个滚动时间窗口，还是简单的按照月份计算
使用平均值还是百分位值，比如：某服务 X 的 ticket 处理响应时间 SLI 的
测量指标：统计所有成功解决请求，从用户创建 ticket 到问题被解决的时间
怎么测量：用 ticket 自带的时间戳，统计所有用户创建的 ticket
什么情况下的测量：只包括工作时间，不包含法定假日
用于 SLI 的数据指标：以一周为滑动窗口，95% 分位的解决时间
-
测量指标能否准确描述服务质量？
性能：时效性、是否有偏差
准确性：精度、覆盖率、数据稳定性
完整性：数据丢失、无效数据、异常 (outlier) 数据
-
测量指标的可靠度
是否服务提供者和客户都认可
是否可被独立验证，比如三方机构
客户端还是服务器端测量，取样间隔
错误请求是如何计算的
SLO
SLO (服务等级目标) 指定了服务所提供功能的一种期望状态。SLO 里面应该包含什么呢？所有能够描述服务应该提供什么样功能的信息。
服务提供者用它来指定系统的预期状态；开发人员编写代码来实现；客户依赖于 SLO 进行商业判断。SLO 里没有提到，如果目标达不到会怎么样。
SLO 是用 SLI 来描述的，一般描述为： 比如以下 SLO：
每分钟平均 qps > 100k/s
99% 访问延迟 < 500ms
99% 每分钟带宽 > 200MB/s
设置 SLO 时的几个最佳实践：
指定计算的时间窗口
使用一致的时间窗口 (XX 小时滚动窗口、季度滚动窗口)
要有一个免责条款，比如：95% 的时间要能够达到 SLO
如果 Service 是第一次设置 SLO，可以遵循以下原则
-
测量系统当前状态
设置预期 (expectations)，而不是保证 (guarantees)
初期的 SLO 不适合作为服务质量的强化工具
-
改进 SLO
- 设置更低的响应时间、更改的吞吐量等
-
保持一定的安全缓冲
- 内部用的 SLO 要高于对外宣称的 SLO
-
不要超额完成
- 定期的 downtime 来使 SLO 不超额完成
设置 SLO 时的目标依赖于系统的不同状态 (conditions)，根据不同状态设置不同的 SLO：**总 SLO = service1.SLO1 weight1 + service2.SLO2 weight2 + …
为什么要有 SLO，设置 SLO 的好处是什么呢？
对于客户而言，是可预期的服务质量，可以简化客户端的系统设计
-
对于服务提供者而言
可预期的服务质量
更好的取舍成本 / 收益
更好的风险控制 (当资源受限的时候)
故障时更快的反应，采取正确措施
SLO 设好了，怎么保证能够达到目标呢？
需要一个控制系统来：
监控 / 测量 SLIs 对比检测到的 SLIs 值是否达到目标 如果需要，修正目标或者修正系统以满足目标需要 实施目标的修改或者系统的修改 该控制系统需要重复的执行以上动作，以形成一个标准的反馈环路，不断的衡量和改进 SLO / 服务本身。
我们讨论了目标以及目标是怎么测量的，还讨论了控制机制来达到设置的目标，但是如果因为某些原因，设置的目标达不到该怎么办呢？
也许是因为大量的新增负载；也许是因为底层依赖不能达到标称的 SLO 而影响上次服务的 SLO。这就需要 SLA 出场了。
SLA
SLA 是一个涉及 2 方的合约，双方必须都要同意并遵守这个合约。当需要对外提供服务时，SLA 是非常重要的一个服务质量信号，需要产品和法务部门的同时介入。
SLA 用一个简单的公式来描述就是：SLA = SLO + 后果
-
SLO 不能满足的一系列动作，可以是部分不能达到
- 比如：达到响应时间 SLO + 未达到可用性 SLO
-
对动作的具体实施
- 需要一个通用的货币来奖励 / 惩罚，比如：绩效得分等
SLA 是一个很好的工具，可以用来帮助合理配置资源。一个有明确 SLA 的服务最理想的运行状态是：增加额外资源来改进系统所带来的收益小于把该资源投给其他服务所带来的收益。
一个简单的例子就是某服务可用性从 99.9% 提高到 99.99% 所需要的资源和带来的收益之比，是决定该服务是否应该提供 4 个 9 的重要依据。
故障复盘
故障复盘就是对于过去的一些服务异常和服务中断情况进行回顾和总结，以确保相同问题下次不会再出现。为了让大家团结协作，我们希望建立一种无指责、透明的事后文化。个人不应该害怕事故，而是确信如果事故发生，团队将会响应和改进系统。
备注: 其实在国内的SRE文化中，一般只有对大型，对业务有重大影响的事故才会进行复盘，但实际上如果在时间和经历允许的情况下，对于一般的普通事故也应该在小范围进行复盘，正所谓大的故障都是从不断的小问题一点一点积累的。另外，其实对于运维相关的个人而言，我们也应当及时的进行小故障复盘，以不断加强个人的故障处理和修复能力。
我认为SRE的一个关键共识正是承认了系统的不完美性，追求永不停机的系统是不现实的。基于不完美系统，我们无可避免要面对和经历系统故障与失败。
所以我们重要的并非找到为这个故障责任的这个人或者那个人，而是更应该刨根问底地复盘这个故障和失败的根本原因是什么，以及如何避免再次出现相同的故障。系统可靠性是整个团队共同奋斗的方向，从失败中快速恢复并吸取教训，每个人放心地提出问题，应对停机，并努力改进系统。
备注: 通常很多企业内部在故障复盘过程中，相关人员可能将故障和失败的根因追溯 不经意间 当做了故障定责和一系列的惩罚措施，通过一些惩戒措施来强行约定故障的发生，这种方式往往是非常不可取的，试想每个人都不想出现事故，要么是认知之外，要么是规则缺陷，永远没有一个人明知会有故障而偏偏去制造故障的。
需要牢记的是: 故障是我们可以从中学习的东西，而不是让人害怕和羞耻的事情！
在日常运维过程中，出现故障等事故对于我们而言其实是一个很好的复盘学习机会。通过历史监控数据，分析事故其中的根本原因，制定后续应对策略，并且通过运维平台将这些应对策略编辑成标准化、可重用、自动化的运维应用场景，为后续相同问题的处理提供标准且快捷的解决方案。这正是事后回顾这个过程最真实的价值体现。
故障复盘的唯一目的是减少故障的发生。有几个我目前认为不错的做法。
故障复盘需要有文档记录，包括故障发生的过程，时间线的记录，操作的记录，故障恢复的方法，故障根因的分析，为什么故障会发生的分析。文档应该隐去所有当事人的姓名对公司的所有人公开。很多公司对故障文档设置查看权限，我觉得没什么道理。有些公司的故障复盘甚至对外也是公开的。
故障在复盘的时候应该将当事人的名字用代码替代，可以营造更好的讨论氛围。
不应该要求所有的故障复盘都产生 Action。之前一家的公司的故障复盘上，因为必须给领导一个“交待”，所以每次都会产生一些措施来预防相同的故障再次发生，比如增加审批流程之类的。这很扯，让级别很高的领导审批他自己也看不懂的操作，只能让领导更痛苦，也让操作流程变得又臭又长，最后所有人都会忘记这里为什么会有一个审批，但是又没有人敢删掉。你删掉，出了事情你负责。
Blame Free 文化？之前我认为是好的。但是后来发现，有些不按照流程操作导致的问题确实多少应该 Blame 一下，比如下线服务的时候没有检查还没有 tcp 连接就直接下线了，或者操作的时候没有做 canary 就全部操作了，这种不理智的行为导致的故障。但是条条框框又不应该太多，不然活都没法干了。
引用来源：：
https://silenceper.com/blog/202009/how-to-use-keda/
https://bgbiao.top/post/sre运维体系
在基于DevOps思想对自动化运维改革的大道上，一直砥砺前行，从未停歇。
道阻且长，行则将至，行而不辍，未来可期。
欢迎搜索 k8stech 关注公众号，定时更新运维开发、SRE、云原生等文章。
