谈谈DevOps那些不是你以为的事儿
十年后的今天各种大会上经常出现DevOps专场，行业内也有很多公司开始招聘DevOps工程师，它逐渐演变成一种主流的软件开发交付模式，出现的频率也越来越高。
这篇文章就是资深人士Kris Buytaert谈谈那些DevOps的事儿。（以下十点可能和你的直觉正好相反）
1.没有DevOps工程师
现在，很多人的头衔是“ DevOps工程师”，但它其实不是一个人、一个角色或者一个头衔。它给人一种错误的印象，即DevOps是单个“ DevOp”就可以完成的任务。 其实DevOps工程师通常是Linux工程师，如果幸运的话，他可能还会做一点自动化的工作。
当招聘人员开始寻找所谓的DevOps工程师时，应聘者应该问问自己这些问题，“公司实际需要你做什么工作？”他们是在寻找一个架构工程师，了解非功能性需求的高级开发人员，可以使事情自动化的高级操作人员，还是什么？
2.没有DevOps团队
不同的组织具有不一致性，DevOps工程师的工作性质也因组织而异。比如有些是在基础设施自动化和维护中发挥作用，而在另外一些组织中却是在整个交付链中发挥作用而已。
DevOps工程师的角色各不相同，因为他必须通过克服传统协作障碍与开发和运维人员进行协作。而不同的组织有不同的障碍，因此其扮演的角色自然不同。
所以，没有将团队称为“ DevOps”，只是在DevOps模式下，这三个团队不再孤立，高效协作。
3.没有DevOps项目
实际上我们通常所说的项目是有期限的：构建、交付然后进行下一个项目，但其实DevOps是关于持续改进的，那也就意味着持续改进其实是不会完成的。
只有在考虑了服务如何扩展到项目之外之后，我们才开始看到容易忘记的事情：非功能需求（NFR），NFRs包含与特定行为不完全匹配的功能。 NFR定义了我们如何判断系统的运行情况。它们通常包括您在DevOps上听到的所有“ilities”：安全性、可靠性、可用性、可维护性和可扩展性，所有这些对于业务成果都至关重要。
在短期项目中缺乏思考所需的同理心是存在风险的。当开始从事另一个项目时，您就不会太关心NFR了，因为您正忙于应对一个新挑战，但不可避免的是，他又会成为别人的问题，所以，持续总是和DevOps挂钩。
4.DevOps与工具无关
尽管许多供应商会尝试向您出售一种工具，但DevOps与工具无关。它主要与人类和协作有关，当然，一些工具可以帮助人们进行协作，它们为具有不同背景的人们提供共享的术语和共享的生态系统；但同样常见的情形是，流行的工具反而不利于协作。
以工具为中心反而会使人们之间的距离越远，而不是更好地帮助人们协作。从技术上来说，在某些领域会对我们有所帮助，但是所谓的“DevOps工具”实际上扩大了不同组之间的差距。
例如，我经常听到“它在我的容器中工作”是开发人员用来定义“他们的”工作已经完成的陈述，但其实，单靠容器并不能解决有效运行应用程序所需的协作挑战。
我们不能让工具成为新的孤岛。
5.没有DevOps“认证”
证书不能表明某人擅长DevOps。不幸的是，管理团队会要求提供一些我们可能无法通过认证的证书。
您可能会针对自己感兴趣的软件、硬件通过书籍、学校进行学习，但是不要指望通过认证就成为DevOps的佼佼者，实践会更重要一些。
6.没有像DevOps管道这样的东西
“ DevOps完成了吗？” “ DevOps管道正在运行。” “ DevOps管道已损坏。”每当我听到这些陈述时，我都想知道我们是如何做到这一点的，现实中的我们可能只是重新定义了交付管道，一些公司开始启动DevOps团队来管理管道的基础设施······
虽然引入持续集成和持续交付（CI / CD）原则对组织产生了巨大影响，但“ DevOps管道”一词的使用方式在我个人看来是一种错误的诱导。当开发人员的管道中断时，Ops团队就会出现问题。开发团队只要编写测试，就不必担心管道失败。这个概念也具有误导性。管道与服务或应用程序对齐，而不是与所有DevOps对齐，这将使我们远离DevOps的目标。
我推荐的是我在全球数百个组织中看到的内容：将应用程序的管道称为应用程序X管道。这样，我们将知道哪些应用程序无法通过其测试、部署或更新。我们还将认识到负责Application X的团队，他们可能会忙于对其进行修复。
7.没有所谓的标准DevOps
全球数千个DevOps故事中最糟糕的就是标准化。就像我们无法对人员进行认证一样，也没有放之四海而皆准的标准。每个组织的所处的阶段都不同，与其他组织也不同。没有任何一种神奇的配方可以实现大量工具，设置大量的自动化流程。
DevOps被更好地理解为类似于ITIL的实践体。ITIL中的L代表库（Library），这是一个具有最佳实践经验的库，而不是指导手册。对ITIL的很多憎恨来自那些（失败的）实现，这些实现将库作为详细的指导手册。标准化的DevOps将取得相同的成果。
8.没有诸如DevSecOps之类的东西
DevOps本质上与安全性有关。我发现在组织采用连续交付方面最大的成功来自安全团队。 CD是一种安全需求：您能够出于业务或安全原因可以在需要时进行部署和升级。从根本上讲，DevSecOps和DevOps之间没有区别。安全一直是开发和运营理念的一部分。
9.没有完成DevOps这样的事情
您是否见过一个组织表示，“我们将在第四季度进行DevOps项目，到明年我们将成为DevOps”，并且还成功了？
软件交付永无止境，技术总是在变化，需要维护，并且，理想情况下，DevOps思维方式始终存在。改进交付方式后，您将还会想不断改进。并不是因为您的应用程序功能完整或它所处的生态系统已经停止发展。这是因为您的工作质量成倍提高，许多人的生活质量也得到了类似的提高。
在有人称这项工作“完成”之后，实际上DevOps仍将继续工作很长时间。
10.有诸如DevOops之类的东西
不幸的是，许多人尚未意识到协作的重要性。他们常常无意间建立了孤岛，把工具看的比实践更重要，要求获得认证，并相信上述九个要点。他们将很难以我所述的DevOops的方式取得成功。
对于DevOops来说，是要比DevOps原则更重视工具和孤岛，这将改善您的工作。愿我们所有人的DevOpsy更多，而DevOopsy更少