1 业务角度看搜索平台

1.1 从平台自身业务接入成本看

业务支持人均人力成本大大降低：在业务schema频繁变更、版本维护、自测试、发布运维逐步流程化、自动化。出错时候、搜索效果不好的时候平台技术才介入。平台的效率在应用达到100级别时候非常明显。

同时，平台接入的业务越多，平台积累的业务经验、优化经验、在线问题以及处理经验丰富了并沉淀了，后期的类似业务搜索方案的制定、上线效率、稳定性无形中大 大提升，从最初的1-2天完成上线部署流程，到现在可以10分钟同时部署日常、预发、线上系统（排序效果优化这个令算，排序本身就不是一次性工作）

1.2 从业务方接入成本看

借助平台的半自助化处理（纯自动化很难，因为搜索效果需要关联schema、查询语法、系统参数、业务特点等综合考虑），业务可以自行更新schema、调 整dump、查看更新、查看dump、查看索引、验证数据等一序列操作，对平台的具体人的依赖弱化到对平台共有的基础技术、业务流程的依赖。也便于形成统 一规范，有点类似sql 语法规范那样。

另外，其他team自己搭建的类似系统的“重复开销”减少了，但是依然存在不少系统自己继续搭建自己的系统（可能是KPI、可能是有人力、可能是原型系统搭建so easy而一开始没有遭遇专业问题。。。）

1.3 从业绩角度看

平台的更大的价值，用我厂流行的观点，转化率、成交率、PU、UV 衡量的话，平台的“集中价值”有多大，真的非常非常大。

2 从技术角度看

专业的平台，碰到的复杂问题经验丰富、对策处理方法多、成熟度比但系统、自己初搭建的更有技术保障性（不排除那个team 搭建者本身就是一个经验丰富的牛逼人啊 ，这样毕竟少数）。

专业的平台，在平台性能、功能、运维演进过程中，一小点的提升、改进，直接让平台多应用受益。（需要提升的应用才升级，不是强制升级的，平台必须支持具体应用具体小版本，这里小版本是指plugin的东西、特殊的系统参数优化，例如cache）

专业的平台，对技术的专注、深度、业务的支持，要求更高。并且能提升行业技术水平（对外交流后，平台的技术实力不言而喻）但是，平台化也存在不可忽视的问题。

3 平台化的问题

3.1 业务方人员频繁变更的“培训成本大”

第一次接入后，后面业务方人员调整，面临新人从新“培训”的过程（后台的使用、概念的理解、流程的认识等等）。由于项目急、时间紧、添加删除字段、改变查询条件等，旺旺、电话沟通成为主要方式。大家懂得，一上午有2-3个业务技术咨询，一上午基本费了。

提供的文档、demo、培训，已经接入的多半不会继续关注，毕竟流程的东西。还没接入的，也不清楚谁会接入，听者聊聊无几。

3.2 大业务的支持

平台在支持大业务上，需要特殊对待。某个大业务累计变更的上下文背景、特殊的优化场景、特殊的管理、运维，使得需要固定的人手跟进大的升级、优化，而在基础问题就统一处理了。这就意味着某种程度，业务绑架了人力，与平台化有些矛盾。

3.3 平台化后成绩的评定

平台化后，怎么算成绩。我有时候笑称，我们是给别人做嫁衣。平台化后，技术隐藏了，业务产品怎么怎么火了、好了，基本和后端默默支持的团队没半毛钱直接关 系，只有业务接口开发同学对我们的感激、感谢（希望不会有人说我价值观有问题啊，算我不成熟的描述这个状态吧，不要上纲上领啊）。

另外，不管怎么样，大的项目进入平台，项目的影响力，无疑影响平台的影响力，这是好事。管理分工也就需要把控了，如果都抢大项目，那么小项目、小需求怎么办，怎么体现价值？

平台化架构稳定后，更多的是性能优化（引擎本身）、基础组件的效果提升（qp、排序），而这些投入并不是立杆见影的效果，也不一定说就一定改进后一定合理，需要反复上线优化、对比。慢工细活下的压力？成绩？成长？对团队的更加和谐、积极、正向的发展是考验。

3.4 平台化后硬件资源

平台化本身如果不能，实现“叠加应用、恭享资源”在集群级别或者单机级别。这个平台只实现了部分的平台化，实现部分的价值。假设能实现app叠加，优化资源恭喜。那么，硬件资源谁预算、谁控制比较好？

当前终搜线上是业务申请的，而日常、预发共享的。（最多的机器叠加超过30+ 应用，索引超过40G，而内存就是4g、8g 不等的虚拟机）