在任何一家互联网公司，应用的迭代速度都是非常快的。尤其当下，市场竞争恨不得用秒来计算。先发优势非常明显，大家争先代码以最快速度触达用户。但这极容易引发一些为了快速迭代而舍弃掉比如规范上、标准化上、兼容性上的问题，从而导致技术债务。随着业务发展，那么后续会逐渐的对应用的稳定性，要求比较高，这个时候，我们如何对之前的技术债进行修复治理，如何梳理出一套标准化的流程？
万事没有绝对！我们只能在一条水平线上下取舍
需求背景
为了解决一些历史问题or技术债务，这里我列举其中一个场景作为例子：
- 我们通过定时跑脚本的方式，过滤出不符合规范的SQL，慢查询等等。
- 汇总邮件，发送至责任人。
- 待责任人邮件确认后，进行工单指派，等待问题修复。
- 修复完成，关闭工单。
规范治理平台可以对所有的数据进行展示。这样带来的第一个问题就是，不规范的点，可能是日益增长的，现阶段我有三个，后面有新增那么平台需要配合一次编码
需求目标
设计不是落地了就结束了，也不意味着设计出来了，就是一定合理的。他是否会给日后的维护带来一定成本？设计是否最大程度合理化？
一个优秀的SRE，应该懂得如何为团队做减法，而不是为了解决一个问题从而衍生出另一个问题！
这也正符合规范平台落地的意义所在！减少技术债务
如何设计？
首先站在运维开发的角度，我们不可能每增加一个场景都进行一次编码，我们希望编排的动作和开发分离开，这样新增时无需和运维开发沟通，减少沟通成本。那么存储的字段运维开发也不需要关心，由编排人员自行控制，所以新增场景的流程大致如下：
这样设计的优势
- 场景可配制化，动态增加
- 字段灵活，更能覆盖多种场景下的数据多样性
- 减少沟通以及维护成本
