登录
首页
vwin德赢AC米兰官网网址本期:2022年7月
实践
企业应用的可靠性
信贷:Boscorelli
图1．
设计企业可靠性工程
为企业可靠性进行设计是一个多维度的问题，它跨越多个实体:客户、供应商、平台工程、成本和SRE组织。本文的其余部分将对这些公理进行扩展，并描述影响和塑造企业可靠性规程的行为、原则和方法。
客户的目标。＂如果你不了解你的客户目标，那么你就不需要作为一个组织存在。“无论你是一个传统的IT组织还是一个成熟的SRE组织，这个基本原则都是正确的。
将客户目标转化为slo。在企业设置中，典型的客户是试图实现特定业务目标的垂直业务(如法律、财务或人力资源)的所有者。拥有一组定义良好的业务目标为开发具体的功能需求奠定了基础，允许您有效地将这些需求转换为可量化和可度量的结果，也称为SLOs。
尽早定义SLOs可以更好地设计和实现整个系统。然而，获得一组清晰的可度量slo是一个包含许多考虑因素的详尽过程(例如，什么在技术上可行vs.不可行，昂贵vs.成本效益，可靠vs.脆弱)。在整个过程中密切地让客户和供应商参与进来是至关重要的，因为它发展了对需求、约束和权衡的共同理解，并有助于协调理想的slo和可实现的slo之间的差距。
记录slo，包括为已建立的目标和阈值(例如，99.9的正常运行时间)提供强有力的理由是关键，因为这成为所有各方(SRE团队、软件供应商和客户)之间的契约。这种严格也创造了一种透明和开放的文化，告知系统应该如何设计和服务应该如何操作。要深入了解有效的工程SLO，请参阅SRE书中的SLO章节。1
对客户和供应商的同理心是关键。客户(业务所有者)可能并不总是对问题空间有相同程度的理解。他们的方法可能纯粹是业务驱动的，并且他们可能希望应用程序永远不会崩溃。同样，供应商可能不能完全理解IT生态系统是如何设计的，并且不能独立地操作以交付系统。SRE团队应该成为客户和供应商之间的真正合作伙伴，并开发对总体目标、特定需求和领域约束的共同理解。
鉴于第三方领域的性质，可能很难找到一个满足100%业务功能的完美系统，因为等式中有许多变量(例如，第三方软件、硬件、成本和供应商)。因此，与客户密切合作，开发一组详细的需求，并区分核心和可选需求有助于权衡分析，例如，如果应用程序有约束，评估它们对业务目标的影响，或者在不影响业务目标的情况下重新访问和调整客户需求，或者完全找到一个新的供应商。
让客户从头到尾经历这个过程可以帮助他们更好地理解空间，并权衡所有重要的考虑因素，最终允许他们做出有效的业务驱动的决策。
SLOs是使顾客满意的一种手段;求解SLOs。以客观上的目标为基础，解决顾客幸福问题是关键;最好以可测量的方式(SLOs)满足基于客户目标的功能。客户只有一个基本的标准:系统是否能够以一种具有成本效益和可靠的方式将业务目标转化为业务功能?
有了这种客观的观点，就创造了一种透明和无可指责的文化。然而，要记住的关键一点是，slo并不是一成不变的:随着业务需求的发展，需要重新访问系统slo。因此，与客户定期重访SLO协议的严格纪律有助于处理这些更改，并随着业务需求的发展调整范围和期望。
供应商的选择。与供应商合作的企业应用程序工程是一项超越应用程序本身的长期投资。因此，选择符合企业价值观和原则(例如，软件设计原则(规模和性能)、数据安全和隐私管理、使用开放标准以及操作和维护的便利性)的供应商是很重要的。
为了确保供应商满足其需求，企业需要一个严格的评估和验证过程。两组截然不同的评估决定和塑造了应用程序的可靠性:
- 功能评估:表示客户所需的业务功能。
- 基础设施评估:表示应用程序的IT需求。
功能评价。功能需求直接来源于客户目标，并构成了评估过程的基础。每个功能需求都有一组关键功能特征。评估过程的目标是对这些特性进行深入分析，并评估第三方软件的可行性。
要理解这一点，请考虑以下场景。假设您的企业正在评估一个第三方IT库存系统，以管理您的企业IT资产信息。您的业务目标之一是实时预测库存的供应和需求。这可能导致对集中式全局库存数据库的需求，该数据库在每次结帐发生时实时更新。
基于这个场景，让我们分析功能评估应该深入研究的核心特征。
功能规范。供应商是否理解功能需求和预期结果?在刚才描述的场景中，功能需求是为所有资产信息维护一个全局库存数据库。预期的结果是能够跟踪资产信息和实时更新全球库存数据库。
依赖和约束。供应商需要了解任何核心依赖关系或约束吗?例如，全局库存数据库是否依赖于任何外部实体?读写需要集中式数据库，还是需要分布式设置?这两种方法的优缺点是什么?
尽早定义SLOs可以更好地设计和实现整个系统。然而，获得一组明确的可测量slo是一个详尽的过程。
功能接口。供应商是否理解此需求中涉及的所有端到端功能接口?例如，库存数据库是否有任何报告接口?管理员如何与数据库交互?用户在签出时如何与数据库交互?什么是端到端流程?
地理的要求。该企业是否在全球范围内设有分支机构?用户是否可以从不同的区域访问这个库存系统?这些用户的具体性能和延迟需求是什么?
规模和负载要求。在全球和每个地区，有多少用户会使用库存系统?这些用户的QPS(每秒查询次数)或加载需求是什么?是否有任何高峰或非高峰的容量要求或注意事项?
安全需求。供应商是否了解系统的安全态势?是否有基于用户类型的特定访问限制(例如，管理员与普通用户)?认证和授权机制是什么?应用程序是否依赖于集中授权服务，如LDAP(轻量级目录访问协议)或AD(活动目录)?是否存在单点登录依赖项?
遵从性需求。供应商是否理解并满足此应用程序的遵从性要求?
处理需求。供应商是否了解基于系统设计的关键故障模式?供应商的软件如何处理异常(例如，请求超时、写失败期间的重试和连接重置)?
发布管理。供应商使用什么软件发布管理规程?发布周期是什么?在发布给客户之前如何测试变更?什么是质量保证/确认过程?
测试和验证。供应商是否有一个涵盖端到端工作流的整体测试计划，它是否包括所有的边缘用例?测量负载和性能的测试计划是什么?
基础设施评估。基础设施需求为整个应用程序创建基础。因此，确保这个基础层的端到端可靠性是至关重要的。
每个企业都是独特的，有自己的一组基础设施需求和约束。在评估企业应用程序时，您希望确保供应商能够满足企业IT生态系统的需求。例如，假设您的企业出于内部效率和其他业务原因完全采用了虚拟化。在这种情况下，供应商的应用程序应该与VMware兼容并得到VMware的支持。否则，应用程序可能成为IT组织中的非标准模型，从而提高与基础设施、许可、硬件和支持相关的成本。
以下是一组关键的基础设施需求，以确保供应商的软件与企业的IT生态系统兼容。
核心基础设施。供应商必须满足企业的硬件、网络和操作系统需求。这包括IT团队支持的特定硬件模型、企业数据库、软件和操作系统版本。
网络。厂商必须满足网络的认证授权要求，如LDAP、AD、单点登录等。
Infrastrucutre安全。供应商应该理解并满足企业与访问管理、周界安全和数据加密相关的安全策略。
基础设施规模。企业应该制定具体的规模调整计划，包括基于其功能需求的环境数量以及计算和存储需求，并密切评估供应商，以确保其软件可以伸缩并满足这些规模调整需求。
高可用性和灾难恢复。SRE团队应该清楚地了解基于SLOs和客户目标的可靠性需求。决定高可用性设计，如主动-主动或主动-被动、灾难恢复需求和策略，以及数据恢复(恢复点目标)和恢复(恢复点目标)，在与供应商合作时都是至关重要的。企业必须确保供应商的应用程序能够满足其需求，或者供应商愿意与SRE团队协作以提供所需的可靠性。
数据管理。当涉及到数据完整性、备份、恢复和保留时，供应商应该有明确的数据管理规程和方法。供应商是否有强大的数据安全规程，如传输和静止数据的加密?
集成。列出IT生态系统所需的所有依赖系统和必要的集成，例如，认证服务，如LDAP或AD;公司邮件服务和必要的集成;以及集中备份、监视和日志记录等服务管理工作流。
可操作性。确保供应商对软件更新/升级有很强的纪律，明确定义维护窗口，等等。
这些需求概述了在选择企业应用程序时应该评估的核心方面和特征。注意，这不是一个详尽的列表，不同企业的需求可能不同。
功能和基础设施需求会严重影响应用程序的设计和交付。因此，评估这些需求的可行性是设计应用程序可靠性的关键步骤。
通用应用平台。大多数企业依靠第三方软件来支持其业务垂直领域的运作和需求(图2)．然而，运行不同的第三方应用程序可能导致企业中存在大量不同的系统。没有跨应用程序的公共基线会使维护服务的可靠性和效率随着时间的推移变得更加困难。这为SRE团队创造了大量的开销，并增加了组织的运营成本。
图3)：
基础设施部署模块基于一组资源需求(如CPU、内存、操作系统和实例数量)，提供基于意图的端到端应用程序环境部署。这种机制非常高效，因为工作流只需要配置一次，并且可以根据需要触发。它还提供了标准化、一致和可预测的环境，从而提高了总体可靠性。 许多企业已经开始采用开源技术来帮助他们管理应用程序的底层基础设施。诸如terrform之类的工具提供了一些抽象来处理端到端环境的供应和部署，而这些环境与底层平台无关(例如，在premises vs. cloud)。 应用管理模块在应用程序的生命周期内处理关键工作流。这些工作流程的一些例子包括: Puppet、Chef和Ansible等软件解决方案为企业提供了跨应用程序编排这些工作流的框架和解决方案。 常用业务模块管理可以跨所有应用程序共享的标准化工作流，例如日志记录、监视和报告。这一层还可以包括针对企业特定需求的定制服务模块，例如定制web前端或单点登录服务。 一些公共服务模块的例子包括: 结合基础设施部署、应用程序管理和公共服务模块，创建了一个平台，使企业能够摆脱单片应用程序的管理，进入模块化、可扩展和可重用应用程序的新领域。 工程成本。当企业选择第三方软件时，他们正在做一个基于成本和roi的决定，即使用一个“可靠的”企业应用程序，以一种具有成本效益的方式交付业务功能。确定维持ROI曲线的正确的可靠性-成本权衡是成本工程的关键。 Reliability-to-cost权衡。图4说明可靠性(9的数量)如何直接影响总体可用性或减少停机时间。每增加9个减少量是次线性的。虽然增加一个9是非常诱人的，但重要的是要认识到设计一个额外的9可能是昂贵的，而过度设计可靠性会产生递减的ROI。为了理解这一点，让我们看看下面的场景。 考虑应用程序的依赖关系。要设计一个具有99.9% SLO的系统，经验法则是让所有关键依赖系统提供额外的9个SLO(即99.99)。这意味着您必须考虑应用程序及其所有关键依赖项的可靠性投资(额外成本)，因为系统的可用性仅为其依赖项的总和。2 选择一个符合ROI曲线的SLO。理想的SLO是交付所需功能并具有符合ROI曲线的可靠程度的SLO。在前面的场景中，最好的SLO是95%，因为它是满足业务目标(120万美元)的最便宜的选项。 过度设计可靠性会导致ROI递减。从前面的场景中可以明显看出，增加服务的可用性并不总是转化为收入的显著增长。从这个场景中可以明显看出这一点。事实上，每增加9个，可靠性工程的收益就会以次线性的方式增加，从而打破ROI曲线。 可靠性不仅仅是一个系统设计问题。您可以拥有世界上设计最好的系统，但是如果没有适当的严密性和纪律，保存系统的核心方面，例如可用性、性能和安全性，将变得非常困难。可靠性是系统中涉及的所有团队应该共同承担的责任，包括供应商、开发和SRE。但是，SRE团队最终是负责的，因为他们负责实现他们的SLOs。在应用程序的生命周期中，有几个关键的节点，在这些节点上维护适当的严密性可以转化为维护服务的可靠性。 标准化和统一性的设计。当您认识到一致性的重要性并投资于标准化时，可靠性就会得到保留。企业应用程序的挑战之一是，在软件技术、操作系统和工作流编排方法(如发布管理和补丁管理)的通用标准方面，供应商之间没有达成协议或共识。每个供应商都提供自己的口味。 SRE的角色是发布他们支持的工具和技术组合(基本操作系统、发布管理和配置框架)的通用标准，以及他们期望从供应商那里获得的最小操作成熟度(例如，自动安装和无缝补丁工作流)。 依赖于多个软件供应商的成熟企业认识到拥有一个基线生态系统和强大的操作成熟度的重要性。在寻找第三方应用程序时，他们不仅要考虑业务功能，还要考虑生态系统的成熟度。 变更管理。改变是强大的。您可以构建一个高度可靠的系统，但一个小的更改(错误的配置推送或软件错误)就可能危及整个系统的可靠性。保持可靠性来自具有一套严格的变更管理检查和平衡，这些检查和平衡可以检测、防止或最小化问题的影响。SRE应该负责维护这种严密性。考虑以下的制衡。 测量、监视和警报。测量、监视并引入阈值，以警报SLO关键路径上的所有内容。这提供了主动检测和修复问题的能力。 流线的变化。要求所有更改都经过验证和回归测试。这应该在引入变更的所有团队中作为一个强大的需求来执行。 专用金丝雀环境。每个关键的生产应用程序都应该有一个专用的canary环境作为先决条件。它应该是生产环境的精确副本。这允许测试面向用户的影响，如负载和性能。 分阶段交付)帮助揭示仅在生产中发现的不可预见的问题(测试中未发现的问题)。这提供了快速回滚更改并将影响最小化的灵活性。 回滚和恢复。另一个关键原则是确保每个更改都可以回滚。理解变更的依赖关系图并确保原子回滚尤其重要。这在复杂的系统中是很困难的，但是在这种情况下，有一个明确的恢复点是大多数关键更改的关键。 错误的预算是一个简单的概念。每个服务都有一个目标SLO，如果它超过了该SLO，则正常运行时间的正增量将成为推动任何更改或发布的预算。这是SRE书中深入解释过的一个强有力的概念与您的应用程序开发团队共享这种严格性是确保服务可靠性的好方法。 停机和事故。无论一个系统多么可靠，都应该预料到并为灾难做好准备。与其解决不停机的问题(这是不切实际的)，还不如将重点放在有效地管理停机(尽量减少停机)并从中学习，这样就不会重复相同的模式。 弹性测试。这里的目标是通过破坏系统来对应用程序的弹性进行压力测试，观察破坏的影响，然后改进应用程序的可靠性。 事件的准备。SRE团队应定期进行消防演习，以实践事故管理，包括与合作伙伴团队的广泛协调，及时与利益相关方沟通，并尽快恢复服务。如果没有这样的准备，响应和处理实际事件会降低恢复服务的速度和有效性。 从中断中学习。重复的停机不再是停机;这是一个错误。对于每一次宕机，都应该进行彻底的事后分析，清楚地确定宕机的根本原因，并关注哪里出了问题，以及今后可以改进哪些方面。对于企业来说，培养一种专注于提高应用程序可靠性的无可指责的事后分析文化是至关重要的。 在过去的几年里，云平台提供商越来越关注企业，提供了一套安全、可靠、具有成本效益的产品，从高度可伸缩的计算、存储和网络服务到现代化的管理产品，如容器即服务(Kubernetes)、无服务器和DBaaS。此外，云提供商正在提供AI(人工智能)、ML(机器学习)和大数据领域的先进服务，为企业重新思考和转型其业务垂直领域提供了广泛的可能性。 这种转变为企业提供了拥抱和采用云计算的巨大机遇。然而，进行如此大规模的迁移带来了一个新的挑战:企业如何在不降低可靠性的情况下适应并快速发展? 云迁移策略。企业通常有复杂的业务需求，因此将100%的工作负载迁移到单个云提供商的“提升-转移”策略可能是不可实现的。混合云环境为工作负载提供了跨公共和私有云环境无缝操作的灵活性。这种方法极大地简化了云采用策略，并提供了一个受控的环境，确保在向云过渡的整个过程中具有可预测的可靠性级别。 深思熟虑地采用混合云策略的企业在整体可靠性方面的风险更小，并且有更快的云转换路径。投资一个通用的应用程序平台，并采用诸如Kubernetes (https://kubernetes.io/)， Istio (https://istio.io/)和无服务器计算(https://en.wikipedia.org/wiki/Serverless_computing)，提供了操作工作负载的灵活性，与云提供商无关。诸如GCP(谷歌云平台)Anthos平台(https://cloud.google.com/anthos/)也可以帮助企业以可靠和高效的方式加快向云的过渡。 VEC的生态系统。在供应商、企业和云提供商之间建立牢固的关系对企业可靠性的未来至关重要。云提供商需要通过合作项目激励软件供应商，使第三方软件现代化，采用基于云的技术，并构建经过认证的兼容多云的软件产品。这种VEC(供应商-企业-云)生态系统加上技术变革将带来企业领域的快速变革。 维护企业可靠性是一个持续的过程，随着云技术的出现，这一过程正处于关键时刻。下一个十年将是利用云能力进行大规模企业转型的时代，只有那些掌握了可靠性工程规程的企业才能成功转型到基于云的企业计算领域。 转向软件定义的sla 企业软件即服务 为什么云计算永远不会免费 1.C.琼斯，威尔克斯，J.墨菲，N.和C.史密斯，服务级别目标。站点可靠性工程。B.拜尔C.琼斯，J.皮托夫和N.R.墨菲编。奥莱利传媒，2016;https://landing.google.com/sre/sre-book/chapters/service-level-objectives/． 2.Treynor, B.， Dahlin, M.， Rau, V.， Beyer, B.服务可用性的计算。acmqueue 15， 2 (2017);https://queue.acm.org/detail.cfm?id=3096459． 数字图书馆是由计算机协会出版的。版权所有©2020 ACM, Inc. 没有找到条目
图5阐述了如何选择满足ROI的完美可用性SLO。
维护企业可靠性
企业可靠性的未来
在queue.acm.org
杰森Lango
https://queue.acm.org/detail.cfm?id=2560948
院长雅各布斯
https://queue.acm.org/detail.cfm?id=1080875
戴夫Durkee
https://queue.acm.org/detail.cfm?id=1772130
参考文献
