10月23号下午，语雀凉了，而且从下午两点凉到了晚上十点多，足足有7个多小时处在不可用的状态。
有人评论：语雀宕机震惊程度100%，宕机了这长时间，震惊程度10000000%
第二天在1024程序员节这天，语雀官方发布了故障复盘：关于语雀 23 日故障的公告，文章总结了故障原因、处理过程和未来的改进措施，为了表示诚意，还给所有个人用户赠送了6个月的会员。
这场故障引起了行业内部的一场讨论，有嘲讽的，说你们招人的时候不都问什么高并发高可用，各种灾备手段完善的飞起，怎么这次故障持续了这么久呢，也有从开发和运维的角度对这篇复盘文档做了完善的分析。我本人是语雀的忠实用户，在这么多的markdown软件中，我觉得语雀在易用性、排版、字体、交互等方面给我的体验还是相对不错的。这次故障语雀官方给的原因是：“由于运维升级工具bug，导致华东地区生产环境存储服务器被误下线”，看起来就是数据库、ES这种底层的存储实例被整个干掉了，被干掉的存储实例由于机器问题又无法立即重新上线， 所以团队只能从备份的数据中重新导了一份到新的存储系统中，由于数据量比较大所以直接从三点导到了七点钟，又用了两个小时进行数据校验，最终服务才得到恢复。
在这篇故障复盘里提到了一些高可用架构设计的方案，比如面向技术变更的“可监控，可灰度，可回滚”，同Region多副本容灾，两地三中心等，这些都是企业生产和面试中的一些高频问题，我们这期文章给大家总结一下这些概念背后的含义。
可监控，可灰度，可回滚
在企业开发过程中，任何线上环境的变更操作都是高危敏感操作，都需要谨慎对待，绝大多数的系统故障都是由于线上变更导致的。这里的变更可不仅仅是指代码变更，还包括配置变更、实例配置升级等。在线上变更期间，服务必须要做到可监控、可灰度、可回滚，其中可监控不仅在变更期间，在系统运行的日常期间也需要能够实时的收集运行的各种数据和指标，包括服务器的CPU、内存占用率，GC信息、运行日志、各种业务的打点数据、服务异常信息等，并能把这些数据用图表、曲线等各种方式展示出来。这些数据不仅是程序员排查和定位问题的重要依据，也是服务风险评估和扩容的重要依据。没有监控，你的服务在线上就完全是一个黑盒运行的状态，没有人知道它在运行期间遇到了什么样的问题，服务器是否需要扩容等。常见的监控手段包括Prometheus，还有美团的Cat等，大家感兴趣可以去了解一下。
可灰度是指你的服务需要具备灰度发布的能力，灰度发布也叫金丝雀发布，它指的是在你的服务全量变更之前，可以先针对一小部分用户进行试用，这部分用户的筛选可以有很多维度，比如地域、年龄、注册时间或者其他的业务属性，我先准备几台服务器部署新版本的应用，将这部分用户的流量打到新服务上，然后针对这部分用户的反馈和监控数据对新版本的稳定性做调整，减少发布风险。与此相对应的还有蓝绿发布、滚动发布、AB测试等，如果大家想知道可以在评论区留言，我们在后面给大家展开去说。
所谓可回滚是指当变更导致线上系统出现错误时，需要有能力将线上有问题的版本快速回退到变更之前的状态，从而减少对用户的影响，否则线上错误持续的时间过长，对系统的数据完整性和用户体验、用户粘度都会产生非常大的影响
两地三中心的高可用能力
在语雀的复盘文档中还提到了两地三中心的高可用能力，两地是指同城和异地两个地点，三中心指的是生产中心、同城灾备中心和异地灾备中心。其中异地机房通常要和同城机房距离在1000公里以上，这样才能应对城市级别的灾难。生产中心的数据要实时同步给同城灾备中心，同城灾备中心再将数据异步备份到异地灾备中心。同城灾备中心需要具备与生产中心同等的业务处理能力，这样应用才能在不丢失数据的情况下从生产中心平滑地切到同城灾备中心，保证服务不间断。当生产中心和同城灾备同时不可用时，再通过异地灾备手动恢复数据，实现业务的恢复。由于同城灾备到异地灾备的数据是异步备份的，所以这种恢复方式通常会丢失少量的最新数据。
当然，两地三中心属于异地多活众多解决方案中的一种，在真实的线上环境中需要根据企业和项目的情况去选择合适的方案，比如在资金有限的情况下，需要优先保证支付、资金、交易这种核心链路保障方案的完备性，对于重要程度相对低一些的项目就可以降级使用同城灾备、同城双活等其他方案了。
