近日，多个APP频繁陷入“崩溃”故障，大范围宕机的背后，到底产生了什么问题？互联网大厂们又如何解决呢？
2023年年末，“崩”似乎成了部分互联网大厂的收尾词，前有阿里云“史诗级”的故障，后有滴滴大范围宕机，再如近日腾讯视频会员的崩溃，皆在网上掀起热议波澜。
近期，大厂频繁故障上演的“连续剧”，不禁让人心生疑问：它们怎么了？
业内专家汪斌（化名）告诉《IT时报》记者，系统出现Bug并不奇怪，但持续时间过长，意味着应急预案相关手册并没有完全覆盖问题。
另一位从大厂“毕业”的资深技术员工则将原因归咎于前几年流行的“中台”，“一旦中台存在设计缺陷和设计冗余，管理者与执行者之间割裂，很容易形成事故。”
最近一个月内的连续故障，之所以引起喧哗，在于其有着新特征：一损俱损。
阿里和滴滴都是旗下相关App出现了故障，意味着在核心层或底层出现问题，也有人将原因归咎于这两年大厂降本增效、技术型人才缺失，影响业务稳定开展。
技术研发者邓为（化名）此前在某大厂架构部门任职，亲历过公司内部的业态无序后，他无奈离开。
“真的很离谱。”在他看来，近期大厂频繁出问题与人员变动有不可分割的关系，近三年来，互联网大厂的人员规模经历了从扩张到缩减的过程，也留下了不少业务黑洞。
“技术腐败”是他对自己在大厂工作期间经历、见闻的总结。“前几年形势好的时候，大厂纷纷扩招，‘抢占’业务高地，但人员膨胀后，实际的需求规划未准时到位，结果人招进来却没活干，需要自己找活，或者自己建项目。”邓为表示，此前公司内部有很多项目属于“巧立名目”，有的把简单问题复杂化以消化多余人力，有的将外部项目拿进公司稍作修改，换个名字便视作新项目，还有的人将已有项目不断合并、组合后成立新项目。
此外，几年前兴起的中台概念也并不完美，并不是中台设计动机有问题，而是打造中台的过程需要行政强制要求配合搭建。但在执行过程中，缺失技术管理和决策问责机制，即使中台存在设计缺陷和设计冗余，也没有太好的修改机制。
“公司执行层和管理层的割裂是这种情况发生的关键所在。”邓为说，执行层维持实际业务的运转，管理层倾向于操控项目的概念和方案来维持绩效，“决策一旦发生错误，最终复盘问责却不会对管理层形成威胁，因为管理层不仅掌握人事权，也具有解释权，结果最后故障出现后，关键技术人员往往是首先被追责的人，然后形成恶性循环。”
当然，多次宕机事件背后，仍然有技术问题。
详看阿里云此前公布的问题报告——AK在读取白名单数据时出现读取异常，因处理读取异常的代码存在逻辑缺陷，生成了一份不完整的白名单，导致不在此白名单中的有效请求失败，影响云产品控制台及管控API服务出现异常，同时部分依赖AK服务的产品因不完整的白名单出现部分服务而运行异常。
如何理解？“AK是一个服务功能，是构成阿里云平台的基础。”汪斌认为，下层服务的服务能力类似于中台，可以为上层服务提供数据库、存储等功能，但会导致下层“变重”，即架构变得冗余和复杂，“当架构中的设计逻辑不清楚时，极容易出现问题，这对上层来说亦是灾难。该企业频繁发生故障，或因架构过于集中。”
再来看滴滴事故，官方宣称是“底层系统发生故障”。据有关媒体报道，造成此次事故的原因是由升级K8S集群导致，即本应升级到1.12，但升级到了1.20，协议不兼容而引发连锁反应。“这个问题则应该是运维制度管理欠缺考量，在操作过程中并未考虑灾难发生的可能。”汪斌表示。
大大小小的宕机事件让人产生此类事故是否无法避免的疑问。
据《北京日报》报道，无论是本地计算还是云计算，互联网的服务数据终究要流向数据中心，汇集到几个中心节点，这种物理属性决定了数据中心无法规避外界因素，也就无法做到永不宕机，而企业的安全冗余和灾备能力受“投入产出比”影响，也不可能无限进行备份。
“企业多数的规章制度多‘脱胎’于日常的经验教训，从这些事件中，我们能获得的启发是，一方面要健全运维制度，另一方面是强化操作流程，从中总结经验。”汪斌说道。
我在参加人人都是产品经理2023年度评选，希望喜欢我的文章的朋友都能来支持我一下~
点击下方链接进入我的个人参选页面，点击红心即可为我投票。
每人每天最多可投30票，投票即可获得抽奖机会，抽取书籍、人人都是产品经理纪念周边&起点课堂会员等好礼哦！
投票传送门：https://996.pm/YNxy4
作者：孙永会，编辑：郝俊慧，孙妍
来源公众号：IT时报（ID：vittimes），做报纸，也懂互联网。
本文由人人都是产品经理合作媒体 @IT时报 授权发布，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。