因为大家的使命不同，让两种角色天然的站在了对立面上，开发希望快速迭代，运维希望尽可能保障线上稳定而减少迭代次数，因为大家都知道绝大部分线上故障都其实是因为配置变更和软件升级导致的，天然的分割造成了相互之间存在着对对方的不信任，所以也就有了双方最后的妥协：固定每周周二和周四的发布窗口进行发布，但这是牺牲了业务运营效率为前提的。
其实这里存在了一个系统能力和业务方迭代需求上的一个很大gap，为了解决上述矛盾基于运维开发一体化的devOps概念的全新管控系统建设应运而生，也就有了第一阶段的开发运维一体化的建设，通过这些ops也较好地解决一些发布迭代问题。
但是我们的业务场景天然是一个技术体系的管控，所以我们认为devops不应该还停留在单个系统开发运维一体化的方法论认知上，所以希望我们的devops的定义是单个系统ops之上的“ops”，所以本质上我们和集团其他所谓的devOps..有着非常大本质上的区别。
集团比较有代表性devops..就是天基..，它主要解决的是服务源代码到部署再到升级的一个全过程的管理，面向的用户本质上还是运维人员。所以在这个基础上，天基利用IAC（Infrastructure As Code，基础设施即代码）的维度+Git管理部署配置去打造产品其实已经足够，这是一种典型devops的..设计思路，但是仅仅如此的设计其实对于我们来讲也许并不够，因为对于我们来说我们的用户是最终用户，他并不具备线上系统运维专业知识，只看到配置或者code，他一定会晕菜。
所以从根本上来讲我们需要将对DevOps理解上继续往前走一步，朝着面向..产品化的角度上前进一步：一是对用户屏蔽配置或者code或者领域知识复杂度，二是将系统协同变成一种端对端体验的管控，因为只有做到了简化复杂度和全链路端对端体验的管控才能真正让复杂搜索业务迭代效率得到本质上的提升，为了达成上述2个目标我们经过多年努力逐步落地了sophon、bahamut、Maat等系统，也取得了很好的业务迭代效率提升。
