作者：王晔倞 链接：https://dbaplus.cn/news-141-2712-1.html 上个月，我们某个产线系统遭遇了一次数据库宕机事件，整个控制台服务停止响应近一小时。
事后复盘，在场所有人都觉得不可思议，为什么呢？因为MySQL是双主互备模式，如果一台数据库挂了，应用服务应该是无感知才对。怎么会把整个服务都搞挂了呢？
经过排查发现，虽然MySQL运行在双主互备模式之上，但为了节省资源，测试环境部署的是MySQL单节点，可能运维在发布的时候不知道要修改JDBC连接模式，直接在配置文件中搞了个直连单节点，就丢到产线上去了。
发布后，业务与开发都进行了功能性验证，自然都顺利通过。
直到在产线跑了一年后，数据库主库挂了，服务停止响应了，大家才发现。
说完了数据库，再说一个与应用服务器有关的案例。
上周的某个工作日，工作群里突然一阵大乱，有的人说OA系统卡死，几秒种后被抛到了登录界面，而有的人却说一切正常。
起初，大家都认为是网络抖动，或者是神打了个盹。但我不信邪，追查了一通，结果发现了蹊跷。
原来是某位运维的小伙伴，为了扩充资源，在没和任何人打招呼的情况下，直接重启了某台物理服务器，导致上面的近十台虚拟机受到影响。
OA系统采用的是双节点模式，其中的一个节点恰巧部署在这台机器上。
问题来了，抛开人为故障的缘由不谈，既然是双节点，为什么一个节点挂了之后，有些用户会有感知呢？
经过排查发现，两个Tomcat节点并未开启Session共享，所以才引发被重启的那个节点Session丢失，从而导致用户被抛到了登录界面。
为什么“理论高可用”屡禁不止？
我曾经多次在技术社交场合，与一些CTO、VP及架构师，甚至一线开发聊起过类似话题，但他们似乎都觉得这样的话题压根没必要讨论。为什么？
因为在他们眼里，发生这样的事完全是经验、能力与责任心的问题。
在我看来，经验多、能力强与责任心高的人才是可遇不可求的，尤其对那些中小型企业，无论成本还是规模，都不具备吸引这些人的属性，就算你有幸拥有几位这样的高手，基本也都被投入在业务一线的阵营中，不仅每天琐事缠身，忙得脚打后脑勺，而且还要顾及团队成员的成长，除非是一些重大技术决策与实施，一般不可能每件事都亲力亲为。
所以，当某位小伙伴突发一些所谓的 “技术疏漏” 事件，只要不把公司搞死，从情感上还是可以接受的。
扯完大道理，我还是结合自己的经验来谈谈。
连下盘都不稳，还扯什么高可用？
在健身圈里，有好多健身者只练上肢肌肉，不练腿部肌肉。这也可以理解，毕竟健身是一件非常枯燥而急需自律的事情，你花同样的时间和精力，腿部肌肉再发达，也不得不套在衣裤里，秀给谁看？但是手臂肌肉就不一样了，你穿短袖的时候，手臂肌肉可以露出来，穿长袖时，手臂肌肉也能透过衣物显现出轮廓来。
但那些健身老司机都明白，如果你不练腿部肌肉，时间一长，你的身材就像《神偷奶爸》中的格鲁一样，不仅缺少美感，而且还会影响上肢的训练。
你想，所有的上肢训练都需要压在两条腿上，下盘不稳，怎么玩得起来？
因此，我们常说：“要练上肢，先稳下盘，只有下盘稳了才是真男人！”
同样的道理，一套系统，一套稳定的系统，一套稳定而高效的系统，就好比一个人的身体，上肢是应用，下盘是基础。
在追求 “快速迭代” 的今天，业务功能的 “快上线，别出错” 似乎变成了标准配置，也成为了衡量技术团队价值高低的一把尺，但这背后需要有强大的基础服务支撑，而这些基础服务却需要大量的金钱、精力的投入。
设想下，想要获得资源的投入，就需要得到决策高管们的认同。
假如你跟老板说，给我加100个人和100台服务器，我能搞出几个爆款功能，只要你曾经有不错的业绩，外加与老板之间有信任的基础，估计这事就成了。但假如你跟老板说，给我加100个人和100台服务器，我要对DevOps平台进行改造，相信很多老板都会问：“啥意思？啥叫DevOps？这对我的业务增长能带来什么帮助？”，你随即挺直了腰板说：“肯定有帮助啊！IT投入是一种价值投资！”。
想必很多老板都会愤然站起，并对你来一个手势：“Get Out！”
这叫 “秀才遇着兵，有理说不清” ，这也正常，一来是很多IT人的口舌普遍都很笨拙，想举重若轻地把一个技术问题给没有技术背景的领导说明白，比登天还难，二来是在一家业务驱动型的公司里，如果你想通过数字化的方式，呈现出技术投入和业务收益之间的量化关系，那你的抗击打能力要强，否则你会很容易精神崩溃。
长此以往，系统的发育变得畸形，像极了一个 “只练上肢，不练下盘” 的健身者。
平时穿着长裤，露着带有肌肉线条的手臂，看似一切都很正常，但对方给你来个扫堂腿，立马摔个四脚朝天。
不过，这些很多公司的技术负责人都不承认，不信你随便找一家公司的技术负责人来问，你们公司的系统高可用吗？他一定会拿出一堆图和数据，告诉你，我这里固若金汤，啥事没有。
但跟你混熟之后，或者你直接进入内部一看，基本都是千疮百孔，摇摇欲坠。如果你非要寻其根源，基本就是 “缺钱、缺人、没时间”。
想搞随机故障测试？歇着吧
在这篇 #讲个 '理论型' 高可用架构的故事给你听# 的文章里，我有提到想学 “饿了么” 搞随机故障测试，结果怎么样呢？
搞了一次，大家都觉得有点鸡肋，放弃了。
咦？为什么呢？先来晒一下当时的方案。
在决定启动做这件事之前，我们先明确了3个目的，一是论证是否存在理论高可用，二是验证是否能快速发现问题，三是当发现问题之后，是否能快速解决问题。然后再确定了3个测试场景，一是随机断网，二是随机断电，三是随机弱网络。
一切就绪，拿什么系统开刀？直接在产线上搞嘛？
有人提议拿交易系统，而且必须上产线，否则没有意义，话音刚落立即有人反对，理由也很犀利，“出了事怎么办？你确认没问题吗？”
一群人没经验的人，你看我，我看你，无法回答，算了，放弃。
那就拿某非交易系统，在仿真环境搞吧。问题来了，虽说是仿真系统，但无论是应用节点数量，还是服务器性能配置，都与产线有很大不同。比如数据库，仿真系统就是只有2个节点，一主一备。
就在要进入僵局的时候，我提议：“既然大家都没经验，要不就先试试看，然后咱们基于实践再来复盘。”
赞同，当天晚上就风风火火地搞起来了。结果如何？一切正常。
无论是应用，还是数据库，乃至中间件，轮流断网、断电及网络丢包，只要还有一个节点活着，似乎业务都能正常访问。
瞧瞧，咱们的系统太高可用了。
有句话说得好，“来得早，不如来得巧”，就在我们随机破坏测试执行后的第二周，被测系统就在产线来了一场罢工，原因是某节点宕机之后，负载均衡策略没有生效，导致部分用户收到404。加q群：478052716 免费领取（Java架构资料，视频资料，BATJ面试资料）
咦？不是随机破坏测试的时候测过吗？通过排查，才发现NG的配置与环境部署，生产与仿真完全不同。
从结果看，这一记耳光很响亮，对大家的打击不小。
在复盘时，有人提出，我们重新梳理仿真环境，无论配置、节点、部署，都改成与生产一样，并在仿真环境按生产环境要求添加监控。也有人提出反对，觉得与生产同步完全不可能，人力和物力都不允许，何况我们的仿真环境是用来做业务验证的，如果用它来承担随机破坏测试，会不会对业务部门产生影响？另外，这才刚刚触碰到非交易系统，如果是交易系统，又该如何去做？
最终，大家都觉得必须在生产上做，这件事情才会有意义。但该怎么做？
在服务、环境、灰度及监控不完善，经验不足的情况下，这个课题还要不要继续下去？
还是歇了吧，等条件成熟的时候再做吧。
再牛逼的经验，也挡不住客观环境的变化
我曾问过很多人，为什么你们费尽心思要招有经验的人？回答基本一致。
一是探测地雷，仰仗他的经验，能避免他曾经踩过的坑不在这里重现。二是降成提效，仰仗他的经验，能够用更少的资源、更快的效率达到目标。
更重要的是，我们期望这些有经验的人，能够慷慨地将自己的经验传授给那些经验尚浅的年轻人，从而达到团队整体实力提升的效果。
想得挺好，效果怎么样呢？
在我的经历中，无论你请谁来，无论你怎么为他配备资源，放心，他曾经踩过的坑还是会在这里重新踩一轮，那些栽过的跟头也继续要栽一次，甚至踩得更深，栽得更狠。
这是为什么呢？
当然，不排除我身边都是一些倒霉鬼，或者引进的人都是水货。但相比之下，我更愿意相信是因为客观环境因素的不同，从而导致原有经验的可落地性变差。
怎么理解这句话？我来说个亲身经历的案例。
去年，我写过一篇 #故障：一场由虚拟化存储引发的分布式缓存性能悲剧# 的文章，详细描述了一次由虚拟化存储引起的分布式缓存故障。
在文章发布后的第二周，就曾有读者提出质疑：“核心中间件，居然出现如此小儿科的故障，你们上线之前不做高可用与性能的测试吗？”
我的回答是：“我们不仅在上线初期做了非功能性混合场景测试，而且每周还会做常规性压力测试。值得一提的是，代理层的核心代码是团队中某架构师从以前公司带来的，声称这套系统曾经历过 “双11” 的洗礼，流过血，流过汗，值得信赖。
无论怎么想，似乎都会相信这套系统是可靠的、高效的。但万万没想到，在稳定运行很长一段时间后，却无声无息地死在了I/O争抢上……
因为事故的影响范围太大，在事故复盘的过程中，业务方老大吐槽，“我平时偶尔也参加你们的技术评审会，最常听见的词就是 ‘高可用’、‘高性能’，看了大家是很重视的，也确实做了很多工作，但为啥一遇到实际场景，就不奏效了呢？”
我当时正在气头上，直接回了句，“是啊，我也想知道啊，等明天我打个电话问问服务器，为啥他突然间发脾气，不高可用了。”
就因为这件事，整整一周，团队的士气都很低落。
事情过去一个月后，我请团队小伙伴喝酒，一来缓解下情绪，二来提升下士气。
酒桌上，我端起酒杯走到那位负责缓存的架构师面前，说：“别一脸颓废，搞咱们这行遇到这种事情不是很正常吗？一切都过去了，后面咱们再慢慢改进。”
他笑了笑，端起酒杯站起来，说：“哎……我一直对这套系统很有信心，没想到出这种事，觉得太丢人了，搞得好像我只会耍嘴皮子似的。”
我拍了拍他，说：“别担心，下次神会与你同在。”
自从有了互联网+这个名词之后，似乎到处都能看到或听到各种高可用架构，并且还会有个看似很牛逼的人告诉你这个系统架构多么牛逼，用某某框架你的系统就会起飞，但仔细想想，这对你来说有用吗？
因为他们只给你指了一扇门，告诉你通过那扇门你就有多牛逼，但钥匙在哪里呢？而且也没有告诉你，在走到那扇门之前，用什么方法才能把我从现有的坑里拽出来？
记得在某技术大会上分享的结尾词，我说过这样一段话：
为什么别人的高可用架构，用到我这里不起作用了呢？
因为真正的高可用压根就不用纠结架构设计，更不用纠结是否有大厂用过，对于一般的企业来说，只需要把注意力放在代码的健壮性、主备设计及环境治理上就行了，不需要其他的。
忽略了这几点，还谈什么高可用呢？