DevOpsDays的开创者DevOps资深人士Chris Bytaert分享了他的经验，他的发现将使您感到惊讶。
十年前，我们突然去了一次旅行。我们聚集了比利时根特的一些好朋友，讨论了敏捷，开源和早期云计算的经验。 2009年，John Ollspoe和Paul Hammond在Velocity上做了“每天10个以上的部署：Flickr上的Dev和Ops协作”的演讲（该演讲的录音值得一看）。看完这个演讲后，Patrick Debois决定成立DevOpsDays。
十年来，DevOps世界真的发生了很大变化吗？自从会议开始以来，我一直参加DevOpsDays活动，在这段时间里，我积累了丰富的经验。在这篇文章中，我将分享10个可能对您有帮助的教程。
1.没有像DevOps工程师这样的人
许多团队的人都具有DevOps工程师的头衔，但并非所有专家都喜欢这个头衔。这个专业名称给人一种错误的印象，即DevOps是一项可以由一个人完成的工作。 DevOps工程师通常是Linux工程师，有些运气可以解决自动化问题。当招聘人员开始寻找DevOps工程师时，求职者应该问自己正确的问题：“公司真正想要求职者什么？他们在寻找组装工程师吗？ Senora谁了解非功能性需求？操作部门的专家能够处理自动化或其他人吗？”大多数情况下，公司正在寻找一位专家，以分散其余员工的注意力，使其无法满足敏捷的实际原则和要求。
通常，在拥有大型DevOps部门的组织中，没有人参与DevOps。“ DevOps”一词仅表示与团队其他成员的分离，申请人可以得到不错的薪水并学习工作中的新技能，但他不会“从事DevOps”。
2. DevOps团队不存在
过去我们经常说过，DevOps的目标是消除不同团队之间的混淆。特别是在开发人员和运营部门员工之间。但是，最近我们遇到了一个新现象-许多DevOps团队的出现。
建立DevOps团队听起来像是一种新做法，但是这里存在明显的矛盾。在一个组织中，这个团队将处理开发工具，而在另一个组织中，这实际上是开发团队和运营专家之间的隔离墙。问题在于，这堵墙会造成混乱，沮丧并降低有用互动的程度。称为“ DevOps”的团队最多可以解决各种问题，并对与他们一起工作的服务负有责任。通常，专业团队不希望在名称中使用“ DevOps”一词。
以我的经验，在团队名称中使用“ DevOps”一词可能会阻碍实现预期结果。
3. DevOps项目不存在
所有项目都是有限的。您可以开发，部署解决方案并继续前进。另外，在过去的十年中，有传言说DevOps是持续改进的，而持续改进是无止境的。反过来，您的项目的结果是长期运行的服务，并且该服务暗含着“开发->部署->健康支持”的顺序
只有在查看了项目之外的服务之后，我们才能看到容易忘记的方面：非功能性需求。非功能需求包括不适合特定行为的功能。这些要求还决定了我们对系统性能的评估。这些要求通常包括归类为DevOps的方面：可靠性，可用性，可维护性和可伸缩性。所有这些特征对于实现业务成果都很重要。
在处理短期项目时，有可能您不会对此工作给予足够的重视。当您进入下一个项目时，您将不再考虑上一个项目的非功能性需求，因为您将面临新的挑战，而其他问题将不再困扰您。反过来，在管理服务时，您确实会参与到工作中，并且对所有内容进行优化以使所有内容都能平稳运行是您的最大利益。
4. DevOps工具不存在
尽管许多供应商会尝试向您出售各种工具，其中包括一种可以解决您所有问题的工具，但DevOps与工具无关。 DevOps与人及其互动有关。一些工具确实可以帮助人们进行协作。通常，工具可以帮助来自不同背景的人们共享相同的术语和生态系统。但是，工具经常会阻碍有效的沟通。
基于工具的文化可以隔离人们而不是帮助他们进行交互。事实是，人们沉迷于他们的工具链，并远离那些不使用它的人。从技术的角度来看，某些工具可能非常有用，但是许多新工具（通常称为DevOps）扩大了不同群体之间的分歧。例如，我经常听到“这在我的容器中起作用”的短语。开发人员使用此短语表示“他们的”工作已完成。容器本身不能解决与有效运行应用程序相关的互操作性问题。我们不能允许工具彼此隔开。
5. DevOps中没有认证
没有多项选择测试可以确认您能够与同事进行有效的沟通。提供认证的组织可能具有令人难以置信的技术专长（甚至是有效的沟通），但是认证不能表明有人擅长DevOps。
不幸的是，管理团队要求在难以认证的领域进行认证。受过您最喜欢的软件和硬件的教育，并探索云。在当地大学学习，阅读可以从中学到很多东西的书，特别是戴明，福斯格伦，汉布尔等人写的书... 但是一旦获得认证，就不要指望在DevOps中表现最好。与同事的互动更为重要。
6. DevOps管道不存在
“ DevOps已经工作了吗？”“ DevOps管道正在工作。” “ DevOps管道已损坏。” 每当我听到这些声明时，我都会为我们想到这个术语感到惊讶，我们是否重新命名了部署管道，还是某些公司的DevOps团队正在使用此基础架构？或者也许是因为开发人员正在呼叫运营团队管道是否破裂？
尽管CI / CD技术非常重要，但我对术语“ DevOps管道”的使用持怀疑态度。如果开发流程中断，则应归咎于运营团队。开发人员在编写测试时不会考虑管道。这个概念本身也是令人误解的。分别为每个服务或应用程序创建管道，而不是为整个DevOps域创建管道。通过创建通用管道，我们冒着增大团队之间差距的风险，而这并不是DevOps的目标。
我建议使用一种在全球数百个组织中见过的技术：将每个单独的管道称为Application X管道，这种术语将使测试，部署或升级时更容易知道哪个应用程序存在问题。我们还将知道哪个团队将在附录X中进行修复（可能在操作团队的朋友的帮助下）。
7. DevOps没有标准
在数千个DevOps故事中，最难的是标准化。与我们无法认证人员的方式相同，DevOps中没有一种适合所有标准的尺寸。每个组织都有自己的路径，并且这些路径可以非常不同。没有神奇的秘诀列出工具，并描述创建自动化流程的方法，这些流程将突然成为组织中的DevOps。
DevOps中的标准意味着您将采用某种方法，使您的组织可以开始协作并摆脱办公室政治，它还应该提高工作质量，提高士气并让您以更少的干扰获得更好的结果。
DevOps应该被理解为一组与方法类似的实践ITIL。请记住，ITIL中的L代表图书馆。而且，该库不应作为操作指南，而应作为最佳实践列表，您需要从中选择最适合自己的实践。ITIL之所以被憎恨，恰恰是因为没有成功实现，在该实现中，该库正好被用作逐步指导。DevOps中的标准化将产生相同的结果。
8.没有像DevSecOps这样的东西
我们于2009年启动了DevOpsDays，该会议向所有人开放。当然，最初，这是针对操作团队的开发人员和员工的活动，但所有人都来找我们：数据库管理员，测试人员，业务分析师，金融家，当然还有安全专家。早在2012年，我们在OWASP会议上发表讲话，谈到了我们所做的事情。我们开玩笑说，就像HTTPS中的“ S”一样，DevOps中的“ S”代表安全性。
DevOps是安全性的核心。我发现CD原则最适合安全团队。CD是一项安全性要求：您必须能够随时进行部署，这将使您能够部署和实施业务或安全性问题所需的更新。
一方面，令人遗憾的是我们不得不想出包括安全负责人在内的言论。另一方面，很高兴我们再次讨论了这一点。基本上，DevSecOps和DevOps之间没有区别。安全一直是开发和运营的一部分。我可以为此使用术语DevSecOps，但是最好仅使用术语DevOps。
9.您不能切换到DevOps
您是否遇到过一家公司发表过这样的声明：“我们今年第四季度正在进行DevOps项目，明年我们将完全转向DevOps”，这真的成功了吗？所以我还没见面。
软件交付永远不会停止，技术总是在变化，它总是需要支持，并且（理想情况下）对DevOps的态度和态度应该保持不变。完善交付方式后，您将需要进一步改进。这不是因为应用程序的所有功能都已实现，也不是因为应用程序所在的生态系统已经停止开发。您将希望继续发展，因为您的工作质量呈指数增长，同时生活质量也在增长。即使某些任务获得“已完成”状态，DevOps仍将继续发展。
10.有一个像“ Dev-oops”的东西
不幸的是，许多人不了解协作的重要性。他们在团队之间建立起隔离墙，认为工具比实践更重要，要求对所有人和所有人进行认证。他们还认为以前的所有9条陈述都是错误的。这些人将永远为成功实现我所谓的Dev-Oops而奋斗。
DevOps涉及思维工具，团队分隔远比可以改善工作的真正DevOps原则更为重要。让我们努力去做DevOps，而不是DevOops。
主要目标
我们已经运行DevOpsDays已有10年了，在这段时间里，成千上万的人在一个轻松，开放的环境中相互学习了很多有趣的东西。我发现一些与DevOps和敏捷目标冲突的概念很流行。专注于获得服务以帮助您的公司，并且不要停止学习。这与复制工具并在组织中实现它们无关。这是关于以各种方式关注持续改进。
通过参加SkillFactory的付费在线课程，了解如何从头开始或在技能和薪资水平上获得高水平职业的详细信息：
- DevOps课程（12个月）
更多课程
- - (8 )
- UX- (9 )
- Web- (7 )
- Machine Learning (12 )
- Data Science (12 )
- (9 )
- «Python -» (9 )