DevOps思维模式的崛起

发布于:2021-01-22 13:32:12

0

126

0

DevOps 开发者

DevOps已经成为其中一个流行语,有许多相互矛盾的定义。可以肯定的是它正在上升。在我们2020年的开发者调查中,大约80%的受访者认为DevOps至少有点重要。我们来看看这个现象,一些定义,和我们的工程师谈谈我们的调查数据所反映的一些趋势。

什么是DevOps?为什么它如此流行?

DevOps试图解决的问题就在名字里。它旨在克服编写代码的团队(Dev)和管理用于运行和管理产品的基础设施和工具的团队(Ops)之间的制度鸿沟。随着软件开发生命周期变得越来越复杂,跟踪结果的责任变得越来越困难,也越来越容易将瓶颈、延迟的截止日期或产品质量的缺陷归咎于其他部门。

开发人员、质量保证人员和经常进一步分散的运营团队可能不知道彼此的障碍,对业务环境几乎没有洞察,甚至目标相反。不信任正在损害这个组织,让所有参与的人都不高兴。

StackOverflow的站点可靠性工程经理TomLimoncelli简短地指出了难点:“大多数地方的软件开发生命周期都被打破了。DevOps有助于解决这个问题。”

术语DevOps体现了对我们这个时代最关键问题之一的解决方案:软件团队如何才能最好地提供业务价值?答案是什么?开发人员和操作人员一起工作(DevOps),而不是孤立地工作。

如果DevOps信守承诺,其好处可以包括改进部署频率、加快上市时间、降低新版本的失败率以及缩短修复间隔时间。随着更大的可预测性、效率、安全性和可维护性的好处在整个生命周期中不断涌现。或者简单地说,就像Stack Overflow的首席产品官Teresa Dietrich一样,“正确的DevOps文化最终会让您交付的产品更好。”

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

那么,DevOps如何兑现承诺呢?

DevOps试图解决哪些问题?

在高层次上,DevOps有三个支柱:通信、自动化和测量。DevOps的状态报告发现,在DevOps取得成功的公司共享这些共同的线索

让我们进一步分析一下,看看一些DevOps实践以及它们试图解决的问题。

孤岛到团队思维

开发人员主要与开发人员合作,运营工程师主要与运营工程师合作,基础设施工程师关注他们的基础设施问题。很容易被孤立。

不同的部门和专家需要开始作为一个团队,朝着一个目标思考。为了使团队在没有摩擦的情况下共同工作,需要进行文化转变,并使用适当的工具来鼓励透明度。

这个想法被广泛引用的Gene Kim描述为所有SDLC步骤之间的平稳过渡,从确定需求到实际构建应用程序,然后将代码移交给IT操作,最后交付给客户机。

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

当孤岛盛行时,大多数公司会在应用程序部署的开发人员和操作人员之间感到更大的痛苦。

Limoncelli记得,他在其他公司工作时,新版本意味着需要数天或数周的手动部署,而这涉及到周末工作的情况并不少见。很多地方都有“地狱月”:这是一段紧张的时期,每个人都急于完成发布并部署它。在一些公司,这种情况一年发生12次以上,“有了良好的DevOps实践,那些‘地狱般的月份’就消失了。自动化是本月工作的重要组成部分。这可以防止消耗,减少损耗,使企业更具可持续性。

同样,DevOps的状态报告也显示了交付团队需要标准化他们的模式和组件。报告作者承认,这项任务的复杂性差异很大。“有些球队做这件事时没有考虑太多。其他人,特别是那些从整个组织继承代码的人,必须采取系统的方法消除变量并实现标准化。”

然而,利蒙切利确信,变化正在发生。他很高兴看到文化的变化。从招聘的角度来看,他告诉我,过去缺少“地狱月”是只有少数公司能提供的“额外津贴”。“最终,”他预测,“没有良好的DevOps实践的公司将发现很难聘用。”

标准化技术堆栈和惰性路径

不必要的复杂性和变化有许多历史或政治原因。因此,标准化作为过程的一部分使自动化更容易。

Splunk首席技术倡导者安迪曼(Andi Mann)在《DevOps州报告》(State of DevOps report)中写道,成功的公司表现出“齐心协力,使堆栈正常化,消除需要一次性维护、测试和管理的异常值或雪花。”,将应用程序配置保持在版本控制中,在部署之前测试基础结构更改,并将源代码提供给其他团队,作为DevOps早期阶段的基本步骤。

对于如何使DevOps成功的新观点,Limoncelli建议努力做到“低语境”。

低语境系统,相对于高语境系统,需要的先验知识很少。利蒙切利给我举了一个简单的例子:机场标识很容易理解,因为每个人,来自世界各地的旅客都可能需要知道如何去洗手间(如果你幸运的话)。而家庭聚餐的习俗,以及所有出席者之间的复杂关系,都是几十年来学来的,没有写下来。

利蒙切利认为,当DevOps团队努力创造一个低语境的工作环境时,他们会更加有效。例如,他主张让人们采纳推荐的做法的最好方法就是把它变成“懒惰之路”。“如果您对CI/CD和Git等基础工具的默认设置与您推荐的实践相匹配,那么您就是在让做正确的事情和做简单的事情一样。你希望人们落入成功的深渊。”

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

重复一个过程和完善也是由基因表达的,“重复和实践是掌握的先决条件。”

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

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

从手指指向反馈循环

如果你给你的同事带来了你应该怀疑的好处,那么你可以假设一个问题只会因为缺乏信息或沟通而被踢到开发周期的下一个团队。答案是:多分享。

正如吉恩所指出的,“分享带来信任,信任带来更高层次的合作。”在他的DevOps整体理论中,反馈循环是他的三个“DevOps之路”原则之一。

正如一个堆栈溢出用户在写Gene的循环时所说,“这是通过持续的集成/交付/部署以及共享的监视和警报来实现的。”。他们将自助服务监控和警报视为解决开发人员和操作人员在孤岛中工作的反模式问题的良方之一。“只需开放对这些关键指标的访问,就可以形成共享文化、填充反馈循环、实现持续反馈,并促进团队间的持续学习文化。”

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

利蒙切利还认为,DevOps预示着指指点点文化的终结,“探戈需要两个人,”他喜欢这样说。“这些改进不能仅仅由开发人员或操作人员(操作工程师、系统管理员、生产工程师、SRE)自己完成。DevOps就是要共同承担责任,从而实现合作。”

与失败交朋友

DevOps的心态不仅包括更好地传递错误反馈。这意味着一开始就要善于犯错。

基恩所描述的支柱之一是不断的实验,他强调冒险和从失败中吸取教训的重要性。蒂姆·亨特(timhunter)对Gene的三种方式的理解已进入官方正典,他解释说,DevOps的人们需要“实践中断,并找到创新的方法来处理它们。”

他们都认为DevOps给了团队克服限制的信心,因为有一个过程可以依靠并处理结果。更频繁的迭代和反馈会产生更好的产品。

到处都是DevOps?

从2008年多伦多敏捷大会那天开始,它已经走过了很长的一段路,当时围绕Ops和Dev如何改进协作的讨论只吸引了一位听众。相比之下,今年的Stack Overflow developer调查中,80%的受访者认为DevOps至少有点重要。

此外,44%的人报称在至少有一名DevOps员工的地方工作。我们还看到,该领域专家的价格标签反映了需求的增长。对于个人贡献者来说,专业化排在工资级别的首位。

不仅如此,如果考虑到经验的话,我们会发现DevOps的薪水要比在不同角色中拥有相似经验的开发人员高得多。

尽管今年约有12%的开发者调查参与者自称是DevOps专家,但采用DevOps思维模式的过程绝不意味着要雇佣一位拥有DevOps头衔的高薪专家,并完成这项工作。DevOps工程师应该构建工具并指导人们使用DevOps实践。错误的方法是让一个专门的DevOps团队为其他人完成工作,并由此创建一个新的竖井。这正是DevOps打算拆除的。