本文来自开源云中文社区。
规模是复杂软件系统最常见的压力源之一。只要“预期”与“实际”（每天的用户数、每个用户的事务数、每个事务的大小、每个事务保留时间等）有显著差异，它就会导致大量返工。公共云服务最令人印象深刻、最有价值的贡献之一是其看似无限的规模（网络、处理、存储等）。同样，最具可模仿性的实践之一是那些将“云规模”开发团队与“常规”软件开发团队区分开来的实践。
那么公共云服务公司是如何做到的呢？而且，即使在开发不需要“云规模”的解决方案时，我们也可以从他们的工具包中应用哪些差异化实践？
改进软件的10种方法
在探索云计算所需的实践之前，为任何高性能软件团队设定基线是很重要的。DevOps Research Assessment（DORA）中概述的实践是一个很好的起点。DORA中的技术实践、精益产品开发、精益管理以及文化和工作环境方法适用于任何软件系统的预期规模。但也必须有一些新的或不同的东西来支持这些实践，以实现云规模。
这些实践将常规软件与云规模软件区分开来，分为四类：
知识——团队成员知道什么
运维——团队成员如何处理运维
开发——团队成员如何构建软件
帮助他人——团队成员如何分享以上所有内容
这些类别和其中的实践结合在一起，使软件团队能够加快开发新功能的速度，提高所交付软件的质量，并提高实现所需规模的可能性。
知识
“风险来自于不知道自己在做什么。”对于复杂的软件系统来说尤其如此。虽然DORA中列出了有助于培养学习文化的实践，但从直接经验中获取知识没有捷径。
实践1——雇佣或发展分布式系统专业知识
深入理解分布式系统及其解决方案的常见缺陷，对于构建云规模的软件团队至关重要。阅读这些陷阱是积累知识的良好开端，但处理失败的经验会带来无与伦比的理解力。同样，要想在短时间内找到创造性的方法来解决这些挑战，通常需要利用以前的成功和失败经验。
例如，分布式系统专业知识允许团队在与提供“至少一次”通知传递的系统交互时保持幂等性。虽然对于某些通知服务来说，“仅一次”传递是一个可能的选项，但该选项通常会带来严重的性能损失。凭借深厚的知识，团队认识到在保持等幂性的同时解决“至少一次”交付的模式，与选择“仅一次”通知方法以避免复杂性的团队相比，其性能提高了几个数量级。
在常规开发团队中，分布式系统的专业知识往往很集中，这限制了团队的效率和有效性。而在云规模团队中，分布式系统专业知识非常普遍。
实践2——非常熟悉所使用的库和云服务
你可能听过这样一句格言：“一个业余爱好者练习直到能做对一件事，一个专业人士练习直到不做错一件事。”这同样适用于软件依赖关系选择，“一个业余爱好者整合一个库，直到它们开始工作；一个专业人士整合一个库，直到它永远工作。”
花适当的时间选择合适的库，一个可以正常工作但也会失败的库，这是DORA团队试验实践的一个很好的实现。同样的选择严格性也适用于公共云服务。必须充分了解其固有限制和故障模式，以便正确设计和构建这些潜在故障。代码审查有助于确认故障模式已得到处理，但只有深入了解与之交互的库或云服务，才能了解要处理的故障。
在常规开发团队中，库和云服务的选择是基于什么是流行的，什么对简单的案例最有效。这可能导致故障场景。而在云规模团队中，云服务和库选择涉及对源代码（如果可用）、文档的深入探索，以及对实验、基准测试和原型（包括故障模式）的大量关注。
运维
DORA广泛涵盖运维，包括其测量能力。云规模团队在运维领域的不同之处不是实践本身，而是应用的复杂程度和完整性。
实践3——提供深入完整的运维可视性
监控和可观察性已经是公认的必要条件。DORA指南概述了几个重点领域，包括检测和关联。检测意味着必须将代码添加到系统以公开其内部状态。关联意味着可以使用从应用程序及其底层系统收集的指标来解释行为。
团队经常发现，由于检测不足或关联不足或不准确，运维可见性不可能实现。随着软件系统变得更加分布式和复杂，这一点变得尤其具有挑战性。有越来越多的优秀工具可用于跨应用程序、区域和云进行分布式跟踪。虽然这些工具处理关联，但它们仍然需要开发团队在检测上花费时间。与其他工程任务一样，在正确的时间、以正确的方式、使用正确的元数据（以便与其他数据关联）公开应用程序的正确内部状态也同样重要，甚至可能更重要。如果没有正确的检测和关联，很可能会发生一些意外的事情，但不会被注意到。
在常规开发团队中，运维可见性没有得到与功能开发相同的时间和关注，功能开发缩短了检测，并且常常依赖于不充分的工具来跨复杂的分布式系统进行度量关联。而云规模团队明白，卓越的运维需要深入完整的运维可视性。
实践4——创建强大的运维自动化和工具
自动化部署和测试也是公认的持续交付实践。自动化背后的目的是减少工作量，增加成功的可能性，并使重要但痛苦的过程变得简单、可靠，从而更频繁地执行。
自动化的应用程度对一些团队来说仍然是难以理解的，他们认为这是一种主要用于持续交付的技术。考虑一个团队正在构建由API网关、API实现和支持API的数据存储组成的API解决方案。他们可以（正确地）自动化API解决方案的构建、部署、测试和发布过程。但他们可能会忽视（错误地）基于单个模式文件完全自动化API设计、实现、支持数据存储和前置API网关的机会。
工具是另一个经常有选择地应用的领域，但没有达到它可能达到的程度。当工具是“进入生产的唯一途径”时，它们会得到必要的时间和关注。同样，当优秀的工具是开源的时，他们会以拥有所有权为荣，并关注团队内部唯一工具可能缺乏的细节。
常规团队在知道其他人使用自动化的地方使用自动化。他们在内部工具上花费了时间和精力，但在设计和代码质量上并没有像新特性开发那样严格。而云规模团队明白，自动化应该应用于存在可重复流程的任何地方，包括软件开发。他们花在审查内部工具的设计和实现上的时间和审查外部功能上的时间一样多。
实践5——严格进行on-call审查
反思是持续改进思维的核心，而（各种风格的）回顾是敏捷软件开发的核心。虽然回顾在今天很常见，但根据计划和执行的质量，其有效性可能会有很大差异。正如运维工具在常规开发团队中经常短缺一样，运维on-call评审也是如此。就像许多DORA实践一样，仅仅“做”是不够的，要做得特别好。
特别好是什么样子？有几个突出的特点：
格式是一致的——这提供了一种涉及所有必要主题的结构化方法（没有忽略任何内容）。
这些材料来自于深入的运维可视性——对话是非常数据驱动的，依赖并显示了运维可视性和自动化工具投资的价值。
快速跟踪和关闭行动项——许多行动项作为on-call轮换的一部分进行处理。那些没有被优先考虑的通常是下周的事。
动态是协作的——每个团队成员的心态都是关于如何弥合导致运维问题的任何差距。问题不容忽视，需要解决。
方法是严格的——团队成员相互负责，从会议持续时间到内容结构，再到确定的行动项目。
常规团队将绩效反思限制在回顾中，如果没有捕捉到行动项并迅速结束（如果没有应用所学知识），回顾可能会成为死记硬背的做法。处理运行事件并进行表面纠正，但往往缺少真正的根本原因分析和纠正，这需要投入资金。
云规模团队知道，运维可见性提供了丰富的数据，可以收集这些数据来改进设计、实施和团队绩效，前提是提供了足够的时间和精力来检查和学习这些数据。
实践6——永远金丝雀（ABC）
云规模团队在自动化测试和部署方面投入了大量资金。金丝雀发布技术是团队逐步发布新特性的方法，避免了大爆炸式的运维事件。这项技术符合DORA关于小批量工作的指导。
一旦新软件发布，重要的是要有主动/合成/黑盒和被动/真实用户/白盒监控，并结合主动通知故障。软件即服务（SaaS）产品的理想发布顺序如下：
第一波发布——新软件的首次发布，理想的目标是已知非生产环境的小型用户和环境（沙盒账户）。
主动监控序列——综合驱动流量到共享服务（控制平面），以确认发布是否按预期工作。
被动监控结果——检查真实用户活动（数据平面），以确认发布是否按预期工作。
第二波发布——假设2和3（经过一段足够的时间）都没问题，继续到第二波，然后重复相同的过程。
常规开发团队可能会选择蓝色/绿色部署策略，因为它比金丝雀发布更容易机械化。他们也可能不会投资大量的主动和被动监测，因为前者需要实施实践4，而后者需要实施实践3。
云规模团队以小批量工作，并利用领先的运维实践。他们明白，组合是一个大于其各部分的总和。
