在先前的一篇文章里笔者聊到了从内部变更风险防控转向ToB客户稳定性保障的一些思考主要聚焦在角色转变和业务场景的差异上。今天这篇文章就探讨一下笔者对于如何搭建一套客户稳定性系统的一些想法算是把之前的思考往落地层面再推进一步。首先一套客户稳定性系统从产品角度考虑需要体现对客的属性。也就是说这套系统不是单独去关联很多能力而是结合这些能力的执行表现去抽象出一套客户风险大盘的视图。从这个角度来讲我们这套系统可能就需要有以下核心的内容巡检告警从准实时的角度监控到当前客户资源水位如何有多少巡检告警问题产生处理情况怎么样变更防控从准实时的角度感知并监控当前客户相关的变更记录和风险影响确保变更引起的问题得到收敛风险治理从短中期的角度反映包括客户侧和产品内部待治理的风险清单以及风险治理的闭环情况客情分析从长期持续的角度展示当前客户侧日常提过来的问题和解决情况以及由这些问题本身提炼出来的潜在风险有这么几个功能基础我们就可以简单搭建一套对客的稳定性系统框架。当然做了这些还是不够的还有重要的一点是需要把这套系统跑起来给到各类稳定性保障的角色来用。这里的角色就涉及到SRE和对客支持角色。SRE角度比较好理解整套系统对SRE而言是一个工具链通过这个工具链可以很方便运维客户侧整体风险情况而从对客支持角色角度整套系统更需要反映产品侧整体的稳定性保证客户侧问题能够静默解决或者可以及时被判断出来。而这套系统怎么样让对客支持角色可以深度使用才是落地的关键。基于此笔者目前暂时提出一些想法。第一点是完善风险通知机制。不论日常的监控告警和变更防控还是稍微长期一些的风险治理跟客情分析都需要有一套通知机制把这些风险事件推送给对客支持角色去辅助他们的判断。客户的类型是多样的包括但不仅限于游戏、AI、金融还有政企类在产品本身功能不能很好兼顾太深入的客户业务场景的情况下最能判断怎么处理风险的角色还是需要前线同学。所以第一要义是让这套工具链服务好前线同学给到足够的信息让前线同学更好判断产品侧的实时情况。第二点就是刚才提到的需要针对特定的业务特征做一套充分反应对应业务特征的风险汇总能力这样才可以更深入挖掘到客户风险做定向解决。比方说AI-Agent类客户的场景如果采用KubernetesSandbox技术做Agent托管那么从产品侧角度需要关注整条链路的交付风险。再往下拆的话就分为几个方面核心组件包括APIServer、Etcd、Controller Manager、CoreDNS等基础组件的cpu/mem水位、可用性、调度情况等属于是Kubernetes场景通用的基础指标Sandbox Pod状态需要考虑pending/terminating状态的pod数量是否过多也需要观察休眠唤醒的时间是否过长Sandbox交付需要考虑sandbox申请时候在特定限流配置基础下能否达到特定数量交付的SLA同时也要实时监控到sandbox交付侧的平台告警并且有运维机制解决交付侧/集群侧状态不一致的情况最后一点就是做好周期性的数据运营需要涵盖到产品风险和治理进展两大块。持续的数据运营加上通晒探讨不仅能够反映产品侧/客户侧需要解决的问题也能够促进整套客户稳定性系统做的更加深入让整个对客稳定性体系做的更好。