在可靠性时代，许多服务正从内部服务器迁移到云。云模型允许您的服务利用AWS、MicrosoftAzure或GoogleCloud等大型托管提供商的好处。这些服务器可能比内部服务器更可靠，原因包括：
- 大型主机提供商有许多基础设施冗余，这意味着单个服务器可以在不影响客户的情况下故障。
- 云提供商受益于强有力的安全措施以减少漏洞。
- 云具有很高的带宽和容量，减少了中断的风险。
然而，与所有事物一样，云提供商也提出了自己的风险和挑战。团队想要利用这些好处，同时考虑到这些限制。要做到这一点，您的DevOps实践必须考虑到云。在这个博客中，我们将了解SRE如何帮助在云中迁移和操作，并分享一些关于如何最大限度地提高可靠性的技巧。
使用SLO和错误预算安全迁移
在AWS博客文章，AWS GM StephenOrban描述了将服务迁移到云的六种策略。所有策略都会注意到一个过渡时期，其中必须重新评估或更改服务。即使您可以在云中重新承载服务而不作任何更改，您应对云进行修改以优化它。
这一过渡时期会影响可靠性。开发人员可能需要在短时间内更改服务的几个方面。运营商将需要纳入发展变化和调整程序。在进行这些更改时，很难理解您所承担的风险的影响。您可能预期某些服务会出现中断，或者需要更长的时间才能修复。你怎么知道这是否是一个可接受的可靠性下降？
SRE帮助提供有价值的答案SLI(服务水平指标)和SLOS(服务水平目标)。SLI是为了反映对客户满意度影响最大的指标而构建的。SLOS为这些指标提供了一个目标。这个目标设定在顾客幸福感下降的时刻。在此之前，SLO形成一个错误预算。只要你在这个预算之内，你就可以相信可靠性的下降不会影响你的客户。
将迁移计划分解为潜在的事件场景。考虑一下不同事件类型的置信区间。重构代码时，监视烧录率。以你目前的速度，你能为每一次事件处理最坏的结果吗？为违规行为制定一个计划，例如回退或将工作转移到可靠性工作上。向云的缓慢而可靠的过渡要比匆忙的过渡要好，后者引入了大量的同时发生故障的表面积。
一旦您在云上有了服务，请确保您的SLO帐户为您的提供商的限制。如果云主机只能保证99.99%的可用性，不要保证您的服务将提供99.999%的可用性。这些第三方依赖会影响您的客户幸福感。即使这些事件不是你的错，它们仍然会影响你的客户对你的可靠性的看法。当你瞄准你的可靠性目标时，你需要考虑它们。
在CloudDevOps中实现SRE
在云上运行您的服务有其自身的挑战和优势。当您为云第一环境调整DevOps过程时，您会发现您可能会自然地实现许多SRE最佳实践。Rastko vukašinović解释了一篇文章在他的博客上。他分解了DevOps的两个规模：一个关注服务的部署，另一个关注在生产中运行的服务。
对于云优先环境，部署的许多方面通常是标准化的。资源管理变得更加自动化和灵活。这改变了部署规模和生产规模集成的方式。Rastko解释了SRE如何更多地将DevOps应用于实时服务，而不是部署。与传统的离散部署模型不同，部署到云上通常需要直接使用活动服务。这使得Rastko所称的“无缝的送货流程”成为可能。
Rastko强调，这样的流畅不是魔术，而是“非常艰苦的工作”。它可以帮助建立模型如何在您的组织中运行开发和操作。查看可靠性模型中的每个环节。对于基于云或微服务的环境，它需要如何改变呢？您可以在基于云的环境中自动化或流线哪些步骤？
确保向云的转换不会产生信息断开。SRE意味着从失败中学习并创建一个反馈循环。云模型可能会增加技术依赖，并改变运营商部署代码和解决事故的方式。SRE工具，如事件回顾确保您仍然分享学习，无论过程如何变化或规模。这有助于保持反馈循环的运行。
在云端保持可靠的一些顶级技巧
检查并重构监视数据。监测数据是SRE的生命线。来自私有云环境和公共云环境的数据的规模和上下文可能有很大的不同。确保你还能捕捉到你需要的东西。同时，寻找对您可用的新数据源，例如集成监测工具云服务。
针对云问题测试您的服务。虽然许多云托管提供商坚持SLA，中断相对少见，但云托管服务仍然很容易中断，就像任何其他服务一样。如果可能的话，在生产中进行测试，并利用混沌工程来模拟潜在的事件场景，这样您就可以尽可能地为实际事件做好准备。制定紧急计划，例如投资于架构冗余或故障转移计划，以尽量减少主机提供商停机的影响和成本。这些事件超出了你的控制范围，但如果反应良好，客户对你可靠性的看法就会有所不同。
在云环境中运行事件响应。事件响应工具，如自动运行簿，也可能需要在切换到云时进行更改。它们应该包括检查它是本地问题还是基于云的问题。如果是后者，他们应该详细说明如何从云提供商那里获得帮助。随叫随到的响应者将需要有这些信息在手边。
福州APP开发，好! 好在哪里我也不知道？
