“干掉 DevOps 团队！”
戳蓝字“CSDN云计算”关注我们哦！
作者 | Daniel Jones
责编 | 唐小引
封图 | CSDN 付费自图虫创意
出品 | CSDN 云计算（ID：CSDNcloud）
【导读】开发和运维“一体”的感觉是由开发人员和操作工程师之间的技能组合和实践的桥接以及自动化（DevOps）工具的实现引起的。世界各地的大型互联网公司都已采用 DevOps 方法来彻底改进其性能、安全性和团队动态。然而，DevOps 究竟如何使用才能为企业真正带来益处，不走入歧途，也是值得大家关注及思考的问题。
DevOps 团队必须死。
DevOps 团队的存在滋生了误导、懒惰和不诚实，在所谓“IT 流行趋势”的掩护下，这些行为都变成了大家眼中积极的变化。
在洋溢着“流行趋势”的企业里：
我们符合敏捷方式吗？符合！我们为接下来三个月的冲刺做好了计划！
我们有 Kubernetes 策略吗？有！再过一个月，就可以投入生产了。
我们有 DevOps 团队吗？有！我们已聘请了许多 DevOps 工程师，成立了专门的团队来编写 YAML，并负责执行 Ansible playbook。
DevOps 团队是一个非常普通的反模式，为了向公司的高管证明他们走在了流行趋势的最前沿，他们采用了一套看似高大上的实践理论，但实际上公司的责任和文化仍然停留在几十年前的水平。
如果你有一支名为“DevOps”的团队，那么可以肯定地说，你根本没有在实施 DevOps，而且还有可能反其道而行之。
实际的 DevOps
说完了骗点击量的标题，现在，我可以偷偷地告诉你，我有一些朋友才是 DevOps 工程师。我说的是真的。
让我们来定义一下 DevOps 的工作究竟是什么：
你需要编程，你需要运行系统，还会在凌晨 4 点被叫醒。
这就是为什么我很惊讶有些“DevOps 工程师”的个人资料显示他们压根没写过代码。亲，你必须停止这种行为。
DevOps 更准确的定义是：
DevOps 是一种实践，从事该项工作的跨职能团队需要负责应用程序或服务的整个生命周期，从创建到运营和支持。
因此，在定义哪些不属于 DevOps 之前，让我们首先简要地总结一下 DevOps 的好处。
DevOps 有哪些好处
由于多种原因，真正的 DevOps 可以提高工作流程的效率，缩短产品上市时间并提高质量。
编写软件和运行软件的人员的利益是一致的，因为他们是同一群人。如果系统发生故障，那么开发人员会在凌晨 4 点被叫醒，那么他们必然会更加用心地保障质量和可操作性。
除了利益一致外，由于编写软件和运行软件的是同一个团队，因此他们更加关心彼此的问题。
同一个团队内没有交流障碍，而且代码变更的成本也较低。由于没有两个团队间沟通的延误（比如一个团队在填写了服务票后，需要等待另一个团队来实现），因此所有沟通都可以及时传达。
DevOps 更准确的定义是：
举个例子：在我撰写本文之际，我们的一位工程师向我感叹说，某个类似于 REST 的客户应用程序需要先提供一些加密数据，然后才能执行操作，否则就会返回错误响应。为了生成加密数据，你需要首先运行这个应用，然后访问一个特殊的端点。因此，我们必须先部署这个应用，然后看着它被标记为不正常，触发端点，然后再使用加密值重新配置应用，最后再重新启动应用。我觉得“十二因素”（https://12factor.net/）也没有专门指出这种情况，但我很确定，如果该应用的开发人员和部署人员是同一拨人，那么他们可能会想出一种不会过分依赖手动作业的解决方案。
非 DevOps
看看下列非 DevOps 的现象，你们公司中了哪些？
有一个名叫“DevOps”的团队。
有一个名叫“DevOps 工程师”的职位。
“DevOps 团队”不负责编写生产环境中运行的应用程序。
如果系统出问题，应用的开发团队不会在凌晨 4 点被叫醒。
应用的开发团队需要主动请求“DevOps 团队”处理某些工作。
如果你们公司中了一项或多项，那么很遗憾：你们的团队并不是 DevOps！好消息是，你们不是唯一一家有这种问题的公司，“DevOps 工程师”的招聘广告有成千上万。
回顾过去，我们曾经称这些人为系统管理员，或者叫“配置管理员”。这些人对 Linux 有一定的了解，可以将你的代码放到环境中。如今，如果你是一名精通 Puppet / Chef / Salt / Ansible / kubectl 的系统管理员，那么恭喜你，现在你就是 DevOps 了，而且你的工资也会上涨 50%！
如前所述，实际上负责开发应用程序的人们不需要去“请求”DevOps 完成下列工作：
创建 CI 管道 / Jenkins 的工作
创建 Git 代码库
根据代码创建 Docker 镜像
将代码部署到环境中
为正在运行的实例建立日志
如果只有请求了才去做，那么你们就不是 DevOps！
如果你们的行为不是 DevOps，那么你的老板就无法获得应有的好处。你在对公司的高管撒谎，因为他们以为你们采用了 DevOps 这个高端的实践，而实际上你们只是挂着羊头卖狗肉。
你们还不如不要 DevOps，因为老板付了钱给你，而你却没有提供相应的专业技能，而且你还破坏了这个术语的名声，毕竟还有很多人付诸了正确的实践。
Matthew Skelton 从各个方面深入定义了非 DevOps 的很多细节，还总结出了“反 DevOps”列表（https://web.devopstopologies.com/#anti-types）。Matthew 曾与人合著《Team Topologies》，书中明确指出了如何组建团队才能实现高效的流程。
客户经常请求我们帮助他们找出如何更快地交付价值。最常见的阻碍交付价值的因素之一就是流程效率低下，他们花费在等待上的时间甚至超过了实际工作的时间。将开发和运营活动分割开来是造成等待的常见原因。然后滥用“DevOps”这个本来能够解决问题的术语，给同一个团队另起一个虚有其表的名字，这无疑是往伤口上加盐！
我们真的应该干掉 DevOps 吗？
不应该。（除非他们是从未来穿越过来的机器人，目的是降低人类的生产力，与此同时人工智能正在朝着获得感知能力和奴役人类而加倍努力，如果真的是这样，那么我认为我们应该更加果断的行动。）
我们应该干掉“DevOps 团队”这个概念。
我们不应该再称他们为“DevOps 团队”。
我们不应该再假装实践某个概念，而是真正去实践。
如果你做不到，那么就不要对自己和老板撒谎。
我有一个 DevOps 团队，现在该怎么办？
我们应该确保这些人能够构建可重复使用的自动化，为开发人员自身提供服务。
这个 DevOps 团队不应该仅承担一次性、常规业务的事务处理工作。
他们应该构建一个内部产品，为开发人员提供自助服务。在这个模型中，应该由应用的开发人员承担起真正的 DevOps 工作，为他们提供在生产中操作应用程序所需的工具：日志记录、软件度量、生命周期控件等。下图显示了“后 DevOps”的模型。
这个 DevOps 团队不会为 App 开发人员执行“一劳永逸”的任务。他们从 App 开发人员那里征求需求，并将需求写成产品的待开发功能。他们需要为待开发功能构建自动化和可重用的解决方案，方便开发人员执行操作任务。他们需要构建永久的产品，不应该临时应付服务票。
我们公司将这样的 DevOps 团队称为平台团队，尽管我认为在科技行业中“平台”和“服务”之类的术语使用过于频繁。
如果你的“DevOps 团队”确实承担起了上述工作，那么还要称他们为“DevOps 团队”吗？当然应该以他们交付的产品来命名，不是吗？
做正确的事
不要为流行语和趋势所迷惑，你应该花点时间思考如何使用这些术语。如果组织不下功夫减少等待时间和缩短生产周期，那么无论花多少钱聘请 DevOps 工程师都无法改善价值交付。
我们应该停止滥用术语，更不应该在实践中自欺欺人。
英文：Kill The DevOps Team
链接：https://www.engineerbetter.com/blog/kill-the-devops-team/
作者：Daniel Jones
译者：弯月
【END】
推荐阅读
集五福，我用Python
微软开源NAS算法Petridish，提高神经网络迁移能力
AI 没让人类失业，搞 AI 的人先失业了
我国自主开发的编程语言“木兰”是又一个披着“洋”皮的红芯浏览器吗？
小网站的容器化(上)
好扑科技技术副总裁戎朋：从海豚浏览器技术负责人到区块链，揭秘区块链技术之路
春节加班老铁求在看！