十年前，我们开始了一段偶然的旅程。我们聚集了比利时根特的一些好朋友，讨论我们的敏捷、开源和早期云经验。Patrick Debois 在 John Allspaw 和 Paul Hammond 在 Velocity 2009 上的演讲“每天 10+ 次部署：Flickr 的开发和运维合作”（非常值得观看）之后，创造了 #DevOpsdays 这个活动名称。
现在，十年后，世界已经不同了。DevOps 无处不在，对吗？ 还是真的如此？ 自创立以来，我一直参加 DevOpsDays 活动，并且从我的经验中学到了很多。这里有 10 个要点，希望您也能从中学习。
1. 没有 DevOps 工程师这种说法。
现在很多人都将“DevOps 工程师”作为职位名称，而且很多人不喜欢这个头衔。这个头衔给人一种错误的印象，即 DevOps 是一项可以由单个“DevOp”完成的工作。大多数情况下，DevOps 工程师是一位 Linux 工程师，如果他们幸运的话，会做一点自动化。当招聘人员开始寻找 DevOps 工程师时，应聘者需要问自己正确的问题，首先是：“公司实际需要应聘者做什么？” 他们是在寻找构建工程师、了解非功能性需求的高级开发人员、可以自动化事物的高级运维人员，还是完全其他的东西？ 大多数情况下，他们真正寻找的是会转移视线，不去关注实践中缺乏敏捷原则的人。
在一个拥有大量 DevOps 工程师的组织中，这通常意味着没有 DevOps 正在发生。DevOps 头衔是新的信息孤岛的标志，应聘者可以赚到不错的钱并在工作中学习新技能，但他们不会“做 DevOps”。
2. 没有 DevOps 团队这种说法。
在早期，我们经常说 DevOps 是关于消除不同团队、开发人员和运维人员之间的混乱之墙，关于打破信息孤岛。然而，在旅程的某个地方，我们看到了一个新的现象：DevOps 团队的兴起。
“DevOps 团队”听起来像是一种新的实践，但各个组织之间的不一致性显而易见。在一个组织中，它是负责工具的团队，在另一个组织中，它实际上是开发团队和运维团队之间的信息孤岛——一个造成更多混乱、更多挫败感和更少协作的信息孤岛。在最好的情况下，它偶尔是具有对其构建的服务承担端到端责任的跨职能团队。这些团队通常更喜欢不被称为 DevOps 团队。
我发现，将团队称为“DevOps”可能会阻碍您旨在通过 DevOps 实现的结果。
3. 没有 DevOps 项目这种说法。
“项目”本质上是有限的。它是您构建、交付然后转移的事情。来自 10 年演讲的一个一致主题是，DevOps 是关于持续改进的，而持续改进永不完成。同样，这些所谓的项目的输出是长期服务，而服务是您构建、交付并保持运行的东西。
只有在我们思考服务如何超出项目范围时，我们才开始看到容易被遗忘的事情：非功能性需求 (NFR)。NFR 包括不完全符合特定行为的功能。NFR 定义了我们如何评判系统的运行。它们通常包括您在 DevOps 周围听到的所有“-性”：安全性、可靠性、可用性、可维护性和可扩展性。所有这些对于业务成果都至关重要。
在缺乏同理心的情况下思考短期项目存在风险。当您转移到另一个项目时，您不会像关注 NFR 那样关注，因为您正忙于新的挑战，现在是别人的问题了。但是，当您运行服务时，您确实关心，并且减少摩擦以保持事物平稳运行符合您的最佳利益。
4. 没有 DevOps 工具这种说法。
虽然许多供应商会尝试向您出售一个，甚至是终极的工具，但 DevOps 不是关于工具。它是关于人和协作。一些工具帮助人们协作；通常它们为具有不同背景的人们提供了共享的术语和共享的生态系统；但同样常见的是，流行的工具会阻碍协作。
以工具为中心的文化是一种比帮助人们协作更能隔离人们的文化，因为人们会痴迷于他们的工具链，并与那些不使用它的人保持距离。虽然从技术上讲，它们可能是很棒的工具，并在某些领域对我们有所帮助，但许多新的所谓 DevOps 工具扩大了不同群体之间的差距。例如，我经常听到“它在我的容器中工作”这句话，这是开发人员用来定义“他们的”工作已完成的声明。仅靠容器并不能解决有效运行应用程序所需的协作挑战。我们不能让工具成为新的信息孤岛。
5. 没有 DevOps “认证”这种说法。
没有多项选择题测试可以确认您作为个人与您的同事协作。提供认证的组织可能在技术甚至协作原则方面拥有最好的建议，但证书不能表明某人擅长 DevOps。
令人遗憾的是，管理团队要求获得我们无法获得认证的东西的证书。在您喜欢的软件、硬件或云方面接受教育。参加当地大学并阅读将教育您的书籍，例如 Deming、Forsgren、Humble 和 其他人 的著作。但不要期望通过认证成为 DevOps 专家；与您的同事一起工作更重要。
6. 没有 DevOps 管道这种说法。
“DevOps 完成了吗？” “DevOps 管道正在运行。” “DevOps 管道坏了。” 每当我听到这些陈述时，我都会想我们是如何得到这样一个术语的。我们只是重新命名了交付管道，还是因为一些公司开始组建 DevOps 团队来管理管道的基础设施？ 还是因为开发人员在管道坏了时呼叫运维人员？
虽然引入持续集成和持续交付 (CI/CD) 原则对组织产生了巨大影响，但我认为“DevOps 管道”这个术语的使用方式会引发指责。当开发人员的管道坏了时，运维团队有过错。只要开发团队编写了测试，他们就不担心管道失败。
这个概念也具有误导性。管道与服务或应用程序对齐，而不是与所有 DevOps 对齐。当我们概括管道时，我们就有可能鼓励团队之间的信息孤岛，这将使我们远离 DevOps 的目标。
我推荐的是我在世界各地数百个组织中看到的：将应用程序 X 的管道称为应用程序 X 管道。这样，我们就会知道哪个应用程序在通过测试、部署或更新时遇到问题。我们也会知道负责应用程序 X 的团队，他们会忙于修复它，也许会在他们的运维朋友的帮助下修复。
7. 没有标准 DevOps 这种说法。
来自全球数千个 DevOps 故事的最艰难的消息是标准化。就像我们无法认证人一样，也没有一刀切的标准；每个组织都处于他们旅程的不同阶段，与其他组织的旅程不同。没有神奇的秘诀，您只需实施一些工具，设置一些自动化流程，然后您突然就成为了 DevOps。
标准 DevOps 将意味着您实施了一个秘诀，然后组织突然开始协作，放弃办公室政治，提高质量，提高士气，并走上以更高的收入和更少的停机时间实现快速发展的道路。
DevOps 最好理解为类似于 ITIL 的实践体系。记住 ITIL 中的 L 代表库，一个包含最佳实践的库，可从中精选——而不是操作手册。对 ITIL 的许多憎恨来自于那些（失败的）实施，他们将库视为详细的操作手册。标准化 DevOps 将结出同样的果实。
8. 没有 DevSecOps 这种说法。
从 2009 年的最初开始，我们就将 DevOpsDays 作为一个邀请所有人的地方。当然，最初的战场在开发人员和运维人员之间是可见的，但每个人都包括在内：数据库管理员、测试人员、业务、财务，是的，还有安全。早在 2012 年，我们就在 OWASP 聚会上发表演讲，宣传我们所做的事情。我们开玩笑说 DevOps 中的“s”代表安全，就像 HTTPS 中的“S”一样。
DevOps 本质上是关于安全的。我发现在组织采用持续交付方面取得的最大成功来自安全团队。CD 是一项安全要求：您需要有能力随时部署，以便您可以在出于业务或安全原因需要时进行部署和升级。
一方面，令人难过的是，我们不得不发明一个词来让安全人员参与进来。另一方面，很高兴再次进行讨论。从根本上讲，DevSecOps 和 DevOps 之间没有区别。安全一直是开发和运维思维的一部分。如果称之为 DevSecOps 有帮助，我会称之为 DevSecOps，但只称之为 DevOps 也可以。
9. 没有完成的 DevOps 转型这种说法。
您是否见过哪个组织说，“我们将在第四季度完成 DevOps 项目，到明年我们将成为 DevOps”——并且成功了？ 我也没有见过。
软件交付永不停息，技术总是在变化，将需要维护，并且——理想情况下——DevOps 思维会持续存在。一旦您改进了交付方法，您就会想要不断改进。这不会是因为您的应用程序功能完整，或者它所处的生态系统已停止发展。这将是因为您的工作质量呈指数级提高，并且许多人在他们的生活质量方面也体验到类似的提高。在有人称这项努力“完成”很久之后，DevOps 将继续存在。
10. 有 DevOops 这种说法。
不幸的是，许多人没有意识到协作的重要性。他们经常无意中建立信息孤岛，比实践更重视工具，要求认证，并相信其他九个要点。他们将以我喜欢称之为 DevOops 的方式努力取得成功。
DevOops 是指比将改善您工作的 DevOps 原则更重视工具和信息孤岛效应。愿我们都更 DevOpsy，少 DevOopsy。
主要收获
在 DevOpsDays 活动的 10 年中，世界各地成千上万的人们在协作和开放的环境中互相学习。我发现一些与 DevOps 和敏捷目标背道而驰的概念很流行。专注于使您的服务在您的公司中良好运行，并在过程中学习。这并不意味着复制粘贴工具或仪表板。这将意味着专注于以各种方式持续改进。
祝您好运，我希望在 10 月 29 日至 30 日在根特 DevOpsDays 的 10 周年庆典上见到您。我们有强大的演讲者阵容，包括：
- Patrick Debois 将谈论 连接所有业务管道
- Bryan Liles 将谈论 从系统管理员到 DevOps：我们从哪里来，要到哪里去
- Bridget Kromhout 将谈论 分布式 DevOps
- Ant Stanley 将谈论 无服务器设计模式如何不改变任何东西 [对于 DevOps]
- Julie Gundersen 将谈论 成为 DevOps 的倡导者
很快再见，回到一切开始的地方。
4 条评论