如何化解产品和技术部门之间的矛盾

说成矛盾，一则感觉尖锐了些，其次我来谈这个问题，有点行外人看行内人的感觉。但是运维部门和业务部门之间也同样存在在结果期望上的矛盾，毕竟"多快好省"的服务都是大家需要，但往往现实制约了无法提供“多快好省”服务，于是便有了以下的头脑发散。

研发技术侧都表达过产品的需求太多，给技术侧的时间很短，导致研发的质量下降。产品希望研发能提供更高更快的产出；技术希望产品提出更高质量的产品需求，避免迭代无谓的需求，这就是矛盾所在。从现实层面上来说，互联网的业务竞争压力越来越大，产品需要寻找更多的差异化，因此需要更多的敏捷化尝试，同时原有产品也会快速发展，此时传递到技术侧的压力会更大。这个矛盾如何解决？以下是自己的一点认识。

在传统制造、纺织行业，工单进度都是可以通过加人来解决问题，为什么软件行业就不能？富士康的新人和纺织厂的女工，培训一两天就可以上岗工作， 新手的产出和老手没有区别。为什么软件行业就不能？

在互联网行业有几个数据也值得思考，为什么whatsapp亿级用户规模的产品，研发只有50个员工？为什么google能够管理百万台的服务器规模，google kubernetes每秒能启动7k个docker容器，每周会超过20亿个容器，怎么做到的？为什么facebook能人均管理2w台服务器？为什么米聊推出一个月以后，微信能够迅速发布，并快速迭代功能？这个问题都留在后面回答。

记得早年有一本书叫《人月神话》，其中讲到的人月就是讲一个软件产品不能简单的通过增加人力来解决项目进度问题，根源在于在软件产品项目中人力和工时没法简单的互换。因为一些新人的加入，需要对其进行培训（时间成本），并且新人的加入会带来沟通更高的复杂度（沟通成本，巴别塔问题）。在人月神话中对这个问题有一些答案，我认为其中两点非常重要：

第一、专制、民主与系统设计

在系统设计时，概念完整性非常重要，这种概念的完整性，必须出自少数人和一个人的想法，这就是需要专制的原因。另外对于一个软件产品来说，需要将架构设计独立于功能实现之外,这样能获取概念整体性强而有力的方法。

第二、 外科手术团队

在接受相同的训练、同样都是两年资历的情况下，优秀专业程序员的生产力要比差劲的程序员好上十倍。短小精悍团队是最棒的——尽可能用最少的人。绝大多数大型软件系统的经验显示，使用一堆人蛮干的方式最耗成本、最慢、最没有效率，做出来的系统在概念上也最不完整。类似于外科手术团队的组织提供了一个良方，既可因少数人的决策而兼顾到产品的整体性，又可因多数人的合作与大幅沟通减少而得到全部人的生产力。

在传统的软件项目，它不是一个分布式的系统，所以上面提到的概念完整性，我觉得更多是聚焦在软件工程思想（如CMMI、瀑布模型等等），而非技术架构，让研发过程标准化可控，去到某个行业，就是其解决方案，比如说电信行业的eTOM模型。

但对于快速多变的互联网分布式系统来说，此时的概念完整性，是要建立一个技术标准，从而产生一种可复用的能力，从而解决效率问题、成本问题和质量问题。此技术标准最直接的理解就是就是应用技术公共化的能力，低层次理解是公共组件，高层次理解是公共服务。这两者的区别是：组件是面向功能的实现，服务是组件之上，还需要考虑其可运维性，可运维性就意味着管理成本低，透明化服务能力强，可用性高等等。

构建如上所说的可复用的技术标准在现实层面也会遇到很多困难，主要体现在：

第一，很难构建一个强势的团队（公共组建服务组）来建立这一技术标准。之前在YY见过一个研发团队，数据存储选了mysql、mongodb、Cassandra，上线之后业务问题频出。如此多样化的选型，需要团队自身有很高的技术学习和储备成本，传递给后续的测试和运维成本也非常的高昂。

第二、业务应用研发团队往往不信任公共组件服务，有些团队在看到公共组件服务出问题，就着手自己构建。个人的观点是，投资未来，容忍失败，随着经验的积累，它带来的价值回报远远大于过程中的一点问题付出。关于公共服务化的好处，还可以用一个数学模型来帮我们估算，因每个软件都非100%可靠，比如说是99%。如果每个团队各自选型，产生的软件数量是10个，此时可用性就是99%的10次方，是0.9043820750088；如果是通过公共服务化收敛最终是6个，此时的可用性就是99%的6次方,是0.941480149401。

第三、公共组件服务和业务模型的适配能力。其实这块的核心挑战是落在存储服务上，不同的业务形态对存储有着不同的选型要求。传统的web应用，读写满足90%/10%的规律，数据热点相对集中，比如论坛的热帖；而到SNS应用下，读写的分布就更加离散，数据热点不集中，全名打飞机就是一个典型的业务场景，此时Mysql的存储就不一定合适所有业务了。谈到文件存储，文件的大小对文件存储选型起着决定性的影响，HDFS/MFS/FASTDFS在这些维度都有着选型对比。现在Sql/NoSql/NewSql存储非常多，千万别抱着用一种存储覆盖所有存储场景的想法，一定会是一个存储组合服务存在。另外存储的跨介质支持非常重要，对于硬盘、SSD和内存的存储支持，这一点在现在的高端存储中都有实现。

虽然之前运维和研发也推动过一些标准化和公共服务化，但依然觉得还不够深入和体系化。我对技术标准化和公共服务化有着自底向上的层次化归类，如下：

第一层、网络框架标准化。无论是选择mina、netty或者其他网络框架，关键的评估是看是否可以在此之上快速构建自己的网络应用，同时需要极大的简化自己的网络编程模型。

第二层、协议的标准化。这个非常重要，对测试和运维有着很大的影响。我们知道基于http协议的应用，非常容易维护，因为标准统一，测试也好封装测试自动化测试用例，运维也方便基于http协议采集运维数据。但对于私有协议来说，设计格式千差万别，很难做统一的自动化测试和运维自动化。如果协议统一，运维想要实现统一的监控功能，直接修改底层协议实现数据上报或者数据染色即可，可以看看google的Dapper服务设计。

第三层、容器服务的标准化。有了底层的网络框架，可以封装自己的http web容器，http协议是一个标准协议，基本上能解决大部分的业务场景，维护起来也非常简单。但http协议在大并发业务场景下，会影响性能，本身的文本协议解析的时间消耗就很大。此时需要构建自己的私有协议，私有协议可以基于PB或者thrift制定一套协议标准，同时确保协议可扩展。基于PB和thrift调度框架，进一步封装达到服务自动生成，进一步降低研发的成本。

第四层、应用服务的公共化。可以说以上三点都是解决应用逻辑层服务的标准化，最终都是想让研发只需要关注业务逻辑代码的研发。但这个还不够，需要进一步提供更多的公共化应用服务，比如说：A、通用数据存储；B、通用大小文件存储；C、通用的服务调度框架;D、通用的应用容器框架;E、通用缓存等等。

基于这些标准化的公共服务能力，构建应用就如同搭建积木一样，后续的测试和运维基于这个标准的积木体系，可以快速构建自己的模型。现实生活中，乐高几个标准积木，可以搭建千变万化的模型。

在腾讯的时候，经历了业务技术架构几次的变化以及对运维的影响。第一阶段：业务在百台规模的时候，是一种组件化阶段，当时用apache、haproxy等等，运维靠手；

第二阶段：后来业务增长到千台规模，组件开始自研收敛，前端用qzhttp（类似JWS），逻辑层用了一个SPP server框架，具备了半自动化能力，运维架构开始按照架构层切分，不再跟随业务，运维的专业能力逐渐显现，此时一些面向架构层的自动化平台开始形成，确保了运维随业务增长的压力，同时确保服务的质量和效率；

第三阶段：再后来业务增长到万台规模，推动前端业务去状态化，所有的业务状态不断下沉到数据存储服务，此时存储再以标准化的服务形式存在（SQL、Nosql和文件存储服务），提供一致性的访问接口，确保服务透明化。

从整个发展过程来看，技术架构中的公共服务抽丝剥茧，最后只剩下几种形式，此时自动化效率水平不断提升，可扩展能力不断增强，伴随的就是运维和测试成本不断降低，研发也一样，同时质量也在提高，这些就是我们常说的可运维性，因此可以说可运维性是整个技术链条(研发、测试、运维）的核心能力输出。

开始我没有去谈如何要求对方提高质量需求或者减少需求，降低需求压力；也没去谈如何做自动化；谈如何让服务能力前移（比如说研发来做运维），减少自己的工作量；谈如何加强团队合作，有效沟通，提升服务能力？我觉得这些都是一种能力要求，技术思维还是让我去思考如何通过技术驱动来解决这些问题。

总而言之，首先需要建立一个强势的完整性概念---必须走公共服务化之路，并且让所有的研发团队必须遵循这一标准，形成可复用的能力，也就是人力和工时互换的能力，这是一种无状态的组织能力。更深层次说无状态的技术架构可以催生无状态的技术团队。

其次，这个能力必须需要有一个强势的外科式手术团队，强势的团队中还必须有一个强势的领导存在，因为以上所说的标准和服务需要你强势推广和有效说服的。