有很多方式可以很好的推广和实行Devops，但是在一些公司具体实施Devops的过程中往往会遇到各种问题，各种坑。本文提出DevOps的七宗罪并不意味着在一个实行DevOps的团队如果出现类似的问题，整个公司都有倒闭的风险，而是提出这七宗罪来让我们的DevOps团队认识到问题并及时解决掉才是我写这篇文章的主要目的。

1. 将DevOps作为一个吹牛逼的职位头衔来对待，而不是视之为一种方法与理念

有许多公司中高级一些的运维人员，特别是偏开发方向的运维人员往往给自己头上冠以DevOps的头衔，显得自己很高大上，加上国内技术圈子目前的风气很不好，各种浮夸风盛行，一些大公司的技术主管都靠着几篇PPT整天混基于各种峰会、各种圈子在给自己镀金。

比如国内有个叫高效运维的微信号去国外参加了一个野鸡大会，回国竟然开始进行DevOps资格与证书的的各种培训与考试，也真是让人贻笑大方了。

DevOps是一种方法与理念，将某个人冠以Devops的头衔本身就是一种错误，这种做法反映了对DevOps的根本误解，过于侧重于职业倾向会给公司和团队造成浮夸与盲目。

简单来讲，DevOps是一种方式与方法，是开发、运维工程师从架构、设计、开发、测试到生产的完整的产品生命周期的具体实践过程。

2. 没有取得高层决策者的支持与理解，DevOps很难开花结果

DevOps的成功最终在于它可以转变企业对软件开发的思考方式及其对商业成功的推动作用。

DevOps从根本上是一个业务、流程上的变化，而不是纯粹的技术上的变革。虽然DevOps通常与新的工具和实践相关联，但真正的变化是使开发与运维工作同业务推广与公司发展战略保持一致的新的工作方式。

公司的技术团队可以通过一个具体项目来体会与实现DevOps的理念，而整个公司则会从DevOps的具体推行与实践中获得回报，所以DevOps的落地需要有公司高层自上而下的支持。这意味着为了获得成功，公司的CTO/CIO级别的高管需要首先认可DevOps的理念，并且富有激情的将DevOps理念实施下去。

3.不关注指标

“如果你不能测量它，你就不能改进它。”，监测DevOps生命周期的每一步都很重要，正确的指标对于确保DevOps成功实施至关重要。

除了技术指标。 诸如平均时间分辨率（MTTR）或平均故障时间（MTBF）之类的指标，还应关注流程和人员的指标，例如每月或每日活跃用户，衡量开发、测试到、部署的具体时间也是衡量您当前有效性时需要考虑的重要指标等等。

4.把DevOps看成是对各种新工具、新技术的追逐

就像DevOps不能被看作是一个职务一样，DevOps也不能简单地被认为是一个工具的堆砌。在DevOps世界里，有发布的工具（Jenkins，Travis，TeamCity），配置管理（Puppet，Chef，Ansible，CFengine），编排（Zookeeper，Noah，Mesos），监控，虚拟化和容器化OpenStack，Vagrant，Docker）等等。
DevOps工程师因为对新工具的热爱而闻名，但在某些时候，工程师更需要专注于目标的实现，而不是紧跟时髦。
至少，一个新的DevOps工具应该与现有架构和流程互相适应，即便是不能大幅提高生产力，也不应该对现有产品造成伤害。

如果原有日常的工作状态将受到新的“DevOps”工具的影响，那么受影响的团队如何克服和融合新的DevOps工具则非常重要，否则很难让其他团队也采用该工具，没人使用的话这个工具也就不会实现其全部的价值与潜力。

DevOps旨在打破孤岛和障碍，使员工能够更快地完成工作。这意味着新工具，而不仅仅是购买更多的工具。

5.认为失败是不能接受的

公司或多或少都在使用一些自动化工具管理现有的产品与业务，但DevOps团队、工具、流程等等也会犯错。 例如，LB进行故障检查，会有自动踢掉的节点与恢复后的自动加入的情况，有时可能因为服务的某些”假象”导致某些功能不完善的新节点被加了进来，影响了正常的服务。

DevOps是一个循序渐进的过程，谁都无法保证不犯错误，关键是监控到有问题的步骤或者流程后需要能够捕及时捉到，并进行修正与改进，防止下次在粗线类似的问题才是DevOps重要的哲学理念。

6.将Devs和Ops割裂开来

有效的DevOps强调的是整个系统的性能，而不是特定的任务或部门的性能。

正如在描述DevOps问题的许多文章中所写的，Dev和Ops不能坐在不相互对话的孤岛中。开发人员无法创建代码，并在完成后将其放在代码库上，那么Ops将如何部署它？所以Devs和Ops是作为一个团队协同工作的。

7.没有良好的预警机制与工具

Ops们都会有这样的体会，有时候一个故障可能导致很多的连锁反映，各类报警铺天盖地，如何从纷杂的报警中找出真正的报警原因（root-cause）并且迅速解决才是Devops要做到的。

更好的做法是过滤掉没用的报警，根据问题的严重性逐级发送报警信息，什么样的报警需要发给dev，什么样的报警可以忽略，什么样的报警需要通知客户等等。

DevOps实际运行中，如何提高客户满意度并快速解决问题、减少停服务的时间是最重要的，如果您的DevOps工具不能有效地发现、汇总和发出警告的话是有严重的缺陷的，需要完善相应的预警工具。

结论

本文提出DevOps的七宗罪，列举出目前DevOps实施中可能遇到的问题，帮助相关企业和团队能够认识DevOps的真正思想，逐步解决现有的问题，将DevOps进行下去！

本文固定链接: https://sudops.com/devops-7-deadly-sins.html | 运维速度