向DevOps环境过渡中特容易犯得四种错误

　　DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称，用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。本篇文章讲述了向DevOps环境过渡的容易犯的四种错误，大家快阅读吧~

　　分享：简介DevOps: Development和Operations的组合

　　可以把DevOps看作开发(软件工程)、技术运营和质量保障(QA)三者的交集。

　　传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法(例如敏捷软件开发)，这是一个重要的课题：按照从前的工作方式，开发和部署不需要IT支持或者QA深入的、跨部门的支持，而却需要极其紧密的多部门协作。然而DevOps考虑的还不止是软件部署。它是一套针对这几个部门间沟通与协作问题的流程和方法。

　　需要频繁交付的企业可能更需要对DevOps有一个大致的了解。 Flickr发展了自己的DevOps能力，使之能够支撑业务部门“每天 部署10次”的要求──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。这种能力也被称为持续部署，并且经常与 精益创业方法联系起来。 从2009年起，相关的 工作组、专业组织和 博客快速涌现。

　　DevOps的引入能对产品交付、 测试、功能 开发和 维护(包括──曾经罕见但如今已屡见不鲜的──“ 热补丁”)起到意义深远的影响。在缺乏DevOps能力的组织中， 开发与 运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望 基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。

　　以下几方面因素可能促使一个组织引入DevOps：

　　使用敏捷或其他软件开发过程与方法

　　业务 负责人要求加快产品交付的速率

　　虚拟化和 云计算 基础设施(可能来自内部或外部供应商)日益普遍

　　数据中心 自动化技术和 配置管理工具的普及

　　有一种观点认为，占主导地位的“传统”美国式管理风格(“ 斯隆模型 vs 丰田模型”)会导致“烟囱式 自动化”，从而造成 开发与 运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。

　　DevOps经常被描述为“ 开发团队与 运营团队之间更具 协作性、更高效的关系”。由于团队间 协作关系的改善，整个组织的 效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。

　　DevOps对应用程序发布的影响：

　　在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下：

　　与传统 开发方法那种大规模的、不频繁的发布(通常以“季度”或“年”为单位)相比，敏捷方法大大提升了发布频率(通常以“天”或“周”为单位)

　　减少变更范围与传统的 瀑布式开发模型相比，采用敏捷或 迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于 部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。加强发布协调靠强有力的发布协调人来弥合 开发与 运营之间的技能鸿沟和 沟通鸿沟;采用电子数据表、 电话会议、即时消息、企业门户(wiki、sharepoint)等 协作工具来确保所有相关人员理解变更的内容并全力合作。 自动化强大的 部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。

　　脆弱的项目管理技能，错过的时间线，敏感的员工——其中的任何一条都可能破坏你羽翼未丰的DevOps环境。

　　DevOps混合了任何由公司应用开发和系统运营团队一起执行的任务。这简单的定义掩盖了向DevOps环境过渡的复杂性。真的，CIO们向DevOps过渡所面临的潜在问题很多。这些地雷所在范围从技术(比如测试环境或架构的错误)到文化(比如高估速度而低估质量)，再到管理(没有获得执行官的支持)。

　　这里，我们的专家列出了在向DevOps环境过渡时易犯的四种常见错误，并指出如何避免它们：

　　错误1：被DevOps标题所迷惑：

　　当技术执行官建立他们DepOps能力时，常常是从雇佣DevOps工程师开始。这不一定是最佳方法。DevOps工程师通常会偏向于DevOps技能的某一个方面。也就是说，更倾向于运营或者偏好开发，Shalom Berkowitz说。他是技术人事公司Mondo负责技术招聘的初级团队领导。

　　首先评估你的DevOps环境需要什么技能，并在寻找候选人时特别提及。譬如，说明在Linux中的经验需要，或者Ruby的知识，或者Puppet的合格记录，而不是招聘泛泛的DevOps人才，并假设申请人有符合需求的经验。

　　错误2：忽略时间线：

　　无可否认，传统的瀑布式方法下工作更加封闭，更有秩序，James Stanger说，他是非营利性贸易协会CompTIA的高级产品主管。

　　相较而言，DevOps从本质来看就有让人混淆的可能，因为“每人都能影响到其他人的工作，”他说。

　　“引起的混乱会影响合理化开发，”Stanger说。也可能招致范围蔓延，因为每人都有可能在他们迭代时添加他们自己的好想法。

　　“他们会倾向于认为那不再是线性的，不再有时间线，我们只是一起工作，”他说。

　　经理需要在DevOps环境中坚持强烈的项目管理原则，忠诚于文档和截止日期以避免失控项目。

　　“发生变化的是实施时间表，不是对时间线的需要，”他补充道。“你在以更加循环的方式做事情，但是你仍然要朝着时间线前进。”

　　错误3：过快过多地向DevOps过渡：

　　Jay Lyman是451 Research 的DevOps&IT Ops开发部门的首席分析师，他说他和他的同事们已经看到，组织将DevOps原则应用到太多的项目和/或太复杂的项目上，直到DevOps团队有足够的经验和专业知识来管理这些项目。

　　Lyman建议企业从小的开始，先将DevOps应用到一些容易实现的目标----通常是新的方案或者新的应用----来建立起所需的技能和流程。

　　他补充说，许多组织通过寻求和借鉴他们的网络运营和移动团队的战略实现了早期的成功，因为这些领域的性质，它们已经快速迭代和使用了DevOps原则。

　　错误4：忘记反馈回路：

　　反馈回路驱动DevOps，但有时候关键利益相关者(例如数据库管理员和安全专家)被排除在外，导致一个有缺陷的最终产品，Lyman说。

　　“确保这个反馈循环中没有缺失链接，因为让这些利益相关者参与是你进步的方式，”他说。

　　同样，Stanger表示，组织需要帮助他们的DevOps人员了解反馈的重要性，并确保他们不会将其视为无端的批评。

　　“反馈不能被视为一个负面的事情，它必须被视为一个机会，以解决需要改进的事物，”他说。

小结：最后相信大家阅读完毕本篇文章后，学到了不少知识吧？其实大家在这方面私下还得多研究，如果大家想了解更多相关方面的详细内容的话，请登录课课家教育平台咨询~