得益于丰富的第三方云基础设施、API和SaaS工具，我们比以往任何时候都更快、更具功能地构建软件。
但是，如果这些云提供商出现故障，我们也会随之停机。由于大多数供应商拒绝提供其平台的可见性，我们只能手忙脚乱地问，“哪里出问题了?是我们还是他们”
这就是为什么当我们谈论强大云服务的承诺时，还需要谈论问题，包括供应商在出现故障时如何减轻后果，以及在此期间如何缓解缺乏可见性的问题。
云依赖性非常棒，前提是不出现问题
上游云依赖性——即AWS、Auth0、GitHub、Twilio等软件——正变得越来越受欢迎和重要。这是因为建立在第三方云依赖性之上并与之合作可以使我们的软件变得更好。因此，我们越来越多地转向第三方云应用程序来为支持产品和运维业务。
然而，我们需要通过这种创新来解决一个重要问题：我们的可靠性在很大程度上受到依赖关系可靠性的影响。
更多的云依赖性=更少的可靠性
你可能会认为，如果你依赖于运行时间为99.99%的多个服务，你就会得到一个运行时间为99.9%的产品。但事实并非如此。事实上，当添加更多的服务时，你可以安全地提供的正常运行时间实际上会减少。
这是因为你推出的每一种产品，都会将所用产品的不可靠性引入到自己产品的可靠性中(即使它非常小)。最简单地说，如果你添加一个运行时间为99.99%的硬依赖项，你需要从应用程序所能达到的最佳运行时间中减去大约0.01%。
虽然0.01%看起来微不足道，但它与你使用的每一项服务加在一起。根据正常运行时间的研究，70%的主要SaaS停机与上游云依赖性问题有关。事实上，根据产品或应用程序的不同，工程团队可能会发现，25%至70%的可警报事件来自第三方云依赖性问题。
缺乏可见性
因此，考虑到云供应商的可靠性，对它们的可见性将是一个高度优先事项。不幸的是，目前这种可见性并不足。
更重要的是，当前的可观察性工具在内部关注第一方和第二方信号，迫使我们推断云服务的健康状况。因此，我们无法以高效、及时的方式回答“是我们还是它们”的问题。
供应商状态页是手动更新的，如果它们有更新的话。因此，状态页平均在问题开始后29分钟更新，并且仅针对最严重的问题进行更新。我们大多数人都不得不求助于推特和黑客新闻，以获取有关关键可靠性数据的最新信息。
这种现实导致：
——MTTD、MTTI和MTTR延长导致不必要的停机时间
——低效、信息不足的事件响应
——错失避免事故的机会
我们甚至没有让供应商对它们的SLA负责。
什么是供应商SLA责任?
无法了解上游服务运行状况的另一个后果是，这些供应商掌握了可靠性数据和SLA合规性的所有权力。让我们思考一下：
——他们根据自己的规格定义SLA。
——只有他们愿意，他们才就问题进行沟通。
——他们不会在充满信任问题的状态页之外共享度量标准。
——他们要求客户在出现问题时承担举证责任。
如果我们没有数据来知道他们是否按照自己的可靠性定义保持可靠(这可能与你的不同)，那么就无法追究云供应商的责任。
是时候改变了。
软件制造商值得更好的
我们需要什么才能达到适当的可见性水平并避免依赖不可靠性的陷阱?
——及时、详细的云依赖性健康指标。我们应该像对待第一方和第二方软件一样，对第三方依赖具有类似的可见性。云供应商与我们编写和运维的软件同样重要，甚至更重要。如果没有云依赖性健康指标，我们就只能在没有完整上下文的情况下回答“是我们还是他们”的问题。
——特定于我们的服务状态以及我们对产品的使用。停机很少会同时导致所有客户的整个产品瘫痪。仅仅说“一些客户的错误率正在上升”是不够的。相反，我们应该知道哪些功能受到了影响，在哪里，为谁服务，最重要的是，我们的帐户/资源是否受到了影响。在没有必要的时候，不要让我们用模糊的状态页更新来扰乱事件响应。
——所有第三方服务健康信息的单一位置。在事件响应过程中，时间至关重要，我们不能浪费时间在15个不同的状态页面、Twitter、Hacker News和内部仪表板之间来回切换。我们应该在一个地方实时完整地查看所依赖的每一个第三方服务，以及应用指标、日志和跟踪。
——控制我们获得可见性的内容、地点和方式。供应商拥有所有的权力，他们迫使我们求助于他们，并依赖于一种常见的状态页面体验。除了可以访问服务运行状况指标(而不仅仅是状态页更新)，我们还应该以访问和控制自己的应用程序指标的方式访问云依赖性指标。我们值得一流的Slack集成、本地Datadog插件、PagerDuty集成、Webhook等。
如何让供应商对其承诺的可靠性负责?
——独立的SLA权威机构。供应商掌握着SLA的所有权力，按照他们的意愿对其进行定义，如果他们愿意，则报告违规行为，但如果他们想要退款，则强制客户证明违规行为。它们就是看守鸡舍的狐狸。随着每年全球SaaS支出超过1460亿美元，我们应该有一个独立的SLA合规仲裁者，写入合同。
——建立在数据基础上的供应商/客户合作伙伴关系。很多次，我们坐在QBR中，云供应商和他们的客户在可靠性上存在分歧，每个人都使用自己的数据来支持信念。大多数云供应商希望为客户做正确的事情，大多数客户希望帮助供应商提高可靠性。然而，每个人都只看重自己的数据。共享可靠性数据应该成为常态，为所有人建立更好的可靠性桥梁。
——社区基准和基线。你知道你的云依赖流量是否和每个客户的流量一样吗?你知道一家供应商一年中预计会发生多少次停机，或者他们通常会以多快的速度解决这些停机吗?不要在状态页面上查看这些信息;它会误导你。我们不仅应该得到关于自己云服务体验的指标，还应该知道这些指标与其他指标以及预期指标的比较情况。
——主动沟通。在事件发生期间，供应商通常知道自己有问题，但会等待更新状态页面，直到他们获得事件的明确细节，或者更糟的是，得到营销主管的批准。在这些情况下，简单的“我们认为我们可能有某种问题。请继续关注细节”会有很大帮助，但这种情况很少发生。同样，供应商不应该等到客户发现他们违反了SLA，而不是自己承认问题。
——用于状态页的w3c标准。很难想象在一个世界里，状态页在创建更大更好的云依赖健康可见性方面没有发挥作用。当转向状态页时，我们应该得到一致的体验，这样我们才能清楚、快速地找到需要的数据。利用云依赖性构建软件就像使用互联网浏览器访问它们一样常见，而状态页几乎是所有云产品的基本方面。w3c状态页标准可以推动行业向前发展，使状态页发布者和用户的生活更加美好。
云客户权利法案将对我们的软件可靠性实践产生深远影响，但这一现实还有很长的路要走。今天有可能获得这种可见性吗?
填补自己所缺少的
对第三方可靠性的可见性应该是我们自身可靠性工作的关键组成部分。“是我们还是他们”的问题可以而且应该迅速而明确地得到回答。但是，在云供应商给应得的东西之前，我们可以自己做一些事情来提高可见性和降低风险。
我们应该像对待内部依赖一样对待我们的第三方依赖。确切地知道你有什么依赖关系，把它们包括在你的服务目录中，并为它们提供运行手册。从那时起，我们可以开始绘制体验到的实际可用性，以了解哪些服务对自己的可靠性带来的风险最大。
为了获得这种可见性，你可能需要采用金丝雀测试策略，编写针对关键第三方端点的连续检查脚本。简单的API ping并不能说明功能的全部情况，但像Datadog这样的可观察性提供者提供的多步骤综合监控可以说明这一点。或者，使用专用的云依赖性监控解决方案，如Metrist或APImetrics。无论采用何种方法，我们都有责任收集所需的指标，以便在知情的情况下做出反应，并与供应商合作以提高其可靠性。
说到与供应商合作，现在是时候与他们建立关系了。正如我们应该像对待内部服务一样对待第三方服务一样，我们也应该把供应商视为团队的延伸。大多数云供应商都希望为客户做正确的事情。建立融洽的关系可以在停机期间提供实际支持，并在问题发生之前进行积极协作。了解所依赖的公共云提供商和地区，并确保它们不会在同一个地方托管其状态页，可以帮助识别并降低所承担的风险。
随着可见度的提高和与供应商的牢固关系，我们可以：
——评估并选择可靠性符合需求的供应商。
——管理供应商以提高可靠性，并让他们对SLA负责。
——通过警告和自动化避免第三方停机的影响。
——通过更明智的事件响应降低MTTR。
——通过对云依赖性服务运行状况的直接监控和警报来减少MTTD。
要求供应商
软件越来越依赖云供应商来发挥作用。我们身处一个相互关联的世界，供应商需要像这样行事。
我们为这些成为基础设施关键组成部分的服务支付了高昂的费用，包括需要配置和故障排除的人员，但这些服务的透明度没有跟上可观察性工具和可靠性文化的进步。
这些供应商不想影响客户的可靠性。通常，构建我们所依赖的产品的软件工程师会束手束脚。他们希望以编程方式更新状态页，快速沟通，并分享有关软件性能的更多细节，但由于自身的可观察性限制或围绕面向客户的可靠性沟通的严格流程，他们做不到。
因此，是时候让云供应商加入我们的可靠性之旅了，这样我们就不会在他们停机时沮丧。
