系统又双叒叕“挂了”？互联网公司如何维稳“生命线”

在技术迅猛发展的今天，软件系统的稳定性和可靠性已然成为互联网公司的生命线。近年来，多家知名互联网公司遭遇的软件系统故障，不仅影响了用户体验，也暴露了在可靠性工程和业务连续性规划方面的不足。

面对软件可靠性现状，日前 InfoQ《极客有约》X QCon 直播栏目特别邀请了腾讯 IEG 技术运营部助理总经理 & 专家工程师党受辉担任主持人，与携程云原生研发总监周昕毅、Bilibili 基础架构部平台工程负责人刘昊、腾讯 IEG 技术运营部 SRE 总监杨军，在 QCon 全球软件开发大会 2024 上海站即将召开之际，共同探讨线上可靠性工程的问题的解决思路。

部分精彩观点如下：

• AIOps 还没有成熟到可以脱离活人工程师。
• 低级错误虽然不能忍，但可以通过技术和管理手段降低发生概率。
• 及时性是故障沟通的第一要务。跨技术团队协作需要统一的对象和认知。
• 随着云原生和微服务架构的普及，可观测性体系的建设变得更加复杂，但也是提升系统透明度的机遇。

以下内容基于直播速记整理，经过不改变原意的编辑。

党受辉：不同规模的公司，对稳定性和可靠性的关注点会有所不同吗？ 

杨军： 首先我们先看看稳定性和可靠性的区别。我认为稳定性和可靠性还是有区别的。稳定性主要指产品在长时间运行和不同环境条件下的表现，关注的是系统能否持续运行而不出意外或崩溃，以及性能是否稳定。例如，家用空调出厂时都会做至少 3 个月 24 小时不间断长期运行测试，这是稳定性的基本要求。而可靠性则侧重于产品在一定条件下无故障执行功能的能力，关注的是故障率，即产品正常工作的概率。就像一把枪，大部分时间它处于待命状态，但一旦需要使用，它必须能够可靠地击发。AK47 之所以是世界名枪，就是因为他在任何条件下都有很高的可靠性。

回到这个问题，以游戏行业为例，最关注的是可靠性。即游戏运行周期内各项功能的正常执行的能力。每款游戏都有其例行维护周期，所以，从稳定性角度看，只要满足在维护周期内可以连续工作即可 (一款月更游戏至少需要保证能连续无故障运行 30 天)，但是我们更强调这个时间周期内功能要正常。所以，游戏行业对可靠性的要求更高，要求在运营周期内的所有功能都能随时正常工作，以确保玩家的体验。相比之下，金融或电信等行业可能对稳定性有更高的要求，因为它们需要全年无休地提供服务，从稳定性上来说至少是 365 天，甚至更长。

刘昊： 对于小型公司而言，由于资源有限，它们更关注在有限预算内实现基本的稳定性和可靠性。这些公司可能不会设定过高的要求，而是倾向于使用开源工具和云服务来降低基础设施成本和维护团队的人力成本。它们更注重业务的快速迭代以响应市场需求，而其软件系统的复杂性相对较低。因此，它们在稳定性工程化实践上的投入不会太多，主要围绕业务迭代和开源组件的稳定性。

当公司规模达到中型时，由于拥有一定的用户基础和收入来源，这些公司开始更关注业务的可靠性、可扩展性和高可用性。面对稳定性和可靠性的挑战，这些公司会投入更多精力和财力到可观测性和资源的自动化能力上，以确保系统在高负载下稳定运行。同时，它们可能会引入专业的 SRE 团队，对传统运维团队进行升级，专注于业务系统和基础设施系统的稳定性与可靠性，并投入更多资源在可观测性方面，确保全面的监控覆盖和快速的故障发现。在稳定性工程化实践方面，也会进行相关探索，并建设对应性的系统平台，以支撑稳定性的数字化管理和运营工作。

对于头部互联网公司或涉及民生的大型公司，它们面临的挑战更为严峻。这些公司的系统需要承载全球范围内的大量用户，用户基数和业务复杂性决定了稳定性和可靠性是公司生存和发展的基石。在这种情况下，公司需要确保系统的高可用性、低延迟，并具备一定的灾难恢复能力，如机房级别的灾难和业务连续性。这些公司会面临复杂的异构分布式系统架构，需要在故障发生时保证服务的可用性。

这类公司会更关注稳定性的体系化建设及运营，有针对性的围绕稳定性中各个阶段进行技术规划和布局。在业务场景管理、预案、智能监控、故障定位、止损、复盘和数据量化考核等方面都会投入大量资源。此外，还会进行容灾专项、故障演练、多活推进和大促保障等常态技术运营工作。同时，成本控制也是一个关键考量点，公司会建立专门团队关注技术体系的成本。由于业务复杂性高，还需持续关注新技术领域，如 AI、大模型等，以应对新业务业态的技术稳定性保障挑战。

周昕毅： 我认为，小规模公司可能依赖 SRE 工程师的个人能力来提升系统稳定性。但随着公司成长，个人能力有限，必须引入系统化流程和工程实践来增强稳定性和可靠性。

党受辉： 感谢刘昊老师及前面两位老师的分享，不同规模的公司可能需要根据自己的具体情况和需求，制定和调整相应的稳定性和可靠性策略。初创公司可能更侧重于快速迭代和成本控制，而大型企业可能更侧重于复杂的系统管理和全球服务一致性。

党受辉：互联网大厂因“低级错误”导致的技术故障能忍吗？有哪些针对性的预防措施？ 

刘昊： 低级错误导致的技术故障是无法容忍的，这通常需要一系列技术手段和流程布局来预防和解决。从软件开发到上线的整个 CICD 生命周期来看，我们可以在研发阶段通过设计审查、代码审查等手段确保代码质量。在 CI 阶段，利用自动化工具进行静态代码分析，提前发现问题。测试阶段，通过完善的测试用例和自动化测试，确保产品质量。上线阶段，通过建立检查项、发版环境顺序检查、发布观测等待时间等措施，防止粗心大意导致的错误。

在基础设施和基础组件方面，我们需要关注变更的影响面，并严格遵守分级发布规范。同时，建设分层和安全变更域，进行批次灰度，确保变更的影响可控。对于无法完全自动化的基础层变更，我们需要建立有效的 SOP 并保证其时效性，避免依赖人脑记忆。

周昕毅： 为了有效预防这类错误，首先，通过故障演练，我们在常规变更操作中进行预演，并模拟极端情况，以确保任何可能的低级错误都能在演练阶段被识别和解决，避免影响到生产环境。其次，在持续交付过程中，我们基于过经验中沉淀出的知识、落地为工具，防止重复发生同样的错误。第三，在架构设计时，关注防呆设计，提高”犯错“的门槛，控制故障的爆炸半径，确保低级错误不会引起重大故障。我们鼓励在系统设计阶段就引入故障防御，对于可能发生的故障进行场景推演，落实好”面向灾难场景的架构设计“。

杨军： 我的观点是，我们应该接受低级错误是无法完全避免（100% 避免）的客观事实。低级错误通常由人为因素引起，如粗心、缺乏经验、不专注、疏忽或疲劳。我们需要在管理上做得更细致，尽早发现可能导致低级错误的因素，并尽量避免它们。同时，我们必须在可接受的成本范围内降低低级错误的可能性。如果我们为了避免低级错误而无限制地增加资源投入，最终可能导致成本大幅增加，而业务价值并未相应提升。

党受辉： 如果线上可靠性工程出现问题，那么前期在应用产品设计、研发测试、发布变更等环节的所有投入都可能变得毫无意义。

党受辉：在出现故障时，如何与用户进行有效沟通并保持透明度？ 

周昕毅： 作为服务管理员，我们应该尽可能多地向服务使用方提供信息，帮助他们理解当前的实际情况，包括故障的影响范围、发生时间以及可能的关联影响。在决策时，我们还需要向用户简单解释采取某种措施的原因，比如流量切换或服务降级的逻辑。其次，我认为真诚是沟通的关键。我们必须承认错误，不掩盖问题，不隐瞒对我们不利的信息。然后，我们需要清晰地向用户表明我们的解决方案和预计的服务恢复时间，同时避免过度承诺，确保我们给出的期望是可以实现的。用户在服务出现问题时希望有选择权。我们应该快速解释每个方案的优缺点，帮助用户做出合理的决定。

故障发生时场面往往混乱，每个人都希望从自己视角看到最新的故障情况。根据我们的经验，通过发送服务监控看板来展示服务的实际情况是非常有效的沟通手段。监控看板不仅能帮助我们快速定位和解决问题，还能向用户展示问题逐步解决的过程。服务的监控看板应该随着服务的生命周期持续迭代更新，这样既能提高日常排障效率，又能在故障发生时提升透明度，帮助我们持续提升服务的可靠性。

杨军： 我对用户沟通方面做一些补充。首先，我们需要区分沟通的用户群体，这里我们主要关注内部真实的技术接口用户。故障发生时应立即通知内部用户，避免他们猜测和产生不必要的焦虑。另外，在故障发生时建立一个专门的沟通渠道也很重要，这有助于减少不必要的解释，确保所有讨论都集中在当前的故障上。此外，我认为在故障发生前后也应该保持沟通。例如，在游戏行业，我们会进行例行巡检，提前告知内部用户和运营团队潜在的风险。故障发生后，收集客户的反馈和对故障的改善措施也是必要的沟通环节。

刘昊： 在公司内部，我们必须明确自己的用户是谁，并确保在故障发生时，我们能够准确地识别并通知所有受影响的用户。其次，我们需要确保服务具备透明度。我对透明度的理解是，我们对服务本身的描述应该足够清晰，包括服务的指标描述。这依赖于我们对服务的 SLO（服务等级指标）梳理，以及对平台 / 业务场景的明确描述。

党受辉：在处理系统故障时，如何推进跨技术团队之间的有效协作？ 

刘昊： 首先，迅速建立清晰的沟通渠道，及时通知相关人员，建立专门的故障处置群，以便集中讨论和处理问题。其次，当相关人员集中后，明确各自的角色和职责。在故障场景中，必须清楚谁负责即时传递故障信息，谁负责具体的故障处理操作，以避免职责不清晰导致的空转等待或作业重复。此外，还要制定明确的故障响应流程，并在日常中进行对应性演练和周期性培训，以便在真实情况下能够熟练地按照流程响应。

周昕毅： 面对大规模故障时，可以指派一个主持人来维持秩序，确保关键信息传达给关键人员。每次故障复盘时，反过来审视协作过程中的不足之处，并在下一次响应中进行改进。同时，定期进行跨团队的演练，模拟故障场景，以提高团队的整体应对能力。最后，互相信任非常重要。我们不仅要确保自己的工作做好，还要对合作的团队给予充分的信任。

杨军： 对游戏来说，在重大保障时期，我们设有专门的线上和线下"war room"，由一个总负责人统一调度资源和接口人。部门长期设有一个故障同步群，包括各个业务的负责人、组长、总监，直至总经理。一旦发布信息，我们会根据故障的性质在不同层级进行处理：单业务故障通常由组长层面调度解决，多业务或平台性问题由总监层面处理，而公司级别更大系统的故障则由总经理层面协调。群内还有一位质量专员，负责对所有故障进行分析和处理，跟进故障之后的各项工作，确定哪些需要培训，哪些需要知识共享，以及改善措施的落地执行进展。

党受辉：展望未来，稳定性和可靠性工程将面临哪些新的机遇和挑战？ 

周昕毅： 我想从监控和可观测性的角度分享一些看法。随着越来越多的企业采用云原生架构，系统的交付和运维管理效率得到了显著提升。云计算提供的弹性和可扩展性，以及分布式系统架构的容错能力，都极大地增强了系统的可靠性。但同时，这也使得系统间的关联关系变得更加复杂。

例如，物理机和虚拟机时代，服务的 IP 地址相对固定，而容器化部署后，IP 地址不断变化，数量可能指数级增加。这种变化首先对监控系统提出了挑战，指标基数的膨胀促使我们进行改造。现代企业的架构弹性持续发展，IT 组织需要构建的可观测性体系也变得越来越复杂。监控和日志数据的增长速度超出了预期，我们需要在复杂架构和海量数据中化繁为简，建设出适合自己组织的可观测性平台，提升整体稳定性。

新一代的监控工具和可观测性平台能够提供更深入的系统状态和性能洞察，为 AI OPS 提供坚实的数据基础。我们需要利用这些工具，建设出能够适应云原生架构下复杂性和动态性的可观测性体系，以应对未来稳定性和可靠性工程的挑战。

刘昊： 稳定性工作应深入地与业务结合，避免技术自嗨，确保技术投入能够为业务带来实际收益。目前，稳定性工作正从后保障阶段走向前保障，从故障发生后的应急响应转向提前预防和减少故障的可能性。再者，AI 智能体和大模型技术的成熟为我们提供了重塑稳定性领域的机遇。我们需要考虑如何将这些新技术应用到稳定性工作中，这将渗透到我们的基础架构团队、现有系统和工作流程中，带来重塑现有工作的机会。

杨军： 机遇方面，我们正面临着数据驱动的可靠性工程的机遇，意味着稳定性和可靠性将越来越依赖于大数据。因此，我们需要为智能运维或 AI OPS 提前做好技术和数据储备。其次，可靠性设计的集成化和标准化也是一个机遇，产品开发将更注重在早期阶段就考虑可靠性因素，并引入多学科团队参与，确保产品全生命周期的高可靠性。随着行业标准的完善，可靠性设计标准化将成为趋势。第三，新技术的融合，如物联网技术中的远程监控和实时数据，为稳定性工程带来新的机遇。

挑战方面，数据驱动的可靠性工程要求我们面对数据质量和完整性的挑战，这对玩家体验优化至关重要。如果数据质量不佳，可能导致误判。复杂性的多因素影响也是一个挑战，例如在游戏研发早期，研发团队可能更关注游戏玩法而非稳定性，这需要多层团队协作来克服。技术的快速更新要求我们在技术选型和系统维护时，能够适应新技术的挑战，同时避免盲目追求新技术。此外，政策法规的稳定性影响也是一个挑战，尤其是在海外业务中，合规性和当地政策对稳定性建设有重要影响，需要我们在系统设计时提前考虑。

党受辉： 我注意到，当前行业中许多公司仍在加强监控能力，这反映出之前的监控欠账较多。监控是快速发现故障的关键，但随着新技术如容器的出现，传统的监控手段可能已不再有效，需要补充新的观测技术。

我认为，稳定性工程师应该在解决了故障发现问题、提升了救火效率之后，进一步从源头上减少故障的可能性。通常，我们认为软件生命周期中，70% 的故障是由于变更引入的，20% 是由于代码质量问题。因此，在解决了监控和故障定位问题后，SRE 应该尽可能将服务左移，即在更早的阶段介入，以预防故障的发生。

随着自动化和数据驱动的技术发展，未来可能实现更智能的发布和变更，这将是大多数公司需要重点布局的方向。但即便如此，SRE 工程师的作用并不仅限于此。在企业中，尤其是当企业领导或业务负责人不是技术出身时，他们可能更关注业务模式和盈利能力，而不是技术细节。因此，SRE 团队需要思考如何在业务模式和创新方面发挥作用。

我们已经在尝试将 SRE 的重点放在软件开发的早期阶段，例如研发服务。除了线上环境，企业内还有许多研发环境和预发布测试等关键环节。SRE 团队可以帮助研发团队在解决稳定性问题后提高效率，通过提供效率工具，从 SRE 的视角保障研发过程的可靠性。

嘉宾｜党受辉、周昕毅、刘昊、杨军 

本文来自微信公众号“InfoQ”（ID：infoqchina），作者：Kitty，36氪经授权发布。