十年前，我们开始了一次偶然的旅程。 我们召集了比利时根特的一些好朋友，讨论我们的敏捷，开源和早期云体验。 在和在Velocity 2009上发表演讲之后， 创造了#DevOpsdays事件，“每天部署10个以上：Flickr上的开发人员和运营人员合作”（这很 ）。

十年后的现在，世界已经不同了。 DevOps无处不在，对吗？ 还是真的？ 自成立以来，我一直参加活动，从我的经验中学到了很多东西。 这里有10个要点，希望您也能从中学到。

1.没有像DevOps工程师这样的人。

现在，很多人将“ DevOps工程师”作为职务，其中许多人不喜欢该职务。 标题给人的错误印象是DevOps是单个“ DevOp”可以完成的工作。 DevOps工程师通常是Linux工程师，如果幸运的话，他会做一点自动化。 当招聘人员开始寻找DevOps工程师时，申请人需要向自己提出正确的问题，首先是：“公司实际需要申请人提供什么？” 他们是在寻找建筑工程师，了解非功能性需求的高级开发人员，可以使事物实现自动化的高级操作人员，还是正在寻找其他东西？ 通常，他们真正在寻找的是一个会在实践中将视线从缺乏敏捷性原则转向的人。

在拥有许多DevOps工程师的组织中，这通常意味着没有DevOps发生。 DevOps头衔是新的竖井的标志，申请人可以赚很多钱并在工作中学习新技能，但他们不会“从事DevOps”。

2.没有DevOps团队。

在早期，我们经常说DevOps是要消除不同团队，开发人员和操作人员之间的困惑墙，以打破孤岛。 然而，在旅途中的某个地方，我们看到了一个新现象：DevOps团队的崛起。

“ DevOps团队”听起来像是一种新习惯，但是各个组织之间的矛盾显而易见。 在一个组织中，是由负责工具的团队负责，而在另一个组织中，这实际上是开发人员和运营团队之间的孤岛—一个孤岛，这会造成更多的混乱，更多的挫败感和更少的协作。 在最好的情况下，偶尔会有跨职能团队对他们所构建的服务负有端到端的责任。 这些团队通常不喜欢被称为DevOps团队。

我发现将团队称为“ DevOps”很可能会阻碍您希望通过DevOps实现的目标。

3.没有DevOps项目。

本质上的“项目”是有限的。 这是您构建，交付然后继续进行的工作。 十年对话的一个一致主题是DevOps是关于持续改进，而持续改进永远不会完成。 同样，这些假定项目的输出是长期服务 ，而服务是您构建，交付和保持运行的东西。

只是在我们考虑服务如何扩展到项目之外之后，我们才开始看到容易忘记的事情：非功能需求（NFR）。 NFR包含的功能不能完全适合特定的行为。 NFR定义了我们如何判断系统的运行情况。 它们通常包括您在DevOps上听到的所有“缺点”：安全性，可靠性，可用性，可维护性和可伸缩性。 所有这些对于业务成果至关重要。

在短期项目中缺乏思考所需的同理心存在风险。 当您转到另一个项目时，您将不再需要NFR，因为您正忙于应对新挑战，而这又是另一个人的问题。 但是，当您运行一项服务时，您一定会在意，并且最大的利益就是减少摩擦，以使一切正常运行。

4.没有像DevOps工具这样的东西。

尽管许多供应商会尝试向甚至是最终一种，但DevOps并不是工具。 它与人类和协作有关。 一些工具可以帮助人们进行协作。 通常，它们为具有不同背景的人们提供共享的术语和共享的生态系统； 但同样常见的是，流行的工具不利于协作。

当人们沉迷于工具链并使自己与不使用工具链的人保持距离时，以工具为中心的文化可以使人们更多地孤立，而不是帮助人们进行协作。 从技术上讲，它们可能是很棒的工具，可以在某些领域为我们提供帮助，但一堆新的所谓的DevOps工具却扩大了不同小组之间的差距。 例如，我经常听到“它在我的容器中工作”是开发人员用来定义“他们的”工作已经完成的陈述。 单靠容器并不能解决有效运行应用程序所需的协作挑战。 我们不能让工具成为新的孤岛。

5.没有DevOps被“认证”的东西。

没有多项选择题测试可以确认您作为个人是否与您的同事合作。 提供认证的组织可能在技术甚至协作原则方面拥有最出色的建议，但是证书不能表明有人擅长DevOps。

不幸的是，管理团队要求提供某些我们无法通过认证的证书。您可能会在自己喜欢的软件，硬件或云中接受教育。 上一所当地大学并阅读将对您进行教育的书籍，例如 ， ， 和的书籍。 但是不要指望通过认证在DevOps方面变得出色。 与您的同事一起工作更重要。

6.没有像DevOps管道这样的东西。

“ DevOps完成了吗？” “ DevOps管道正在运行。” “ DevOps管道已损坏。” 每当我听到这些声明时，我都想知道我们是如何做到这一点的。 我们只是重塑了交付管道的品牌，还是因为一些公司开始组建管理管道基础架构的DevOps团队？ 还是因为管道中断时开发人员调用操作？

这个概念也令人误解。 管道与服务或应用程序对齐，而不是与所有DevOps对齐。 当我们对管道进行泛化时，我们冒着在团队之间鼓励孤岛的风险，这将使我们远离DevOps的目标。

我推荐的是我在全球数百个组织中看到的内容：将Application X的管道称为Application X管道。 这样，我们将知道哪些应用程序无法通过其测试，进行部署或更新。 我们还将认识到负责Application X的团队，他们可能正在努力对其进行修复，也许在他们的ops朋友的帮助下。

7.没有标准DevOps这样的东西。

全球成千上万的DevOps故事中最难的消息是标准化。 就像我们无法认证人员一样，也没有一个人人都能适应的标准。 每个组织的旅程都不同，与其他组织的旅程也不同。 没有神奇的配方可以实现许多工具，设置许多自动化流程，突然间您将成为DevOps。

标准的DevOps意味着您实施了一个食谱，突然该组织开始合作，放弃办公室政治，提高质量，提高士气，并且在减少停机次数的情况下快速获得更高的收益。

DevOps被更好地理解为类似于的实践机构。 请记住，ITIL中的L代表图书馆（Library），这是具有最佳实践经验的图书馆，而不是说明手册。 对ITIL的仇恨很多来自那些（失败的）实现，这些实现将库作为详细的指导手册。 标准化的DevOps将取得相同的成果。

8.没有诸如DevSecOps之类的东西。

从2009年开始，我们就启动了DevOpsDays来邀请所有人。 当然，开发人员和操作人员可以看到最初的战场，但是每个人都包括在内：数据库管理员，测试人员，业务，财务以及安全。 甚至早在2012年，我们就在聚会上进行演讲，宣扬我们所做的事情。 我们开玩笑说，DevOps中的“ s”代表安全性，就像HTTPS中的“ S”一样。

DevOps本质上与安全性有关。 我发现在组织采用连续交付方面最大的成功来自安全团队。 CD是一项安全性要求：您需要能够根据需要进行部署，以便出于业务或安全原因可以在需要时进行部署和升级。

一方面，令人遗憾的是，我们必须发明一个词来使安全人员包括在内。 另一方面，最好再次进行讨论。 从根本上讲，DevSecOps和DevOps之间没有区别。 安全一直是开发和运营理念的一部分。 如果有帮助，我将其称为DevSecOps，但可以将其称为DevOps。

9.没有完成的DevOps过渡这样的事情。

您是否看过一个组织说过：“我们将在第四季度进行DevOps项目，到明年我们将成为DevOps”，并且成功了吗？ 我也没有。

软件交付永无止境，技术总是在变化，需要维护，并且理想情况下，DevOps思维定式始终存在。 改进交付方式后，您将希望不断改进。 并不是因为您的应用程序功能完整或它所居住的生态系统已经停止发展。 这是因为您的工作质量成倍提高，许多人的生活质量也得到了类似的提高。 在有人称这项工作“完成”之后，DevOps将会继续。

10.有诸如DevOops之类的东西。

不幸的是，许多人尚未意识到协作的重要性。 他们常常无意间建立了孤岛，对工具的重视程度高于实践，要求获得认证，并相信所有其他九个要点。 他们将很难以我喜欢称之为DevOops的方式取得成功。

对于DevOops来说，是要比DevOps原则更重视工具和孤岛，这将改善您的工作。 愿我们所有人都更多DevOpsy而更少DevOopsy。

主要外卖

在10年的DevOpsDays活动中，全球成千上万的人在协作和开放的环境中互相学习。 我发现一些与DevOps和敏捷目标相反的概念很流行。 专注于使您的服务在公司中运行良好，并不断学习。 这并不意味着需要对工具或仪表板进行复制和粘贴。 这将意味着专注于以各种方式不断改进。

祝您好运，我希望您在10月至在举行的 10周年庆典上见到您。 我们有很多发言者，包括：

• 将谈论
• 从
• 上的
• （
• （

很快见，回到一切开始。

翻译自: