想要DevOps自动化吗？它是pipeline前的profile

Posted 2021-04-16 云技术

 “当你说DevOps时，每个人真的睁大了眼睛”，商业敏捷顾问Almudena Rodriguez Pardo指出，她开启了2018年的伦敦Agile Tour来讨论DevOps自动化的，人性化方面的问题。

“自动化一切！这是持续交付的关键不是么？”在电信领域超过20年开发经验的Rodriguez Pardo说道，除了自动化，你还必须关注计划和推动这一流程的人。

今天，我们重申她的那些能用于任何类型从DevOps开始转换或者已经在努力的的那些步骤。

1.Anyway，DevOps到底是什么？

无论你已经定义了什么，都没有错，因为现在DevOps没有任何官方的定义。

      

Rodriguez Pardo指出Agile Manifest，如何为敏捷软件开发来提供指导，但DevOps没有这样的东西，这意味着没有人的定义是错误的。我们同意，这意味着开发与运维，但是这也是澄清结束的地方。

“这实际上是一个很大的问题，因为每个人都在谈论它，每个人都意味着不同的定义。”她继续道。

因此，在她的演讲中，她通过VersionOne给出了她自己最为认可的定义：“DevOps不是一个工具或过程，而是一种重视整个组织的持续通信，协作，集成和自动化实践。”

这也很合适，因为目前没人能真正统一认可DevOps中CI/CD中D的定义（“delivery”，有时是“Deployment”）。每个人都认为第一个代表持续集成，但是CD是必须交付，部署，开发还是其他的什么呢？通常它意味着所有这些。

Rodriguez Pardo在她的演讲中所做的是提醒我们，因为没有标准定义，这是任何接近DevOps转型的第一个对话点——首先明确定义你甚至再说什么关于每个部门。

 “它包括通信，协作和集成，而不仅仅是自动化。这是我非常喜欢的地方。”这是Rodriguez Pardo专注于做自动化的因素。

大多数正在做DevOp转型的公司已经接受了Scrum框架——明确定义了Scrum Master，产品负责人和开发团队的成员的角色——如果你假设在引领scrum流程之后，产品会直接交付到客户的手上，那么这种做法很有效。这种情况很少会发生，当你谈论电信公司的复杂性时，情况远不止此

事实上，Rodriguez Pardo声称Scrum和Kanban只是简化了“agilization”的项目管理流程。

 “现在我们正在前进。我们正在尝试使用DevOps，我们仍在尝试与优质，高质量的工作代码进行交互，但我们也会关注正在发生的环境。因此，不只是修复代码并将其推出门外。我们需要确保运行环境的安全。”她解释道。

她说道，每个部门的持续交付pipline差异很大。

目前，大多数技术支持的组织现在都有持续集成和设计，但是持续交付，持续部署和持续发布因公司而异。Rodriguez Pardo表示，如果你是AWS或者Spotify，你可能每分钟就会发送三次，因为你直接想你的客户提供交付。但是，如果你在电信公司工作并且你正在全国范围内与网络运营商合作，同时有几千人在谈话，你可能不希望连续发布。

“在预生产和生产之间，你可能会采取一些步骤”，她说道，指的是所谓高复杂性行业的公司，下面以爱立信为例。

她指出爱立信是如何将持续改进和反馈循环集成到他们的DevOps中去的。无论在预生产中发现了什么，都会被纳入到下一个迭代中去。

连续性如何连续，这在此因公司和部门的不同而已。在这种情况下，爱立信能够从每六到十二个月发布到每月一次。Rodriguez Pardo承认这是不连续的，但是为了进入到英国甚至整个欧洲范围内的网络，这是相当不错的。

“这不是关于连续是什么，而是你想达成的是什么，”她说。

对于大多数公司来说，“一切皆持续”可能显得过于雄心勃勃。然而，容器化和虚拟化等技术的进步，意味着每个开发人员都可以获得“漂亮的操作环境”。这将成为很多公司的重要DevOps加速器。

2.在交互中绘制持续的pipline映射

DevOps的第一步是自动化。Rodriguez Pardo说这听起来合乎逻辑，但通常不是。事实上，她引用了一项关于欧洲企业的IT调查结果，该调查显示大多数公司的自动化率只有20%。

她说，当她与那些没有自动化的公司交谈时得知，他们没有自动化的原因是没有预算。

“自动化不是一种选择”，她反驳道，分享了几乎所有DevOps工具和协调器将他们结合起来，指出他们有多少是便宜并且开源的。

Rodriguez Pardo说，没有理由不进行自动化，但是不能忘记自动化的人为因素。

      

她的一位客户，必须与不同的运营商合作。一位LatAm运营商表示他们只想与一个特定的人合作，因此必须将此人添加到DevOps计划中。然后，他们必须适应不同运营商的架构。然后他们必须在不同的结构中进行测试并对网络进行改进。他们还具有集成保护功能，因为供应商希望在发布之前，在其自己的环境中能看到更改。

“安全，测试，开发，运维，集成——无论你的pipeline是什么样的，都要确保完整的质量代码pipeline能够让客户在最短的时间内满意。”—— Almudena Rodriguez Pardo

一个CI/CD的pipeline必须包含用户和连接点到他们的距离。

她说，在这种情况下，你甚至可能有需要调整的东西，或者你可能要开发人员前往客户的所在地。她将此称之为手动交付，这是自动化的反义词，但并不否定其价值，因为DevOps的重点在于客户的兴趣。

“因为通过将你的软件亲自带给你的客户，你与她坐在一起，你也听到了他的评论，你听到他喋喋不休的谈论他不喜欢的地方。你可以有共鸣和学习的痛点。”Rodriguez Pardo说道。

映射该反馈的回路越宽，听到它的操作就越多。每个人都在监听，你会发现荒谬的不协调。在一个团队中，开发人员的KPI是减少错误，而测试人员的KPI是尽可能多的发现错误。

“你能想象到排球的来回走动吗？”“不，你错了。”“不，你的测试有问题。”

然后，部门经理欧了一些“革命性的”东西，Rodriguez Pardo打趣道，他们互相交谈，决定共同的目标。

3.DevOps：专业化和跨职能的平衡

Rodriguez Pardo继续说道，“这就是Scrum的用武之地。这不只是坐在一起。它是关于共享，达成共识，相互支持以及创建跨领域的功能。”

无论你是否拥有Scrum，Kanban或者其他东西，她都建议在这些团队中纳入运维，以便团结共同的目标。

她说道，DevOps不仅仅是打破孤岛，而是关于发展技能。这通常涉及到垂直方面的专业化，但随后对水平方面的所有内容又了一般性的了解，从工具的简要理解到团队的目标和跟踪。

为了达到这个目标，她建议你可以通过与开发人员合作相关的小型测试试验来完成这项工作，或者让每个人在Jenkins进行一些基础研讨会，以便对持续集成进行交叉合作。

Rodriguez Pardo说，目的是为了吸引一些对此有兴趣的人斌给他们一些尝试，提供一些像社区应用实践和跨公司行会这样一些想法。

最终目标最好通过下面的Spotify图表说明。

“在运营商的支持下，他们是一致的。他们在团队中成熟，了解他们拥有什么，没有什么。以及他们可以合作的地方。”她说，并补充说，每个人都是自主的，安全的，并且朝着让客户满意的方向前进。

最后，DevOps只关注人，包括客户和团队。在招聘DevOps的文化变革中时，你不再只是聘请某种语言的最佳候选人，你正在招聘一个人格，以及她如何适应变化，不仅适合自己的团队，而且还可以与其他团队合作走向跨职能的知识。

 “有一点我们不能忘记的是，每当它看起来像是一个技术问题时，每当我们认为我们遇到技术问题时，它总是一个人的问题。”—— Almudena Rodriguez Pardo

原文链接：

https://thenewstack.io/want-devops-automation-its-people-before-pipelines/

译者介绍：

王小刚，泛90后程序员一枚，云计算从业者，热爱开源，现做Kubernetes和DevOps相关工作，云技术社区译者。

↓↓ 点击"阅读原文" 【加入云技术社区】

相关阅读：

更多文章请关注

文章好看点这里更[好看]