降本增笑，阿里云的数据库管控又崩了

游戏渣渣 :

卧槽，标题给我整笑了。“降本增笑”——这四个字是真绝，比那些PR稿里“技术升级”“架构优化”什么的好使多了，一针见血。 我是真没想到这文章能写这么细，连故障时间都给我列出来了：10月23日语雀8小时，11月12日授权模块3小时，11月27日数据库管控2小时。咱就是说，这频率也太离谱了吧？我这人记性不好，但我连双十一都记不住的人，硬是记住了这仨日期。你品品，这是什么道理？说明这故障频率已经高到能给我这种普通人留下肌肉记忆了。 说句实在话，我在阿里云上也是付费用户，虽然没十年那么久，但也有五六年了。去年公司搞了个新项目，我寻思终于能用上点高级货了，就开了他们的托管数据库和那个对象存储。结果呢？一次维护直接把我们的线上服务给搞挂了，客服工单排队排了仨小时，最后给的答复就是“我们正在紧急修复中”，连个具体恢复时间的承诺都没有。你能想象我当时啥心情吗？对着那个状态页面刷新了一下午，刷新到指头都抽筋了。 文章里那段我特别有共鸣：“每次故障发公告的时候，建议干脆加上个倒计时功能，看看距离下一次故障还有多久。”我当时在群里跟同事吐槽的原话就是：阿里云这故障公告写得比我们日报还勤快。我们项目组现在开周会，第一项议程都改成“这周阿里云崩了几次”了。 不过话说回来，我其实不太同意文章里有些地方的归因思路。怎么说呢，我看评论区有个高赞说是裁员裁的，说阿里9个月减了1.5万人，老程序员都毕业了，剩下小年轻经验不够所以出问题。我看到这个的时候吧，怎么说呢，这个说法确实有道理，但我觉得没说到点子上。你想想，阿里云再怎么裁，也还是上千亿的盘子，核心系统不可能真就靠那几个人撑着。而且真要是技术难题，他们完全可以外包给第三方运维公司，花点钱就解决了，不至于这么拉胯。 我反而觉得文章里那段关于“高P搞PPT、PUA下属”的吐槽，才是真正扎心的。就我认识的在阿里待过的朋友，当然人家也没明说是哪个部门哈，跟我聊过他们的工作状态，大概就是vave可以总结成：不停开会对齐，不停改PPT，不停跟别的组扯皮，真正写代码的时间可能还没有我在工位摸鱼的时间多。你想想，这代码能写好吗？肯定是赶工赶出来的多，上线能跑就行，哪有什么时间去管底层原理、考虑各种边界情况啊。 我前年去过一次阿里云栖大会，那场面确实宏大，讲台上各种炫酷的技术名词，什么“全栈自研”“弹性计算”“内建智能”，听得我一愣一愣的。我当时还在想，哇塞这技术好牛逼啊。结果呢？回来没俩月，就看见新闻说他们某核心节点因为发配置发错了，直接把一堆客户的东西全删了。我当时真的就是一口老血喷出来，就这？ 咱们就说文章里那观点，管控程序崩了，但下面的云服务器啊、数据库实例啊这些还跑得好好的。这个我太了解了，这种架构在云厂商里太常见了。大家都知道要搞管理面和数据面分离，但真到了落地的时候就全看各自的良心了。管理面看起来只是个“管事的”，但实际上它就是个总开关，一旦这个闸门出了问题，下面那些乖乖跑的羊再健康也没用，一样出不来东西。我有个运维的兄弟跟我说，他们公司有次主控节点挂了，整个集群看起来每一个节点都是绿的，健康检查全过，但就是没人下发指令，所有节点在那儿空转，业务全部卡死，你看着监控面板傻眼，什么都做不了。 所以我还是挺认同文章里说的，如果你不是非得要那些花里胡哨的服务，就用最基础的云主机，自己装个开源的数据库和存储，反而可能更靠谱。这个思路我是试过的。我们原来用的某云厂商的托管数据库，每个月账单几千块，后来受不了了，找了台4核8G的按量付费服务器，自己折腾装了个Linux，配了个MySQL，再用个开源的备份工具，一个月下来的成本也就是那托管库的一个零头。数据安全不说，稳定性反而还更好了。当然你得有专门的人去盯着这些东西，没运维能力的小公司就别闹了，这就跟开车似的，没那个技术就别上高速。 关于这个“下云”的潮流，我倒是没那么激进。文章中那句话说得很中肯，“公有云那按需付费的特性还是很给力的，适合有突发需求的公司”——这句话我举双手双脚赞成。我们公司现在就是混合用，日常稳定的业务放在我们自己的机房，拿几台二手机器跑跑实验性项目，测试环境就全扔公有云上，过期销毁，也不用担心浪费。这也算是找到了一条“低消费高幸福感”的路子吧。 不过说到专业领域，我确实有点不同意见。文章里说“现在用K8S可以快速搭建成私有云”，这话有点太轻松了。K8S这个东西，你要说用它来干活，那真是好使，但你要说快速搭建私有云，那纯属是想多了。YAML把你写到吐不说，后面还有一堆网络存储的坑等着你。真建起来并长期把人伺候好，成本绝对比你想的高，而且高不少。我见过很多所谓“下云”的中小公司，折腾了个把月，最后还是灰溜溜回公有云了。人家技术积累在那摆着呢，确实有值得学习的地方，不用因为几次故障就完全否定它。 我还想多说一句，关于阿里的“文化”这件事。这么多年了他们老喊着“拥抱变化”，可我看到的实际情况是，变化确实抱了，但那是因为组织架构总在变，战略总在变，人员也总在变。前几天还跟的一个项目，今天一觉醒来就被拆了，你想专心把一个事做深做透？那可是奢望。代码库上几万条注释，有相当一部分是在骂人的，这个我敢打包票。我还见过有同事在离职之后，因为心里不爽，把一些关键服务的配置直接乱改，离职交接什么的就看各自人品了。 所以真要说阿里云为什么总出问题，我其实觉得是这套“大公司软件工程”的老毛病。什么东西都想要，什么山头都要建设，结果人人都想搞个大事情，最后就是每个项目的复杂度都在爆炸。组件之间互相不知道对方有什么改动，就那么互相盲人摸象地往上堆东西，直到哪天谁一个不小心踢到哪个不认识的角落，那整个系统就开始连锁反应了。这跟裁员多少关系不大，你觉得呢？ 我是搞数据库的，我太清楚了，这类系统最大的问题往往是“你以为你知道它从哪儿断的”，但实际上去排查的时候就会发现自己掉进了一个无底洞。一会是访问控制那层的问题，一会是配置同步出了问题，一会又是ID生成突然冲突了。阿里云的管控系统，实际上就是一个巨大的分布式系统，这里面光内部服务数量就有几千上万个。这个规模下，每一个组件都在疯狂地互相调用，任何一个环节出现抖动都可能传导成雪崩。想要彻底排查清楚问题，那不是一朝一夕能搞定的。但消费者才不管这些呢，我们只知道花了钱，你凭什么让我的业务断？骂就完事了。不过他们技术人员也不容易，这倒是真的，但也只能怪自己公司没把事干好吧。 还有一个小细节也特搞笑。文章里那个“降本增笑”这个组合词，我看完真的乐了很久。因为我们公司就有这种例子。去年为了“降本”，把IT部门砍了一半运维，结果连打印机的驱动都没人配了。后来老板开月会说可以报销，让各部门自己想办法，结果就是我们买了几台喷墨打印机放办公室旁边的楼道里，谁要用谁自己去用。你说这叫什么事。这就跟阿里云现在一样，光顾着省钱，却忘了你自己的产品本身就是拿来服务用户的，省到最后连用户最基础的体验都保障不了了，这不就是本末倒置么？ 我要是阿里云那帮管理层，我现在应该愁的不是技术问题，因为技术问题对他们这个体量来讲真不是什么事儿，你得相信他们的技术实力。核心的麻烦在于，信任这个东西一旦开始碎了，就很难再补回来。我都开始认真考虑要不要把整套系统都搬到另一个云厂商去做个交叉验证了，毕竟鸡蛋放在一个篮子里，万一哪天这个篮子彻底散架了，那真就是妥妥的职场滑铁卢了。 我不是什么技术大牛，也不是什么行业专家，我就是个普普通通求个安稳的软件工程师加云服务使用者，用户视角和开发视角各占一半吧。这几年在阿里云上踩过的坑，说一句都是用真金白银砸出来的。你说让他们快点修复吧，我又觉得这修复不是一次紧急故障修复就能行的，指不定得牵扯出一堆系统性的问题。我觉得阿里云现在缺的不是程序员，缺的是真正静下心来把系统做好、把架构理清、把产品打磨好的那股子心态。你看看他们那官网技术文档，动不动就是几千页，但真正能在关键时刻帮你定位问题的有多少呢？ 反正看完这篇文章，我现在对这“降本增笑”四个字真是五味杂陈。既觉得这词造得精妙无比，又觉得有几分辛酸。大家都在这圈子混，谁没遇到过几个因为省钱而翻车的糟心事呢？只是阿里云体量太大了，一崩就得上热搜，被全国人民围观。 多少年的口碑，就这么几周一次地，崩完了。你们说值不值？要我说，真踏马离谱。 本来还想再聊五分钟的，结果手一滑看到钉钉群里有人说我们系统又抽风了，也不知道是不是又跟某个云厂商的故障有关。得了，先干活去了。等下次阿里云再出故障，我再来这儿跟大家唠。

半夏507 :

下云？小公司连个专职运维都没有，K8S装上就以为高枕无忧了？半夜告警响起来都找不着人，还是多用云安全点。