Close

DevOps:打破开发运维的屏障

什么是 DevOps?

DevOps 为我们带来了一项优势

“DevOps 使我们非常频繁地进行发布,为我们提供了上市时间优势。我们现在能够每天发布产品,而非 6 个月发布一次,并能在几个小时内为客户推送修复信息。”

— Hamesh Chawla,Zephyr 的工程副总裁

DevOps 是一组能够自动执行软件开发团队和 IT 团队之间流程,以便他们可以更快速更可靠地构建、测试和发布软件的做法。DevOps 的理念基础是在过去在相对孤立的小环境中工作的团队之间构建协作文化。承诺的优势包括增加信任、更快地发布软件、更快地解决关键问题,以及更好地管理计划外工作。

在 Atlassian,DevOps 是接近 Brangelina (Brad Pitt and Angelina Jolie) 的下一个最炙手可热的混成词(两个词的组合),它结合了软件开发和 IT 运维的最佳之处。就像我们讲的笑话一样,它需要一些说明。 

从本质上看,DevOps 是一种文化、一项运动,以及一个哲学理念。

这是开发团队和运维团队之间一次有力的握手,强调转变思维、更好地协作以及更紧密地集成。它将敏捷、持续交付、自动化等更多功能整合到一起,以帮助开发和运维团队更有效率、更快创新,以及为企业和客户提供更高的价值。

DevOps 的历史

DevOps 运动在 2007 到 2008 年间开始盛行,在当时,IT 运维和软件开发社区直言不讳地表述了他们所认为业界的致命性障碍。

它们与传统的软件开发模式相左,后者要求代码编写人员在组织和功能上与代码部署和支持人员分开。

开发人员和 IT/Ops 专业人士具有单独的(且通常具有竞争性的)目标、单独的部门领导、单独的对其进行评估的关键绩效指标,而且通常在单独的楼层,甚至是单独的建筑上工作。结果导致了只关注所在领域的孤立的团队、较长的工作时间、混乱的发布以及不愉快的客户。

“当然有更好的方法”,他们表示。因此,两个社区聚在一起,开始讨论 – 通过像 Patrick Dubois、Gene Kim 和 John Willis 这样的人促进对话。

在网络论坛和本地创客聚会上兴起的事物现已成为软件时代精神中的重大主题,这可能也是您来到此处的原因!您和您的团队正承受着企业内孤立团队和受损沟通线所带来的痛苦。

您虽然在使用敏捷方法进行规划和开发,但仍然竭力避开一系列戏剧性事件以发布代码。您已经听说过 DevOps 的一些事情及其对团队的看似魔法一般的影响,并且认为“我想获得一些这种魔力”。

坏消息是,DevOps 不是魔法,无法在一夜之间完成变革。好消息是,您不必等待上级管理层推出大型计划。通过了解 DevOps 的价值并持续做出细微的改变,您的团队即可马上开启 DevOps 之旅。我们来详细了解一下这些优势。

基础架构即代码能使我们执行比以往 10 倍有余的构建,而且无需我们为团队增添一个人。—Michael Knight,Atlassian 的构建工程师

这对您有何意义?

协作与信任

文化是 DevOps 中的第一成功要素。培养一种共同承担责任、具有透明度和更快进行反馈的文化是每个高绩效 DevOps 团队的基础。

在斯洛伊尔工作的团队往往不遵守 DevOps 的“系统思维”。“系统思维”是指意识到您的行为不仅会影响您的团队,还会影响到参与发布流程的所有其他团队。缺乏可见性和共同的目标意味着,未制定依赖性规划、优先顺序不一致、相互指责,以及产生“不是我们的问题”心态,从而导致速度减慢和质量不合格。DevOps 是全面查看开发流程和打破 Dev 与 Ops 之间的障碍的心态上的转变。

更快地发布和更明智地工作

速度决定一切。更频繁地进行 DevOps 发布实践的团队具有更高的品质和稳定性。

缺乏自动化测试和审查周期会妨碍向生产环境进行发布,而缓慢的突发事件响应速度则会大幅降低速度并让团队丧失信心。不同的工具和流程会增加 OPEX,导致上下文切换和减缓发展势头。借助自动化和标准化工具与流程,团队可以提高生产效率以及更频繁地进行发布,同时具有更少的问题。

缩短解决时间

反馈循环最快的团队最具发展力。完全透明和无缝沟通能使 DevOps 团队最大限度降低停机时间和以前所未有的速度解决问题。

If critical issues aren't resolved quickly, customer satisfaction tanks. Key issues slip through the cracks in the absence of open communication, resulting in increased tension and frustration among teams. Open communication helps Dev and Ops teams swarm on issues, fix incidents, and unblock the release pipeline faster.

更好地管理计划外工作

计划外工作是每个团队所面临的现实,一个最频繁地影响团队生产效率的现实。通过确定的流程和明确的优先级,Dev 和 Ops 团队可在继续关注计划内工作的同时更好地管理计划外工作。

跨不同的团队转移和优先处理计划外工作不但低效,而且会分散手里的工作。然而,通过更高的可见性和主动式回溯,团队可以更好地预测和共享计划外工作。

适用于 DevOps 的 CALMS 框架

文化

如果我们可以用一个词来总结 DevOps 文化,那么这个词是“协作”– 如果我们可以用两个词的话,那么它们就是“跨职能协作”。(好吧,这更像是三个词。)

如果没有考虑到开发和 IT/运维专业人员想要开展协作的真正愿望,那么世界上所有的工具和自动化都是无用的。原因在于,DevOps 并不能解决工具问题,它能够解决的是人为问题。因此,您不太可能在某天把头伸出隔间,然后发现您公司的团队形成了 DevOps 文化。但是,您可以做一些简单的事情来培养它。

想一想,DevOps 更像是敏捷产品,但却内含运维操作。形成以项目或产品为导向的团队来代替基于职能的团队,朝正确的方向迈出一步。包括开发、质量保证、产品管理、设计、操作、项目管理,以及该项目所需的其他任何技能组合。在 Atlassian,我们甚至将营销工作嵌入到产品团队中。

通过设立共同的目标、制定合作计划等,可以促进开展合作。在一些公司,突然转变为基于项目组建团队的情况太多,转变速度也太快。因此,步骤要更细致些。开发团队可以且应该邀请运维团队内适当的成员参加冲刺计划会议、每日脱口秀和冲刺演示。运维团队可以邀请主要开发人员。了解其他各方的项目、理念和努力是一种敏捷、有机的方式。通过使发布管理和紧急故障排除更加有效,花费在倾听和交叉传授主题领域知识上的时间便能得到回报。

对于紧急状况而言,这些方面能够有效地检测 DevOps 文化。开发人员、运维人员和客户是否支持以团队形式来应对和解决问题。是否每个人一开始都认为团队成员利用他们当时拥有的信息和资源制定了最佳决策?突发事件事后析误是否关于修复流程,而非相互指责?如果答案为“是”,那么这是一个表明您的团队以 DevOps 文化为核心的好迹象。

注意,最成功的企业在各部门,以及组织图的各个级别都具有 DevOps 文化。他们设有开放的沟通渠道并定期进行交谈。他们负责确保每个员工的目标保持一致并按需对其进行调整。他们认为,保持客户满意是同等重要的产品管理责任和开发团队责任。他们明白 DevOps 不是一个团队的工作,而是每一个人的工作。

自动化

投资于自动化可消除重复的手动工作、产生可重复的流程,以及创建可靠的系统。

对地尚未实现自动化的团队而言,通常应首先构建、测试、部署和配置自动化功能。另外:使开发人员、测试人员和运维人员达成协作而非构建系统以惠及每个人的更好的理由是什么?

对自动化不熟悉的团队通常会从持续交付开始:一种通过自动化测试手段运行每个代码更改的实践,通常由基于云的基础架构进行推动,随后可打包成功的构建并借助自动化部署将其提升到生产阶段。您可能会猜到,并不能快速、轻松地设置好持续交付,但投资回报令其非常值得。

为什么?计算机可比人类更严格、更如实地执行测试。这些测试可以更快地捕获错误和安全漏洞,从而使开发人员更轻松地修复它们。自动化部署可以提醒 IT/Ops 在环境之间进行“漂移”,从而在发布时降低或消除“意外”。

DevOps 的另一个主要贡献是“配置即代码”理念。开发人员努力创建模块化、可组合的应用程序,因为它们更加可靠且可维护。同样的想法还可以扩展到托管这些应用程序的基础架构,无论其位于云端还是公司自己网络上。

的确如此,系统总是在变化。但是,我们可以使用代码进行配置以创建不变性立面,因此,重新配置受感染的服务器比修复该服务器的速度更快,更不用说更可靠了。它也可以降低风险。开发和运维都可以通过配置代码并入新的语言或技术,并且彼此共享更新。兼容性问题会立刻显现出来,而不是在发布中间发生。

“配置即代码”和“持续交付”并非可在 DevOps 环境中看到的唯一一个自动化类型,但却值得特别提及的原因是,它们有助于打破开发和运维之间的壁垒。当 DevOps 使用自动化部署将经过彻底测试的代码发送到具有相同配置的环境中时,“在我的机器上工作!”便会变得无关紧要。

精益

在软件环境中听到“精益”时,我们通常会想到消除低价值的活动和快速迁移 – 变得朝气蓬勃,变得敏捷。即便与 DevOps 更相关的是持续改进和接受失败的理念。

持有 DevOps 理念的人认为持续改进的机会无处不在。有些机会显而易见,例如,定期回溯,以便可以改进您团队的流程。有些机会则不易察觉,例如 A/B 对您的产品的新用户测试不用的加载方法。

归功于持续改进成为主流思想,我们才实现了敏捷开发。敏捷方法的早期采用者已经证明,今天客户手中的简单产品比六个月后客户手中的完美产品更有价值。如果该产品得以持续改进,则客户会坚持使用下去。

猜猜看:失败是不可避免的。因此,您也可以组建自己的团队以应对失败、进行恢复和汲取经验教训(有人称之为“反脆弱性”)。在 Atlassian,我们认为如果您在一段时间内没有遭遇到一次失败,那么您没有付出足够的努力。

我们设立了宏伟、大胆、冒险的目标,以此来向我们的团队提出挑战。此外,我们还确保我们的团队拥有实现这些目标所需的自主权和资源。我们雇佣聪明又有雄心的人,并预期到他们有时也会失败。

在 DevOps 的背景下,失败不是应受到惩罚的过错。团队认为有些事情必然会在某些时候变得“一团糟”,因此他们建立了快速检测和迅速恢复。(阅读 Nexflix’s Chaos Monkey,了解这个出色的示例。)事后析误重点关乎流程出现故障的位置以及如何进行增强 – 而非哪个团队成员编写的该代码。为什么?因为持续改进和故障是息息相关的。

DevOps 已经实现了发展,使开发团队可以负责更多运维工作,这就是 Chef 的工作原理。我们不能再各管一摊了。我们的工程师负责 QA、编写和运行自己的测试以将软件交付给客户。— Julian Dunn,Chef 的产品经理

测量

我们很难证明您为持续改进而付出的努力实际上会改进除数据以外的一切。幸运的是,有大量用于衡量绩效的工具和技术,例如用户对您的产品花费了多少时间、那篇博文是否产生了任何销售,或者关键警报在您的日志中弹出的频率。

尽管您可以测量几乎任何内容,但这并不意味着您必须(或者应该)测量一切。借鉴敏捷开发,从基础知识开始:

  • 从开发到部署需要多长时间? 
  • 经常出现的错误和失败的发生频率如何?
  • 系统发生故障后多久才能恢复?
  • 目前有多少人在使用您的产品?
  • 您在本周获得/损失了多少用户?

有了坚实的基础,则更容易围绕功能使用、客户旅程和服务水平协议 (SLA) 获得更加精细的指标。您掌握的信息将在进行路线绘图和规划您的下一个大动作时派上用场。

所有这些丰富的数据都将帮助您的团队制定决策,但它在与其他团队共享时可发挥更强大的作用 – 特别是其他部门的团队。例如,您的营销团队想要获得可供销售的闪亮的新功能。然而与此同时,您认为该产品充斥着技术性债务,因此会产生较高的客户流失率。提供支持您制定路线图的用户数据 – 即使这种做法的功效平平,而且需要大量修正 - 使得更容易达成共识,以及从利益相关者处进行购买。

Devops 不是任何一个个人的工作,而是每个人的工作。— Christophe Capel,Jira Service Desk 的主要产品经理

分享

开发和运维团队之间长期存在摩擦的主要原因是缺乏共同的基础。我们认为,分担责任和共享成功对弥合分歧大有助益。开发人员可以通过帮助分担运维人员的重大责任之一:呼叫器立即赢得好感。DevOps 在很大程度上采用应用程序的构建者同样应该参与其交付和运行流程的理念。

这并不意味着您雇佣开发人员并简单地期望他们也能成为出色的运维人员。这意味着,开发人员和运维人员需在应用程序生命周期的各个阶段并肩工作。

采用 DevOps 的团队通常会发生旋转作用,使开发人员能解决最终用户遇到的问题,同时对生产问题进行故障排除。此人可在必要时创建补丁以响应客户报告的紧急问题,以及处理积压的客户报告的缺陷。“支持开发人员”了解有关如何在野外使用该应用程序的大量信息。开发团队对运维团队高度可用,因此两者可建立信任关系并彼此尊重。

携手苦力钻研拙劣的补丁能以更美好的心情来庆祝成功。当您看到开发团队在发布当天为运维团队带来了百吉饼时,您就知道您的公司已经具有 DevOps 文化。

同行的积极反馈能像薪酬和职业抱负那样激励我们。公开承认一位团队成员在上线之前检测到某个可恶的 bug 具有重大意义。如果您的部门具有用于员工奖赏的弹性预算,请勿放弃使用它!

准备开始您的 DevOps 之旅?

开启您的旅程