近期因为工作调整的原因，笔者从以前面向内部研发团队的变更风险防控和稳定性建设，逐渐转向面向ToB客户的云服务稳定性保障。虽然本质上都是在做SRE稳定性相关的工作，但从服务对象、技术架构到运营方式，都有非常大的差异。今天这篇文章，就结合自己以前做变更风险防控和稳定性建设的实践经验，聊一下从云服务角度做ToB客户稳定性保障的一些思考和对比。
一块是服务对象的转变，以前做变更风险防控平台，服务对象是公司内部的研发和SRE团队，包括公司内部整体的架构也比较扁平，技术栈比较统一，所以沟通成本比较低，需求沟通起来也比较直接。在这样的场景下，变更风险防控平台的建设就会更加趋向于产品化，因为会有无数不了解稳定性业务或技术的同学来平台做咨询或者提需求，所以每项功能都做的比较细致体贴。最终呈现出来的平台不仅是功能齐全，在用户友好度上也有比较优质的体验。
但ToB客户稳定性保障的性质会相对不同，因为是对外服务，所以单从组织架构阵型上就不会那么扁平。笔者自己是做Kubernetes云产品的产研角色，但云产品要触及到不同外部客户的话，云产品产研和客户之间也会隔着客服和前线技术支持的角色，并不是说直接可以对接产研。或者来讲，只有必要的情况，产研才会协助解决问题，一般情况下，需要产品能力自身保障履约的SLA。
所以这种情况，做稳定性治理的思路上，并不能说随便就拉群沟通优化产品体验，而是会更加依赖平台功能化的动作，在不影响各方风控敏感的基础上，一是把组织阵型之间的协作流程承接起来，二是面向内部角色的稳定性治理提供标准的技术模块，三是能够识别影响客户的风险并利用流程能力让客户更快解决。这其中，三是目的，一和二是手段。这样可以应对几种常见的业务场景：
- 风险治理：客户提出问题希望产品研发协助修复，但这个问题可能遗留已久未治理的问题，并且这个过程技术支持角色没有感知，因此衍生出来的一个事情是未治理的巡检风险工单化，推送给技术支持角色，推进客户治理
- 变更感知：云产品自身发生变更，比如Kubernetes托管面组件发生变更，这些操作影响到客户线上业务，导致发生故障，因此又衍生出来一个事情是托管面变更风险推送给技术支持角色，由技术支持角色判断并告知客户可能的影响
- 健康检查：对于日常客户和云产品的沟通协作，客户可能因为数据面集群访问控制面出了问题，向技术支持角色咨询云产品底层健康状态，那么有什么方式可以快速判断控制面的健康情况，就需要云产品研发提供诊断能力，去落实这个事情
有了这些能力之后，对于ToB客户稳定性治理这件事情也能做到比较基础保障。当然仅凭这些也是不够的，最终态还是说怎么从客户出发，减少因为云产品本身稳定性问题带来的不确定性，提升客户对云产品的信任，这也需要考虑到客户本身的性质。比如游戏业务对于单节点本身的性能要求比较高，AI业务训练时因为gang-scheduling，又对瞬时起大量pod的时长和稳定性要求比较高，一些涉及到人文关怀的业务虽然在云产品使用上并没有太大的投入，但如果云产品出问题会造成很多社会影响，可以说这些客户也是需要重点关注和保护的。
所以说，ToB客户稳定性保障，长远看不仅需要关注产品技术指标本身，也需要有一些手段衡量客户的体验，对于不同类型的客户需要区分不同的衡量手段，对于重保客户也需要衡量相比于常规客户其稳定性提升的幅度，这样才能构建更加有效的体系去进一步指导稳定性保障的动作。
总体来看，从变更风险防控到ToB客户稳定性保障，虽然工作性质有所变化，但核心理念是相通的：事前预防优于事后止损，数据驱动优于经验判断，体系建设优于单点优化。还有很多事情，笔者也会亲身经历，亲身探索，未来还有什么想法，就再继续写上。