近期因为工作调整的原因，笔者从以前面向内部研发团队的变更风险防控和稳定性建设，逐渐转向面向ToB客户的云服务稳定性保障。虽然本质上都是在做SRE稳定性相关的工作，但从服务对象、技术架构到运营方式，都有非常大的差异。今天这篇文章，就结合自己以前做变更风险防控和稳定性建设的实践经验，聊一下从云服务角度做ToB客户稳定性保障的一些思考和对比。
一块是服务对象的转变，以前做变更风险防控平台，服务对象是公司内部的研发和SRE团队，包括公司内部整体的架构也比较扁平，技术栈比较统一，所以沟通成本比较低，需求沟通起来也比较直接。在这样的场景下，变更风险防控平台的建设就会更加趋向于产品化，因为会有无数不了解稳定性业务或技术的同学来平台做咨询或者提需求，所以每项功能都做的比较细致体贴。最终呈现出来的平台不仅是功能齐全，在用户友好度上也有比较优质的体验。
不知不觉在质量技术领域也走过了七八年之久，从最早的覆盖率测试工具，UE4游戏客户端自动化，到后续的数据变更风险防控，再到变更风险防控平台架构建设，期间做过很多思考，也沉淀了许多技术文章。随着业务测试->质量提效->技术风险SRE->稳定性架构师的工作内容变化，笔者也自觉自己未来的工作从垂类角度，也会逐渐独立于质量技术，转而更加深入做SRE稳定性和后端架构领域。所以今天这篇博客，也决定和自己多年来的【测试人生】做一个暂时的道别，当然也借着这个机会，聊一下自己对于质量技术的现状和未来发展的思考。
首先聊一聊现状，坦白来讲因为AI时代的到来，质量技术又再一次焕发了生机。主要体现在以下几点：
近期AI编程的新概念层出不穷，从最简单的Code Completion，到NEXT预测，再到现在什么Vibe Coding、OpenClaw，外加Spec Coding、Harness Engineering等Agent工程名词，可以说随着LLM的能力增强，不考虑业务架构，纯考虑编程本身，AI几乎已经可以替代所有人类，对于程序员而言，以前要做亲自编码，现在则需要转化为一个管理者的角色，指导AI完成程序员的工作目的。
为了体验AI编程的强大，近期笔者借助AI Native的开发工具，通过纯Vibe Coding的方式，开发一个基于kubebuilder的operator管理工具。kubebuilder本身提供的命令和功能已经很丰富了，但还是免不了一些小问题，比如在国内某些镜像和依赖拉不下来，或者开发多个operator没有一个工作区做统一管理，这些问题都可以由一个operator-gallery工具去做解决。
换言之，operator-gallery的职责是封装kubebuilder，端到端地处理operator的构建、部署和卸载流程，这样开发者只需要专注在types和controller的实现就可以。
近期因为探索AI编程的缘故，希望给日常生活中多找一个AI-Native的IDE，一方面做纯Vibe Coding的开发，另一方面也能够兼顾日常手动微调编码的需要。当然由于众所周知的原因，也希望这个IDE可以照顾国内用户，不是说总是要搭梯子编程，这样编程之外的冲浪需求就不方便了。
经过一番探索，在Trae、Cursor以及Claude Code等一系列候选名单中，笔者选择了Qoder。并不算是打广告，主要是基于以下的理由：
近日笔者发现自己Macbook-Pro播放B站视频，全屏的时候必然卡顿，退出全屏就没事。笔者电脑的参数是：
到网上一查发现《Edge浏览器在MacOS 26(Tahoe)系统上看B站卡顿》一篇文章，实测下来确实如此，拔掉电源就没事，插上电源必然卡成PPT，并且视频还比拔掉电源亮一些。
至此怀疑是Edge浏览器某些设置的问题，经过一番探索，发现在Edge设置的「系统和性能-系统」栏目下，取消「增强视频」即可解决。「增强视频」的作用是，接通设备电源后，锐化视频并提高颜色、照明和对比度。「增强视频」功能启用的机制是，不会增强屏幕上较小的受保护视频和视频，当多个视频在一个网站上处于活动状态时，将仅增强最近播放的视频。这也明显符合在B站上小屏和全屏播放的情况。
希望有遇到相同问题的人，可以尝试笔者提供的解决办法。
不知不觉在变更风险防控领域投入了三年之久，从最早做数据类变更风险防控工程，到后续做变更风险平台架构能力，在取得些许成果的同时，也同样沉淀了很多关于变更风险防控平台的技术思考与判断。趁着阶段性收尾，今天就做个总集篇，重点针对建设变更风险防控平台的这段经历，梳理一遍核心经验。
本文主要讲述4个方面：（1）基础工程架构设计（2）质检任务执行设计（3）质检稳定性与效果优化（4）应对LLM时代的挑战。
在变更风险防控领域，规则校验和变更中观测一样，是必不可少的能力之一。面向配置类变更和SQL数据类变更，通过严格的静态规则校验可以拦截很多事故风险，保障配置或SQL发布后的安全。从变更风险防控平台的角度来说，一个规则校验系统（规则引擎），可以简单设计成多组变更场景到校验规则的映射，业务SRE角色可以编写较大业务域的通用规则，而业务研发可以编写特定业务域的专项规则，当一个变更发起时，多条规则就统一在这个系统里做执行，这样就能够实现通用的变更规则校验需求。
但是现在是2026年，是一个全民养虾的时代，以前花大力气编写的规则跟系统，不用Agent打平一遍，那怎么着都得out了。所以本文也基于这么个场景，在已有变更规则校验的标准业务流程基础上，怎么研发一个规则校验Agent，去讨论一些思路。
稳定性保障是后端架构演进这件事情上不可缺少的部分。对于不同业务来说，稳定性可能有不同的口径，治理策略或目标也因业务规模大小或服务场景而各有差异，但共性仍然是存在的，讨论起来也逃不过SLA、可用性或者Latency之类的名词。在先前笔者关于稳定性基础保障以及OOM问题排查相关的文章中，已经提到了许多重点稳定性问题的解决措施。所以今天这篇文章，就换一个视角，以一个宏观问题解决者的角度，来聊聊治理后端稳定性的一些实战经验。
LLMAgent应用研发在当下是一个非常热门的话题，目前一个典型的趋势是，各类垂类领域都在思考LLMAgent如何能够代替人力，为其业务场景赋能，一方面是常规提效，另一方面是深度挖掘CornerCase。恰巧笔者最近在做变更风险防控领域LLMAgent应用的技术调研，所以今天这篇博客，也简单分享一下调研来的一些思考。
主要分两个部分，第一部分是LLMAgent可以用在变更风险防控的什么环节，第二部分是系统化落地需要考虑做什么事情。
近期笔者在投入变更风险防控开放平台的额外功能开发，目的是希望设计一套更加灵活的变更风险观测策略匹配机制，能够在满足面向任意变更场景应用观测策略的同时，尽可能保证产品体验，让用户清晰地了解到自己配置的什么策略能够在什么情况的变更过程中生效。在先前的文章当中，有粗浅提到变更观测策略匹配的事情，但没有深入探究，并且笔者以前接手的项目，很多底层设计的技术债也难以偿还，要在以前实现的基础上再做重构也不是很现实了。
所以，趁着扩展新系统的机会，笔者重新思考了下变更风险观测策略匹配机制的事情，跟随这篇文章来抛砖引玉下自己的想法。
首先，还是一个根本问题，一条变更风险观测策略的粒度是怎样的？如果粒度太粗，那么从产品视角，很容易导致「所见非所得」的问题；如果粒度太细，那么用户配置起来也会相当麻烦。经评估，由单个检测能力执行的粒度代表一条策略，这样的形式相对合理，不仅方便产品层面做「所见即所得」的设计，而且实际执行过程中，也可以以原子化的形式做编排，从调度角度来讲也很容易扩展。
详细来讲，一条策略在设计上，需要关联以下几类概念：