如何与 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 官方博客