架构治理事故复盘
一、架构治理事故简述
废弃接口治理专项在经过平台前置校验和风险评估后，选择了通过飞书推送卡片给用户，逾期自动合入MR的策略。
- 平台前置校验
* 平台监测无流量120天 → 用户确认下线 → 流量灰度拦截 → 流量正式拦截 → 生成IDL接口下线MR
- 风险评估
- IDL codegen代码场景，编译阶段提示接口不存在，不会影响线上服务
- 泛化调用场景，小流量上线阶段调用异常触发告警，不会造成线上高危影响
这次事故是由于未考虑到Codebase的IDL仓库有重定向所导致的IDL被多PSM复用的场景，导致删除PSM A废弃接口的同时，删除了与其共用IDL的PSM B的的接口。且IDL自动合码后，依赖PSM B的上游是定时拉取IDL最新版本进行泛化调用，没有小流量灰度阶段，导致事故发生。
二、治理原则-效率 OR 稳定性
架构治理是一项在不改变系统原有功能的基础上进行的配置、IDL、代码、流程等方面的治理，旨在优化系统架构，提升系统稳定性、系统性能、研发效率。但架构治理有些专项工作的收益偏长期、业务不受益甚至要承担风险，比如废弃接口下线。
这种优化项如果作为既定目标确定要去推进，但是研发不受益导致配合度不高。就废弃接口下线来说，通过前置校验和风险评估后，从客观来讲，采取消息通知和逾期系统自动操作的方式是比较理想的。但由于这里面弱化了用户的响应，虽然提高了效率，可以达成更大、更激进的目标，但是一定程度上会有稳定的风险。一旦出现事故，整套流程就是备受质疑的点。
在实现目标时，效率和稳定性上偶尔会有冲突，目标越激进越冲突。从执行者角度来看，我起初出于目标管理和理性判断决策了自动合入的策略，但是事故之后，由于未感受到有容错机制，所以决策思路转向为稳定第一，以后的所有方案要满足程序正义。执行者没有得到制度上的容错，只能以制度作为功能设计的第一原则，不会再去量化和权衡效率、风险、稳定性，即便一个高效率方案的事故风险为千万分之一，也选择放弃。
缺乏容错和稳定第一，恐怕就是各大公司内缺乏创新的一个原因吧。我虽不愿，奈何不系之舟随波浮沉。乐观来看，自动合入导致的事故，只能说是个坏的决策结果，而不能说是坏的决策。
三、治理目标-架构治理目标管理
团队和专项目标在遇到事故后，会调整稳定性的权重。由于近因效应和记忆易得性会影响事故概率的判断，会导致把稳定性的权重调增的过高。尤其是在没有机制容错的情况下，团队行事准则会变成目标和事故双导向。此时会自下而上，调整架构治理目标，降低预期。比如，审慎的砍掉所有看得见的有风险的事项，毕竟哪个团队也不想短期内出现2次事故。
目标会自底向上进行传导，逐级向上修正预期。最坏的结果是与顶层目标冲突，或者逐级修正后收益小和进展慢导致价值低估，最终导致架构治理项目停滞。转而把人力投入到短期有益、低风险的事项中去，但是当真的决定去做这样的事时，需要先问下，你真的找到这样的事了吗？还是陷入了指标陷阱，追逐数据而非解决问题。
四、方案评审-邀请拥有更多信息的人
见关于会议
五、流程设计-架构治理和程序正义
当无容错机制时，程序正义是唯一选择。任何通过量化手段得到的低风险评估，在事故面前都苍白无力。程序正义体现在通过卡点转移责任、通过流程体现合规、避免质疑和挑战现有的流程、不做优于少做、少做优于多做、不出问题优于解决问题。
程序正义的褒义体现在它保证了正常流转的下限，但同时僵化了流程。如果期望通过公司文化的务实创新、敢为极致等口号来解决此类问题，只是空想。响应口号需要承担打破流程、流程失灵的风险，风险由执行者承担，那么文化就只是一个大家心照不宣的笑话，无人会去遵守。
六、事故定责-制度的容错机制
制度容错是指，意识到系统的复杂性，在复杂的系统中做的一些事情会有一些固有风险。意识到风险是客观存在的，无论事务的执行者是谁都无法避免，那么在制度层面给与容错，才能保持创新的持续存在。
七、事故流弊-奖惩细则决定做事原则
事故流弊是指事故定责的影响。因为事故对绩效的影响，事故复盘会上往往会陷入立场争辩，而非问题求真。大家各执一词、拼声量、拼程序正义，最大程度上说着无法被证伪的谎言。事故定责，是关键事项的关键反馈，会影响个人和团队在后续做事上的原则，短则影响个人在当前公司的时间，长则影响个人的整个职业生涯。
结语
先求存，再求真。