故障，是每个技术人都不愿遇到，但却总会遇到的事件。程序Bug、安全漏洞、黑客攻击、服务器宕机、网络中断等诸多因素都有可能引发系统故障，使我们的业务面临瘫痪的窘境。这样的例子，国内外都在不断的发生，比如：
2020年，由于严重的全澳性IT故障，Coles的收银机全部不能联网，down机瘫痪。收银员扫不了货品顾客也不能结账，澳洲每家Coles超市都被迫暂时关闭。
2018年，上海的医疗保险信息系统就突发故障，波及上海各大医院的结算系统，致使大量市民在就医时无法正常使用医保卡，众多医院的排队窗口前纷纷大排长龙，场面混乱。事发之后就有不少网友质疑，涉及面如此之广的医保信息系统，“难道没有应急措施？”
这些活生生的真实案例都在提醒我们，技术赋能业务产生更高效率、获取更多价值的同时，保障系统稳定运行也至关重要。一旦系统出现大范围、长时间故障，致使业务中断的后果可能直接磨灭技术赋能带来的收益，甚至还可能带来经济损失、品牌受损等严重后果。
所以，有必要给我们的系统上一份“保险”——构建高可用的系统架构，这是每个技术团队都在努力的核心目标。
那么怎么样的系统是否具备高可用能力的呢？我认为主要考量两个方面：容错与容灾。
容错能力指的是当故障来临时，业务系统是否可以不中断，继续服务的能力。常规措施就是集群化部署，同样业务的应用部署多台服务器，即时有个别服务坏了，其他服务依然可以提供业务支持。这就像飞机配置多台引擎一样，即时有一台坏了，剩下的依然可以支撑它飞行到指定地点安全着陆。
容灾能力指的是当重大灾难来临时，容错能力已经全部失效了，但我们依然有能力通过一些手段让业务重新恢复。常规措施就是备份，当某个机房发生了严重的故障，所有服务器都无法正常工作了，但数据备份还在，那我们就可以重新加载它们并让系统重新运行起来。这就好比飞机上的引擎全部坏了，但为了保证飞行任务以后还能执行，必须提供保护飞行员逃生的装置，比如通过弹射跳伞的方式令其可以幸存下来，之后又继续再其他飞机上继续执行任务。
首先，在构建高可用系统之前，我们要对故障有几个基本的认识：没有任何一个设施是100%安全可靠的。所以，一个系统在设计高可用架构的时候，复杂度随涉及的设施的数量增多而变高。
其次，我们需要尽可能的精简运维体系。简单的说，上云是大部分企业的最佳选择。除非自身团队在同预算的情况下，能够在基建维护上达到相同乃至更高的可用性。不然你机房建设、服务器、网络等基础设施的维护可能都将要你半条命。
再者，必须平常心对待可用性保障，这个道理就不多说了。意外总是在发生，翻翻过去的那些故障，是不是都还历历在目：
2022年6月，Cloudflare的意外中断导致大量热门网站访问出现问题
2021年12月，AWS大面积故障导致大量网站无法服务，亚马逊电商也遭受重创2021年5月，IBM Cloud在短短5天里连续发生两次严重的中断事故
2020年3月，Google Cloud多个地区的云服务瘫痪，时间长达14小时
2019年2月，Google Cloud因光纤受损出现网络问题，时间长达10小时
2018年4月，Azure因受雷雨天气影响导致电压激增而中断服务，时间长达28小时
但是。正因为没有100%的无故障，我们才要用高可用，因为这是唯一挽救你造成巨大财产损失的机会。
最后，我们不得不正视一个云服务用户的常见误区。当我们选择云服务商的时候，需要明确云厂商到底给我们提供了哪些高可用能力，而剩下的高可用能力覆盖是需要我们自己设计和实现的。我们要知道，一个高可用系统的构建是贯穿基础设施、中间件、服务端、客户端等多方面的。对稳定性高度敏感的企业一定要平常心看待故障 ，用好高可用。
（下图展示了云服务厂商和用户的高可用上的责任模型：云服务商提供的主要是基础硬件服务的高可用能力。而我们之前所提到的业务容错（负载架构）、容灾（保障数据备份）能力都是在用户侧的。供参考）
所以，如果在上云的时候，对自身业务系统不做额外的高可用保障，那就很可能出现文章开始我们提到的那些业务窘境。
今天跟大家聊了聊系统上云时，容易被忽略的高可用问题，以及如何做好云上高可用架构的方法。对此你有什么想法呢？留言区一起聊一聊。
欢迎关注我的公众号：程序猿DD。第一时间了解前沿行业消息、分享深度技术干货、获取优质学习资源