几天前，蚂蚁内网因为一个抢春茶的小活动发生了宕机事件。
再大的峰值都经历过，一个千份春茶的秒杀活动技术就支撑不住了呢？内网在质疑技术时，蚂蚁AI程序员出来认领了这口锅。
原来，这个秒杀系统是由AI+低代码自动生成的。
在和技术小哥聊过后发现，这次宕机还不是AI生成代码的问题，AI生成代码的业务逻辑没有大的问题。但是在整个研发生命周期中，不仅仅是生成代码这一步，还有测试构建、发布运维等一系列步骤，特别是涉及可靠性的运维场景，还需要人工专家干预才能让系统健康运行起来。
值得一提的是，蚂蚁用AI做代码研发已经非常成熟了，在蚂蚁，有60%以上的技术人使用过蚂蚁自己的代码大模型，在他们提交的代码里10%是由AI生成的。在蚂蚁AI研发平台CodeFuse写的代码中，被采纳率是30%，在生成单元测试这个场景，采纳率可以达到60%。
不懂技术的小编
用自己的话总结了下
这次复盘要点
真的可以动动嘴说说话，AI就能帮我们写代码开发系统，这是一次失败但真实的实践。AI+低代码，早就在蚂蚁玩转起来了。
AI可以理解业务逻辑，业务逻辑没出bug。但想把业务逻辑发布上线、平稳运行，现在还真离不开程序员。换句话说，AI写代码还并不能完全代替人，程序员现在不会失业的。
这次失败引发了更高纬度的问题思考: AI专家和人类专家又该如何配合、相得益彰呢？在这篇文章里，技术小哥给出了自己的理解。
以下是他的复盘全文
都怪我，都怪我，都怪我！这几天陆续收到了很多同学关切的询问，大家非常好奇这几个问题：
01
秒杀这种被玩了这么多年的技术，而且是公司内部的小流量，怎么还会出事？
02
听说这个产品是用AI制作的？难道是AI写的代码有Bug导致了故障？
03
为啥要花费人力做个内网小淘宝，莫非是人多了闲的？
所以咱就整个文档，统一介绍一下咱在干啥吧，给大家暴露一下更多细节，也顺便回答了这几个问题。
确实是可以和AI对话
来搭建网站的
这是一段截选的录屏，咱们全程都是与大模型对话，几分钟内搭完了有礼（蚂蚁内网的一个系统）的几个重要页面：
值得强调的是，咱们搭建的网站是端到端的，并非静态页面或者设计稿，而是前端、后端、数据库全部覆盖。所以从某种意义上说：如果不关注性能问题，这个用嘴搭好的网站就算完工了，可以发布使用了。
本来我们也有个递进的方案：这个机器人先只产出设计稿DEMO，并不上线，但是，我们还是想冲一冲，拿出来溜溜。
到底是哪句对话引发了宕机
宕机的表面原因非常简单，是大家非常熟悉的雪崩效应：
数据库QPS太高 => 数据库耗时上涨百倍 => 应用系统被拖挂 => 用户白屏。
我们的数据库预算只做了1000QPS上限，实际达到2000，这也是应该着重道歉的地方，侥幸心理、偷懒心理、风险意识不足等等，都说的没错。
不过我们依然可以聊一下其中一些有趣的细节，比如：录屏中的哪句对白是引发故障的罪魁祸首？
这句话的杀伤力在于，它促成了经典秒杀场景。
我们之所以抱有侥幸心理，是因为前几次的活动（比如春节礼品），系统压力都非常低，轻轻松松就过去了，所以对这次春茶活动也没多想，毕竟公司人数没变，流量应该也差不多，总不至于为内部系统申请太高的预算规格。
可正因为这句对白的存在，将原本分散的陆续到达的流量，汇集到了活动开始的那几秒钟，所有人在收到钉钉推送之后，都有充足的准备时间，打开电脑，刷新页面，坐等那几秒集中爆发。
而我们又没有做任何针对性的优化，数据库也没有扩容，即使汇集流量的绝对值不大，但奈何资源太少，单机已经过载，最后引发了雪崩效应：
这个话题的有趣之处在于：如果制作者忘记说这句对白，说不定我们就苟过去了（大家看钉钉消息有快有慢，流量会错开）；那莫非我们真的是被一句话给玩死的？AI对所有需求都言听计从、来者不拒，是不是太过危险了？它能关注到隐藏的技术风险吗？
在目前的设计里，我们并没打算让这位AI同学来扛技术风险，而是想用另一种视角，下面介绍实现原理。
关于我们的实现原理
以及未来的应对策略
如果只看当下，那我们要做的就是：扩容DB、下次注意。
但只说这些那就太无聊了，容量问题、秒杀问题的应对策略是个老生常谈的面试题，大家也懒得听我叨叨。虽然我知道要怎么做，但这次表现确实很菜，诚恳接受大家的批评。
值得探讨的是一个用工转移的话题，相信大家看得出来，我们理想中和机器人对话的角色是非研发人员：
如果图中的用工模式真的到来了，未来产品的制作都交给了非研发人员（PD、UED、甚至业务方自己），那就会出现很强的运维滞后性。
本质原因是跳过了程序员参与的架构设计和研发阶段，等交到运维人员手里时，已经是发布前夕了，而且也找不到研发人员讨论细节。比如上面那句引发宕机的对白，运维人员是毫无感知的，也不会有人给予提醒。
而运维人员拿到的是什么呢：
这很像是上古时期的重DBA风格：以前的业务系统普遍使用Oracle存储过程，待发布代码都是大段大段的SQL，通过DBA这样的角色，实施SQL分析优化，考虑机器容量，考虑分库分表，考虑索引等等，保障生产稳定。
在我们的设想中，无论是用户嘴里说出的自然语言、还是贴近自然语言的低代码，都不应该关注性能问题，编程机器人只专注于提炼纯粹的业务逻辑。
业务逻辑之外的所有工作，都称为运维工作，以SQL作为交接物，以DBA进行角色类比。这也符合架构工作者的夙愿：彻底分离业务逻辑代码和性能相关代码，让业务专注于业务本身。
所以我们关注的重点可以类比为：如何重现DBA的运维风格，让他接得住四面八方涌来的暴力SQL，比如：
在减库存场景中，用Redis原子更新代替数据库行锁（悲观锁），是应对秒杀常用的最佳实践之一。而我们要做的就是——在收到的大篇SQL中发现这个pattern，并替换为最佳实践：
01
这个例子很能体现上面提到的“滞后性”：以前是程序员从业务理解中识别出秒杀场景，现在却是DBA从SQL中反向解读出秒杀场景（逆向工程比正向工程更难）。
02
有人说看到行锁就要上Redis，其实也还要看多对一比例，比如把“减库存”换成“减个人额度”，SQL形态差不多，也是先行锁后减减，但额度是跟人走的，多对一比例很小，并不会产生热点，用DB完全没问题。
03
从某种意义上说，这种滞后性也是倒逼着我们将原来的“架构师经验”沉淀为“可量化规则”，我们不应该对需求文档中的“秒杀”两个字敏感，而是应该对程序行为和量化数据敏感；在这一点上做的非常好的是ODPS，它会尽可能的理解算子特性和数据分布，制定最优的执行计划，以前人为的优化（比如数据倾斜和Join模式）基本都被它吃掉了，写SQL的人不需要感知。
04
替换为最佳实践并非易事，但技术上还是有迹可循的，比如刚才提到的ODPS，对原SQL在执行前和执行中进行偷梁换柱的改写，在数仓OLAP领域是很成熟的技术，运用在OLTP也未尝不可。
如果是真人DBA来应对，那可以预料到很多显而易见的难点。与其总结这些人工难点，不如先设想一下自动化：我们乐观的期待以后对话式编程会繁荣起来，那难道我们要养个百人DBA团队来顶吗。
自动化的主要内容，就是上面提到的容量规划和最佳实践，已有的实现方案主要是这几个方向：
云化视角，无人值守，自动伸缩，按流量计费，用户无感知（不需要我提前去评估和申请预算，自动伸缩，按实际流量事后结账；应用侧相对好做，数据库难度略大）。
中间件视角，集成者视角，比如存储系统种类繁多，需要各取所长，用中间件封装最佳实践（比如在某个业务系统里要同时用到DB、Redis、HBase等，只因它们在不同场景有不同的性价比）。
基础设施视角，我们需要一个超级数据库，就像上古时期所有业务都用小型机和Oracle硬刚一样，它在内部解决性能优化和自动伸缩问题（也可以在内部玩一个AIOPS）。
Agent视角：假设一切维持人工，缺少自动化，我们也可以训练一个大模型Agent，来替换人工。虽然做不到按流量自动伸缩，但有个数字人会在发布前找用户咨询、凭经验预估流量，会登录预算平台提交申请，还能登录运维平台实施扩容动作，还能看日志排查问题发起重试，有成本意识、活动结束了还会去缩容……
这些都可以是后续努力攻克的重点，而且已经有很多团队在这些方向做出成果了，怪我没有找到使用门路，诚恳的邀请大家来解救我。而且编程机器人的发展会对这些技术提出更加急迫的诉求——如果整个生产链路上只有前半段被AI提速了、后半段依然人工，那后半段肯定苦不堪言。
如果这些让用户无感的全托管平台普及了，哪怕做业务的都是像我们一样只会无脑发SQL的菜鸡，也是能平稳运转的；与其奢望人才普及，不如沉淀平台能力，实现技术普惠，对吧。
所以行文至此，我很想把宕机的原因总结为：我们花了大量精力去做AI程序员（只关注业务逻辑的程序员），却几乎没有投入精力去做运维自动化（含性能优化的运维）。这也是导致本次故障的核心原因。
不过这些都是面向未来的畅想，不能用作今日之借口，今日的机器人仍在孵化中，无论是对话还是运维，都是我们自己全程代劳的，引发宕机的那句对白也是我们自己亲口说的，并无滞后性借口，理应提前预判，出现故障是无法狡辩的，只能承认自己疏忽大意，接受批评。
这次的事故对我们来说也是宝贵的财富，同学们对于未来要面对的难题也会更加清晰和敬畏。
基于以上内容
回答最初的几个问题
QUESTION
秒杀这种被玩了这么多年的技术，而且是公司内部的小流量，怎么还会出事？
ANSWER
·压力水位是个除法，虽然分子（公司内部流量）很小，但分母（我们的数据库资源）更小，除完之后的压力还是挺大，超过了DB单实例上限，耗时进入了剧烈抖动；
·所以倾向于理解为一个容量规划问题（管理分母的问题），应该反思的是我为啥没有履行稳定性职责，没有申请更大的预算（并引申到自动化话题，期望未来这个过程是自动的）；
· 即使数据库过载，为何也没用限流和排队来做优雅降级？这个没有借口，就是没花时间，没来得及，接受批评；这条从自然语言到低代码编译再到SQL执行的链路也是新做的，没复用上公司已有的基础设施，算是非标系统了，该补的东西都要尽快补上。
QUESTION
听说这个产品是用AI制作的？难道是AI写的代码有bug导致了故障？
ANSWER
· AI产生的是业务逻辑，业务逻辑没出bug，一般导致宕机的都是容量问题，而不是业务逻辑错误；
·可以这么理解：我们希望用AI和自动化技术替代人工，需要研发加运维两个阶段的投入，我们目前重点投入的仅在研发阶段，忽视了运维阶段，忽视就招来了故障。
QUESTION
为啥要花费人力做个内网小淘宝，莫非是人多了闲的？
ANSWER
·确实不该花费，人也不多，所以想用机器人来顶；
·我们自己也感觉，不应该凡事都依赖高级人才的普及，我们追求的互联网科技，并不该定义成“公司里有很多擅长秒杀的高级程序员”（但如果有个很擅长秒杀的机器人，那就很酷了）；
·很感谢我们的行政业务方，他们也有相同的理念，他们愿意陪我们一起挨骂，给予了最大的宽容；
·如何能最大程度满足业务需求，又不在这个勒紧裤腰带的年代耗费过多资源，我觉得眼下火热的大模型是一个很值得探索的答案，即使我们水平不行，也会有更多有志之士能达成目标的。
最后透露一下，技术小哥哥已经认领了故障。蚂蚁CTO也在内网表态了: 这个事情会按故障处理，即便是AI写的代码，蚂蚁AI写出来的代码，也要是可靠的、可信的。
