如何与 DevOps 为伍？

DevOps 是一个席卷 IT 界的新术语。但它究竟是什么，南非的公司们如何利用它来加快高品质应用程序的开发速度？国外知名博客作者凯西·吉布森找到了一些答案。

其实 DevOps 这个词已经火了一段时间了，我们知道它是很多新时代数字化企业的成功秘诀。但是，在南非公司收获由 DevOps 带来的全部好处之前，重要的是理解它的涵义，以及如何最大限度地利用它的优势。

维基百科对 DevOps 的定义为：「一种强调软件开发人员和其他IT专业人士之间沟通，协作（信息共享和对 Web 服务的使用），集成化，自动化和合作测量的软件开发方法。」「该方法认可软件开发，质量保证（QA）和 IT 运营之间的相互依存关系，旨在帮助企业快速生产软件产品和服务，改善经营业绩。」这听起来很像敏捷之类的现有开发方法，但根本的不同之处在于： DevOps 积极推进一系列流程和方法，致力于开发、质量保证和 IT 运营之间的跨部门沟通与协作。

DevOps 的一个主要目标是快速应用部署，从而缩短产品上市时间，降低新版本的故障率，缩短崩溃事件的修复时间和平均恢复时间。DevOps 的目标是通过自动化方式方法，最大限度地提高运营流程的可预测性，效率，安全性和可维护性。Chef 的 EMEA 副总裁兼首席企业架构师的贾斯汀·阿巴克尔，解释说，DevOps是与业务的整体转型密切相关的。

「通过思考企业运作的方式，我们才知道要完成什么任务，」他说。 「事实证明，DevOps 的核心原则是让公司全员了解新的变化和战略。」让IT人员了解到，如何看待业务的变革正在进行大有裨益。 「实际上，这不只是关于 DevOps，或西海岸的想法或基于 Web 的企业，」阿巴克尔说。 「所有的业务正在开始改变。」「但往往当你从大网站跳槽到大企业时，会有某个核心因素使人们不希望发生改变。或者，他们忙于应对为期八周的项目然后永远不再改进。」「但你可以做到这一点，并且你必须这样做。除非你的运营模式使用 DevOps 方法，否则，你将使公司变得不稳定。如果你认为公司现在中规中矩且安全可靠，这是一种错觉。」阿巴克尔说，在已经转变的企业中，新产品能根据一系列需求快速迭代。「他们不试图预测未知的未来。快速迭代的能力帮助它降低风险。你们应该有能力进行最佳预测，创造一个最小可行产品，并以此为基础快速迭代。」

速度是来自大型 Web 的新的必备条件，阿巴克尔补充道。 「如果你想在更高的速度下操作，就会犯错误。但动作更快意味着更快地修复，比起贯穿整个公司的操作流程你更需要这种能力。「让速度做你的向导。」这一切都增加了公司的可靠性，使其越发牢固，阿巴克尔解释到。并且，速度是必要的：「如果你不能快速响应，那就等于自说自话。」

在南非，一组 IT 开发者和学者成立了一个 DevOps 工作组，致力于探索 DevOps 的规则，并促进其在当地环境中的使用。

亚当·雅各布，Chef 首席技术官，在该工作组的成立大会上讲话，谈到 DevOps 是怎样出现的，并提供了一些使它奏效的忠告。「DevOps 是由从事相关工作的人建立的，对每一个人来说都是不同的，”他说。 「它来自一段历时15 年的深网运作经历，这段经历最终演变为一种工作方式。」他解释说，负责运营大型网站的人逐渐认识到了他们之前学到的 IT 学科知识在新的环境中一无所用。」「随着时间的推移，我们意识到，必须建立更强的信任关系，提高自动化程度、更加自力更生。当你遇到问题时，厂商都很乐意卖给你解决方案 —— 对于你的问题，他们总会有答案。但他们并不真正了解你的问题，所以你真得靠自己。」IT 公司面临的挑战如此难以界定，提出 DevOps 的定义或方法几乎是不可能的，雅各布补充道。「虽然有一些共同的主题和行为，但不同的定义却不计其数，」他说。 「DevOps 不是作为一个理论概念存在，而是作为一种生活体验而存在。」

但是,通常，在成功运用 DevOps的人眼中，的确存在一些共同的宏观趋势。

Chef 提出 DevOps 有点像功夫或者说武术。「尽管有数百种不同的武术流派，但他们都可以被认定为武术，」他解释说。 「显然，他们并不都是一样的，它们共享三个基本理念。」
这三个共同的基本要素是基础，形式和应用。「这三样东西是共享的。教基础的方法是相同的，形式也是相同的，而且在现实中应用它们的方法也是相似的，但因不同个体而异。这就是你所知道的练武术的方式。」

「你可以用同样的方式来类比 DevOps。」雅各布解释道，DevOps 更多是关于重新打造经营业务的方式，而不是软件开发的流程。「不管你喜不喜欢这是我们现在正在做的——事实上我们都在实践 DevOps。现在需要的是集齐所有的专家并让他们相互协作，使人们组成团队，完成他们无法独自完成的事。」

根本上来说，DevOps 是一种专注于如何建立和运营高效率公司的文化和行业运动，诞生自从业者的经验，雅各布说。他提醒道，同样的规则用于低效率的公司将导致不稳定。「值得记住的是，该运动来自网络的创新者们。当你将它应用到自己的环境中时，需要从中获取对你有效的部分。DevOps的从业者都相信——并且践行——一系列准则，雅各布补充说，不采用这些准则的人就没有拥抱 DevOps」

这些规则如下，他说：

• 以安全，满意，知识和自由为设计目标。

• 做 DevOps 服务于人和公司的所有产品。「这始终是一个事实，人们喜欢做这样的工作，因为这是一个建立更好的产品的好机会。快乐的人创造快乐的的产品就等于快乐的企业…」

• DevOps 的人精干。「他们消除非增值的行动; 帮助推动; 旨在持续改进，颠覆性的变化，批量和试验。」

• DevOps 的人会和失败建立关系。「这是正常的现状，不是一个要避免的事情; 会感到恐慌意味着你没有试图解决这个问题。」

• 无处不在的工作流程自动化。「一旦我们想要工作，应该建立工作流程并默认其自动化。」

• 多元化。「DevOps 是多元的，一个高机能的团队也必须是多元的——越是如此越能做到更好; 需要多种多样的技能。」

DevOps的形式——关注人们实际做了什么——要求团队专注于一个比手头任务更大的目标，雅各布说。 「因此一个工作也许不在于修好网站，而是在于改变这个国家。」DevOps 的形式是这样的，他解释说：

• 相信。「你相信什么东西会在你的领域创造良好的成果？使用主动语态来讲，以好的结果为目的，公开包括 DevOps 规则在内的理念，并将其融入对你的行业或遇到的问题有特殊意义的事情中。」

• 建立一个高度授权的团队。「他们必须有权限采取行动，在适宜的情况下做出正确的决定;与关心组织的宗旨并能够分享利益的领袖为伍。」

• 形式多样的关系。「认识专业领域以外的人;了解他们做什么，了解他们遇到的的问题和拥有的观点。他们可以是来自法律，财务或销售领域。」

• 借此在重要决定上达成共识。「循环性的计划，包含批评和反馈。这将有助于解决问题。」

• 有较强的价值主张。「人们是买止痛药而不是维生素，重点要放在人们需要而非想要的事情上。能区分是一个客户想要一个功能还是许多客户需要一个功能。」

• 建立一个路线图。「包括愿景和反馈。平衡创新与需求，将它们组合成主题，提炼那些为功能，并向客户确认他们。需要坚持这个主题，结果也许会保持原样，但功能将会发生变化。」

• 总要有兴奋因素。「包括那些用户用了并感到愉快的功能。」

• 建立功能迭代。「不是试图逐渐描绘出蒙娜丽莎，因为在开始之前你就得知道它是什么样。而是从一个草图开始，加点颜色，然后完成它。」

• 管理风险。「通过阶段性假设进行小批量工作。请记住，必须且只能通过客户进行效果验证。引入短期收益减少长期风险——这让短期路线图不够清楚，但减少了一些在长期的风险。」

• 不要担心规模。「非必要的时候不必担心它——而且这通常会比你想的更晚。」

• 执行。「人们会想出新的理论，你需要通过执行挑战它们。执行总是胜过理论。」

• 证明每星期持续进行。「并且邀请大家给出反馈。」

• 选择适合这份工作的语言和工具。“我们都是通晓多门语言的人; 新的语言和工具是这个行业的巨大优势之一。迭代开发和小批量生产会有利于规避风险。」

• 有一个 bug 数据库。「给错误分类和排优先级。」

• 持续集成。「永远在短期迭代分支中合并分支到 master。测试是好的，但持续集成更好，当它出现问题可以及时进行修复。”

• 遵守四眼原则。除非至少有两个人都发现了问题，不要改变什么。必须有另外的人时时检查你的工作。

• 编写测试。「但一次只写一个测试，这很有必要。」

• 持续交付。「你应该摒弃只要你想就能做到的想法。」

• 一个变化的路径。「在组织中发生变化的方式固定的。如果有一个一致的模式会使加强规则和辅助流程变得简单。它可以帮助人们互相帮助，这在执行的层面是灵活的。」

• 代码经过相同的工作流，不用考虑它是用于应用程序或基础结构。

• 专注于可用性。「这其中包括正常运行时间，缩短平均诊断时间和平均修复时间。失败是不可避免的，不同的是你如何面对它。」

• 收集 metrics。「可以从操作系统，网络，应用程序或进程收集。

• 能力计划。「你本应在那但可能并没有。确定关键 metrics，把它们放在一个图中，设定一个上限，绘制趋势线; 并且在需要的时候扩展时间跨度。”

• 只对可行动的人告警。「让正确的人去关注问题——但数量越少越好; 只通知可以采取行动解决问题的人。」

• 练习事件响应。「这可能最重要的步骤。第一个响应者是事件指挥者，他们决定做什么，统筹资源和通信状态。这不是排等级，但只能有一个事件指挥者。”

• 事件剖析。「学习不责难的去描述的事件，建立时间表，确定影响因素，描述对客户的影响，描述整治任务，并说明任务可以如何改善响应流程。”

• 使用可扩展系统设计。「自发因素为自己负责，实现目标的过程中要有对其他能对其进行评估质量的因素的明确保证。」

• 为简易性，可扩展性和再利用而设计。

一旦被谈论起来，关于 DevOps 声音往往是复杂的，有时甚至是矛盾的，但是雅各布说，坚持技术是安全的。 “记住一个原则，用您的识别能力实践这种形式，”他建议道。

「在现实世界中，DevOps 是在描述一个涉及整个组织中的利益相关因素，并连续八周进行尝试的问题。你能够负担得起投资这八个星期。」

为了验证这个规则，雅各布建议企业选择一个足够小的垂直问题，就在这八个星期进行一次有意义的迭代。「在第二阶段，设置了你的目的，信念和团队。写下的目的和信念，授权团队，并做好准备。下一步骤是做产品开发。 写下的价值主张；建立关于主题，成果和特点的路线图；包括一些兴奋因素，并确保功能简单，拥有可扩展和再利用的特性。」

接下来就是功能迭代。 「通过小批量风险管理，选择语言并进行工作，同时忽略规模，」雅各布说。 「提出理论时，把重点放在执行性上。每周向整个公司展示进度。使用源代码控制。有一个 bug 数据库。使用一个变化事件流。让其他人监视一切。记得做持续集成并且每次都测试。使用可扩展的系统设计。操作时，专注于可用性，收集 Metrics，规划能力，对可行动的事件进行告警，坚持事件响应和事件剖析。」交付时需要坚持最终演示并保持可追溯。

「对 DevOps 而言最重要的是，找到属于自己的方法，」雅各布说。

原文作者 Kathy Gibson，本文由 OneAPM 工程师编译整理。

Cloud Insight 集监控、管理、计算、协作、可视化于一身，帮助所有 IT 公司，减少在系统监控上的人力和时间成本投入，让运维工作更加高效、简单。本文由 OneAPM 工程师翻译整理，想阅读更多技术文章，请访问 OneAPM 官方技术博客。

本文转自 OneAPM 官方博客