DevOps 之 7 大习惯

发布于:2013 年 9 月 28 日 10:22

弗雷斯特研究公司(Forrester Research)分析师格伦·奥唐纳(Glenn O’Donnell)库尔特·比特纳(Kurt Bittner)发表了一份报告,该报告不仅介绍了开发人员与运维人员在隔离状态下工作时是如何看待彼此的,还给出了双方协作的七大习惯。下面是他们给出的“高效 DevOps 之七大习惯 ”:

  1. 促使双方互相交谈
  2. 对每件事都采用由外而内的方法去处理
  3. 使构建、测试及发布过程自动化,以便减少其中包含的人为错误
  4. 使开发和生产环境简化并标准化
  5. 向从开发到运维的全过程逐渐灌输系统工程文化
  6. 实现反馈和前馈 [1] 回路
  7. 把开发人员放在一线支持的岗位上

接下来就将个中细节一一道来:

促使双方互相交谈

对于了解彼此的日常挑战和困难而言,面对面的交谈是一种好方法。这方面的知识可以让开发人员与运维人员明白彼此行为的来龙去脉,从而帮助双方更好地理解对方。虽然这一点是相当显而易见的,但是如果没有把这一点作为先决条件的话,DevOps 根本就无法开展下去。

对每件事都采用由外而内的方法去处理

IT 运维人员很常见的做法是,先弄明白那些设备是可用的,然后努力把它们调整至最佳工作状态。而 DevOps 则需要一种不同的观点:开发人员与运维人员都必须首先理解业务客户的需求。然后基于这些需求,他们应该去定义哪些东西是满足需求所必需的。这种由外而内的方法会导致开发人员与运维人员安排其工作优先级的方式发生根本性的转变。

使构建、测试及发布过程自动化,以便减少其中包含的人为错误

很重要的一点是,让开发人员与运维人员一起工作,以便使交付过程自动化。譬如可伸缩性测试(scalabilitiy-testing)之类的事情是运维人员的专业领域,而测试各种业务功能却是开发人员的家常便饭。因此在测试自动化之上,他们应该使用现成工具去自动化基础架构。

使开发和生产环境简化并标准化

此处的重点在于,应该严格执行对于新系统的简化,而对于现有系统只能做尽可能多的简化。詹姆斯·加文诺(James Governor)近日主持了一次 DevOps 专家小组讨论,在讨论中他问道,为了能够引入 DevOps,是否有必要简化基础架构。

向从开发到运维的全过程逐渐灌输系统工程文化

将整体式的软件分解成若干更易于处理的模块——不管是自动化基础架构还是编写应用程序代码皆应如此。

实现反馈和前馈回路

为确保应用程序平稳运行,开发人员需要有关应用程序在生产环境下运行状况的反馈。而运维人员在此过程中则需要尽早获知所需的运行时环境信息。

把开发人员放在一线支持的岗位上

尽管支持任务会将开发人员从更具创造性的工作中带离,然而由他们去处理其代码在生产环境中引发的各种问题却是很重要的。因为他们不仅是快速修复故障的最佳人选,而且他们还能学到很多关于其应用程序在生产环境下运行状况的内容。

译注

[1] 前馈(feed-forward)控制,指通过观察情况、收集整理信息、掌握规律、预测趋势,正确预计未来可能出现的问题,提前采取措施,将可能发生的偏差消除在萌芽状态中,为避免在未来不同发展阶段可能出现的问题而事先采取的措施。更多详细内容参阅前馈前馈控制

查看英文原文: 7 DevOps Habits

阅读数:2549 发布于:2013 年 9 月 28 日 10:22

更多 DevOps、语言 & 开发 相关课程,可下载【 极客时间 】App 免费领取 >

评论

发布
暂无评论
  • DevOps、SRE 的共性:应用全栈思路打通开发和运维

    我讲述了DevOps和SRE的目标、原则和具体实践,并结合实战给出了通过“人、流程、工具”的步骤落地DevOps的方案。

    2019 年 9 月 9 日

  • 越来越重要的破坏性测试

    破坏性测试能够很好地测试分布式系统的健壮性,但也因为其破坏特点,使得它在持续交付中无法显示真正的威力,而混沌工程很好地解决了这个问题。

    2018 年 9 月 1 日

  • 答疑|没什么能阻挡你拓展边界的渴望

    今天我总共梳理了六个问题,前五个和SRE的落地及概念有关,最后一个关于个人成长,我们一起继续交流。

    2020 年 4 月 27 日

  • 对 Mob 编程的一些观点

    《Mob Programming Guidebook》一书的合著者Maaret Pyhäjärvi最近撰文介绍了她在Mob测试上的经历,以及Mob是如何使她的团队在转变为多功能团队的道路上取得进展。Woody Zuill近期也在Agile Uprising播客上探讨了Mob编程是如何以小规模、可发布的增量方式,为软件交付提供了一种有效的协作模型。

    2018 年 4 月 7 日

  • 让 DevOps 起作用

    从Neil Garnichaud在Dr. Dobb’s上发表的文章《究竟什么是DevOps》来看,想要频繁地发布高质量的软件,首先需要弄清如何使开发人员、QA人员和运营人员在一起协同工作。Neil分享了他对DevOps方面的看法,涉及的主题包括开发人员的需求意愿、准备状态、习惯、合作关系,以及领导层。

    2013 年 2 月 1 日

  • 需要 100% 的测试覆盖率吗?

    多少测试才算够用呢?答案因人而异。有人会告诉你要做到100%的测试覆盖率。另一些人却不这么想,他们认为这个问题的答案因测试代码质量的不同而不同,而衡量测试覆盖率并不能说明这些测试及被测试代码的质量。

    2007 年 5 月 31 日

  • 敏捷团队中测试人员的角色

    Karen Greaves和Sam Laing将会在Agile Testing Days 2015上发表主旨演讲,演讲题目为“测试人员正在消亡”。InfoQ将会覆盖本次会议报道。InfoQ对二人进行了采访,关于敏捷是如何影响测试人员角色的,为了缩短测试交付周期,测试人员可以采取哪些措施,敏捷团队中测试人员与团队其他成员之间的协作,敏捷团队中测试人员可以贡献的价值。

    2015 年 11 月 10 日

  • 发挥人的潜能:探索式测试

    通过今天这篇文章,我阐述了一个基本思想是:探索式测试是一种软件测试风格,而不是一种具体的软件测试技术。

    2018 年 10 月 5 日

  • “赶工状态”与明星平庸化

    James Golick和Reg Braithwaite 讨论了这样一个经常被置之高阁的事实,即陷入“赶工状态”的团队是如何导致不良结果的。讨论中提到了将压力施加于团队后产生的各种各样的情况,这些情况经常将项目推向更糟的境地;同时还讨论了团队和管理者如何使用不同的方法改变类似糟糕的处境。

    2008 年 3 月 2 日