实现 Cloud-Native 可运维性

Casey West 认为：为了提高运维成熟度，您需要微服务架构、持续交付流程、DevOps 文化和平台自动化。这四点组合在一起可以帮助您为实现 Cloud-Native 可运维性而改变整个公司，进而不断向您的客户提供更多价值。

Casey West 是 Pivotal 公司的首席技术专家。他在 2016 年敏捷和软件架构研讨会（ Agile and Software Architecture Symposium， ASAS）中就关于运维成熟度的发展历程发言。InfoQ 将以问答、总结和文章的方式报道这次研讨。

West 认为微服务并不是对计算机资源的优化；他们的目的是支持架构和公司。采用微服务可以帮助您避免缓慢的、有风险的单体部署策略，并曝光组织文化和部署战略中效率低下的部分。

West 说：要说到我们从 DevOps 之中获得的好处，那就是它改善了我们一起工作的方式。DevOps 可以用来创建人们合作、学习和分享的文化。

West 建议: 团队一起完成的第一件事情应该包括建立生产流程和自动化生产。他提到了平台自动化的特点，这可以用来建立一个最基本的可塑的平台：

• 动态域名系统、路由和负载均衡
• 支持服务代理
• 基础设施搭建
• 健康管理、监测和恢复
• 持久化产品存储库
• 日志聚合

Casey West 在 ASAS 2016 会议发言后，InfoQ 采访了他。Casey West 回应了需要什么来实现 cloud-native 可运维性、建立持续交付流程和 DevOps 文化以及如何评估机构是否能够开发和提交 cloud-native 软件等问题。

InfoQ：cloud-native 可运维性指的是什么？

Casey West：Cloud-native 可运维性是为大型系统利用云的优势而采用的一种全面的软件设计和交付的方法。我的目标是让观众思考可运维的、成熟的、交付商业价值的四个主要组成部分，而不只是关注某一种现代方法（如“DevOps”或微服务等）来优化开发和生产能力。

InfoQ：在您的发言里，您提到您需要微服务架构、持续交付流程、DevOps 文化和平台自动化。为什么您需要这四样东西？

West：我们需要全部这四样东西。因为他们彼此依赖，不可或缺。比如说，如果您没有办法自动化地持续交付，可是您的工程师团队却在用微服务架构不断地推进项目，那么您的团队就很难以非常及时而又代价极小的方式发布到生产环境。正如您微服务策略的成功取决于流水线式的部署流程，它也依赖于 DevOps 运动固有的共担责任和合作的文化。

同样重要的是，一个成熟的、完全自动化的、弹性的生产环境是成功所必需的。如果生产环境是您的应用程序难以维系的地方，并不断崩溃，需要人工干预，您就无法实现宏伟的目标：增加产量的同时降低风险。

InfoQ：如果想要建立持续交付流程，公司需要做些什么？

West：持续交付需要在公司中的几个职能团队之间的协调和合作。开发人员和测试人员必须共同努力，建立可靠的、值得信赖的自动化测试套件。当对软件做了改动时，通过测试套件的测试应该能让您的团队充分相信，这种改变不会让系统崩溃。

自动化交付流水线是以质量测试套件开始的，并以最简单的一键部署到生产为结束。再次重申，一个完全自动化的部署策略是至关重要的。它需要开发人员、发布工程师、IT 和运维之间的合作。在大多数环境中，当容量和物理资源分配自动化的时候，当单次部署过程中的修改很小的时候，无停机时间的自动化部署（通常被称为“零停机时间部署”或“蓝绿部署”）是可能的。

部署过程中的这些小修改，或小批量是最关键的。它需要与如产品和项目管理以及开发人员等项目利益者相协调。当公司过去常常一年一次或两次对生产进行改动时，它们用于部署的改动规模是非常巨大的。即使每两个星期上线一次，这仍然意味每个部署要发布几十个不同的系统组合的改动，以及更改几千行的代码。在这种情况下，改变系统是非常危险的。如果生产环境发生了异常，你怎么知道是哪些变化引起的问题？你如何分类并且有效地修复它？

小规模提交提供了一个不那么危险的选择：一次一个增量地更改，然后将它们依次部署到生产中。这样，每次发布您可能只需改变一行或十来行代码。我们可以推断在这个范围内的变化并更清楚地了解其对系统的影响。如果我们知道异常是什么变化引起的，我们可以做出更快的反应。

为了采用这种策略，你必须将生产或部署的变化从功能发布中分离。他们在持续交付中是不一样的东西，并且我们做业务时必须了解这一点。开发也必须用功能标志或 A/B 测试策略为这种方法做计划。这样，功能发布就可以从代码部署中抽离出来，独立管理。

InfoQ：哪些是 DevOps 文化的组成部分？

West：在我看来，DevOps 运动对我们软件交付团队效能的最重要的贡献是它的文化。合作（collaboration）、自动化（automation）、学习（learning）、测量（measuring）、和共享（sharing）的首字母缩写"CALMS"（“平静”）最能代表这一点。这些不是具体的行动，而是我们如何一起工作。这些都是有效的团队在现代机构中的招聘和培养的特点。

InfoQ：您怎样评估一个机构是否能够开发和提交 cloud-native 软件？

West：在公司中，架构、流程和文化的自动化迭代一直在进行。他们必须同时在业务价值交付的这四个方面努力，以利用机会成功地使用云。作为一家企业，我们已经看到有证据表明，一个公司如果具有成熟的微服务架构、值得信赖的持续交付、负责的 DevOps 文化和完全自动化的生产平台，它就能够在开发和交付 cloud-native 软件获得最大的成功。

InfoQ：对于希望实现 cloud-native 的机构，您最后有什么忠告？

West：继续听取 Fred Brooks 在他 1986 年的开创性文章“没有银弹”中的意见：

“没有单一的发展，无论是技术或管理方法，都无法在十年内实现在生产力、可靠性、简单性的某一方面的一个数量级的改善。”

我仍然相信这是真的。然而，基于云的平台、组织文化、自动化交付和软件设计的最新进展，我们可以结合这些努力，提高我们的生产力，增强可靠性和简单性。对于提供大规模、Cloud-native 解决方案，我相信我们别无选择，只能利用这四个关键因素，以减少风险，提高产量，并最终保持竞争力。

查看英文原文： Achieving Cloud-Native Operability