大厂系统崩溃上演“连续剧” 技术的错还是制度的锅？_风闻

大厂离职员工：中台或形成“技术腐败”

作者／  IT时报见习记者 孙永会

编辑／  郝俊慧  孙妍

2023年年末，“崩”似乎成了部分互联网大厂的收尾词，前有阿里云“史诗级”的故障，后有滴滴大范围宕机，再如近日腾讯视频会员的崩溃，皆在网上掀起热议波澜。

近期，大厂频繁故障上演的“连续剧”，不禁让人心生疑问：它们怎么了？

业内专家汪斌（化名）告诉《IT时报》记者，系统出现Bug并不奇怪，但持续时间过长，意味着应急预案相关手册并没有完全覆盖问题。

另一位从大厂“毕业”的资深技术员工则将原因归咎于前几年流行的“中台”，“一旦中台存在设计缺陷和设计冗余，管理者与执行者之间割裂，很容易形成事故。”

管理背锅

强推中台留隐患

最近一个月内的连续故障，之所以引起喧哗，在于其有着新特征：一损俱损。

阿里和滴滴都是旗下相关App出现了故障，意味着在核心层或底层出现问题，也有人将原因归咎于这两年大厂降本增效、技术型人才缺失，影响业务稳定开展。

技术研发者邓为（化名）此前在某大厂架构部门任职，亲历过公司内部的业态无序后，他无奈离开。

“真的很离谱。”在他看来，近期大厂频繁出问题与人员变动有不可分割的关系，近三年来，互联网大厂的人员规模经历了从扩张到缩减的过程，也留下了不少业务黑洞。

“技术腐败”是他对自己在大厂工作期间经历、见闻的总结。“前几年形势好的时候，大厂纷纷扩招，‘抢占’业务高地，但人员膨胀后，实际的需求规划未准时到位，结果人招进来却没活干，需要自己找活，或者自己建项目。”邓为表示，此前公司内部有很多项目属于“巧立名目”，有的把简单问题复杂化以消化多余人力，有的将外部项目拿进公司稍作修改，换个名字便视作新项目，还有的人将已有项目不断合并、组合后成立新项目。

此外，几年前兴起的中台概念也并不完美，并不是中台设计动机有问题，而是打造中台的过程需要行政强制要求配合搭建。但在执行过程中，缺失技术管理和决策问责机制，即使中台存在设计缺陷和设计冗余，也没有太好的修改机制。

“公司执行层和管理层的割裂是这种情况发生的关键所在。”邓为说，执行层维持实际业务的运转，管理层倾向于操控项目的概念和方案来维持绩效，“决策一旦发生错误，最终复盘问责却不会对管理层形成威胁，因为管理层不仅掌握人事权，也具有解释权，结果最后故障出现后，关键技术人员往往是首先被追责的人，然后形成恶性循环。”

技术归咎

架构设计和运维制度欠考量

当然，多次宕机事件背后，仍然有技术问题。

详看阿里云此前公布的问题报告——AK在读取白名单数据时出现读取异常，因处理读取异常的代码存在逻辑缺陷，生成了一份不完整的白名单，导致不在此白名单中的有效请求失败，影响云产品控制台及管控API服务出现异常，同时部分依赖AK服务的产品因不完整的白名单出现部分服务而运行异常。

如何理解？“AK是一个服务功能，是构成阿里云平台的基础。”汪斌认为，下层服务的服务能力类似于中台，可以为上层服务提供数据库、存储等功能，但会导致下层“变重”，即架构变得冗余和复杂，“当架构中的设计逻辑不清楚时，极容易出现问题，这对上层来说亦是灾难。该企业频繁发生故障，或因架构过于集中。”

再来看滴滴事故，官方宣称是“底层系统发生故障”。据有关媒体报道，造成此次事故的原因是由升级K8S集群导致，即本应升级到1.12，但升级到了1.20，协议不兼容而引发连锁反应。“这个问题则应该是运维制度管理欠缺考量，在操作过程中并未考虑灾难发生的可能。”汪斌表示。

大大小小的宕机事件让人产生此类事故是否无法避免的疑问。

据《北京日报》报道，无论是本地计算还是云计算，互联网的服务数据终究要流向数据中心，汇集到几个中心节点，这种物理属性决定了数据中心无法规避外界因素，也就无法做到永不宕机，而企业的安全冗余和灾备能力受“投入产出比”影响，也不可能无限进行备份。

“企业多数的规章制度多‘脱胎’于日常的经验教训，从这些事件中，我们能获得的启发是，一方面要健全运维制度，另一方面是强化操作流程，从中总结经验。”汪斌说道。

排版／ 季嘉颖

图片／ 东方IC

来源／《IT时报》公众号vittimes