云原生时代，如何开启DevOps 之路？

Posted 2021-04-16 Pivotal

您

的公司决定向市场投放一种新的数字产品：可能是一款医疗应用，让病人在看医生时能够检索要到当地药房按方取药的处方；也可能是一款停车应用，告诉司机当前位置一公里半径内的车库中有哪些停车位。

提出想法只是开端，但并不牢靠。

因为后续需要有资金投入、需要有项目经理进行统筹，方能解决各种不确定性，完成构建、测试和运行等各个阶段。这种瀑布式的流程是专为软件交付而设计的，但云计算已经让一切发生了改变。

数字行业产品开发的节奏就是速度（快速迭代）和“早交付、多交付”。曾经是最先进的流程，现在却变得笨拙，无法满足当今的需求。

这看起来很熟悉吧？

这段动画可能让您会心一笑，有些人甚至感到有点厌恶，因为它描绘了一个典型的瀑布式流程：来自各个孤立环节的人在项目中进进出出，生产出自己负责的产品组件，然后交给负责下一阶段的参与者。

这张图其实是过分简化的，处于动态之中的人员和团队会让这整个过程变得错综复杂！在现实中，项目进程可能是向前推进，也可能出现倒退，甚至可能会横生枝节。

最糟糕的地方也许在于，各个孤立环节中的人只是各司其职，只见树木不见森林。

他们声称自己完成了分内工作，却是一盘散沙，这经常会与将软件产品投入市场的大局背道而驰。毫无意外，由此产生的结果往往差强人意。

例如，应用开发人员通常会因在特定时段内构建出功能而受到奖励；质量保证 (QA) 人员的绩效则是根据修复的错误数量来进行衡量并得到嘉奖。

如果开发进度比较紧张，开发团队就无法保证用时充足。他们在编写自动测试时可能会少花些时间以跟上进度，但这样一来质量必然会下降。结果，QA 会发现更多错误并因此受到嘉奖。各个孤立的环节本身运转良好，但全局性的成果，即发布功能丰富、可靠、稳定的应用，通常很难实现。

像糖果机一样的综合性团队

我敢肯定，您一定听说过产品团队的概念。与前面提到的项目团队不同，产品团队集合了各种不同的技能和职责，为实现一个目标而工作，整个团队的宗旨是实现这个目标，向客户交付价值。

产品团队从宏观上看很有意义，但具体到执行，细节才是最重要的。您可能会问的第一个问题是：“我们的产品团队需要引入哪些技能，如何获得这些技能？”

这个问题第二部分的答案很简单：您已经拥有了大部分技能，它们分散在目前的孤立环节中，需要您在不同的（产品）环境中将它们重组。

至于问题的第一部分，和许多事情一样，答案都是：视具体情况而定。您需要权衡多个因素，其中最重要的是：所有人都了解他们所构建的产品，更要了解实际投入使用的产品。

Pivotal 可以帮助客户生产两种不同种类的产品，因此也推崇两种基本类型的产品团队。

新组合：应用团队和平台团队

第一类产品是您要为受众（从客户、供应商和合作伙伴到同事等的任何人）构建的应用。我们把负责构建此类产品的团队称为“应用团队”。

第二类产品实际上是一个产品，即 Pivotal Cloud Foundry® (PCF) 平台。您可以把 PCF 视为一个由您“构建”和运行的产品，为的是打造一个完整的开发服务生态系统。等一下，你说什么？PCF 是由 Pivotal 构建的，对吧？你现在说由我们（指客户）来构建和运行 PCF，是什么意思？

实际上，PCF 是由 Pivotal 构建的，具体方式是编写代码并生成您放入数据中心或云环境中的版本。但是，通过为应用团队用户提供 PCF，或者具体一点，通过在实例化过程中实施所需的策略和实践，您也可以将它变成您自己的。

例如，您可能希望在每次部署、扩展或升级应用时在审核日志中写入条目，这一点可以通过将该功能嵌入该平台来实现。我们把这个负责构建、运行这个平台的团队称为“平台团队”。该团队的职责就是调整该平台以优化工作负载。

下图描述了应用团队和平台团队分别覆盖的领域及各自的职责。两个职责列表看起来非常相似，这并不是巧合，因为这些活动是所有负责将产品投放入市场的团队都必须要执行的。

 

现在，让我们回到之前提出的问题：“对于每个产品，我们的产品团队需要引进哪些技能，如何获得这些技能？”我们还是先从问题的后半部分入手。这里有是一个粗略的草图，您公司的 IT 结构可能就是图中所描述的样子：

 

我敢说，您对图中的企业架构师、首席安全官 (CSO) 以及其他团队都不陌生。我们把所有这些团队看成是一个个糖果，来玩一个糖果游戏：

 

让我们简化一下这些角色，并把它们放入正确的领地范围 — 就从上面提到的应用团队和平台团队开始吧。

我们可以从应用设计和开发以及运营之类的角色开始：

● 将软件架构师和软件开发人员（服务器端和客户端）从中间件/应用开发小组移到应用团队。第一个移动理所当然，无需进一步解释。

● 将中间件工程师移到平台团队。该工程师负责开发和运行应用所在的平台，之前，他们在该平台上安装和配置应用服务器（如 WebSphere、JBoss、WebLogic 或 Tomcat），现在他们负责 PCF 中提供的构建包。由于 PCF 原生支持 Java、.Net、Ruby、php、Python、Node.js 和 GoLang，因此可能需要不同的中间件工程师来配置和维护对这些不同框架的支持，因此他们属于平台团队。

● 最后我们要移动的是运营人员。在我待过的许多组织中，应用运营和基础架构/系统运营全部都由 IT 部门内的一个团队来处理。开发人员编写代码、帮助完成初始部署，再过一小段时间，就会远离应用的日常运营。

● DevOps 的兴起改变了这一切。虽然不是必须由开发人员负责运营，但通常情况下，开发人员确实比以往更大程度上参与到了日常运营当中，毫无疑问，应用团队承担了运营职责。

请注意，每个产品团队（应用团队和平台团队）都肩负了产品的运营职责。这已经是一个独立的角色，我们又进行了分散，这样一来，每个产品团队现在都包括这样一个重要角色。

这意味着这些产品团队中的每个人都要对产品的整个生命周期负责。这正是现代化平台时代的问责范围。

当然，还有许多角色需要划入合适的范围。 成为一个迅捷的软件驱动型企业需要一套全新的工具集，然而只有新技术是不够的，改造流程以加快速度才是重中之重，同样重要的还有围绕这一目标重组新的角色和团队 （这正是“Conway' s Law”康威定律所揭示的）。

最后要说的是，法规遵从性或容量规划等要求并未消失，它们只是采取了新的形式，由修订后的角色来执行罢了。我们在这篇文章中看到的只是开端。

*本文节选自《Built to Adapt》（一本由Pivotal 出版的刊物），这本书围绕软件如何改变业务构建方式介绍了相关故事和观点。

Pivotal 由EMC、VMware 和 GE共同投资成立，总部位于美国硅谷，Pivotal专注于帮助企业用户实现实现数字化转型，已为硅谷多家重要企业塑造了软件开发文化。Pivotal 的 Pivotal Cloud Foundry 云原生平台和大数据解决方案推动了众多世界知名品牌的软件创新。全球财富500强中，超过三分之二的企业都是Pivotal 的用户。2016年5月，福特和微软共同投资Pivotal，公司整体估值达到28亿美金。 了解更多，请访问： https://pivotal.io/cn 或咨询我们的技术专家：400-135-8900。