PDF企业应用程序的可靠性
理解企业可靠性
Sanjay Sha
企业可靠性是一门学科，旨在确保应用程序以一致、可预测且经济高效的方式交付所需的业务功能，同时不损害可用性、性能和可维护性等核心方面。
虽然实现高水平的可靠性是大多数企业的共同目标，但涉及第三方应用程序的可靠性工程可能是一个复杂的领域。第一方软件可以构建模块化和可扩展的应用程序，并与企业的 IT 生态系统无缝集成。第三方软件并不总是具有相同的灵活性。在不损害功能和可靠性的前提下，将现成的企业应用程序整合到现有的 IT 生态系统中，是一个经典的工程和哲学问题，CIO 办公室必须始终处理这个问题。
尽管存在这种复杂性，企业仍然追求和选择第三方软件来驱动其 HR（人力资源）、法律和财务等业务部门，因为购买企业应用程序而不是内部构建软件在经济上是合理的。然而，企业有时仅根据所需的业务功能做出购买决策，而往往忽视应用程序的整体可靠性。这可能会损害应用程序的可用性和可支持性，并增加长期管理成本。
本文介绍了一组核心原则和工程方法，企业可以应用这些原则和方法来交付高度可靠且经济高效的应用程序，并帮助他们驾驭复杂的企业可靠性环境。
术语
以下术语贯穿全文
业务负责人 — 业务部门（如法律、财务或 HR）的负责人或领导者；业务负责人 和 客户 可以互换使用。
客户 — 业务部门（如法律、财务或 HR）的业务负责人。
企业应用程序 — 外部公司拥有的软件，也称为 第三方软件。
SLO（服务级别目标）— 衡量业务功能有效性的可量化目标。
SRE（站点可靠性工程）— 企业的支持组织。一些企业可能没有专门的 SRE 团队；相反，他们拥有 DevOps 和系统或 IT 管理员等支持团队。此处概述的原则和方法具有足够的通用性，可以应用于任何支持组织。
用户 — 代表企业应用程序消费者的组织员工。
供应商 — 第三方软件的提供商。
可靠性公理
可靠性公理是一组原则，强调有助于培养和维护企业可靠性文化价值观和行为。
文化 = 可靠性公理 (价值观) × 可靠性工程 (行为)
以下五个核心公理定义了企业可靠性，并构成了本文的基础：（1）关注客户；（2）选择合适的供应商；（3）投资于通用应用程序平台；（4）将可靠性工程化为具有成本效益；以及（5）建立以工程为中心的支持组织（或 SRE）。
关注客户
客户目标决定了应用程序的可靠性。拥有一套明确定义的客户目标是基础，因为这些目标可以转化为切实可衡量的目标。这些目标，也称为 SLO，驱动应用程序的整体可靠性态势，例如可用性、性能、数据完整性、监控和事件响应。SLO 确保应用程序经过工程设计，能够精确满足客户的需求。
选择合适的供应商
供应商的选择会影响核心应用程序的可靠性。选择企业应用程序不仅仅是购买满足业务功能的软件。它还涉及到与一家供应商合作，该供应商的思维方式和软件构建原则与企业相似（例如，设计上安全、可扩展的软件组件、用于扩展的开放 API 以及易于支持和维护）。
投资于通用平台
应用程序的整体可靠性是业务核心应用程序及其所有依赖项的可靠性总和。将基线依赖项转变为通用平台可以帮助标准化应用程序的管理方式并带来一致性。使用通用平台可以大大减少技术孤岛，并提高整体可靠性和效率。通用平台可能意味着拥有共享的部署管理器、CI/CD（持续集成/持续交付）框架或用于监控、日志记录、备份等的共享服务管理工作流程。
将可靠性工程化为具有成本效益
过度工程化可靠性会打破 ROI（投资回报率）曲线。可靠性是应用程序成熟度的函数，因此也是其整体可用性的函数。假设您有一项服务，其 SLO 为 99.9%。如图 1 所示，添加一个额外的 9（99.99%）会次线性地增加服务的可用性。
虽然将服务的可靠性从每月 43.2 分钟的停机时间提高到 4.32 分钟可能很诱人，但这可能代表着一项重大的工程壮举，而且价格昂贵。因此，在指定服务所需的可用性时，决策应基于业务需求：“为了满足业务目标，我的系统需要达到多高的可用性（多少个 9）？”
建立以工程为中心的支持组织
应用程序可靠性由 SRE 维护。设计一个完美的应用程序并不能保证高质量的生产体验——至少在没有 SRE 组织的支持下不能保证。应用程序和运行它的 IT 生态系统都在不断变化——开发人员推送新代码，供应商发布新的安全补丁，或者基础设施团队更新底层平台的软件。
可靠性不是“构建一次，终身无忧”的构造；而是一个持续维护和坚持其原则和方法的过程。认识到需求并投资于发展 SRE 技能的企业脱颖而出，因为他们认识到，没有这些技能，企业可靠性就无法维持。
设计企业可靠性工程
企业可靠性设计是一个多维度的问题，涉及多个实体：客户、供应商、平台工程、成本和 SRE 组织。本文的其余部分将扩展这些公理，并描述影响和塑造企业可靠性学科的行为、原则和方法。
客户目标
“如果您不了解您的客户目标，那么您就不需要作为一个组织存在。” 无论您是传统的 IT 组织还是成熟的 SRE 组织，这一基本原则都适用。
将客户目标转化为 SLO
在企业环境中，典型的客户是业务部门（如法律、财务或 HR）的负责人，他们试图实现特定的业务目标。拥有一套明确定义的业务目标为制定具体的功能需求奠定了基础，使您能够有效地将这些需求转化为可量化和可衡量的结果，也称为 SLO。
尽早定义 SLO 可以更好地设计和实施整个系统。然而，获得一套清晰的可衡量的 SLO 是一个详尽的过程，需要考虑许多因素（例如，技术上可行与不可行、昂贵与经济高效、可靠与脆弱）。让客户和供应商始终参与此过程至关重要，因为它有助于在需求、约束和权衡之间达成共识，并有助于弥合期望的 SLO 和可实现的 SLO 之间的差距。
记录 SLO，包括已建立的目标和阈值（例如，99.9% 的正常运行时间）的充分理由至关重要，因为这将成为所有各方（SRE 团队、软件供应商和客户）之间的合同。这种严谨性还创造了一种透明和开放的文化，以告知系统应如何设计以及服务应如何运行。要深入了解如何有效地工程化 SLO，请参阅 SRE 书籍中的 SLO 章节。1
对客户和供应商的同理心是关键
客户（业务负责人）可能并不总是对问题领域有相同的理解水平。他们的方法可能纯粹是业务驱动的，他们可能期望应用程序永远不会宕机。同样，供应商可能并不完全了解 IT 生态系统是如何设计的，并且无法独立运行以交付系统。SRE 团队应成为真正的合作伙伴，以在客户和供应商之间达成一致，并就总体目标、具体要求和领域约束达成共识。
鉴于第三方领域的性质，可能很难找到一个 100% 满足业务功能的完美系统，因为等式中存在许多变量（例如，第三方软件、硬件、成本和供应商）。因此，与客户紧密合作制定一套详细的需求，并区分核心需求与可选需求，有助于进行权衡分析——例如，如果应用程序存在约束，评估其对业务目标的影响，或重新审视和调整客户需求而不损害业务目标，或者完全寻找新的供应商。
带领客户从头到尾经历这个过程有助于他们更好地理解空间并权衡所有重要的考虑因素，最终使他们能够做出有效的业务驱动决策。
SLO 作为客户幸福的手段
基于客观目标解决客户幸福感是关键；最好以可衡量的方式（SLO）根据客户的目标来满足功能需求。客户只有一个基本标准：系统是否能够以经济高效且可靠的方式将业务目标转化为业务功能？
拥有这种客观的观点可以创造一种透明且不咎责任的文化。然而，要记住的关键点是，SLO 不是一成不变的：随着业务需求的发展，需要重新审视系统 SLO。因此，与客户定期重新审视 SLO 协议的严格规范有助于应对这些变化，并随着业务需求的发展调整范围和期望。
供应商选择
与供应商进行企业应用程序工程是一项长期投资，其范围超出了应用程序本身。因此，选择一家与企业的价值观和原则相符的供应商非常重要——例如，软件设计规范（规模和性能）、数据安全和隐私管理、开放标准的使用以及易于操作和维护。
为了确保供应商满足其要求，企业需要严格的评估和验证过程。两组不同的评估决定和塑造了应用程序的可靠性
• 功能评估：代表客户所需的业务功能。
• 基础设施评估：代表应用程序的 IT 要求。
功能评估
功能需求直接源自客户目标，构成了评估过程的基础。每个功能需求都有一组关键的功能特性。评估过程的目标是对这些特性进行深入分析，并评估第三方软件的可行性。
为了理解这一点，请考虑以下场景。假设您的企业正在评估第三方 IT 库存系统，以管理您的企业 IT 资产信息。您的业务目标之一是实时预测库存的供需情况。这可能会导致需要一个集中的全球库存数据库，每次结账时都会实时更新。
基于此场景，让我们分析一下功能评估应深入研究的核心特性。
功能规范
供应商是否理解功能需求和预期结果？在刚刚描述的场景中，功能需求是维护所有资产信息的全球库存数据库。预期结果是能够跟踪资产信息并实时更新全球库存数据库。
依赖项和约束
供应商是否需要了解任何核心依赖项或约束？例如，全球库存数据库是否依赖任何外部实体？读取和写入是否需要集中式数据库，还是需要分布式设置？两种方法的优缺点是什么？
功能接口
供应商是否理解此需求中涉及的所有端到端功能接口？例如，库存数据库是否有任何报告接口？管理员如何与数据库交互？用户在结账时如何与数据库交互？端到端流程是什么？
地域要求
企业是否在全球范围内开展业务？用户是否会从不同地区访问此库存系统？这些用户的具体性能和延迟要求是什么？
规模和负载要求
有多少用户将使用库存系统，包括全球和每个地区？这些用户的 QPS（每秒查询数）或负载要求是什么？是否存在任何峰值或非峰值容量要求或注意事项？
安全要求
供应商是否理解系统的安全态势？是否根据用户类型（例如，管理员与普通用户）存在任何特定的访问限制？身份验证和授权机制是什么？应用程序是否依赖于集中式授权服务，例如 LDAP（轻型目录访问协议）或 AD（活动目录）？是否存在单点登录依赖项？
合规性要求
供应商是否理解并满足此应用程序的合规性要求？
错误和异常处理要求
供应商是否理解基于系统设计的关键故障模式？供应商的软件如何处理异常（例如，请求超时、写入失败期间的重试和连接重置）？
发布管理
供应商使用什么软件发布管理规范？发布周期是什么？在发布给客户之前，如何测试更改？QA/资格认证流程是什么？
负载和性能测试以及功能验证
供应商是否有一个涵盖端到端工作流程的整体测试计划，并且是否包括所有边缘情况？衡量负载和性能的测试计划是什么？
基础设施评估
基础设施要求为整个应用程序创建了基础。因此，确保此基础层的端到端可靠性至关重要。
每个企业都是独一无二的，并且有自己的一套基础设施要求和约束。在评估企业应用程序时，您需要确保供应商能够遵守企业 IT 生态系统的要求。例如，假设您的企业已完全采用虚拟化以提高内部效率和其他业务原因。在这种情况下，供应商的应用程序应与 VMware 兼容并在 VMware 上获得支持。否则，该应用程序可能会成为您 IT 组织中的非标准模型，从而增加与基础设施、许可、硬件和支持相关的成本。
以下是一组关键的基础设施要求，以确保供应商的软件与企业的 IT 生态系统兼容。
核心基础设施
供应商必须满足企业的硬件、软件和操作系统要求。这包括 IT 团队支持的特定硬件型号、企业数据库、软件和操作系统版本。
网络
供应商必须满足网络的身份验证和授权要求——例如，LDAP 或 AD，或单点登录要求。
基础设施安全
供应商应理解并满足企业与访问管理、边界安全和数据加密相关的安全策略。
基础设施规模调整
企业应根据其功能需求制定具体的规模调整计划，包括环境数量以及计算和存储要求，并密切评估供应商，以确保其软件可以扩展并满足这些规模调整需求。
高可用性和灾难恢复
SRE 团队应根据 SLO 和客户目标清楚地了解可靠性要求。在与供应商合作时，确定高可用性设计（如主动-主动或主动-被动）、灾难恢复要求和策略以及数据恢复（恢复点目标）和还原（还原点目标）都至关重要。企业必须确保供应商的应用程序能够满足其要求，或者供应商愿意与 SRE 团队合作以提供所需的可靠性。
数据管理
供应商在数据完整性、备份、恢复和保留方面应具有明确的数据管理规范和方法。供应商是否具有强大的数据安全规范，例如对传输中和静态数据进行加密？
集成
列出 IT 生态系统所需的所有依赖系统和必要的集成——例如，身份验证服务（如 LDAP 或 AD）；企业邮件服务和必要的集成；以及服务管理工作流程，如集中式备份、监控和日志记录。
可操作性
确保供应商具有强大的软件更新/升级规范、明确定义的维护窗口等。
这些要求概述了您在选择企业应用程序时应评估的核心方面和特性。请注意，这并非详尽的列表，不同企业的要求可能有所不同。
功能和基础设施要求可能会严重影响应用程序的设计和交付。因此，评估这些要求的可行性是工程化应用程序可靠性的关键步骤。
通用应用程序平台
大多数企业依赖第三方软件来支持其业务部门的运营和需求（图 2）。然而，运行不同的第三方应用程序可能会导致企业内部存在大量不同的系统。应用程序之间没有通用基线使得长期维护服务的可靠性和效率变得更加困难。这为 SRE 团队带来了大量开销，并增加了组织的运营成本。
通用平台提供了一个标准化的操作环境，可以在其中运行系统的所有应用程序，从而提高企业的整体可靠性和效率。实施通用平台的关键原则是识别、构建和实施一组共享模块和标准，这些模块和标准可以在支持业务部门的应用程序之间重用。
另一方面，过度工程化通用平台可能会产生负面影响。如果平台有许多标准或变得过于僵化，企业的交付和执行速度可能会显着降低。
目标是制定一项策略，使企业能够在优化可靠性和保持交付和支持业务功能所需的开发速度之间找到适当的平衡。找到这种平衡需要仔细分析权衡和净收益。
通用平台布局
应用程序平台由一组模块组成，这些模块可以分为三个主要类别（图 3）
• 基础设施部署模块。
• 应用程序管理模块。
• 通用服务模块。
基础设施部署模块
基础设施部署模块基于一组资源需求（如 CPU、内存、操作系统和实例数）提供端到端应用程序环境的基于意图的部署。这种机制非常高效，因为工作流程只需配置一次，即可根据需要触发。它还提供了一个标准化、一致且可预测的环境，从而提高了整体可靠性。
许多企业已经开始采用开源技术来帮助他们管理应用程序的底层基础设施。Terraform 等工具提供了抽象，用于处理端到端环境的配置和部署，而与底层平台（例如，本地部署与云部署）无关。
应用程序管理模块
应用程序管理模块处理应用程序生命周期中的关键工作流程。这些工作流程的一些示例包括
• 用于部署应用程序配置的配置管理工作流程。
• 用于管理软件发布和回滚的发布管理工作流程。
• 用于管理密钥和证书部署的安全管理工作流程。
Puppet、Chef 和 Ansible 等软件解决方案为企业提供了跨应用程序编排这些工作流程的框架和解决方案。
??
通用服务模块
通用服务模块管理可以在所有应用程序之间共享的标准化工作流程，例如日志记录、监控和报告。此层还可以包括针对企业特定需求的自定义服务模块，例如自定义 Web 前端或单点登录服务。
通用服务模块的一些示例包括
• 监控模块，用于收集和发布指标以进行报告和警报。
• 备份模块，用于执行备份、保留和恢复。
• 日志收集模块，用于将日志安全地传送到集中式日志服务。
• 自定义 Weblogic/Tomcat 作为服务提供中间件功能。
• 托管 DBaaS（数据库即服务）模块，用于管理数据库工作流程。
将基础设施部署、应用程序管理和通用服务模块相结合，创建了一个平台，使企业能够摆脱管理单体应用程序，并进入模块化、可扩展和可重用应用程序的新领域。
成本工程
当企业选择第三方软件时，他们正在做出基于成本和 ROI 的决策，以使用“可靠”的企业应用程序，该应用程序能够以经济高效的方式交付业务功能。确定能够维持 ROI 曲线的适当可靠性与成本之间的权衡是成本工程的关键。
可靠性与成本的权衡
图 4 说明了可靠性（9 的数量）如何直接影响整体可用性或停机时间的减少。随着每个额外 9 的增加，减少量呈次线性。虽然添加一个 9 非常诱人，但重要的是要认识到工程化额外的 9 可能很昂贵，并且过度工程化可靠性会产生递减的 ROI。为了理解这一点，让我们看一下以下场景。
ABC 企业正在寻找一个可以提供市场分析和洞察的第三方销售应用程序。销售团队预测，通过利用这些洞察，他们平均每小时可以产生 600 美元的收入。他们每季度的收入目标约为 120 万美元。此应用程序所需的正常运行时间（可用性 SLO）是多少？
如果应用程序 100% 可用，则最大收入将为
净收入 = 一个季度的小时数（3 个月 × 30 天 × 24 小时 = 2,160）× 每小时收入（600 美元）
1,296,000 美元（约 129 万美元）= 一个季度 2,160 小时 × 每小时 600 美元
净收入（约 129 万美元）明显超过了 120 万美元的目标收入，但 100% 的可用性是不可行的。图 5 说明了如何选择满足 ROI 的完美可用性 SLO。
以下是此场景中得出的关键结论
1. 90% 的可用性 SLO 产生的收入约为 116 万美元，低于 120 万美元的目标收入。此 SLO 不可行。
2. 95% 的可用性 SLO 产生的收入约为 123 万美元，舒适地满足（略微超过）了 120 万美元的收入目标。此 SLO 可行。
3. 99% 的可用性 SLO 产生的收入约为 128 万美元，远远超过了 120 万美元的收入目标，但它带来了额外的开销
• 95% 的 SLO 保证每月停机时间不超过 36 小时，并且仍然可以舒适地满足目标收入。
• 相比之下，99% 的 SLO 保证每月停机时间不超过 7.2 小时，但工程和支持成本可能会更高。
• 只要工程化 99% SLO 的成本不超过 80,000 美元（128 万美元至 120 万美元），这就是一个可行的选择。
4. 每个额外 9 的净收入增长都提供了递减的回报（增量收入）——例如，在 99.99% 和 99.999% 之间
• 每月停机时间从 4.32 分钟显着减少到 25.92 秒，但收入增长仅为 116.64 美元。
• 要选择 99.999% 的 SLO，增加的工程成本应低于 116.64 美元。
考虑应用程序依赖项
要设计一个具有 99.9% SLO 的系统，经验法则是让所有关键依赖系统提供额外的 9（即 99.99%）。这意味着您必须考虑应用程序及其所有关键依赖项的可靠性投资（额外成本），因为一个系统的可用性仅与其 依赖项的总和 一样高。2
选择适合 ROI 曲线的 SLO
理想的 SLO 是能够以符合 ROI 曲线的可靠性程度交付所需功能的 SLO。在之前的场景中，最佳 SLO 将是 95%，因为它是满足业务目标（120 万美元）的最便宜的选择。
过度工程化可靠性会产生递减的 ROI
从之前的场景中可以明显看出，提高服务的可用性并不总是能转化为收入的显着增长。从场景中可以清楚地看出这一点。事实上，随着每个额外 9 的增加，工程化可靠性的好处呈次线性增长，打破了 ROI 曲线。
维护企业可靠性
可靠性不仅仅是一个系统设计问题。您可以拥有世界上设计最好的系统，但如果没有适当的严谨性和规范，维护系统的核心方面（如可用性、性能和安全性）可能会变得极其困难。可靠性是所有参与系统的团队（包括供应商、开发和 SRE）应共同承担的责任。然而，SRE 团队最终要对此负责，因为他们负责实现其 SLO。
设计标准化和统一性
当您认识到统一性的重要性并投资于标准化时，可靠性得以维护。企业应用程序的挑战之一是，供应商在软件技术、操作系统和工作流程编排方法（如发布管理和补丁管理）方面没有达成协议或共识。每个供应商都提供自己的风格。
SRE 的作用是发布他们支持的工具和技术组合（基本操作系统、发布管理和配置框架）的通用标准，以及他们期望供应商达到的最低运营成熟度（例如，自动化安装和无缝修补工作流程）。
依赖于多个软件供应商的成熟企业认识到拥有基线生态系统和强大的运营成熟度的重要性。他们在寻找第三方应用程序时，不仅会考虑业务功能，还会考虑生态系统的成熟度。
变更管理
变更很强大。您可以构建一个高度可靠的系统，但一个小的变更（错误的配置推送或软件错误）可能会损害整个系统的可靠性。维护可靠性来自于拥有一套变更管理规范，其中包含可以检测、预防或最大限度减少问题影响的制衡措施。SRE 应负责维护此规范。考虑以下制衡措施。
测量、监控和警报
测量、监控并引入阈值以警报 SLO 关键路径上的所有内容。这提供了主动检测和修复问题的能力。
简化的变更和发布管理
要求所有变更都经过验证和回归测试。这应作为引入变更的所有团队的强烈要求强制执行。
专用金丝雀环境
每个关键生产应用程序都应具有专用的金丝雀环境作为先决条件。它应该是生产环境的精确副本。这允许测试面向用户的冲击，例如负载和性能。
分阶段推出
分阶段推出有助于揭示仅在生产中发现的不可预见的问题（测试未发现的问题）。这提供了快速回滚变更并最大限度减少影响的灵活性。
回滚和还原
另一个关键规范是确保每个变更都可以回滚。尤其重要的是要了解变更的依赖关系图，并确保原子回滚。这在复杂系统中很困难，但在这种情况下，对于大多数关键变更，拥有清晰的还原点是关键。
错误预算
错误预算是一个简单的概念。每个服务都有一个目标 SLO，如果它超过该 SLO，那么正常运行时间的正增量将成为用于推送任何变更或发布的预算。SRE 书籍1 中深入解释了这个强大的概念。与您的应用程序开发团队分享此规范是确保服务可靠性的好方法。
中断和事件
无论系统多么可靠，您都应该预测并为灾难做好准备。与其解决无中断问题（这不切实际），不如将重点放在有效管理中断（最大限度减少停机时间）并从中学习，以便相同的模式不会重复出现。
弹性测试
这里的目标是通过破坏系统、观察破坏的影响并随后提高应用程序的可靠性来压力测试应用程序弹性。
事件准备
SRE 团队应定期进行消防演习，以练习事件管理，其中包括与合作伙伴团队进行广泛协调、及时与利益相关者沟通以及尽快恢复服务。在没有这种准备的情况下响应和处理实际事件可能会降低恢复服务的速度和效率。
从中断中学习
重复发生的中断不再是中断；而是一个错误。对于每次中断，都应进行彻底的事后分析，明确指出中断的根本原因，并重点关注哪里出了问题以及今后可以改进什么。对于企业而言，培养不咎责任的事后分析文化至关重要，这种文化侧重于提高应用程序的可靠性。
企业可靠性的未来
在过去的几年中，云平台提供商越来越关注企业，提供一系列安全、可靠且经济高效的产品，从高度可扩展的计算、存储和网络服务到现代化的托管产品，如容器即服务 (Kubernetes)、无服务器和 DBaaS。此外，云提供商还在 AI（人工智能）、ML（机器学习）和大数据领域交付高级服务，为企业重新思考和转型其业务部门开辟了广阔的可能性。
这种转变为企业拥抱和采用云提供了一个巨大的机会。然而，进行如此大规模的迁移带来了一个新的挑战：企业如何在不降低可靠性的情况下适应和快速发展？
云迁移策略
企业通常具有复杂的业务需求，因此将 100% 的工作负载迁移到单个云提供商的直接迁移策略可能不可行。混合云环境为工作负载在公共云和私有云环境中无缝运行提供了灵活性。这种方法大大简化了云采用策略，并提供了一个受控环境，确保在向云过渡的整个过程中保持可预测的可靠性水平。
认真拥抱混合云战略的企业在整体可靠性方面风险更低，并且能够更快地实现云转型。投资于通用应用程序平台，并采用 Kubernetes (https://kubernetes.ac.cn/)、Istio (https://istio.ac.cn/) 和无服务器计算 (https://en.wikipedia.org/wiki/Serverless_computing) 等技术，能够提供灵活的工作负载操作能力，且不受云提供商的限制。诸如 GCP (Google Cloud Platform) Anthos 平台 (https://cloud.google.com/anthos/) 等技术也可以帮助企业以可靠且高效的方式加速向云端转型。
VEC 生态系统
在供应商、企业和云提供商之间建立牢固的关系对于企业可靠性的未来至关重要。云提供商需要通过合作伙伴计划激励软件供应商，以实现第三方软件的现代化，使其拥抱基于云的技术并构建经过认证的多云兼容软件产品。这种 VEC（供应商-企业-云）生态系统与技术转变相结合，将带来塑造企业领域的快速转型。
维护企业可靠性是一个持续的过程，随着云计算的兴起，它正处于关键时刻。未来十年将是利用云能力进行大规模企业转型的时代，只有那些掌握可靠性工程学科的企业才能成功转型到基于云的企业计算领域。
参考文献
1. Jones, C.、Wilkes, J.、Murphy, N. 和 Smith, C. 2016 年。《服务级别目标》。载于《站点可靠性工程》，Betsy Beyer、Chris Jones、Jennifer Petoff 和 Niall Richard Murphy 编辑。O'Reilly Media；https://landing.google.com/sre/sre-book/chapters/service-level-objectives/。
2. Treynor, B.、Dahlin, M.、Rau, V. 和 Beyer, B. 2017 年。《服务可用性的计算》。acmqueue 15(2); https://queue.org.cn/detail.cfm?id=3096459。
相关文章
迈向软件定义 SLA
公有云中的企业计算
Jason Lango
https://queue.org.cn/detail.cfm?id=2560948
企业软件即服务
在线服务正在改变软件的本质。
Dean Jacobs
https://queue.org.cn/detail.cfm?id=1080875
为什么云计算永远不会免费
云提供商之间的竞争可能会压低价格，但代价是什么？
Dave Durkee
https://queue.org.cn/detail.cfm?id=1772130
Sanjay Sha 是 Google 的 SRE 经理。他是一位资深的 Google 员工，拥有超过 14 年在 Google 运行多个大型系统的经验。他领导企业领域，管理 SRE 团队，为 Google 的关键业务垂直领域提供支持。他目前正在参与 Corp to Cloud 计划，旨在在 GCP 上运行 Google 的内部企业工作负载。
版权所有 © 2019，归所有者/作者所有。出版权已授权给 。
最初发表于 Queue 杂志第 17 卷第 5 期 —
在 数字图书馆 中评论本文
更多相关文章
Robert Guo - MongoDB 的 JavaScript Fuzzer
随着 MongoDB 随着时间的推移变得功能更丰富和复杂，开发更复杂的方法来查找错误的需求也在增长。三年前，MongDB 在其工具包中添加了一个自研的 JavaScript fuzzer，它现在是我们最高产的错误查找工具，在两个发布周期中负责检测到近 200 个错误。这些错误涵盖了从分片到存储引擎的各种 MongoDB 组件，症状从死锁到数据不一致不等。fuzzer 作为 CI（持续集成）系统的一部分运行，在那里它经常捕获新提交代码中的错误。
Robert V. Binder、Bruno Legeard、Anne Kramer - 基于模型的测试：现状如何？
您可能听说过 MBT（基于模型的测试），但像许多没有使用过 MBT 的软件工程专业人士一样，您可能对其他人使用这种测试设计方法的经验感到好奇。从 2014 年 6 月中旬到 2014 年 8 月初，我们进行了一项调查，以了解 MBT 用户如何看待其效率和有效性。2014 年 MBT 用户调查是 2012 年类似调查的后续，向所有评估或使用过任何 MBT 方法的人开放。它的 32 个问题包括一些来自 2013 年高级自动化测试用户会议上分发的调查。一些问题侧重于 MBT 的效率和有效性，提供了管理者最感兴趣的数据。
Terry Coatta、Michael Donat、Jafar Husain - EA 的自动化 QA 测试：事件驱动
对于数百万游戏爱好者来说，在 Electronic Arts 担任 QA（质量保证）测试员的职位一定看起来像一份梦想的工作。但从公司的角度来看，与 QA 相关的开销可能看起来非常可怕，尤其是在大型多人游戏时代。
James Roche - 在质量保证中采用 DevOps 实践
长期以来，软件生命周期管理一直是一项受控的活动。产品设计、开发和支持的持续时间是可预测的，以至于公司及其员工围绕产品发布安排他们的财务、假期、手术和合并。当开发人员忙碌时，QA（质量保证）就很轻松。随着发布周期的编码部分接近尾声，QA 接管，而支持力度加大。然后，当产品发布时，开发人员松了一口气，休息一下，然后重新开始循环，而支持人员则转向忙于支持新产品。
© 保留所有权利。