从DO分离走向DO合作

Dev和Ops在业务快速变化的今天必须从分离走向合作，然后在很多公司里面，还存在很多阻碍因素，这些因素在越小的公司越普遍存在。

一般情况下的公司发展，一定先有研发后有运维，后来随着业务的发展，研发逐渐觉得需要运维了，哪种场景下需要？服务器要有人上架（IAAS云不用了），应用要有人部署，故障要有人处理，值班需要有人做，反正就是一些严重影响研发工作能力聚焦的事情，这也无可厚非。

随着业务规模不断的扩大，运维的确也承担了之前说的那些事情，可是这个时候运维的职责好像就被研发限定在这些范围之内似的，无法突破，有研发的因素，也有自己的因素。而在此时，如果研发只顾业务上的需求而忽略运维的需求，运维更是会陷入琐事之中，突破更是很难。这个时候运维也会形成一个心理，你们这帮研发写的程序也够烂的，于是分离和对立的情绪越来越重。我对其也做了思考和作结，其实这些都是问题的背后，是有几种思维模式在影响着我们的行为。

• 炫技思维

这种思维普遍存在，特别是在研发身上，运维也有。见过很多研发，整天在谈论自己使用的技术多么牛b，搞的平台多么强大，特别是在一些中小公司这种情况普遍存在。其实很多时候都没有仔细思考他的技术给业务和公司带来的价值，更别说考虑运维的诉求了。见过一个团队，从头开发自己的分布式文件系统，业务都没上线，很失败。当运维和他说，业界有什么方案的时候，研发举一堆例子给你否决掉，就要自己干。选择一个方案可以有千万个理由，不选择一个方案，只需要一个理由－不合适。其实最怕有的时候，研发做好了跑过来，直接和运维说，我们服务要上线了，更别说运维参与前期的需求评审了，运维非常被动。炫技思维，说到底是完全的技术导向思维，不知道在业务／技术甚至是运维之间思考平衡。

• 自嗨思维

这种思维是自己很high，没想过周边团队的感受，这种思维很任性，任性到只顾自己。它和炫技的技术情节不一样，它完全是一种情感上的自我陶醉和满足。这种自high的情绪来源于自己的产品非常牛b，逻辑之下就是自己也很牛b;来源于我做的东西你不懂，利用信息不对称取得心理优势的大有人在；来源于对彼此认识不够，对方是可以不被需要的。见过很多核心业务的研发，和运维的沟通非常强势，搞得好像核心业务要运维VIP伺候似的。另外说对方不懂的人从来就没有想过，你有责任让对方懂，就有运维说研发不懂网络/lvs/dns等等。彼此认识不彻底，对方也就很难被真正的认可。自嗨思维，说到底是一种孤芳自赏的心态在作祟，我自己玩就够了。

• 责任隔离思维

责任隔离文化，在业务故障的场景下经常出现。当一个故障产生的时候，此时第一个念头，这个故障是谁导致的，哪个团队导致的。有时候，甚至是这个故障两个团队都有不足的时候，还看谁的责任更大，这些都是非常糟糕和不负责任的表现。责任隔离不管在互联网还是在传统企业都存在，不过它在传统企业更甚，是他们的典型思维模式。责任隔离影响的事后续的持续合作，而造成组织效能下降。造成这种现象的背后原因是企业的KPI设置的问题，不以业务导向，而以做多做少和是否正确为考核维度。

我个人倒是建议，在制定KPI的时候，记得多出现正面的字眼和面向业务的KPI，不要出现负面的词语。举个例子，“季度因人为失误不能低于＊＊例”，这种KPI不要出现在考核中，它带来的就是每次问题发生的时候，一定想着这问题不是我导致的。如果设定成直接面向业务的可用性考核，比如说业务可用性达到99%，此时可以规避这个问题。

• 流程思维

这种思维的起源其实是ITIL，因很多公司把运维的最佳实践参照了ITIL来实现。在企业内部搞了大量的IT服务流程规范，通过流程来梳理职责之间的关系，但是留下的问题就是把团队之间合作氛围给破坏。其次当流程形成之后，你如果想再去修改流程将是非常困难的一件事情。从IT服务提供者的角度来说，一定不要让被服务者感受到流程的负担，轻量，再轻量些。流程复杂是因为你组织复杂，搞了很多没用的人。我更是反对一些事务性流程让领导来审核，内在的心理想法是想如果出问题了，领导也可以扛一下。

在传统企业里面，长久养成的流程习惯，就想用流程来解决，而不是技术来解决，也不用用户的要求来检验自己。有家公司，说一个新产品上线，审核流程都要走3个月，这是作死的节奏。

• 另起炉灶思维

这种思维是最需要猛烈抨击的，这背后有两种因素，一种是研发不信任另外一个团队做的产品，另外一个就是更大团队范围内部技术方案和平台不透明，导致团队不知道有这个产品存在。个人观察，第一种情况要更普遍一些。不管哪种情况，很大部分都有运维的责任，这部分的信息都会流向运维，此时运维应该快速识别到这个问题，去驱动大家达成一致（所以需要运维参与需求评审）。在某种程度上来说，公共组件研发团队应该放在运维部门，这样对研发的公共需求收敛的速度会更快。如果任由这种思维发展下去，搞了多种不同的架构，运维必然深深陷入其中，而没法做到“高效运维”。

以上的情况在我们的团队中或多或少的存在，而在我们面向业务和用户的时候，其实需要一个能够彼此合作，敏捷及快速试错的IT组织。所以我们还是需要避免以上几种情况进入到团队和个人的思维模式中，让DO分离真正的走向DO合作，个人也认为有一些可行的方法可供参考：

• 建立责任共享机制

之前谈合作还是太虚，必须要找到一个点先突破，我觉得没有比共享责任更能建立起合作的氛围了。共享责任是一种优化思维，是一起寻求解决方法来面对这词出现的问题，而不是各自避而远之。共享责任不会用对立的眼光去看待彼此；共享责任是一种面向最终用户的思维，把用户感受的好与坏纳入到大家的工作共同考量中去。

• 建立IT性能模型

IT的性能和线上的服务性能道理是一样的，我觉得也可以设定两个指标［吞吐率］和［延时］。之前我在DevOps的介绍中讲过，这两个指标的意义。当他们设定之后，流程在一定程度上是和这两个指标要求相违背的，因此就需要不断的去破除流程带来的束缚，而走向自动化平台。

延时的指标可以重点关注两个指标，服务的上线时间，比如说持续部署的上线时间，这个考察变更能力。还有一个故障的延时，恢复的时间越快，我们认为延时越短，这个事考察故障恢复能力。后面我找个机会和大家探讨下［IT性能组织的内在技术特征］。

• 建立服务公共化标准

这个方法可以避免大家把多样的架构引入到生产环境中，运维面向的对象越多，运维成本就越高，服务可用性就越低。运维必须建立起公共组件库，指导后续的所有业务架构选型。DO此时需要深度的配合，通过服务公共化的实施推进，后端运维的专业性也越来越高，研发需要深度参与关注和解决的问题越来越少。最理想的状态，就是研发只需要关注业务逻辑代码的实现，其他的就全部交给公共服务好了。

• 确定一致的目标

运维和研发必须要有一个共性的目标，好的考核手段就是业务质量或者业务可用性。这两个指标都可以纳入到研发／测试和运维的KPI体系中，驱动力更有效。不写到KPI中，研发团队很容易把运维需求放到很低优先级上，欠下的技术债务就会越来越多，技术债务最终也会转化成运维债务。有了一致的目标，一定程度上可以避免自嗨和炫技思维。

DO分离对企业来说真的是一种能量消耗，必须走向DO合作，DO合作才能创造一个精益和敏捷型IT组织。另外从根本上来讲，运维和研发都存在各自可以互补的优缺点，如果合作，1+1才能大于2，如果拒绝合作，1＋1肯定小于2的，因为耗散已经产生。无论运维和研发都不要有文中所提的思维模式，真所谓术业有专攻，你写得好代码，不代表就可以干得好运维，你干得好运维，并不代表你能写出高可用的代码。

拥抱彼此，合作吧，因为衡量我们标准只有一个，“用户说好，那才是真的好”，其他的还真的都是在扯淡。