可观察性体系在任何一个具有一定规模的企业中，一旦整个SRE运维模型落地，可观察性体系的建设就会变得尤为重要，而整个可观察性在一个可观察的系统，我们通常将其分为以下三个方面：指标监控：即各种指标监控，如基础资源指标、服务性能指标、业务调用指标等。日志：监控各种设备和服务的运行日志。调用链：业务层面的调用链分析，通常在分布式系统中帮助运维、开发、运维人员快速识别整体调用的瓶颈点一套完整的可观察系统，可以保证你洞察到系统并跟踪系统的健康状况、可用性以及系统内部发生的事情。对于整个可观测系统的构建，需要注意两点：确定质量标准是什么，并确保系统持续接近或保持在质量标准限度内。在整个企业级可观测系统中，我认为至少应该包括以下几个特点：完整的指标采集：可以对接企业内大部分设备和技术栈的相应监控指标；同时支持常用设备的监控指标体系，可以快速连接监控设备和指标，避免所有设备监控从零开始；支持海量设备支持日志数据采集：企业IT系统的数量和规模越来越大，监控系统需要监控比以往海量的设备监控。监控数据存储与分析：监控数据是运维分析、运维自动化和智能化的基础，因此海量监控数据存储和基于监控数据的可视化分析是监控系统的基本能力。可观察系统是整个运维系统的基础，需要为整个运维系统提供数据支撑。因此，企业级的可观察性系统应该是基于平台的。一方面，可以通过配置或开发接入更多的运维指标；另一方面，可以对接更多专业的运维工具，将多种运维数据融合打通，为更多的运维场景提供数据服务。整体而言，可观测系统为企业运维提供了数据基础，让我们可以在事故响应和容量预测中使用更多的数据，而不是依赖过去的经验和头脑风暴来做决策。故障响应如果出现故障，将如何提醒每个人并做出响应？工具可以通过定义提醒人类的规则来帮助解决这个问题。故障响应建立在使用可观察性系统构建的数据之上，具有反馈循环，帮助我们加强对服务的监控。故障响应通常包括以下动作：关注：无论是主动发现瓶颈或异常点，还是通过可观测系统被动暴露瓶颈，我们都应该主动关注沟通：及时将观察到的风险点通知相关方，并告知受影响的人面积及相关补救措施。修复：三方达成一致后，根据补救措施对相关风险点和异常点进行修复。需要注意的是，如果整个可观察性系统在早期能够做好，通常故障应该从一个简单的告警信息或者一个上报故障的调用开始。因此，一般情况下，可观察系统足够好，只能起到追溯和故障排除的作用，而不能起到及时发现的作用。这时候就需要依靠各种Observation数据来计算和评估告警，及时将相关告警通知相关人员，暴露风险点。告警只是整个故障响应中的第一个环节，它解决的是如何发现故障的问题，而大多数故障响应工作是定义处理策略和提供培训，以便人们在收到警报时知道该怎么做，通常这部分更多是对以往历史经验和运维经验的总结和沉淀，包括一些经验的抽象和工具化沉淀，保证故障响应的高效性和泛化性（即不依赖人的经验）。对于整个报警系统来说，需要保证的是报警的有效性，否则，整个报警系统很可能沦为一个垃圾数据生成器，而报警的有效性意味着必须满足以下两个要求：告警及时性：系统出现问题需要通过告警信息通知运维人员，及时处理告警；报警的准确性：只要有报警信息系统，就一定有问题（对于很多企业来说，可能会有大量无用的报警，比如磁盘问题，mem等相关问题，当然，这涉及到自动化、业务表单和警报阈值时）；在整个运维过程中，我们经常会发现有大量无关的告警信息，使得运维人员的注意力迷失在告警的海洋中，而通常是非运维领域的领导者会关注整个报警的响应程度。因此，抑制和消除无效告警，使运维人员不被告警风暴吞噬，也是告警管理中的重点建设内容。通常我们每一个可观测系统搭建完成后，可以通过集成到监控平台的各种监控数据，通过趋势预测、短线检测、间歇恢复、基线判断等算法和手段实现告警。反复压缩。压缩收敛，加强告警有效性。同时，对于一线运维人员，我们需要基于同一系统或设备的多项监控指标进行综合建模分析，汇总成一个健康评分，给一线运维人员维护人员系统健康为本系统的分级评价体系真实、直观地反映了系统的运行状态，能够快速定界问题。例如，对基础资源的多项指标进行综合加权计算，从整体上评价资源利用率；应用程序关联的所有资源的资源利用率，以及应用程序运维架构的整体建模分析，计算出综合评价的分数。评估应用程序的健康状况。如果这个过程做的比较成熟，可以在现有的内部解决方案和告警的基础上进行闭环。一个简单的场景是，当磁盘满时，告警会先触发一次标准化的磁盘检查，并进行相关的discardable，如果删除数据仍然无法解决告警，下次可以直接关联到一线操作和维护进行人工干预，然后进行标准化的经验总结。故障恢复故障恢复就是对过去的一些服务异常和服务中断进行回顾和总结，保证下次不会再出现同样的问题。为了让每个人都能共同努力，我们希望在事后创造一种无责备和透明的文化。个人不应该害怕发生事故，但要有信心，如果发生事故，团队会做出反应并改进系统。备注：其实在国内的SRE文化中，一般只有对业务有重大影响的大型事故才会进行review，但其实如果时间和经验允许，一般的事故也应该进行review所谓的big失败是从连续不断的小问题中一点一点积累起来的。另外，其实对于运维相关的个人，我们也应该及时进行小故障恢复，不断加强个人的故障处理和修复能力。我认为SRE的一个关键共识是承认系统并不完美，追求永不停止的系统是不现实的。基于一个不完善的系统，我们将不可避免地面临和经历系统故障和故障。因此，对我们来说重要的不是找这个或那个人对这次失败负责，而是彻底审视这次失败和失败的根源是什么，如何避免同样的失败再次发生。系统可靠性是整个团队所追求的目标，从故障中快速恢复并从中吸取教训，每个人都乐于提出问题、应对停机并努力改进系统。备注：通常在很多企业的故障恢复过程中，相关人员可能会无意中将故障和故障的根源追溯为故障判定和一系列惩罚措施，并用一些惩罚措施来强行约定故障的发生。这种方法往往是非常不可取的。试想一下，每个人都不希望发生事故，无论是因为知识外还是规则缺陷。没有人知道会出现错误，因此永远不会制造错误。这里有一点要记住：失败是我们可以从中学习的东西，而不是值得害怕和羞愧的东西！在日常运维过程中，出现故障等事故，其实是我们回顾和学习的好机会。通过历史监控数据，分析事故根源，制定后续响应策略，并通过运维平台将这些响应策略编辑成标准化、可复用、自动化的运维应用场景，提供标准、快速的处理同样的问题在未来的解决方案中。这是事后追溯过程最真实的价值。测试和发布测试和发布主要是整体稳定性和可靠性的预防作用，而预防是试图限制发生的事件数量并确保基础设施和服务在新代码发布时保持稳定。作为一个长期从事运维工作的人，内心最恐惧的或许就是应用新版本的发布。因为除了硬件和网络设备损坏这种自然灾害级别的概率事件外，新应用版本发布后的第二天通常是宕机和事故的高危期。因此，对于一些大型产品，通常在节假日和重要活动前夕关闭网络，以避免新版本上线带来的业务错误。而测试是在成本和风险之间找到适当平衡的活动。如果你冒太多风险，你可能会被系统故障淹没；相反，如果你过于保守，你将无法以足够快的速度发布新事物，从而使企业无法在市场上生存。在错误预算比较大的情况下（即一段时间内因故障导致的系统宕机较少），可以适当减少测试资源，放宽系统上线的测试和条件，让业务可以在线上有更多功能以保持业务敏感度；当错误预算比较小时（即系统会因为故障而关闭一段时间），需要增加测试资源，加紧系统的在线测试，使系统的潜在风险能够更有效地分析释放，避免系统停机并保持系统的稳定状态。敏感状态和稳定状态之间的平衡需要整个运维和开发团队共同分担。除了测试，应用发布也是通常由运维团队承担的职责。SRE的原则之一是将所有重复劳动编码和工具化；此外，应用发布的复杂度往往与系统的复杂度成正比。因此，应用系统中的大型企业往往开始基于自动化框架构建自动化的应用发布流程。通过自动化发布工具，我们可以构建一个流水线，将部署过程中的所有操作（如编译打包、测试发布、生产准备、告警屏蔽、服务停止、数据库执行、应用部署、服务重启等）自动化。容量规划容量规划是关于预测未来和发现系统的局限性，容量规划也是关于确保系统能够随着时间的推移得到改进和增强。规划的主要目标是管理风险和预期，在容量规划的情况下，涉及扩展整个企业的容量；有关的期望是人们在看到业务增长时期望服务如何响应。风险是花费时间和金钱在额外的基础设施上来处理这个问题。容量规划首先是对未来可预测性的分析判断，其预测的基础是海量运维数据。因此，除了有相应的架构和规划团队进行容量规划外，综合运维数据中心是系统容量规划的必备设施。容量趋势预警与分析，将运维监控、流程管理等各种数据源的各类运维数据进行综合采集、整理、清洗、存储，并将这些来自各种工具的运维数据进行整合，构建各种数据主题.应用于这些数据主题的数据是用来帮助运维人员评估问题的，包括：当前容量是多少，什么时候达到容量限制，应该如何更改容量，容量规划，运维等。运维平台不仅可以提供必要的数据支持，还需要提供必要的数据可视化支持能力。运维数据可视化提供了一些必要的能力，保证运维人员可以更好的利用运维数据进行容量评估。首先，运维平台需要具备强大的数据检索能力。运维平台存储了大量的运维数据。运维人员在尝试建立和验证探索性场景时，往往会反复搜索和查询特定数据。如果运维数据分析平台的数据查询很慢或者查询角度很少，运维人员创建场景需要很长时间甚至失败。因此运维人员可以通过该平台实现关键字、统计功能、单条件、多条件、模糊多维搜索功能，实现海量数据的秒级查询，更有效地帮助运维人员更方便地分析数据。其次，平台需要强大的数据可视化能力。人们常说“千言万语不如一图”，运维人员往往会通过各个系统的运维数据进行统计分析，生成各种实时报表。)进行多维度、多角度的深度分析、预测和可视化，将自己分析的预测结果和经验表达和推广给他人。自动化工具开发SRE不仅涉及运营，还涉及软件开发。当然这部分是指运维和SRE领域相关的工具和平台的开发。在Google的SRE系统中，SRE工程师将花费大约一半的时间来开发新的工具和服务。其中一些工具用于自动化一些手动任务，而其他部分则用于不断填充和修复整个SRE系统的其他部分。系统。通过编写代码将自己和他人从重复性工作中解放出来，如果我们不需要人类来完成任务，那么就编写不需要人类参与的代码。SRE发自内心地鄙视重复性工作，将从原来的人工加被动响应转变为更高效、自动化的运维体系。自动化运维框架：自动化运维工具的优势和必要性：提高效率：通过程序自动化运维，可以有效降低运维人力资源的投入，也可以让运维人员释放精力，专注于更重要的领域。操作标准化：统一众多复杂易错的人工操作，实现统一的运维操作入口，实现运维操作白屏，提高运维操作的可管理性；同时，减少运维人员操作情绪导致的人工失误，避免“从删库到跑路”的悲剧。运维经验和能力的传承：运维自动化工具将众多原有运维团队积累的经验以代码的形式汇总到各种运维工具中，实现自动化、白屏运维操作。运维团队的后来者可以有效地继承、复用和优化。这种编码的工作继承将个人能力转化为团队能力，减少了人员流动对工作的影响。自动化运维系统的构建必须基于运维场景。这些运维场景在企业内部反复迭代创建，是企业中最常用的运维场景。比如常见的运维场景：软件安装部署、应用发布交付、资产管理、告警自动处理、故障分析、资源申请、自动巡检等。因此，整个自动化运维系统的建设应该还支持各类作业自动化配置能力，通过简单的脚本开发、场景配置、可视化定制流程，实现更多运维场景。用户体验用户体验层应该说，作为SRE，最终的目标是站在用户的角度保证服务的稳定性和可用性。这是传统的运维人员不会关注这一点，因为人们通常只考虑底层运维系统或底层资源是否稳定，但实际上整个业务的稳定性才是SRE需要的问题要关心，而业务的稳定性和可用性通常需要从用户的角度来模拟和衡量整体的可用性和可靠性。在上述所有与SRE相关的工作领域中，无论是监控、事件响应、审查、测试发布、容量规划、构建自动化工具，都是为了提供更好的系统用户业务体验。因此，我们在运维过程中都非常注重系统的用户体验。在实际运维工作中，我们经常可以获取应用日志、监控数据、业务测试等与业务相关的用户体验信息。在运维数据平台中，通过这些用户体验监控数据之间的关联和串联，再现了用户最终的业务调用环节以及各应用环节与性能数据的关系。最终，从业务用户体验数据出发，逐步实现系统运行状态数据与设备运行状态数据的链接，使运维系统达到以终端用户体验为中心的目标。这些用户体验信息对于运维团队掌握客户整体用户体验、监控系统可用性、针对性优化系统具有不可替代的作用。事实上，SRE运维体系更强调以用户体验为核心，以自动化和运维数据为手段来保障应用业务的连续性。从这个角度来看，我们会发现与传统运维还有很大的差距，我们不再只是简单的安装部署工程师，我们需要通过一系列的不断保障上层业务的稳定性和可靠性的技术手段。_来自：BGBiao的SRE生活链接：https://bgbiao.top/post/sre...
