DevOps心态的兴起!!!

DevOps已经成为具有许多冲突定义的流行语之一。可以肯定的是它正在上升。在2020年开发人员调查中，约80％的受访者认为DevOps至少有些重要。我们研究了这种现象，一些定义，并与我们的工程师讨论了一些……
梅迪·玛德琳·格沃兹
DevOps已经成为具有许多冲突定义的流行语之一。可以肯定的是它正在上升。在2020年开发人员调查中，大约80％的受访者认为DevOps至少有些重要。我们研究了这种现象，一些定义，并与工程师讨论了调查统计数据所反映的一些趋势。

什么是DevOps，为什么它如此受欢迎？

DevOps试图解决的问题就是名字。它旨在克服编写代码的团队（Dev）和管理用于运行和管理产品的基础架构以及工具（Ops）的团队之间的制度分歧。随着软件开发生命周期变得越来越复杂，追踪结果的责任变得越来越难，并且更容易将瓶颈，延迟的期限或产品质量的缺陷归咎于其他部门。

开发人员，质量检查人员以及通常更分散的运营团队可能不知道彼此的障碍，对业务环境的了解甚少，甚至旨在达成相反的目标。不信任正在损害组织，并使每个参与其中的人都不高兴。

Stack Overflow的站点可靠性工程经理Tom Limoncelli简单而又痛苦地指出：“大多数地方的软件开发生命周期都被打破了。DevOps有助于解决该问题。”

DevOps一词体现了解决当今时代最关键问题之一的解决方案：软件团队如何才能最好地实现业务价值？答案？开发人员和运营部（DevOps）一起工作，而不是孤立地工作

如果DevOps坚持其承诺，则其好处可能包括提高部署频率，加快产品上市时间，减少新版本的故障以及缩短修复时间。随着更好的可预测性，效率，安全性和可维护性的优势，在整个生命周期中都会出现。简单地说，就像Stack Overflow的首席产品官Teresa Dietrich一样，“正确的DevOps文化最终会使您交付的产品更好。”

在今年的Stack Overflow开发人员调查中，有44％的受访者在至少拥有一名DevOps专用员工的组织中工作，世界各地的许多工程团队都在努力减轻现代软件开发的痛苦。

那么DevOps如何兑现其诺言呢？

DevOps试图解决哪些问题？

从总体上讲，DevOps具有三个支柱：通信，自动化和测量。该DevOps的国家报告发现，公司在随后的DevOps共享这些共同的线索。

让我们进一步分解一下，看看一些DevOps实践以及他们正在尝试解决的问题。

从孤岛到一团队思维

开发人员主要与开发人员合作，运营工程师主要与运营工程师合作，基础架构工程师专注于其基础架构问题。最终容易孤立。

不同的部门和专家需要开始以一个团队的方式思考，朝着一个目标迈进。为了使团队能够无摩擦地协同工作，需要进行文化上的转变，并采用适当的工具来鼓励透明度。

Gene Kim将该想法描述为在SDLC所有步骤之间的平稳过渡，从确定需求到实际构建应用程序，然后将代码移交给IT运营，最后交付给客户。

发布期间不再有“地狱月”

当孤岛现象盛行时，大多数公司将在应用程序部署的开发和运营之间感到更大的痛苦。

利蒙切利（Limoncelli）回忆起他在其他公司工作的经历，当新版本意味着数天或数周的手动部署时，通常需要在周末进行工作。许多地方都有“地狱月”：每个人都急于完成发布和部署的紧张时期。在某些公司，这种情况每年发生超过12次。” 通过良好的DevOps实践，那些“地狱月”将消失。自动化是消除地狱月的重要组成部分。这样可以防止精疲力尽，减少人员流失并使业务更具可持续性。

同样，DevOps状态报告表明，交付团队需要标准化其模式和组件。该报告的作者承认，这项任务的复杂性差异很大。“有些团队没有过多考虑就这样做。其他人，尤其是那些从整个组织继承代码的人，必须采取有条理的方法来消除变量并实现标准化。”

尽管如此，利蒙切利坚信变化正在发生。他很高兴看到文化的变化。从招聘的角度来看，他告诉我，“地狱月”的匮乏曾经是只有少数公司可以提供的“福利”。他预测，“最终，”没有良好DevOps实践的公司将根本很难招聘。”

**

标准化技术栈和惰性路径

**

造成不必要的复杂性和变化有很多历史或政治原因。因此，标准化是流程的一部分，使自动化变得更加容易。

Splunk首席技术倡导者安迪·曼恩（Andi Mann）在《DevOps状况》报告中写道，成功的公司表现出“共同努力，使协议栈标准化并摆脱了需要一次性维护，测试和管理的异常值或雪花。 ’ 作者包括建立一套标准的技术，将应用程序配置保留在版本控制中，在部署之前测试基础架构的更改以及将源代码提供给其他团队，作为DevOps早期阶段的必要步骤。

对于如何使DevOps取得成功的全新观点，Limoncelli建议争取“低背景”。

与高上下文环境相比，低上下文系统几乎不需要先验知识。利蒙切利给我的简单例子如下：机场标牌对每个人来说都很容易理解-来自世界各地的旅行者可能需要知道如何上厕所（如果幸运的话）。在数十年的学习中，我们不但写下家庭宴席上的习俗以及所有参加者之间的复杂关系。

Limoncelli相信DevOps团队在努力创建低语境的工作环境时会更有效率。例如，他主张让人们采用推荐做法的最佳方法是使其成为“懒惰之路”。“如果您的基础工具（例如CI / CD和Git）的默认设置符合您的建议做法，那么您在做正确的事就和做简单的事一样。您希望人们落入成功之门。”

如果您想了解有关创建低上下文DevOps环境的更多信息，请单击此处查看Tom的网络研讨会（免费，需要注册）。

吉恩（Gene）还以“ 重复和实践”作为精通的前提表达了重复一个过程和完善。”

DevOps状态讨论了在这种情况下构件的重用。它指出，通过共享模式的反馈，这不仅节省了“消耗”构建块的团队的时间和精力，而且还改善了整个组织使用的工具。

说到反馈：这是DevOps掌握的另一项技能。

从手指指向反馈循环

如果您给同事带来怀疑的好处（您应该这样做），那么您可以假设由于缺乏信息或沟通，问题只会在开发周期的下一个团队中受到影响。答案是：分享更多。

正如Gene所指出的： “共享带来信任，信任带来更高水平的协作。” 在他的DevOps整体理论中，反馈回路是他的三个“ DevOps之道”原理之一。

当Stack Overflow用户写到 Gene的循环时，“这是通过持续的集成/交付/部署以及共享的监视和警报来实现的。” 《DevOps状态报告》的作者对此表示赞同。他们将自助监视和警报视为开发和运营孤岛上的反模式的对策之一。“只需打开对这些关键指标的访问权限，就可以实现共享文化，填充反馈循环，实现持续反馈并促进团队之间持续学习的文化。”

根据Gene的说法，从Ops到Dev的反馈循环意味着每个开发人员都应努力理解其所有客户的反馈。在这里，他将各个部门视为内部客户。

利蒙切利（Limoncelli）还认为DevOps预示着指尖文化的终结：“探戈需要两个人”，他喜欢这样说。“开发人员或开发人员（运营工程师，系统管理员，生产工程师，SRE）无法独自进行改进。DevOps是关于共同承担责任，因此是合作。”

与失败交朋友

DevOps的心态不仅包括在传递有关错误的反馈方面变得更好。这意味着首先要变得更容易犯错误。
吉恩描述的支柱之一是不断进行实验，他强调冒险和从失败中学习的重要性。蒂姆·亨特（Tim Hunter）对吉恩的三种方式的看法已经进入正式的典范。

两者都把DevOps写为使团队有信心克服局限性，因为有一个过程可以依靠并处理结果。更频繁的迭代和反馈会带来更好的产品。

DevOps作为自助服务

请注意，DevOps状态报告在DevOps成功的原型阶段的第五步（也是最后一步）中包括自助服务。因此，您可以将其视为DevOps的更高阶段。

在这里，组织哲学的实施应允许生命周期中的每个人都可以访问内部服务，包括开发，运营，安全性，ITSM和其他功能区域。

进行这些自助服务可以使团队和个人以自己的速度工作，而不必等待诸如批准机票，获取许可证密钥，安装所需的配置或让Sara休假之类的事情。

根据《 DevOps状况报告》，对此的一个重要要求是，Ops必须提供与最终生产环境相匹配的供QA和Dev使用的系统和配置。否则，软件通常会在与生产环境不同的环境中进行测试。自助服务基础结构有助于使两个环境尽可能相似。

工具：定义工具是什么？
工具不能神奇地解决问题。但是，更好的做法需要正确的工具。您希望命名一些名字吗？

在Stack Overflow的姐妹网络上，我们有一个专用的Stack Exchange DevOps社区。大多数DevOps工程师都在此网站以及Stackoverflow.com上与我们共度时光。这些标签很好地表明了DevOps工程师目前正在使用的工具。

事不宜迟，DevOps上的30个热门主题标签：

您的DevOps工具套件很可能包括：

工作跟踪：Asana，星期一，Jira，
源代码控制：Git，Github，GitLab，BitBucket，TFS
CI / CD：詹金斯（Jenkins），Team City，Github Actions
源代码分析：SonarQube
工件管理：Artifactory，Docker容器注册
配置管理：Terraform，Ansible，PowerShell / DSC，Puppet（落后于DevOps状态报告）和Chef
容器编排：Docker，Kubernetes
监测：普罗米修斯
为了进一步增强自动化工具，虚拟基础架构允许组织以自动化方式配置服务器。Amazon Web Services和Microsoft Azure是虚拟基础架构的示例。
注意：大多数DevOps标签在Stackoverflow.com上都有大量的知识资源。与DevOps一样，不要将其视为严格的技术堆栈。实际上，很可能是在应用程序生命周期中与相邻工具松散耦合的工具。

到处都是DevOps？

自从2008年多伦多敏捷会议上关于Ops和Dev如何改进协作的讨论吸引了众多听众以来，这已经走过了很长的一段路。相比之下，今年的Stack Overflow developer调查显示，80%的受访者认为DevOps至少有些重要。

此外，44%的人表示在一个至少有一名DevOps员工的地方工作。我们还看到，该领域专家的价格标签反映了需求的不断增长。专业化在个人贡献者的工资表中名列前茅。

                   2020年收入最高的开发商

不仅如此，如果你考虑到经验，我们可以看到DevOps的薪水比在不同角色中具有类似经验的开发人员高得多。尽管今年约有12%的开发人员调查参与者自称是DevOps专家，但采用DevOps思维方式的过程绝不意味着雇佣那些在职位上拥有DevOps的高薪专家之一，并就此了结。DevOps工程师应该构建工具并指导人们使用DevOps实践。错误的做法是拥有一个专门的DevOps团队来为其他人做工作，并由此创建一个新的竖井。正是DevOps要拆掉的东西。
在该领域的领导地位来自一些通常的犯罪嫌疑人，但不仅限于此。如何逐个团队解释DevOps的心态可能会有所不同。以及如何将安全团队整合到软件开发的整体方法中，这是最佳实践，值得关注。
据说只有几只独角兽。Netflix、Amazon或Google）曾经达到过“在没有任何人为干预的情况下，一路部署到生产中”的持续部署理想。
我对Stack Overflow员工将我们放在何处感到好奇。我与之交谈的人（大多数是SRE）似乎都同意，我们处于中间位置。

Stack Overflow的站点可靠性工程经理Tom Limoncelli认为该公司目前在DevOps方面表现出色，五分之三。他还计划进行一些雄心勃勃的项目，以进一步改善我们的运营。“一年后再问我！” 他惊呼。

引入DevOps是一个巨大的组织转变。毫无疑问会涉及风险。因此，需要一定的好奇心和投入。Garner的Spafford曾经说过：“ DevOps挑战了传统的IT思维，它的不断发展以及对风险接受和管理的要求。”

由于目前缺乏标准方法，因此有一个定义会一直存在。它来自与Stack Overflow网站可靠性工程师Chris Hunt的交谈：“ DevOps就像矩阵中的汤匙。弯曲的不是DevOps，而是您自己。”