韧性技术系统：别等系统崩了才想起造这张「安全网」
上个月跟做互联网金融架构的老炮喝酒，他吐了一肚子苦水。今年开春他们核心支付系统崩了四十分钟，全公司赔了两千多万，还差点丢了那个占全年营收三分之一的大客户。
酒过三巡他说，以前做架构，老板天天催着提性能降成本，韧性这种东西，放在立项表最末尾，连预算都砍一半。这下好了，一次故障，把三年省的钱全赔进去了。
韧性技术系统分层故障隔离架构图
说实话，很多公司现在做的容灾，都是「纸面容灾」。真出事了要运维手动切流量，输错一个配置，就直接变成更大的事故。韧性技术系统不一样，它是自动感知、自动恢复的。不需要人发号施令，它自己就把故障隔离了，把流量切走了，甚至能边跑边修。
全球关键基础设施网络攻击事件统计柱状图
不过话说回来，很多中小公司老板一听到这个词，第一反应就是「这是大公司玩的东西，我们小公司哪有这成本」。
真不对。韧性是一种思路，不是非要砸几百万堆设备。你一个做生鲜电商的小小程序，高峰期的时候把非核心的用户积分抽奖功能临时降级，先保证核心的下单支付能用，这就是最朴素的韧性。你把核心数据做个异地备份，哪怕服务器被雷劈了，你还能找回来，这也是韧性。不是说非要做多活多可用区才叫韧性技术系统，对吧？
做韧性技术系统，最容易踩的三个坑
我接触过不少做架构的朋友，踩过的坑一箩筐，挑几个最常见的说。
第一个坑，为了韧性而韧性，盲目堆冗余，成本翻番没用处。我去年见过一个拿了A轮的创业公司，融了点钱就飘了，上来就做三个可用区多活，一年基础设施成本直接从一百万涨到四百万，结果他们全年的业务峰值，还不到设计容量的十分之一。纯纯交智商税。韧性是跟着业务风险走的，你核心业务一年流水一个亿，和一年流水一百万，需要的韧性完全不一样。
第二个坑，只按脚本测故障，不测黑天鹅。很多公司做容灾演练，都是提前说好「今天我们关A节点，大家看好了切B」，每次演练都满分。真出事了，谁跟你按剧本走？去年有个客户，DNS服务器出故障，整个切流流程没触发，本来只是一个小节点坏了，最后变成全系统崩了三个小时。这不就是演习惯了脚本，真打仗就懵了吗？真正的韧性演练，就得搞突袭，就得测那些想不到的情况：整条光缆被挖断怎么办？跨机房延迟突然飙到500ms怎么办？云厂商给的存储服务挂了怎么办？多摔几次，系统才能真的硬起来。
第三个坑，把韧性全扔给技术，砍了人，最后没人兜底。我见过不少公司，做了自动恢复之后，觉得运维没用了，把运维团队砍了一半。结果自动恢复出bug的时候，连个能上手改配置的人都没有，眼睁睁看着系统崩十几个小时。说白了，技术是工具，韧性最后还是要靠人来补漏洞。机器不可能想到所有情况。
前阵子跟清华计算机系的一个教授喝茶，他说现在国内做韧性技术系统的科研，很多方向都追上国际水平了，接下来十年，「韧性」会变成所有技术系统的核心评价指标，比性能、比成本都重要。
我深以为然。你一个系统做得再快再便宜，跑着跑着突然没了，有什么用？
人无远虑必有近忧，系统也是一样。别等崩了，才想起给自己织一张安全网。
什么才是真的韧性技术系统，不是不死，是死不透
很多人一听到「韧性」两个字，第一反应就是不就是多备几个服务器做容灾吗？不对。那只是最基础的操作。 真的韧性技术系统，核心从来不是追求「永远不出错」——那根本做不到。它追求的是，出了错之后，别把整个业务带沟里。 你可以把它理解成系统的免疫系统。你割个口子，身体自动凝血，不会让你因为流点血就死掉。哪怕你切了一个肺，剩下的那个还能支撑你正常生活。这就是韧性。 换成技术场景就是，你的电商平台某一个商品详情页的服务挂了，不能让整个支付结算也跟着垮。某一个机房的光缆被挖断了，用户顶多刷首页慢两秒，不能直接全平台404。 去年春运12306的高峰峰值，每秒超过60万张票的查询请求，放在十年前，服务器早就集体冒烟了。现在改完韧性架构之后，就算三个节点同时故障，用户也只是需要多刷一次，不会完全登不进去。韧性技术系统分层故障隔离架构图
说实话，很多公司现在做的容灾，都是「纸面容灾」。真出事了要运维手动切流量，输错一个配置，就直接变成更大的事故。韧性技术系统不一样，它是自动感知、自动恢复的。不需要人发号施令，它自己就把故障隔离了，把流量切走了，甚至能边跑边修。
为什么现在突然所有人都在聊韧性技术系统？
放在五年前，搜这个关键词，都没几篇论文。现在呢？云厂商开发布会必讲，政企做项目招标，第一条款就是要求符合韧性技术规范。 为什么突然就火了？ 最直接的原因，现在业务对系统的依赖度，已经到了输不起的地步。放在十年前，你一个电商网站崩半小时，大不了少卖几十万，用户第二天还来。现在呢？直播带货大促的时候，推流系统崩十分钟，主播要解约，品牌方要索赔，平台掉粉几百万，损失是链式反应，一环接一环。 还有最近两年，全球范围针对关键基础设施的网络攻击越来越多。能源、交通、金融，哪个系统出问题，影响的都是民生。去年欧洲多个国家的电网遭网攻，断供好几个小时，损失几十亿欧元。国内现在对关键信息基础设施的安全要求，早就从「被动防御」转到「主动韧性」了。 Gartner去年出的报告说，到2025年，75%以上的企业关键业务系统，会要求把韧性架构作为必备建设要求。这个趋势，挡都挡不住。全球关键基础设施网络攻击事件统计柱状图
不过话说回来，很多中小公司老板一听到这个词，第一反应就是「这是大公司玩的东西，我们小公司哪有这成本」。
真不对。韧性是一种思路，不是非要砸几百万堆设备。你一个做生鲜电商的小小程序，高峰期的时候把非核心的用户积分抽奖功能临时降级，先保证核心的下单支付能用，这就是最朴素的韧性。你把核心数据做个异地备份，哪怕服务器被雷劈了，你还能找回来，这也是韧性。不是说非要做多活多可用区才叫韧性技术系统，对吧？
做韧性技术系统，最容易踩的三个坑
做韧性技术系统，最容易踩的三个坑
我接触过不少做架构的朋友，踩过的坑一箩筐，挑几个最常见的说。
第一个坑，为了韧性而韧性，盲目堆冗余，成本翻番没用处。我去年见过一个拿了A轮的创业公司，融了点钱就飘了，上来就做三个可用区多活，一年基础设施成本直接从一百万涨到四百万，结果他们全年的业务峰值，还不到设计容量的十分之一。纯纯交智商税。韧性是跟着业务风险走的，你核心业务一年流水一个亿，和一年流水一百万，需要的韧性完全不一样。
第二个坑，只按脚本测故障，不测黑天鹅。很多公司做容灾演练，都是提前说好「今天我们关A节点，大家看好了切B」，每次演练都满分。真出事了，谁跟你按剧本走？去年有个客户，DNS服务器出故障，整个切流流程没触发，本来只是一个小节点坏了，最后变成全系统崩了三个小时。这不就是演习惯了脚本，真打仗就懵了吗？真正的韧性演练，就得搞突袭，就得测那些想不到的情况：整条光缆被挖断怎么办？跨机房延迟突然飙到500ms怎么办？云厂商给的存储服务挂了怎么办？多摔几次，系统才能真的硬起来。
第三个坑，把韧性全扔给技术，砍了人，最后没人兜底。我见过不少公司，做了自动恢复之后，觉得运维没用了，把运维团队砍了一半。结果自动恢复出bug的时候，连个能上手改配置的人都没有，眼睁睁看着系统崩十几个小时。说白了，技术是工具，韧性最后还是要靠人来补漏洞。机器不可能想到所有情况。
前阵子跟清华计算机系的一个教授喝茶，他说现在国内做韧性技术系统的科研，很多方向都追上国际水平了，接下来十年，「韧性」会变成所有技术系统的核心评价指标，比性能、比成本都重要。
我深以为然。你一个系统做得再快再便宜，跑着跑着突然没了，有什么用？
人无远虑必有近忧，系统也是一样。别等崩了，才想起给自己织一张安全网。