智能运维项目上线之后，不少企业会遇到一个相似的场景：一线把问题报给系统管理员，管理员判断需要厂商介入，厂商工程师也按时到场了，但问题处理完没几天又回来了。这不是谁不负责，而是三层团队之间缺少清晰的职责界面与升级判据。

一、三层团队各自该负责什么

用友智能服务管理器YonISM 在服务保障上采用分层协同的团队模式。这个分层不是把责任往外推，而是把不同类型的问题交给最合适的一层。

一线由终端用户与系统管理员组成，负责问题的最初描述、基础排查和可自助解决的部分。这一层的价值不在于解决多复杂的问题，而在于把问题说清楚：谁受影响、范围多大、什么时候开始、已经尝试过什么。

二线是数科公司与厂商现场运维服务团队，负责需要现场判断、需要贴近业务系统才能定位的问题。三线是厂商总部服务资源，包含应用、技术与研发，负责产品层面的缺陷、版本相关的问题以及需要研发介入的场景。

二、现场运维能解决什么，不能解决什么

智能运维的现场团队最擅长环境类、配置类与操作类问题：系统连得上但权限不对、流程走不通、某个环节的配置与组织实际不匹配。这类问题有明确的复现路径，现场看一遍就能判断。

但现场团队通常不掌握产品底层实现。当问题指向产品自身的行为逻辑，或者同类问题在不同环境下反复出现，现场再投入人力也只能做临时绕行。这时如果没有人主动判断"该往上走"，问题就会在二线反复消耗，而用户感受到的只是"又拖了一轮"。

三、升级之前要带哪些信息

升级到三线最怕的不是升级本身，而是升级时材料不全。研发需要可判断的依据，而不是一句"客户这边有问题"。至少要带四件事：现象与期望行为的差异、影响范围与出现频率、已经排除过的原因、现场可复现的条件。

这四件事不需要写成长文档，但必须在一线与二线交接时补齐。缺一项，研发就只能反问，一来一回就是时间。

四、边界不清会以什么形式暴露

智能运维里的责任边界不清，很少表现为争执，更多表现为三种可观察的现象：同一类问题反复升级却从未沉淀成知识、二线与三线互相等待对方的动作、用户被迫在多个入口重复描述同一个问题。

第三种最伤体验。用户不关心内部怎么分层，他只关心"我说过一次的事情，为什么还要再说一遍"。YonISM 以统一入口承载请求的好处就在这里：请求只提交一次，后续的分派与升级发生在系统内部，而不是让用户跟着组织架构再走一遍。