如果你对IT管理感兴趣,尤其是对Web运维感兴趣,那么最近一定会注意到“DevOps”这一热词的出现。现在#DevOps标签频繁出现在微博客Twitter上,同时DevOps相关的技术交流聚会也在慢慢增多。 DevOps在很大程度上是一个集合性概念,指的是能够理顺开发和运维之间相互配合关系的任何事物。但是DevOps背后的理念要比上述说法更深远。 什么是DevOps? 人们越来越意识到传统意义上的开发行为和运维行为存在脱节现象,从而导致冲突和低效,因此DevOps应运而生。 正如李·汤普森(Lee Thompson)和安德鲁·谢福尔(Andrew Shafer)所言,在开发和运维之间存在一面“混乱之墙”。相互冲突的动机、流程和工具导致了这面“墙”的存在。
而运维人员则往往视变化为敌人。企业依靠他们维持正常业务运维和实施让企业赚钱的服务。由于变化会影响稳定性和可靠性,运维业务有理由对它说不。我们已经多次听到过如下统计数字:在所有宕机事件中有80%情况是源于自杀式的改变。 开发人员和运维人员认识世界的方法,以及各自所处的角色,存在根本性的差别。他们都认为自己的做法是正确的。的确,孤立的来看他们都是正确的。 更糟糕的是,开发和运维团队通常处于公司组织架构的不同部分,通常具有不同管理者的和竞争关系,而且通常工作在不同的地点。
运维人员然后开始进行他们自认为正确的部署过程。由于开发和运维之间的脚本、配置、过程和环境存在差别,这一部署过程实际上也是首次被执行。当然,期间如果发生一个问题,开发人员会被要求来帮助进行排障。运维人员会说开发团队给的产品存在问题。而开发人员则会回应称该产品在他们的环境下运行良好,因此一定是运维人员在部署的过程中做错了什么。由于配置、文件存储位置和过程的不同,开发人员诊断问题也并非一件易事。 没有一个可靠的方式来把环境回滚到此前已知的正常状态。本来应该一帆风顺的部署过程最后变成一场救火行动,经过反复测试之后才让生产环境恢复到正常状态。
DevOps所带来的好处 DevOps是一个非常强大的概念,因为它可以在众多不同层面上产生共鸣。 从开发或运维的一线人员的观点来看,DevOps可以让他们从众多烦恼中解脱出来。它虽然不是具有魔力的万灵药,但是如果你能够让DevOps奏效,则会节省大量时间,而且不至于打击自己的士气。显而易见,投入精力将DevOps落到实处,我们应该会更加高效、更加敏捷和减少挫败感。有些人可能会反驳称DevOps是一个遥不可及的目标,但这并非说我们不应该去尝试实现它。
IT融合的一个简单定义是,“企业渴望达到的一个状态,能够高效的使用信息技术来达到企业目标——通常是提高公司业绩或市场竞争力。” 通过从共同企业目标角度出发来校准开发和运维的职责和流程,DevOps有助于实现IT融合。开发和运维人员需要明白,它们仅仅是一个统一业务流程中的一部分。DevOps思想确保个体决策和行为应力求支持和改进这个统一的业务流程,无论你是来自哪一个组织架构。
当然对于开发人员来说,“敏捷”有专门的含义,但目标是非常类似的。敏捷开发方法旨在保持软件开发工作与客户/公司的目标同步,尽管需求不断变化,也可以产生高品质软件。对于多数机构来说,迭代项目管理方法Scrum是敏捷的代名词。
但是,当你从企业角度回顾一下整个开发-运维周期,敏捷方法的相关优势通常会变得非常模糊。混乱之墙导致了应用程序生命周期的分裂。开发和运维分别按照不同的节奏进行。实际上,产品部署之间的长期间隔使得一个团体的敏捷工作变成了它一直试图避免的瀑布生命周期。当存在混乱之墙时,无论开发团体有多么敏捷,改变企业缓慢和迟钝的特点是极其困难的。
如果你希望在自己的组织内建立一个DevOps项目,务必牢记“IT融合” 和“业务敏捷性”。 如何将DevOps落到实处? 和多数新出现的话题一样,发现问题的共性特点要比找到解决方案容易的多。 要想实现DevOps相关解决方案,以下三方面需要关注: 1、评价和鼓励改变文化 改变文化和激励系统从来不是一件易事。但是,如果你不改变企业文化,兑现DevOps的承诺将非常困难。考察一个企业的主导文化时,你需要紧密关注如何评价和判断企业业绩。评价的内容将影响和刺激行为的发生。开发-运维生命周期中的所有当事方需要明白,在更大的企业流程中自己只是其中一部分。个体和团队的成功都要放在整个开发-运维生命周期内来进行评价。对于许多机构来说,这是一个转变,不再是孤立的来进行业绩评价,每一个团队不再是基于自己的团队来评价和判断业绩好坏。 2、统一标准化的流程 这是DevOps的一个重要主题,整个开发-运维生命周期必须被看作一个端对端过流程。流程的不同阶段可以采取不同的方法,只要这些流程可以被组合到一起创建一个统一的流程。与评价和激励的问题相似的是,实现这个统一的流程时每个组织可能会有略微不同的需求。 3、统一的工具 这是大多数DevOps讨论一直在关注的领域。这一点不令人吃惊,因为当技术专家在考虑解决一个问题时,第一反应往往就是直接跳转到工具讨论上。如果你关注Puppet、Chef或ControlTier等工具社区,那么你可能已经意识到人们对在开发和运维工具之间建立桥梁的重大关注。“基础设施即代码(Infrastructure as code)”、“模型驱动自动化(model driven automation)”和“持续性部署(continuous deployment)”都是可以划归DevOps旗下的概念。 关于把DevOps变为现实需要哪些类型的工具,杰克·索罗夫曼(Jake Sorofman)提出如下建议: 一个版本控制软件库 它可以确保所有系统产品在整个版本发布生命周期中被很好的定义,且能够实现一致性共享,同时保持最新信息。开发和QA机构能够从中取得相同平台版本,生产机构部署已经被QA机构验证过的相同版本。 深层模型系统 它的版本系统清晰的描述了软件系统相关的所有组件、策略和依赖性,从而可以简单的根据需要复制一个系统或在无冲突的情况下引入变化。 人工任务的自动化 在依赖关系发现、系统构造、配置、更新和回滚等过程中,减少人工干涉。自动操作变为高速、无冲突和大规模系统管理的命令和控制基础。 在从开发到运维的生命周期中存在许多不同的工具。工具选择和执行决策需要根据它们对端到端生命周期的影响来决定。 关于DevOps的澄清 现在某些系统管理员正在试图把自己的岗位名称改为“DevOps”。但是,DevOps不应该是一个单一的位置或职称。把DevOps变成一个新职位名称或特定角色是一件非常危险的事情。例如这会导致以下错误端点:你是一个DBA?或者是一个安全专家?那么不用担心DevOps,因为那是DevOps团队的问题。 设想一下,你不会说“我需要招聘一个Agile”或“我需要招聘一个Scrum”或“我需要招聘一个ITIL”,而只是会说需要招聘了解这些概念或方法的开发人员、项目经理、测试人员或系统管理员。DevOps也是同样道理。 与DevOps具有相同理念的术语很多,例如敏捷运维(Agile Operations)、敏捷基础设施(Agile Infrastructure)和Dev2Ops。还有很多人虽然没有提及“DevOps”,但却在遵循着类似的理念。 |
|