V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Recommended Services
Amazon Web Services
LeanCloud
New Relic
ClearDB
kincaid
V2EX  ›  云计算

腾讯云发布 0408 故障报告

  •  
  •   kincaid · 15 天前 · 8989 次点击

    原文: https://mp.weixin.qq.com/s/2e2ovuwDrmwlu-vW0cKqcA

    省流版: 故障的原因是云 API 服务新版本向前兼容性考虑不够和配置数据灰度机制不足的问题。

    本次 API 升级过程中,由于新版本的接口协议发生了变化,在后台发布新版本之后对于旧版本前端传来的数据处理逻辑异常,导致生成了一条错误的配置数据,由于灰度机制不足导致异常数据快速扩散到了全网地域,造成整体 API 使用异常。

    发生故障后,按照标准回滚方案将服务后台和配置数据同时回滚到旧版本,并重启 API 后台服务,但此时因为承载 API 服务的容器平台也依赖 API 服务才能提供调度能力,即发生了循环依赖,导致服务无法自动拉起。通过运维手工启动方式才使 API 服务重启,完成整个故障恢复。

    想起了之前传闻某团队修复健康码因为健康码无法展示进不了大楼的事情了

    73 条回复    2024-04-20 06:09:51 +08:00
    hugi
        1
    hugi  
       15 天前 via iPhone   ❤️ 2
    好奇健康码那事后来在哪修复的,门口蹲着?
    sakilascott
        2
    sakilascott  
       15 天前   ❤️ 1
    灰度跟生产不可能一模一样,系统越复杂,差异越是大。
    在大多数复杂系统中,这个问题是个千古难题。
    kincaid
        3
    kincaid  
    OP
       15 天前
    @hugi 人家运维公司说不清楚,不知道有没有当时的大佬现身说法了,https://news.sina.cn/gn/2021-12-22/detail-ikyamrmz0473496.d.html
    standchan
        4
    standchan  
       15 天前
    跟滴滴的那个有点像,升级出现问题后回滚困难。强行回滚时候又发现互相依赖的问题。
    BeiChuanAlex
        5
    BeiChuanAlex  
       15 天前   ❤️ 6
    随着时间的发展,人员不断流动,系统越来越大,业务越来越复制,代码越来越多,数据越来越多,导致的结果就是没人能了解全局了,所以这肯定不是最后一次故障,以后还是会有的。
    weijancc
        6
    weijancc  
       15 天前
    结果是因为升级 API 导致的... 是不是该抓一个程序员来祭天
    kincaid
        7
    kincaid  
    OP
       15 天前
    @weijancc yysy 拉个程序员祭天意义不大 hhh
    alanhe421
        8
    alanhe421  
       15 天前
    循环依赖的解决办法不就是再引入一个 C ,解开 AB 的相互依赖?
    zmzeng12
        9
    zmzeng12  
       15 天前 via iPhone
    API 不兼容导致了事故,但灰度机制不足才导致事故扩大到了全网。
    hongfs
        10
    hongfs  
       15 天前
    crackidz
        11
    crackidz  
       15 天前   ❤️ 1
    挺好的,发一个故障分析,起码态度到位了
    okaysir
        12
    okaysir  
       15 天前 via Android
    复杂度提升导致崩溃度增加。国内 IT 界甚至这届人类体系都是这趋势。
    xmumiffy
        13
    xmumiffy  
       15 天前 via Android
    “期间共有 1957 个客户报障” 控制台都打不开了,是怎么报障的,只有有客户经理的才能算受到影响?
    totoro52
        14
    totoro52  
       15 天前
    有人要打包走人了
    yanpj1992
        15
    yanpj1992  
       15 天前
    @xmumiffy 估计工单系统还正常吧
    StinkyTofus
        16
    StinkyTofus  
       15 天前
    @alanhe421 #8 没有用的, 谁都知道问题的解决办法, 但是随着人员流动, 系统越来越庞大, 所有的机制都会维护不到位。
    caqiko
        17
    caqiko  
       15 天前 via Android
    题外话,你们的 100 元代金券到账了吗?
    xmumiffy
        18
    xmumiffy  
       15 天前
    @yanpj1992 工单在控制台里面,整个控制台当时都 502/504/internal error 了
    Hopetree
        19
    Hopetree  
       15 天前
    我看了一个文章,是关于服务状态监控的,他们的服务状态监控就是个摆设,状态有延迟也就算了,还不全(比如服务 A 挂了也影响到了 B ,他们的状态里面没有显示 B 的异常)
    xiaket
        20
    xiaket  
       15 天前   ❤️ 2
    相比于国外厂商的 PIR, 这个故障分析很是避重就轻, 避实就虚.
    louisxxx
        21
    louisxxx  
       15 天前 via iPad   ❤️ 1
    同时回滚到旧版本,并重启 API 后台服务,但此时因为承载 API 服务的容器平台也依赖 API 服务才能提供调度能力,即发生了循环依赖。

    这是哪个脑残设计的自己把自己锁死在房间里的架构?
    GarethChu
        22
    GarethChu  
       15 天前
    100 元代券都还没到账
    xierqii
        23
    xierqii  
       15 天前
    互联网公司循环依赖太常见了。比如去年 yuque 故障、阿里云故障、滴滴故障,其背后都和循环依赖有关系。一个关键服务挂掉后,其他服务没法直接恢复。
    GenericT
        24
    GenericT  
       15 天前 via Android
    @louisxxx 不都这样吗?还记得 Facebook 不,机房的锁也是内网控制的,内网挂了机房连门都进不去。
    odifjg9384hg
        25
    odifjg9384hg  
       15 天前
    没进过大厂, 不知道他们备份机制是怎么样的, 我们上线前都会备份当前版本为 docker1, 即将上线的版本是 docker2, 上线完成后的版本是 docker3, 出现依赖问题就全部回滚为 docker1, 几年从没出过问题
    frankilla
        26
    frankilla  
       15 天前
    @xmumiffy #12 我当时就用的在线客服报障的啊
    frankilla
        27
    frankilla  
       15 天前   ❤️ 2
    之前不是有人在吹外国怎么怎么样,国内怎么怎么样。。。听的我直犯恶心,现在腾讯发问了,不知道这类人怎么回复。
    esee
        28
    esee  
       15 天前
    100 代金券说好要给,最后都不舍得给,抠门的要死
    hancai2
        29
    hancai2  
       15 天前
    @odifjg9384hg 报告里面说了都嘛,回滚依赖于平台的 API ,而 API 又故障了,最终是靠运维手动回滚的。 你们公司应该就是纯手工回滚 docker2 , 就不存在这种循环依赖了。
    n18255447846
        30
    n18255447846  
       15 天前
    100 代金券未到账,找售后也没反应了
    weeei
        31
    weeei  
       15 天前
    @xmumiffy 我们是通过企业微信群报的
    w3cll
        32
    w3cll  
       15 天前
    @BeiChuanAlex 那就重构 🐶
    chen1706
        33
    chen1706  
       15 天前
    tigerstudent
        34
    tigerstudent  
       14 天前
    @alanhe421 #8 那以后的 C ,不就成了现在的 B ?
    gotosre
        35
    gotosre  
       14 天前
    @Hopetree 摆设, 肯定是摆设, 1. 状态不及时更新 2. 对外公布异常/故障要层层审批
    alanhe421
        36
    alanhe421  
       14 天前
    alanhe421
        37
    alanhe421  
       14 天前
    @alanhe421 更正:AC ,BC
    Rehtt
        38
    Rehtt  
       14 天前
    tigerstudent
        39
    tigerstudent  
       14 天前
    @alanhe421 #37 所有服务不还是依赖了 C ,难道 C 以后不会迭代更新了?
    dys0327
        40
    dys0327  
       14 天前
    @caqiko #17 没有
    BadFox
        41
    BadFox  
       14 天前
    点开非法加冯公众号看看有没有新的文章。
    BadFox
        42
    BadFox  
       14 天前
    hellomsg
        43
    hellomsg  
       14 天前
    似曾相识
    hellomsg
        44
    hellomsg  
       14 天前
    草台班子
    Yuesh1
        45
    Yuesh1  
       14 天前
    @xiaket 不知道为什么在周末发,希望不是我的恶意揣测
    mikaelson
        46
    mikaelson  
       14 天前
    图 2 那种流量图,是什么工具画的?之前运营商给我流量图也是这种样式的。
    kkk123
        47
    kkk123  
       14 天前
    对比 cf 的复盘,企鹅的毫无诚意
    jeremyl313
        48
    jeremyl313  
       14 天前
    @n18255447846 我的 4 月 12 日给了
    me1onsoda
        49
    me1onsoda  
       14 天前
    为什么在周末发?怕别人不知道你腾讯 996 啊。。
    standchan
        50
    standchan  
       14 天前
    @w3cll #32 重构除了引入新的坑之外,然后又会重新走一遍上面的流程。总之就是不停的有坑哈哈哈哈
    LieEar
        51
    LieEar  
       14 天前
    再也不觉得大厂牛逼了,这么庞大复杂的系统,原来也是草台班子...
    mikywei
        52
    mikywei  
       14 天前
    国内很多企业不是技术位需求服务,而是为了跟进新技术和显得自己有技术而使用新技术。。。殊不知新技术就是不稳定的。
    xoic
        53
    xoic  
       14 天前
    别说这种大厂了,就是小公司在几年之后,人员流动,系统逐渐复杂,根本没有人会想去了解全局的。大多数人都会直接摆烂,跟着原来的流程逻辑走,能打补丁就打补丁,于是祖传屎山代码就出现了,然后指不定哪天就原地爆炸了。

    老板们都以为人员迭代业务交接的清清楚楚明明白白是理所当然的,所以在他们看来人员迭代不会有代价的,但事实上培养一个能了解全局的员工是需要大量时间的,有时候倒不是刻意不配合交接,东西太多太杂,交接的时候根本没想起来,那么一个小问题导致故障这种情况就太正常了,剩下的人抓瞎就更正常了。
    chperfect
        54
    chperfect  
       14 天前
    按照描述我觉得应该是浏览器缓存的旧的前端页面 js ,然后请求改动后的接口,导致异常。
    huixia0010
        55
    huixia0010  
       14 天前
    @caqiko 并没有
    8355
        56
    8355  
       14 天前
    @me1onsoda 出这么大事儿 复盘会还没开就敢休息吗。。。这确实也不现实。
    Ritter
        57
    Ritter  
       14 天前
    @n18255447846 我的已经收到了 可以再查询一下
    hellomsg
        58
    hellomsg  
       14 天前
    很搞笑:
    [腾讯云] 您好,您之前提交的代金券申请,经过后端复核您在故障期间未登录控制台,并且未有调用云 API 相关接口记录,因此判断您未受到本次故障的影响,非常抱歉暂无法为您申请代金券。

    感谢您关注腾讯云,欢迎随时体验相关产品和服务,若您在使用产品时遇到任何问题,请随时联系我们,感谢您的理解与支持!
    hellomsg
        59
    hellomsg  
       14 天前
    腾讯云这个月的 kpi 是不是想尽办法少补偿用户
    xmskf
        60
    xmskf  
       14 天前
    垃圾腾讯云,说好的补偿代金卷,后面又不给了!
    mkroen
        61
    mkroen  
       14 天前
    @hellomsg #58 我也收到了。虽然也就 100 ,但感觉好小气哈哈
    panisertoller
        62
    panisertoller  
       14 天前
    @xmumiffy api 错误会被系统统计到,所以可以得到错误人数,再加上后续主动报障的工单。就算出来了。
    panisertoller
        63
    panisertoller  
       14 天前
    @hellomsg 没什么搞笑的,估计售后被薅秃了
    panisertoller
        64
    panisertoller  
       14 天前
    @xmskf 被判定为薅羊毛了,先自查下,确定自己被影响了,要再多些也没毛病。
    kun775
        65
    kun775  
       13 天前
    @esee 是的,拖了 5 天,最后说故障期间没有登录记录,不给券,RTM ,我打算迁移服务到阿里云了
    kun775
        66
    kun775  
       13 天前
    @panisertoller #64 明知道那时故障了还要去登录,才能代表受到影响?徒增系统负载罢了,看来以后得弄个脚本,每分钟去登录一次控制台
    Akiya
        67
    Akiya  
       13 天前
    API 循环依赖,一直以为只有草台班子才能够搞出这种
    saveai
        68
    saveai  
       13 天前
    @caqiko 没有,我问了客服,他们说未受到影响。。。。
    zebwqfox
        69
    zebwqfox  
       13 天前 via Android
    难道不是 b 站 slb 炸了然后 vpn 连不进去吗(
    wheat0r
        70
    wheat0r  
       13 天前
    @GenericT #24 cf 去年 11 月 PDX-04 停电故障,据说配电室门禁是由配电室供电的
    GenericT
        71
    GenericT  
       13 天前 via Android
    @wheat0r 都一样的,反倒是说只有大一点的公司才有余力去做这些内部的依赖
    louisxxx
        72
    louisxxx  
       9 天前
    其实知道会自己锁死自己的。但过度自信,二是为了方便统一管控权限。后面估计涨记性了,毕竟停一天损失上亿
    louisxxx
        73
    louisxxx  
       9 天前
    @GenericT 其实知道会自己锁死自己的。但过度自信,二是为了方便统一管控权限。后面估计涨记性了,毕竟停一天损失上亿
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   993 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 19:20 · PVG 03:20 · LAX 12:20 · JFK 15:20
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.