撰文：王小维不写边塞诗 / 制图：脾气超好
在过去几年，优维的团队为客户构建和运营了不少大型分布式系统项目。在这个过程中，我们获得了很多关于分布式架构概念的全面性认知，也充分认识到高负载与高可用性系统运行面临的重大挑战。
一个系统完成开发并不等于大功告成、回家睡觉，上线后的运行挑战往往更大。构建系统本身有一定趣味性，但规划系统如何应对流量大幅增长、确保数据持久以及处理硬件故障等问题往往需要历经磨难的“笨智慧”，从这个维度看，运维大型分布式系统对我们的团队来说是一次又一次极富价值的经历。
我们曾在之前关于Murphy大模型的文章中提到（点击回顾Murphy运维数智人），系统规模越大，墨菲定律越活跃。频繁部署、众多开发人员参与部署代码、涉及多个数据中心以及被大量用户使用等因素，使得出错概率增加。过去N年我们遇到了各种系统故障，故障原因包括但不限于可预测的硬件故障、看似无害的 Bug、数据中心线缆被挖断以及多个级联故障等；我们同时也经历了不少的业务停摆事件，因为系统部分无法正常运行而给给业务带来的巨大影响至今想来依然记忆犹新。
这篇文章可以算作是我们多年工作的总结，也可以看做运维大型系统的实践汇总，从理论层面看具备一定的参考价值。不过需注意的是，我们讨论的是大型系统经验，对于规模较小或关键任务程度较低的系统，这些做法可能不适用，恳请轻喷。
我们需要明确系统是否健康，这就涉及回答“我的系统是否正常工作”这个问题。要做到这一点，收集系统关键部分的数据十分重要。对于在多台计算机和数据中心运行多个服务的分布式系统而言，确定要监控的关键内容并非易事。
▏基础设施健康可观测
如果有一台或多台计算机/虚拟机过载，分布式系统的部分功能可能会降低性能。机器的健康状况，如CPU利用率、内存使用情况等是基础的值得监控的内容。很多客户通过引入优维的EasyOps®平台（点击回顾EasyOps7.0），能够开箱即用地处理这种监控并自动扩展实例。所以，对于企业来说，拥有优秀的核心基础设施团队非常难得，因为他们能使我们提供的基础设施监控和告警发挥更大效能。在优维的产品视角下，无论技术如何实现，当实例或基础设施出现问题时，可观测平台要提供精准、全面的有效信息。
▏服务运行状况可观测
面对流量、错误、延迟……我们常常需要回答“这个后端服务是否健康”的问题，一般情况下，观察访问端点的请求流量、错误率和端点延迟等能提供服务健康状况的有价值信息，我们倾向于将这些信息显示在仪表板上。在构建新服务时，正确使用HTTP响应映射并监视相关代码能让我们对系统有更多了解。所以，确保客户端错误返回40X，服务器错误返回50X，这种监控易于构建，也更容易解释清楚。监测延迟需要进一步考虑。对于生产服务，目标是让大多数最终用户有良好体验。事实证明，测量平均延迟不是一个很好的指标，因为平均值可能掩盖一小部分高延迟请求。根据优维的经验，如果只能测量面向用户的四个系统指标，那应该是：流量、错误、延迟和饱和度。
▏业务指标可观测
监控服务模块能告诉我们服务模块的运行情况，但无法告知业务是否按预期工作。例如金融行业面对支付系统的关键问题：人们能否使用特定支付方式开展支付业务？识别业务事件并进行监控，是重要的监控步骤之一。
在过去很长一段时间里，虽然我们建立了各种可观测（监控），所有服务看似正常运行，但仍可能有关键产品功能不可用，这给我们和客户带来很大困扰。优维的全面可观测产品体系就是在这样的历史契机上被逐步构建和完善起来的（点击回顾全面可观测），从阶段性成果上看，全面可观测的建设无论是对优维内部团队还是客户团队来说都非常“有用”。全面可观测这个产品的成功也让我们认识到，要想做好分布式系统的稳定性管理，我们必须在既有的可观测性基础上，为客户付出大量思考和努力。
如果说的直白点，可观测仅仅是自动检测问题并发出告警以供我们采取行动的参考，人工盯梢依然是一项重要的工作。这里就不得不提“值班”这个议题了。
我们的一个感受是，一旦确立“you build it, you own it”的观念，“值班”问题就无法回避。一般的场景是，每当出现告警时，值班工程师会及时响应并查看详细信息，但目前我们面临一个关键问题：如何构建一套强有力的“监控-告警”机制？
对于许多客户来说，从监控数据中检测异常是一项艰巨的挑战，然而对优维团队而言却是AI和机器学习能够发挥作用的领域。优维的Murphy团队实际上也是一个机器学习团队，我们能够根据客户的使用情况定制解决方案。通过Murphy这一运维数智人，我们可以将监控数据推送到运维告警通道，对具有不同可信度的告警进行分析，进而决定是否呼叫工程师——没错，何时触发告警是个很有意思的问题——告警过少可能导致错过有影响的中断，过多则会让值班人员在夜里疲惫不堪。
因此，跟踪和分类告警以及测量信噪比对于调整告警系统至关重要。检查告警并标记其是否可操作，然后采取措施减少不可操作的告警，这是实现可持续的“呼之即来挥之即去”必经之路。值得一提的是，告警事件的聚合、降噪、排班、认领、升级、协同、灵活的推送策略、多渠道推送以及与IM打通是很普遍的需求。在这方面，我们的 Murphy 数智人展现出了令人信服的问题解决能力，也有更多潜力等待我们挖掘，这可以认为是一个小小的兴奋点。
对于小型系统来说，中断或许不是什么大事，值班工程师通常能够搞清楚正在发生的事情以及背后的原因，一般情况下都可以理解和处理。但对于拥有多个（微）服务的复杂系统，很多工程师把代码推到生产环境中，光是找出潜在问题的位置就已经让人焦头烂额。
优维在处理这类问题上的经验是，制定恰当的标准流程会让事情有很大的改观。首先要明确的是，一旦有多个部署服务的团队存在，跨组织的故障交流就变得极为关键。在我们的工作场景中，大量工程师会依据自己的判断把他们开发的服务部署到生产环境，每小时可能有几百次部署。在这种情况下，一个看似不相关的服务部署很可能会影响到另一个服务。所以，标准化的故障广播和通信渠道能发挥重大作用。比如，我们可以把各种罕见的警报信息加入一个集中式聊天群组来处理故障，这样就能快速确定导致故障的服务并解决问题，相对而言，这种抱团作战比任何个人单兵作战要高效很多。
在故障发生期间，大家往往都急于修复出现问题的地方，这会让我们情绪亢奋。
通常，问题的根源来自糟糕的代码部署以及代码更改中的明显错误，一般的做法是着急忙慌去修复错误、推送修复并关闭故障。但我们认为在故障期间去修复根因是个很危险的想法，采用激进的进攻式修复策略带来的收益很小，损失却很大。因为新的修复需要快速完成，所以必须在生产中进行测试，这就使得我们很容易引入第二个、第三个、第N个错误，或者在现有错误之上再“免费赠送”一个故障。
在我们的经验里见过很多不断恶化的故障，而最有效的办法是：“今天”先专注于缓解故障，克制去修复或调查根因的冲动，并把调查根因的动作推迟到“明天”。
我们常常会建议企业考量团队在处理故障后的后续行动：兄弟们是否会进行小规模调查？敢不敢再后续工作中投入一部分精力，暂停产品工作以进行系统级修复？
▏正确的事后分析是构建强大系统的基础
所谓的“正确”应当是“对事不对人”的认真，也就是“不指责他人”且“分析得非常彻底”。优维提倡的事后分析模板随着项目阶段的不断发展而不断变化，包括事件概述、影响总览、时间线、根因分析、经验教训以及详细跟进清单等内容。
这是优维团队工作中常用的复盘模板：
一项优质的事后分析，除了能深入探究根因并提出改进措施，还要具备更快地预防、检测或缓解所有类似故障的拓展性能力。所谓深入探究，是指团队不满足于找到根因，而是通过问答方式进行深入挖掘，以获得更准确的结论。例如：
Q：为什么会出现这个问题？
A：因为代码里有 bug。
Q：为什么其他人没发现这个错误？
A：代码审查员没注意到代码更改可能导致此类问题。
Q：我们为什么只依赖代码审查员发现错误？
A：因为没有针对此用例的自动化测试。
Q：为什么没有针对此用例的自动化测试？
A：因为在没有测试账户的情况下很难进行测试。
Q：我们为什么没有测试账户？
A：因为该系统尚不支持。
基本结论：这个问题表明存在缺乏测试账户的系统性问题。
解决方案：建议在系统中添加测试账户支持，并为所有未来类似代码更改编写自动化测试。
事件回顾是事后分析的重要辅助工具，极度重视可靠性的团队在面对严重的故障时，会由经验丰富的老司机展开审查和质询，这也是保证事后分析最大程度去除认知“死角”的一种可靠性安排，因为这样的牛逼团队很清楚一个事实：当运维团队的事后分析做得很彻底时，其他团队可以在预防性改进中获得额外助益。我们常常提到系统的鲁棒性，但一套鲁棒性系统的获得并非一蹴而就，而是通过不断迭代构建而成。那要如何持续迭代呢？这就需要团队养成持续改进、从故障中学习的运维文化。
常规活动是否需要大量投入？答案是肯定的，因为这对保持大型分布式系统的正常运行非常关键。这种认知在优维多年前首次服务大型金融客户时就成型了——在此之前，由于规模和基础设施的限制，我们通常难以理解到这个层面。
我们曾经觉得针对单个数据中心进行故障演练意义不大，在观察了几个实践案例后，我们改变了这种看法（点击回顾应急管理）。理论上，设计强大的分布式系统就是为了在数据中心崩溃时仍能保持韧性，既然它能正常工作，为何还要经常测试呢？这个问题的答案比较复杂，核心在于“规模”差异——当系统规模足够大时，我们需要测试服务能否处理突然暴增的数据。
在优维过往的服务案例中，常见的故障场景之一是在故障转移时，新数据中心的服务没有足够资源处理暴增的流量。例如，假设系统A和系统B分别在两个不同的数据中心运行，当前资源利用率为60%，每个数据中心有几十甚至上百台服务器在工作，并且设定当资源利用率达到70%时触发警报。现在进行故障转移，把所有流量从第一个数据中心转移到第二个数据中心。如果在没有增加新服务器的情况下，第二个数据中心很可能无法承受这么大的负载。而增加新服务器可能耗费很长时间，这就会导致请求不断堆积并开始被丢弃。这种阻塞情况可能会进一步影响其他相关的系统，从而引发级联故障。
切流量是预案的重要手段之一。要确保出故障时预案可用，平时就需要进行演练。
计划的服务停机时间练习是测试整个系统弹性的好方法，也能发现特定系统的隐藏依赖项或不适当、意外的使用情况。对于面向客户且依赖较少的服务，这种练习相对容易完成，但对于需要高可用性或被许多其他系统依赖的关键系统来说就比较困难。然而，最好通过受控演练来验证关键系统不可用时会发生什么，让所有团队都知道并做好应对意外中断的准备。
容量规划对大型分布式系统也很重要。这里的大型是指计算和存储成本每月达到数万或数十万的量级。在这个规模下，使用固定数量的部署可能比使用自动扩展的云解决方案更便宜。至少，固定部署应能处理“业务常态”流量，并在高峰负载时进行自动扩展。但在接下来的一个月、未来三个月以及明年需要运行多少最小实例呢？
对于拥有成熟且良好历史数据的系统来说，预测其未来流量模式并非难事。这一点对于预算制定、供应商选择以及锁定云提供商的折扣都非常重要。如果服务费用很高却未考虑容量规划，那么就会错失降低和控制成本的良机。
SLO即服务级别目标，代表着系统可用性的数字目标。对于每个单独的服务，定义服务级别SLO（如容量、延迟、准确性和可用性目标）是一种良好的做法。这些SLO可以作为告警的触发条件。服务级别SLO的示例参考如下：
业务级SLO或功能SLO是服务之上的抽象概念，涵盖用户或面向业务的指标。例如，业务级SLO可能是期望99.99%的电子邮件收据在旅行完成后的1分钟内发送。此SLO可能映射到服务级别SLO（如支付和电子邮件接收系统的延迟），或者可能需要以不同方式进行衡量。
SLA即服务水平协议，是服务提供者和服务消费者之间更广泛的协议。通常，多个SLO组成一个SLA。例如，99.99%可用的支付系统可以是SLA，它可分解为每个支持系统的特定SLO。
定义SLO后，下一步是对其进行衡量并报告，对SLA和SLO进行自动化监控和报告通常是一个复杂的项目，技术团队和业务部门往往会降低其优先级——一方面，技术团队可能不太感兴趣，因为他们已经有各种级别的监控来实时检测故障；另一方面，业务部门更倾向于将重点放在提供功能上，而不是投资于一个没有即时商业影响的复杂项目中。这就引出了另一个议题：SRE。
在快速发展的科技领域，企业对于系统可靠性的追求至关重要。许多快速发展的科技公司通常在早期就会组建SRE团队，也有不少公司在创建专门的基础架构团队时同时启动SRE团队。
那么，企业究竟什么时候设立SRE团队最为合适呢？根据优维的经验，这里有一个可供行业参考的评判标准：当一家企业发展到跨团队的可靠性工作占用了很多工程师的时间时，这家企业就应该设立专门的 SRE 团队了。
SRE团队的存在有着诸多重要作用：
首先，它能够让所有工程师在维护大型分布式系统的操作方面更加轻松。SRE团队可能拥有标准的监控和告警工具，为系统的稳定运行提供实时的监测和预警；可能购买或构建值班工具，并且成为“值班最佳实践”的首选团队，确保在任何时候都能及时响应系统问题。
其次，SRE团队会推动故障复盘并构建系统，以便更轻松地检测、缓解和防止故障。通过对故障的深入分析，找出问题的根源，从而采取有效的措施避免类似问题的再次发生。他们对故障转移演练也有很大帮助，经常推动黑盒测试，从外部视角全面检测系统的性能和稳定性。同时，SRE团队还参与容量规划，确保系统能够满足未来业务增长的需求。
此外，SRE团队推动选择、定制或构建标准工具来定义和衡量SLO并提供报告，这对企业的决策提供有力的数据支持。
然而，不同企业有不同的痛点，SRE团队的名称通常也不一样，可能被称为运维、平台工程或基础设施等。我们今天都应该有一个共识：SRE都需要独立运作。经过20多年的演变，SRE早已发展为一项全职工作，需要专门的团队和资源来全力投入。这是企业系统的可靠性和稳定性的源头，也是企业持续发展的技术保障。
全面可观测及时发现系统的各种异常情况；实施严格的故障管理流程，确保故障能快速定位和修复；进行定期的容量规划，提前为业务增长做好资源准备；培养专业的运维团队，让有能力的人来保障系统稳定；推动自动化运维，提高效率、减少人为错误……这些年，为了提高大型分布式系统的可靠性和稳定性，优维付出了值得我们自己欣慰的努力和奋斗。
我们的团队所积攒下来经验不仅对优维自己有用，更重要的是让我们的企业客户获得了货真价实的好处。这几年无论线上还是线下、公开还是私聊，大家都在谈企业的数字化转型，都在试图通过大型分布式系统来支持业务发展。优维是一家做创新服务的公司，我们有我们的使命，坦诚地说，大型分布式系统的可靠运维是一项既复杂又艰巨的任务，我们希望优维的这些实践经验能帮助更多的企业克服恐惧与困扰，真正实现“不用回头”的“往前看”，大家一起把企业做好，其实就是为数字化时代的发展贡献力量。
- end -
