<p style="text-align: center;"><img src="https://simg.open-open.com/show/91e8ac6cbea2e3ed090d53d199f37ce1.jpg"></p>    <p>有很多方式可以很好的推广和实行Devops，但是在一些公司具体实施Devops的过程中往往会遇到各种问题，各种坑。本文提出的DevOps七宗罪并不意味着在一个实行DevOps的团队如果出现类似的问题，整个公司都有倒闭的风险，而是提出这七宗罪来让我们的DevOps团队认识到问题并及时解决掉才是我写这篇文章的主要目的。</p>    <p><strong>1. 将DevOps作为一种头衔，而非理念</strong></p>    <p>用众多成功高管的话来说，“如果您在头衔中加入了‘DevOps’，那么情况已经出错了。”DevOps是一种理论，而非头衔。单纯引入相关职位完全无助于企业实现DevOps。</p>    <p>正如Bitilancer公司的Matt Juszczak所写道:设置DevOps工程师、DevOps系统管理员或者DevOps测试员等职位本身，就是对DevOps的一种根本性误解。这种误解导致大量项目与计划陷入失败，损害团队与企业，误导业务方向及招聘人员。</p>    <p>相反，DevOps应当作为一种实现方法，旨在让软件开发与转换更加简洁。事实上，DevOps定义要求运维与开发工程师共同参与整个服务周期，包括设计、开发流程到生产支持。</p>    <p><strong>2.未能受到员工及CIO的全面接纳</strong></p>    <p>DevOps成功的实质在于转变对软件及其业务重要性的认知。DevOps是一种根本性的企业运营方式转变，而非技术性变革。具体来讲，DevOps通常利用新型工具及实践转变技术与业务战略间的结合途径。</p>    <p>不过要让企业整体通过DevOps受益，来自高层的支持必不可少。这意味着我们需要一位熟知DevOps的CIO支持并引导相关努力。</p>    <p><strong>3.未着眼于量化指标</strong></p>    <p>Peter Drucker言道：“如果无法量化，则无法加以改进。”量化指标是DevOps生命周期中的第一步，亦应贯穿至每一步。如果不对版本号、平均修复时间或者故障率的变化加以衡量，我们将根本无法了解自己获得了哪些收益甚至不清楚自己到底在做些什么。</p>    <p>AppDynamics写道:正确的量化指标是确保DevOps转型成功的关键。然而，亦不可单纯受限于技术指标。除了平均修复时间（简称MTTR）或者平均无故障时间（简称MTBF）之外，大家还应重视流程与人员指标。每月或者每日活跃用户等都能够很好地帮助我们理解目前的实现效果。</p>    <p><strong>4.将DevOps视为一种军备竞赛</strong></p>    <p>不应将DevOps单纯视为由工具数量所决定。在DevOps世界，关于发布、配置管理、业务流程、监控、虚拟化以及容器化相关的工具层出不穷。虽然与时俱进并无不可，但我们仍应有针对性地关注其是否有能力真正实现自身改进目标。</p>    <p>真正的DevOps解决方案应该对开发者、运维人员及安全人员具备吸引力。正如一位工程师所写道，</p>    <p>如果日常生活会因新型“DevOps”工具而受到影响，那么尽早确保相关团队的接纳态度至关重要。否则，其它团队将很难接受这套解决方案，亦永远无法真正发挥其全部潜力。</p>    <p>DevOps的核心在于打破壁垒与障碍，保证员工能够更快完成工作。这意味着管理层需要全面投入，而非仅仅是购买更多工具。</p>    <p><strong>5. 无法接受失败</strong></p>    <p>即使企业已经开始正确实施自动化方案并获得管理层支持，但亦有不必DevOps团队无法接收失败的结果。举例来说，Netflix公司就会主动诱发失败状况，从而保证自身为服务器宕机或者代码出错做好准备。</p>    <p>从理论层面上，管理层需要意识到失败是构建及发布代码的实践活动中的必然因素。出现失败之后，我们应当以建设性方式总结经验并发现问题，而非一味相互指责。在理想情况下，一套失败的发布版本应当：</p>    <p>“立足错误进行新一轮测试，保证其未来不会再次出现。只有做到这一点，企业才算是真正接纳了DevOps的核心理论。”</p>    <p><strong>6.仍然强行区分开发与运维</strong></p>    <p>行之有效的DevOps“强调整体系统表现，而非特定工作或者部门的孤立表现。”</p>    <p>正如很多相关文章所提到，开发者不可能闭门编写代码并指望其可按照预期顺利运行。相反，开发者与运维者应当协同配合。</p>    <p>这通常意味着开发与运维双方应当随时沟通。如果开发者需要为其代码造成的问题负责，那么他们显然会更为严肃地进行代码编写与测试。同样的，如果运维人员感受到了开发者面临的压力，他们也会保持与之相符的工作态度。</p>    <p><strong>7.未使用关键性警报工具</strong></p>    <p>如果未能切实利用关键性警报工具向工程师们通报严重事故，那么DevOps体系必将遭遇更多其它问题。如果未能在DevOps团队的核心理念当中融入关键性警报工具这一元素，那么：</p>    <ul>     <li>该团队的量化指标关注能力将大打折扣。举例来说，如果我们根本不知道某一事故何时发生，那么如何才能降低平均修复时间？</li>     <li>有效取证将更加困难。关键性警报工具允许各团队查看警告信息中交付的相关错误描述。</li>     <li>开发与运维间的隔阂将继续存在。通过为两支团队同时分配“值班”任务，双方都能够随时查看到警报内容。在对警报拥有明确认知之后，他们将更加有效地进行换位思考。</li>    </ul>    <p>关键性警报工具对于削减停机时间、维持客户满意度以及快速解决问题方面至关重要。事实上，忽略这些要点并继续使用那些根本无法切实达成警报目的的工具，应当被称为一种渎职行为。</p>    <p><strong>总结</strong></p>    <p>看完本篇文章，也许很多朋友感受被戳到了痛处。不过别太担心，存在DevOps的这“七宗罪”绝不代表企业已经无可救药。相反，意识到错误的存在正是加以解决的重要起点。另外，这里建议大家不要一味贪多求快。一次解决一宗罪往往是更安全也更为有效的处理办法。</p>    <p> </p>    <p>来自：http://developer.51cto.com/art/201611/522322.htm</p>    <p> </p>