弹力设计三大纪律，怎样让稳定性KPI高大上？

如今这个年代，提到弹力设计、高可用、稳定性、容灾容错、业务连续性这些。生产环境已经有大量业务流量在跑的服务，重构这种解决方式，肯定会被大局观的上级拍死在沙滩上。那还有什么可做的呢？今天就来聊一聊。

三大纪律

第一，流程规范

第二，刨根问底

第三，定期梳理

流程规范

曾经有一个业界影响很大的事故，原因是一个程序员小哥哥自认为做了一个没有风险的优化，没有和其他人沟通就上线了。他是周一上线的，问题到了周五才引起问题，所有的人都不了解两件事情的关系。直到大家绝望的把整个部门一周内上线的所有代码全部回滚才解决。最终的损失不止是那几千万，还有负面舆论的损失。

这是一个流程要规范的典型例子。实际上，工作上经常会面临这样的问题：一个人评审另外一个人的代码，他看到了和这次修改无关的不爽的地方，非要人家改，不改不给过。我不赞成这种做法，如果有些地方写得不好，应该系统性全面梳理评估其影响之后再重新立项做决定。而不是作为CodeReview的人有权决定让别人改的。

这些真正起到效果的措施方法，写到KPI里怎么能变得高大上呢？还记得《阿里巴巴Java开发手册》吗？把这些历史上的踩坑总结成全公司要遵守的规范，甚至是做成插件或者工具，让全公司都能避坑，这一定是大大的业绩。要是得到业界的认可，下半辈子不用愁找工作了，创业也会有很多人投资。

刨根问底

有个代价惨痛的故事。一个开发小哥哥接收了一个非核心服务的代码，这个代码有bug需要解决。这个服务的技术栈和其他不一样，确实是难为开发小哥哥。他发现定时任务一跑就会出异常，他会做了一个自认为没有任何风险的修改：将异常捕获。然后就上线了。这段代码堵塞了全公司的发布平台，其他项目都发布不了了。这件事的一个教训是做事要刨根问底，先弄懂再动手来做。

刨根问底是个理念和方法，不是具体措施，怎么落实到KPI里呢？别着急，咱们先看最后一个纪律，结合一起来谈。

定期梳理

还是一个悲伤的故事。架构师刚被调到这个项目组就专业而负有责任的梳理了所有的代码，并发现了一些问题。当时评估影响不大，变更的话影响反而很大，所以没有做出任何措施。这个问题在数据库升级时，1/3的数据库被停掉时被触发，造成了严重的影响。

这里的一个教训就是要定期梳理自己负责的系统。包含代码、业务流程、架构、监控告警和历史遗留问题。自己对系统的深刻掌握才是自己在团队中的核心竞争力。

这里有个令人惋惜的事情，道理就是华佗和他两个哥哥的故事。华佗是救火队长，总治疗大病，被大家熟知。他的两个哥哥，一个比一个能更早发现了病情，防患于未然。却没有那么有名。

我也为此迷茫过，自己被大家知道也因为之前接手过一个有重大稳定性问题的项目，做了飞行中换引擎的事情。后来，我总结了一些经验，让项目不再达到如此程度，提前做了。反而好像什么都没做。这其实不是没做好，而是没说清楚。说清楚的提前是理解清楚，如果能做出合理的推演，让大家了解到如果不处理将造成的后果，业绩也能体现。

问题又回来了，这个需要高大山的稳定性KPI怎么做呢？答案还是总结。定期梳理系统，对梳理出来的问题进行推演，说明改进的必要性和价值。一展开要做的事情就多了。但是开头就说了，生产环境有用户在用的不建议重构。但是如果有新业务，是可以拆分出新项目来做的。这是最标准的隔离术。老业务追求稳定，不进行变更。新业务快速支撑，高扩展。这就需要一个完整的架构方案啊，还愁KPI吗？

业务做到一定阶段，都可以和AI合作。业务追求稳定性，需要限流、熔断等稳定性保障措施。业界实际使用中的都是静态设置规则和阈值。实际上完全可以和AI结合，采集监控数据，动态调整策略。追求稳定性，为避免误判风险，一般这种系统只会作为旁路。策略在实时链路生效要经过人工审核确认。这种系统需要持续投入，而一般来讲，真正产生回报需要一年以上的时间。