不同技术团队的配合问题及DevOps

一、技术团队细分及配合问题

在IT企业里产品从创意到交付给用户，从整体上看是由技术部门负责，但如果深入到技术部门，会发现由不同的技术团队负责不同的部分或者阶段。一般会分产品团队、开发团队、测试团队以及运维团队，在互联网公司里，运维团队一般还分基础运维和产品运维两个团队，基础运维负责基础设施(包括机架、网络、硬件)和操作系统的安装，为整体公司的所有产品提供基础设施的运维服务。而产品运维负责线上产品的问题处理、代码的布署和跟开发的接口等。

不同的技术团队一般隶属不同的部门，分散在公司不同的办公区域，团队内部的沟通相对多一些，但团队之间的沟通较少。不同团队都会形成自己的办事习惯、节奏，都有自己的关注点，一般只是知道与之接口的团队的总体职责，但是不知道对方可能面临的困难与工作中的挑战点。另外，如果公司够大，每个团队内部又会分为许更细的小团队，如基础运维一般有系统团队、网络团队和IDC团队等，这样更加重了团队之间沟通难度。

从产品策划到上线，一般是以下边的顺序经过各个团队：

开发团队收集产品的需求，定下时间表并进行开发
开发完后，交由测试或质量团队进行测试
然后交给运维团队布署新产品或新版本
运维团队将运维过程中发现的代码缺陷反馈给开发团队进行修复

在上面的每个阶段，对应的团队都是各做各的，一般是在最后才会把球踢给下一个团队，如果下一个团队发现问题又会把球踢回原来的团队。如果你深入到不同的团队中去，或听到不同的抱怨声音。

基础运维团队经常抱怨：

产品开发一点计划都没有，突然要上线机器，让我们措手不及。
每个产品都急着上线，谁催得急就上谁的，谁能说一下，到底那个重要？
动不动就要重装系统，坏了一块盘就着急去修，刚从机房回来，又要过去。
上线太突然了，没有交换机，没有机架，还需要搬别的机器腾地方。
那个地方有机架和交换机端口，但没有四层设备，他们又要放在四层后边，真的没有办法了。
刚跟他们上线到一个机房，他们又说要换到另一个机房，尽折腾。
他们怎么能那么用设备，把上连端口带宽都跑满了。

产品运维团队会说：

真没办法，上个线不是说没机架，就是没有交换机，还有就是说没有四层设备。
从来不告诉我们什么时候能设备能上线交付给我们，不派专人催着这事，一点谱都没有。
本来没有想好怎么用这些设备，先提前一个月申请上线，得我们想清楚了，他们却说又得换机房。
网络怎么老是出问题，他们怎么规划的。
开发的代码太不靠谱，一上线就引发用户投诉，只能回滚到老版本。
开发人员的技术能力不行，写不出能用的版本。
开发要求有一个跟生产环境一样的测试环境，这不可能有的。

而开发团队却说：

他们又不让我们碰线上的系统，生产环境是什么样，我们都不知道，没法开发代码。
我们辛苦开发几个月，上线出问题又直接回滚了，心情很不好受。
代码在测试环境或我的机器跑的好好的呀，怎么一上线就出问题呢。
测试怎么测的，那么多问题发现不了。
我们希望产品运维同事帮忙搭一个跟线上一模一样的测试环境。

另外，测试团队的人也许会说：

开发人员不写规定写单元测试代码。
想着能用一个自动的集成测试环境，因为开发的原因，老是实现不了。
测试环境跟生产环境不一样，好多问题才发现
还有那么多的bug没有解决，产品就催着上线。

二、技术团队之间配合不好的影响

上面看到的团队之间的冲突和抱怨问题虽然都不一样，产生的影响确是类似的：

产品上线的进度延误，整个团队很难正常交付新版本。
产品上线后问题很多，影响用户的访问。
团队的士气很差。

最近又发生了运维团队与开发团队之间的配合不好的问题，影响及原因如下：

新产品上线延误了两个星期，正常情况下一天就可以上线。原因是开发考虑不周，测试环境中没有发现，到上线前才发现部署到多台机器上后，按开发原先计划的方式多台机器无法协作完成任务。还有就是在设计阶段没有考虑生产环境的状况，在上线的过程中需要做出对应的代码调整。
上线后质量不稳定，出现多次紧急修复。原因同上。
临时增加硬件投入。新产品中有个组件采用全新的技术方案，跟原来的LAMP体系不兼容，所以需要新增机器，单独部署。
除低了服务可用性标准，并产生了遗留问题。因为临时需要增加硬件，而恰好又只有一台，这样就形成了单点，如果该机器出现故障，服务将全部中断。另外，由于开发前设计上考虑不周，跟别的组件集成时产生别的单点。所以这些降低了服务的可用性，以后还得想办法解决。除此之外，组件采有新的软件，安装、服务起停以及软件配置的管理都是纯手工打造，以后还得找时间纳入到自动配置管理中。
影响了团队士气。在上线过程中开发、测试和运维都觉得不舒服，相互之间产生了抱怨。如果不处理好，会影响以后的配合。

虽然，有些问题确实需要靠某些团队提高自身的人员技能才能解决好，但这些团队能够形成一股合力的话，同样的人员组合肯定会产生更好的效果。

三、过去解决团队配合问题的方法

第一次碰到团队之间的配合问题时，我们还没来得及解决的时候，公司战略调整，整个开发和系统运营团队转给了另一个大部门。但我们在别的地方重新梳理技术团队时，后来又没有出现这种问题，回想起来，我们的做法是：

部分开发人员有生产环境中服务器的帐号，可以观察代码的运转情况，少数核心开发人员还有sudo权限，当然他们也不会随便修改服务器的设置
开发时一开始就会跟系统运维团队沟通，在代码中增加数据收集的接口和监控接口，这样上线后，很容易收集产品的性能数据，并能方便地对运行状态进行监控与报警
生产环境中也有沙箱与beta环境，这样大的版本从测试中过渡到生产环境前，先在沙箱环境中适应一段时间，这样能相对平稳过渡到生产环境
部分开发人员临时转到系统运维团队工作一到二个季度，跟系统运维同事一起上线产品，解决产品在运行中发生的问题，这样更好地了解代码如何在生产环境中运行，回去之后能更好地运维同事沟通，开发出来的代码更容易在生产环境中运行

这样，不同团队之间虽然有职责上的明确分工，但在中间的配合的部分做了不少柔性处理。另外，开发、运维与测试等团队中的核心人员之间本身就有认同感，大家一开始的目标就是奔着公司能成功来的，这是没有出配合问题的根本原因。这一点其实跟DevOps的核心点类似，既然如此，何不重新审视一下 DevOps，并参考着解决团队之间的配合问题呢。