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