从运维和 SRE 的不同说起
IT 运维这个概念是 ITIL 框架中的概念，SRE 并不属于这个概念体系中。在ITIL 的官方文本和主流实践中，SRE 被视为一个来源于Google的、与 ITIL 互补的现代运维实践体系。
传统运维岗位主要追求运维操作执行的效率提升，而 SRE 则更关注操作对线上环境的影响是什么。对于系统稳定性要求高的行业都需要 SRE 这样的岗位对运维风险进行体系化控制。
风险控制策略不同
首先，ITIL 体系中，制度和流程是风险控制的最主要方式，而 SRE 体系中则是通过数据反馈出来的对系统的影响来驱动风险控制。其次，ITIL 中的故障演练更多是从业务连续性的角度，演练应急协作流畅度等，而 SRE 体系则更注重技术架构的韧性，即通过混沌工程等工具，在生产环境注入故障的方式验证系统的弹性和容错性。
风险防控架构模式
风险防控作为操作行为的影响评估系统，跟变更执行并行，将风险触达到正确的人，本质上是一种服务。国内蚂蚁将其称之为 TRaaS，将风险防控作为一种服务，面向运维平台提供风险感知和控制服务。
风险防控服务的能力边界
这里大家通常会产生一个认知误区，我这个平台接入了风险防控服务，是不是就可以做任何操作都不会引起故障了。准确来说，不是的。风险控制的目标不是杜绝任何故障的发生，而是让运维操作的结果从不可控变得可控。以杜绝任何故障的发生为风险防控工作的目标不现实，也不经济。
如果以 0 变更故障作为导向，则大家则会最大限度去规避变更，这样一次变更则是一次大版本升级，很容易造成灾难级别故障。实际的做法是通过故障预算的形式，通过权衡稳定性和创新性，确保有一定的灵活度。
简单来说，平台是道路和交规，变更人是司机，总之，平台基于硬性规定做自动化检查和数据支撑，人做最终的决策。
如何证明平台的机制
混沌工程演练，待续