首次公开！阿里搜索中台开发运维一体化实践

阿里妹导读：2015年底，阿里宣布启动阿里巴巴集团中台战略。战略定义为：构建符合DT时代的更具创新性、灵活性的“大中台、小前台”组织机制和业务机制。其中，前台作为一线业务，更敏捷更快速适应市场，中台将集合整个集团的数字运营能力、产品技术能力，对各业务前台形成强力支撑，而集团在中台布局中一个非常重要的一环便是搜索中台化，但因搜索技术本身的复杂度和业务规模的挑战，让搜索中台在技术上、产品上都遇到了世界级的挑战。

面对挑战，阿里选择走上中台开发运维一体化实践之路。这条路究竟要怎么走？下面跟随阿里搜索事业部高级技术专家柳明，一起来了解。

背景

阿里搜索中台的初心是支持前台业务更敏捷更快速适应市场的变化，愿景是让天下没有难用的搜索，基于初心和愿景我们从0到1建设搜索中台3年，三年期间在DevOps、AIOps、offline平台化上都有了不少业内前沿的沉淀，而我作为一名阿里搜索老兵，有幸见证了整个阿里搜索中台的技术发展，所以在这里通过一些我个人有限的经验跟大家去分享一个后端服务该如何解决规模化、成本、效率、质量问题，朝着平台化产品前进的经验。

搜索中台技术发展

下图即是搜索中台从技术角度发展趋势的一个判断，也是经过3年多落地实践的一个过程。

 
可以从图上看到第一个阶段应该是我加入阿里的时候，无论是搜索事业部还是开源搜索技术都是靠人来负责系统和业务运维。当时人力资源是随着业务规模成正比增长的，这期间消耗了大量的人力资源在做着低效而重复工作，这是人工管控的阶段。

之后随着经验沉淀，PE逐渐发现一些常见重复的运维工作可以通过自动化脚本实现，在一定程度上减少了人力成本，提高了运维效率，也初步有了专家经验和领域知识沉淀的影子，这是自动化脚本运维阶段，这也是绝大部分开源技术体系所处的阶段。但是这样的运维方式天然地分割了开发和运维两种角色。

因为大家的使命不同，让两种角色天然的站在了对立面上，开发希望快速迭代，运维希望尽可能保障线上稳定而减少迭代次数，因为大家都知道绝大部分线上故障都其实是因为配置变更和软件升级导致的，天然的分割造成了相互之间存在着对对方的不信任，所以也就有了双方最后的妥协：固定每周周二和周四的发布窗口进行发布，但这是牺牲了业务运营效率为前提的。
 
其实这里存在了一个系统能力和业务方迭代需求上的一个很大gap，为了解决上述矛盾基于运维开发一体化的devOps概念的全新管控系统建设应运而生，也就有了第一阶段的开发运维一体化的建设，通过这些ops也较好地解决一些发布迭代问题。

但是我们的业务场景天然是一个技术体系的管控，所以我们认为devops不应该还停留在单个系统开发运维一体化的方法论认知上，所以希望我们的devops的定义是单个系统ops之上的“ops”，所以本质上我们和集团其他所谓的devOps平台有着非常大本质上的区别。

集团比较有代表性devops平台就是天基平台，它主要解决的是服务源代码到部署再到升级的一个全过程的管理，面向的用户本质上还是运维人员。所以在这个基础上，天基利用IAC（Infrastructure As Code，基础设施即代码）的维度+Git管理部署配置去打造产品其实已经足够，这是一种典型devops的平台设计思路，但是仅仅如此的设计其实对于我们来讲也许并不够，因为对于我们来说我们的用户是最终用户，他并不具备线上系统运维专业知识，只看到配置或者code，他一定会晕菜。

所以从根本上来讲我们需要将对DevOps理解上继续往前走一步，朝着面向平台产品化的角度上前进一步：一是对用户屏蔽配置或者code或者领域知识复杂度，二是将系统协同变成一种端对端体验的管控，因为只有做到了简化复杂度和全链路端对端体验的管控才能真正让复杂搜索业务迭代效率得到本质上的提升，为了达成上述2个目标我们经过多年努力逐步落地了sophon、bahamut、Maat等系统，也取得了很好的业务迭代效率提升。

但只做到DevOPS对于阿里这样体量的平台就完美了吗？显然不是，全链路的DevOps只是有效解决了研发、PE、用户配合效率和用户使用体验的问题，但是对于平台方来讲随着业务规模的急剧膨胀，以及搜索服务类型的复杂多样及多变，业务跟平台的矛盾其实又发生了本质性的转移：如何给在海量规模下为每个业务提供更好的稳定性保障和合理的资源利用率、以及更高的迭代效率等就成为了我们平台新目标。

目前我们基于在AIOPS数据化运营的3年实践中落地了Hawkeye -在线服务优化平台、Torch-容量治理平台、Heracles-日常压测服务化平台、CostMan-成本服务等系统。这些服务系统帮助平台在容量管理，日常巡检、一键诊断优化上取得了一定的阶段性成果，也让我们对未来统一集团搜索运维管控，业务数量即使超过10000+规模效应下平台也能应对自如，树立了坚定的信心。

虽然经过3年的数据化运营的实践，但我们离真正的AIOps还有较远距离，因为之前我们的性能瓶颈分析、问题诊断、故障自愈、复杂运维决策主要还是停留在专家经验沉淀上，说白了还是把人的经验沉淀到系统来解决线上运维的问题，而AIOPS期待的是用数据和算法能力帮我们自动地发现规律问题并解决问题，从这点上看AIOps在我们的平台依然还有非常多的潜力可挖，所以我们希望未来在效率提升、质量保障、成本优化上能真正借助AI的能力帮平台更好地适应未来的发展。<