最近语雀不是出了个号称 “载入史册” 的 P0 级事故嘛 —— 连续宕机 7 个多小时无法使用，作为一个大厂知名产品，这个修复速度属实让人无法理解。要命的是我们公司的知识库也是放在语雀上的，导致那天下午大家摸鱼很愉快。
很快，官方就发布了《故障公告》。有一说一，这个公告写得还是挺不错的，时间线梳理的很清楚。而且起码没有把责任归咎于 “网络原因”，还以为又是某个地区的网线被挖断了呢。
故障公告原文：https://mp.weixin.qq.com/s/WFLLU8R4bmiqv6OGa-QMcw
也有同学看了的语雀故障公告文章，发现改进措施这一段中提到了 “可监控，可灰度，可回滚” 这 9 个字，我觉得这确实是全文的核心亮点了，把事故复盘总结地很精辟。
但是这 9 个字到底是什么意思呢？鱼皮给大家解读一下。
如何保证系统发布的稳定性？
首先，这几点都是企业正式线上项目需要重点关注的能力，所以大家在校自学时一般是很少能接触到的。
但如果你知道并实践过这些，前途不可限量啊！
可监控
可监控是指能够实时地收集和展示系统运行时的数据和指标，以便开发和运维同学可以及时发现系统问题、更快进行故障排查和性能调优。需要监控的信息可以包括系统性能指标（内存、CPU、带宽等）、业务日志、错误信息等。
还有一个与之相关的术语 “可观测性”，就是指一个系统状态对开发维护者的透明程度。举个例子，我不需要每次打开服务器看日志或者用什么 jmap 命令分析 gc，而是直接通过一个面板整体查看系统的状态，甚至是自动提示问题和解决方案。
AIOps 智能运维也是现在很流行的一种技术，用 AI 帮忙运维诊断系统，大大提高开发运维效率。
可灰度
指灰度发布能力（又叫金丝雀发布）。将系统的新版本全量部署给所有用户之前，先仅对一小部分用户进行试用。这样可以通过收集这部分用户的反馈和监控数据就能评估新版本的稳定性，并及时进行调整和修复，从而减少对全体用户的潜在风险。
灰度发布又有很多策略。比如经典的按流量阶段性发布，先随机给 5% 的用户使用新版本，验证没问题后，再给 20%、50%、75% 的用户使用新版本逐渐放量，直到覆盖 100% 的用户。
还有很多策略，列举几个常见的：
1）按照用户的业务属性灰度，比如 VIP 用户先用、老用户先用。
2）按人群灰度，比如特定地域、特定年龄、特定偏好、特定客户端的用户。
3）按渠道灰度，比如通过某平台注册的用户先体验等等。
灰度做的好，可以避免很多线上问题，及时控制影响。因此很多知名产品发布时都会采用灰度或者内测的策略，这也就是为什么有些同学能第一时间体验到微信新功能，有些同学却没有。
可回滚
就像 Git 版本控制系统回滚写错的代码一样，系统的版本也是可以回滚的。
线上系统出现问题时，可以将已经部署的新版本回退到之前的稳定版本。这样做可以快速恢复系统，减少对用户的影响，并给开发同学足够的时间来排查和修复问题。而不是线上一直故障，每分钟都是损失。
最后
咱也不是阿里内部的同学，说实话我不相信阿里内部没有统一的监控平台、灰度发布和部署管理平台。估计是部门自治或者人员不规范的操作导致的吧。（毕竟一个实习生说不定就能干崩一家公司）
总之，上面讲的这些特性都是为了在软件开发和发布过程中提高系统的稳定性、可靠性和可维护性。
想要实践上面这几点其实也很简单，直接用微信云托管平台就好了。我之前直播时录制过一套微信云托管的实践教程，大家如果需要的话，可以评论 “需要教程” 让我看看大家对这方面的需求，有必要的话回头给大家发出来~
说真的，看完这篇解读我第一反应是：这九个大字，写进PPT里谁都会，可真要落地怎么就这么难呢？语雀挂那七个小时，我司知识库全在上面，下午开会要查个老方案，愣是打不开。最后大家集体摸鱼，在一片“打不开”的叹息声中愉快地混过了半天。说实话那半天过得挺开心，但第二天所有活堆一起补，真服了。就这种体验，再看文章说“可监控，可灰度，可回滚”是核心亮点，我脑子里只有一个问号——这几句话你们以前没想过？还是说想到了但没人真当回事？但凡监控靠谱点，能盯着线上烂了七个小时没人管？说实话我看到公告里写“可监控”这三个字的时候，直接笑出声来了。七个小时什么概念啊，一场大觉都睡醒了。哪怕是个最简单的探活脚本，隔五分钟ping一次，也不至于故障了这么久才被发现。除非是连监控平台自己都挂了，那就更好玩了，监控了半天监控了个寂寞。还有那些所谓的“可灰度”，一个云笔记产品，新版本发布前不先放量给内部人试试？哪怕是拿公司员工当小白鼠，灰度个几百人用半天，也不至于把全量用户一波带走。除非压根就是存储层面出了事，这种一般灰度也没用，新旧版本共用一套底层数据，该炸还是炸。但你别跟用户说“我们重视稳定性”，你先把这层的逻辑捋清楚再谈。回滚就更别提了，要是真的能轻松回滚，至于拖七个小时？早就退回上个版本让用户先用了，哪还用得着在线修那么久。说到底，这种复盘文章就两层意思，一层是给上面看的，另一层是给用户看的。上面看态度，用户看诚意。但说白了这就是篇PR稿，把运维里三个最基本的关键词包装得跟什么独门绝技一样，搞得好像普通公司压根做不到。可问题是，语雀是阿里的产品啊，阿里云那套技术栈可是国内天花板级别的，这些手段他们能没有？肯定有啊，而且还很成熟。那为什么还出事？要么是流程出了漏洞，要么是人偷懒了，要么是内部系统各管各的根本没打通。文章里那句“毕竟一个实习生说不定就能干崩一家公司”倒是句大实话，但这句话说出来不就是变相承认了——他们内部的操作规范、变更流程、权限管控，大概率是存在巨大漏洞的。那问题来了，你复盘了这么多“可”，有没有一条是说“到底是谁、哪一步、为什么能绕过所有关卡把整个服务给弄崩了”的？这个才是大家真正想知道的吧。互联网公司干久了都懂，所谓的事故复盘，往往就是回溯时间线，然后一顿操作猛如虎。原因分析写得漂漂亮亮的，细节里全是“某某同学操作失误”、“未遵循某某规范”，啊这，所以问题就出在“人不行”？那我是不是可以理解为，只要下次换个细心点的实习生，就永远不会有P0了？不会真有人信这套吧。还有更逗的，整篇帖子最后竟然扯到微信云托管上去了。我直接好家伙，敢情这哥们儿折腾半天分析这分析那，落点居然是给自己的教程引流。前面把语雀事故说得那么严重，后面画风一转就要发教程了？这波蹭热度的姿势说实话有点太丝滑了，让人怀疑他是不是早就等着哪家出个大事故，好借机做一期内容出来。教程嘛，我猜也就是教人怎么一键部署个静态博客、搭个小程序后端之类的，跟语雀这种几亿条笔记、海量并发、数据强一致的系统压根不是一个数量级。说得难听点，搞个个人博客在微信云托管上跑，就算挂了也就你自己一个人打不开，和P0有个毛线关系？就这还敢说“想要实践上面这几点其实也很简单”，别误导新手了好吗。真正的“可监控、可灰度、可回滚”，是建在复杂系统之上的治理能力，不是开了个云托管服务就等于把三道保险全装上身的。你要真按文章这个逻辑来，那不是学技术，那是自信过头。不过话说回来，这次语雀的公告有一点做得还不错，起码时间线写得清楚，没把锅甩给“机房断电”或者“光缆被挖断”，哦对了，好像提了一嘴是“运维工具 bug”导致的。嗯，运维工具出bug导致整个服务不可用——这本身难道不正说明他们当时的观测和管控本身就是单点吗？一个工具挂了，全都躺平，这跟“可监控”有什么关系啊。说白了，越是复杂的系统，越要承认自己不可控的地方。承认不可控，才可能在设计上多做冗余。但现实是，很多团队都觉得自己的系统稳如泰山，等到真炸的时候才发现，哪哪都是单点，哪哪都没兜底。七小时里，公告里说“数据是安全的”，这话我信，但对用户来说，“数据安全但打不开”和“数据丢了”在体验上就是一个地狱一个更深的地狱。我们这些普通用户，其实不关心你的架构多牛，也不在乎你用了什么金丝雀还是蓝绿部署，唯一在乎的就是：老子打开你的App能不能顺畅看到我的文档。你挂了半小时，我就已经想换别家了。七个小时，足够我另起炉灶把所有资料搬到飞书或者Notion上去。要不是公司当年统一采购了语雀的企业版，我早就跑路了。所以你说这九个字是亮点，我觉得不假，但更准确地说，它们是这整篇文章里最能遮羞的九个字。因为真正的亮点不是写出来的，是做出来的。如果下次语雀再出事，而且还能在两小时内恢复、全程透明播报、事后给出有细节的原因，那我才承认，这次复盘是真的学到东西了。如果下次还能来一次七小时，那这九个字就当个笑话看看就好。反正对我来说，唯一收获就是：公司下一轮采购的时候，我肯定要多嘴一句，要不要换个更稳一点的平台？毕竟摸鱼一时爽，补工火葬场。啊对了，最后真想跟鱼皮说一句，下次你发这种总结，别急着在末尾挂教程。哪怕你真心想分享，也显得特别像蹭完热度就要收割韭菜。你要是真想把“可监控、可灰度、可回滚”讲透，不如拿自己某个线上项目出来，把真实的监控面板、发布流程、回滚演练录屏都放出来，那可比一句“评论需要教程”有说服力多了。写教程嘛，也不丢人，但别借着别人的事故给自己引路，这吃相多少有点不大好看。就这，半夜摸鱼吐槽完毕，睡觉。
草泥马的语雀，老子看完这篇狗屁文章更来气。你说你搞个“载入史册”的P0事故，连续瘫了七个多小时，七个多小时啊兄弟！我司整个知识库全在里面，那天下午一群人端着茶杯开着B站摸鱼摸到天荒地老，领导还以为是大家网络不好呢。合着这破平台一挂，我们整个部门放了个小长假。就这么个垃圾服务，官方回头发个公告，居然还有人夸“写得好”？好你麻痹！时间线清晰有个卵用，故障清清楚楚摆在那，你们是花了七个多小时才搞清楚自己哪炸了？这他妈不是“复盘”，这是给用户上坟前念的悼词，念得再工整人也活不过来！ 然后这文章里还吹什么“可监控，可灰度，可回滚”九个字是全文亮点，我呸！这九个字放在语雀身上简直就像色狼穿了条红内裤——自欺欺人到极点。你说的“可监控”，监控了七个小时就知道自己掉线了？你监控系统是拿小霸王学习机做的？CPU、内存、带宽这些破指标，生产环境崩成狗了才报警，这他妈叫监控？这叫死了之后请个道士来念经！还有那个“可观测性”，哦～真高级，拿个面板看整个系统状态，我都笑了，语雀那面板怕是直接黑屏给你看吧？我一个用户端的都知道这垃圾那天连个错误码都他妈不给，全是白屏转圈圈。这还叫“透明”呢？你们这状态对用户倒是挺透明的——明明白白就是挂了，毫无遮拦！ 再看“可灰度”。哎哟喂，灰个毛啊！你们是有灰度放量吧？是灰度完直接全量崩是吧？文章里还说什么“先5%再20%再50%”的经典策略，还有什么VIP用户老用户先用。我看你们语雀也搞了灰度啊，先把新版本给老用户用，老用户直接全被干趴下，然后全体陪你一起死。你说灰度做得好能避免线上问题？那这次是怎么避免的？是不是你们灰度了一坨大便，结果拉到全体员工头上，干脆就整锅端了？还提微信新功能灰度——人家微信灰度是内测新功能，你们语雀灰度是公测事故，这能一样吗？我家里拉狗屎都有个循序渐进的过程，你们倒好，一上来就拉满，给所有人一记迎面暴击。 再说“可回滚”。这词用的我都觉得对不起Git。Git回滚代码是让写错的地方回到之前好的状态。你们语雀呢？宕机七小时才回滚？你是在纠结回滚到哪个版本吗？是回滚到昨天的稳定版还是前天的稳定版？结果都能把全站搞挂七小时，说明你们手里根本就没有能回滚的版本——所有历史版本都他妈是带着雷的！就像你家地窖里堆着三十箱罐头，你拿出来一箱发现是馊的，再拿一箱还是馊的，最后你发现整个地窖都是馊的，于是你饿着肚子硬撑了七个小时。这叫可回滚？这叫可全他妈滚！ 最让我恶心的是文章最后那段——作者还假惺惺说“我不信阿里内部没有统一的监控平台、灰度发布和部署管理平台，估计是部门自治或者人员不规范的操作导致的吧”，完了还来一句“毕竟一个实习生说不定就能干崩一家公司”。放你妈的屁！你以为猜个实习生很幽默？你这是在给谁洗地呢？我就问一句：一个成熟的平台，能让实习生按个按钮就把全站搞瘫？这玩意儿是纸糊的？权限呢？审批呢？熔断呢？隔离呢？全都没了是吧？按个发布键像拔掉服务器电源一样简单，这已经不是操作不规范了，这是整个体系烂到根子里了。你写这文章不骂公司管理不骂制度漏洞，反而拿“实习生”这仨字揶揄一下，替谁遮羞呢？你是不是阿里公关部派来的卧底啊？还是收了微信云托管的钱跑来混个脸熟？ 哦对了，文章最后那一段才是你的真实目的吧？扯了一大堆“可监控可灰度可回滚”，干货一点没有，最后话锋一转——“想要实践上面这几点其实也很简单，直接用微信云托管平台就好了”，还“评论‘需要教程’让我看看需求”，我真去你妈的吧！合着前面骂了半天语雀，在这儿等着我们呢！你这不叫技术复盘，你这叫事故营销！蹭个P0热度给自家产品拉流量，你是怕这事故不够惨，还得踩上一脚蘸蘸血馒头吃是不是？我要是语雀的运维，看到自己家出了这么大糗，转头一看还有人在发广告贴，我当时就把麦克风线给扯断了，还得顺手把微信云托管的域名给ban了！这套路跟那些保健药广告一模一样——先用惊悚的故事吓你，说啥“不治将死”，然后推出一颗“神药”让你赶紧买。你以为你写的是安全稳定指南？你就是个卖药的在坟头蹦迪！ 老子自己也是个干开发的，写了快十年代码了。说真的，看到这种“可监控可灰度可回滚”的口号我就烦。这九个字谁不知道？是个程序员都他妈会背！我大学刚毕业那会儿进的第一家公司，啥都没有，代码扔服务器上就直接跑，写坏了回滚回滚，也没见过全站崩七小时的。后来去了大厂，天天听领导讲“稳定性三件套”，监控各种指标，灰度各种人群，回滚各种Redis缓存。我当时觉得蛮牛逼的，后来发现，大厂做的不是这套体系，大厂做的是PPT——能把九个字讲出花来，一套一套的文字，就是没人在意真正出了事故时人怎么处理的。监控平台有吧？几十个系统互相不打通；灰度平台有吧？每次发布流程走个两天；回滚脚本有吧？跑起来还报错，得手动重启一百台机器。这他妈就是现实！所以语雀这次能挂七小时，我真的一点都不意外。越是整天把这九个字挂嘴边吹牛逼的公司，出起事来越他妈拉胯。因为动作全是做给领导看的，维护全靠嘴上说说，一到危机时刻，大家还在群里对时间线呢。 你别看七个多小时，我跟你算一笔账啊。按国内这些大厂的故障分级，P0是什么？是核心业务不可用，用户直接受创，经济损失每分钟都在增加。语雀这种企业级知识库，存了多少公司的文档、合同、API设计、年假申请，哪个不是命根子？结果它挂了七个小时，那些公司就七个小时查不了资料、看不了需求、写不了代码。有些保密文档甚至都放在上面，你让安全部门怎么想？我当时就想，这要是机密数据丢了漏了，语雀是不是得赔到倾家荡产？结果官方就发个公告，说句“今天修复了，明天继续努力”。这公告还是赞的？谁家的狗腿子，站出来我看看！ 然后我还想骂一个点，就是文章里吹“该公告没有把责任归咎于网络原因”。这你妈是什么当代道德标准？没甩锅给网线就值得表扬？我丢了一百块钱，小偷没跟我说是风吹走的，我还该夸小偷诚实？你一个做技术产品的，出了故障，自己站出来把问题说清楚，这是基本义务，不是高风亮节！什么叫“没有归咎于网络原因”？网络线路出问题也是你们没有容灾没有备份没有多活啊！你要是真用了双活机房，一根网线断了，另一根马上顶上，用户根本感知不到。您倒好，网络原因都轮不到甩，因为压根就是自己代码写炸了。还“有一说一”，我看你是有一说二，把没做好的当成做好的了！ 再来说这个作者鱼皮。我看他写文章也挺能套的。“这些特性都是企业正式线上项目需要重点关注的能力，所以大家在校自学时一般是很少能接触到的。”一句废话！废话！啥叫在校自学接触不到？现在大学生但凡有点上进心的，自己用Docker部署个博客，搞个GitHub Action自动发布，再配个Grafana看指标，全是自己动手学的，谁他妈等公司的平台？你还拿这个当门槛，以为“知道这几点”就前途无量了？这九个字是高考数学必考公式吗？知道个名字就考上清华了？最怕就是这种技术博主，把一个概念说得神乎其神，其实是“我今天教你这杯水怎么喝”的水平。你实践过吗？你真正面对过几万人流量同时涌进来的时候吗？你处理过凌晨三点数据库连接池被打爆的事故吗？没有的话不要在这儿拿书本上的理论骗赞。还“需要教程吗”？我看你直接把二维码贴出来算了！ 不过我倒真觉得，这九个字本身是没啥错的，说得挺在理。问题不在于这九个字，问题在于你拿它复盘语雀事故，那就是在伤口上撒盐。你说“可监控”，语雀有监控吗？要是有，为什么不能第一个时间自动识别用户访问异常？你说“可灰度”，语雀有灰度吗？有，绝对是有的，但灰度发布出来之后，异常检测估计全关掉了，数据没人看，反馈没人收，白灰度。你说“可回滚”，回滚也要有时间啊！你七个多小时才回滚，你是从古代开始滚的吗？拿着望远镜看了六个小时敌人，才想起来该开炮了吧！所以这九个字，对于语雀来讲就是挂在墙上的字画，平时看着像个文化人，一到关键时刻连屁都不如。你要是真信奉这九个字，那应该把事故报告写成“我们没有可监控没有可灰度没有可回滚的落地能力”，而不是把这三个词当成遮羞布，显得自己很有方法论一样。 再啰嗦一句，我其实挺想看看阿里内部怎么对这次事故做复盘。网上传的嘛，说什么上海某园区网络被挖断又叠加什么部署更新，反正乱七八糟。但七个多小时，你就算买三台新服务器，从零开始装操作系统都够了吧？你甚至可以从容地去设备间，把所有机器断电再通电，然后等它自愈，也用不了七小时吧？七个多小时什么概念？北京坐高铁都能到上海了，中间还能吃顿饭。语雀这故障恢复速度，说是蜗牛爬我都嫌侮辱蜗牛。像这种事故，放在我们公司，负责人估计当场就卷铺盖回家了，技术上出了问题，首先是制度上先治罪。而语雀呢？官方公告末尾还加一句“感谢大家的体谅和理解”。体谅你麻痹！老子下午开会白开了一场，记录全没了，我体谅你，你体谅我的花呗吗？ 后来我也想了想，咱普通用户拿语雀这种平台真的没办法。数据在人家手里，想迁走还得看它脸色。这次事故之后，我们公司总算是醒悟了，决定把所有文档备份到本地，隔一天同步一次。我当时就跟同事说：“早该这样了，我用了三年语雀，每次出差在酒店打开它都提心吊胆，就怕连不上。这不，终究还是出了个大事故，大家才知道孩子哭娘抱，纯熟。”现在我想想，这篇文章虽然看着来气，但至少给不少公司提了个醒——啥云平台都不如自己U盘来得踏实。你就算把“可监控可灰度可回滚”吹到天上，也顶不住一次像样的地震。你那次要是真把我们的年终总结文档给吞了，老子直接提刀到西溪园区门口堵人！ 最后，我还是想说点正经的，虽然我这人满嘴粗话，但道理是这么个道理。做技术的，别整天嘴嗨，别把“可监控、可灰度、可回滚”当成三级口号，喊完了就忘。你得真正把它沉到每一次发版里去，容灾演练定时搞，故障预案定时练，别等着出了事再翻出来念经。当然，这些话说得容易，做起来是真难。但再难，也难不过你们语雀这次修复花七小时吧？还是说，你们真的觉得，翻个车翻七个小时，再把九个字念一遍，就功德圆满了？ 草，写了这么多，我自己都嫌自己话唠。反正就是这么个态度：下次语雀再挂，我他妈直接请一天假，在家打游戏，既不心疼也不骂人，就当天意。反正你们这波广告打得挺好，我已经想好了——回头就给微信云托管提交个注册，不为别的，就为看看这作者吹的牛逼到底能撑几分钟。要是它哪天也来个P0，我保证立刻回来写一篇更长的，骂它个七天七夜，连这九个字的祖宗十八代都给翻出来。行，散了吧，赶紧去自己的文档目录下按个Ctrl+S，别到时候哭爹喊娘。