就是说每个服务都是单独OPS进行单独管控，但实际上如上图所示一个复杂业务就是一个多服务体系协同的结果，所以在我的记忆里当tisplus没上线前，我们接入复杂业务之前第一件事情就是召集在线有状态服务团队、在线无状态服务团队、离线DUMP团队、业务方、PE开个会互通下有无，然后安排怎么合作推进这个项目上线，上线后的线上变更和问题处理也是支持群里相互吼：“我已经做完这一步了，你可以做下一步了”，“你稍等下再操作，我还要重新发下”。所以可以想象这样的业务接入合作效率得有多低，相信大家从我刚才的描述中也能知道为啥我们之前支持10来个业务已经是极限的原因了吧。
有了这些痛点需求，那再回过头来说说我们我们在实践过程中认为复杂搜索系统的devops建设必须有：
提供端对端体验的全链路OPS才是我们认为符合我们场景的devops标准定义。
复杂的运维管控链路中基于我们常识认知的过程式运维方式需要升级到基于目标驱动式的运维管控。
较好的运维抽象及产品抽象，更好的赋能用户。
提高业务迭代效率必须是保障业务稳定性为基础。
有了这些需求痛点，也就有了我们在这个领域的技术..布局-Sophon，接下来我们将分章节详细介绍下该系统。搜索中台devops实践-Sophon
目标驱动式运维
什么叫基于目标驱动式的运维？其实乍一听，会觉得太过于抽象，其实如果听完我的解释，你会觉得非常简单，我们举个实际搜索的运维场景来说明也许更容易明白为什么我们要提倡基于目标的运维管控。
比如我们的搜索系统现在的索引版本是A版本，然后要求系统执行切换索引B版本，但正在rollingB版本的时候，我后悔了我要rolling C 版本。这其实在早些年的时候，线上这种状况是非常让人崩溃的，如果这事让PE去做的话 , 只能杀掉切换流程，检查系统每个节点到哪一步了，清理中间状态，重新发起运维流程，可以想象过程式的运维管控方式在复杂运维体系下是多么低效的事情。
