通信人家园

标题: KDDI事故说明会情况 [查看完整版帖子] [打印本页]

时间: 2022-7-4 11:21

作者: IT看客 标题: KDDI事故说明会情况

KDDIの会見見た。これ凄いわ。・謝罪
・事象の概要の説明（事実確認）
・事象による影響の説明・事象の原因説明
・一次処置対応状況を時系列で説明
・再発防止策（恒久処置）は現在検討中
・再度謝罪これを社長が端的に説明。
技術畑出身かな。信頼度爆上がりした。

・道歉
・事件概要的说明（确认事实）
・事件影响的说明
・事件原因的说明
・按时间顺序说明主要治疗的响应状态
・目前正在考虑复发预防措施（永久治疗）
・再次道歉总裁简要解释了这一点。

附件: K13.png (2022-7-4 11:19, 253.55 KB) / 下载次数 0
https://www.txrjy.com/forum.php?mod=attachment&aid=NTM1NjQ0fGEzMjhkYTZmfDE3NTQzMzkzOTd8MHww

附件: K12.png (2022-7-4 11:19, 236.69 KB) / 下载次数 0
https://www.txrjy.com/forum.php?mod=attachment&aid=NTM1NjQ1fDI4MWQyYWRjfDE3NTQzMzkzOTd8MHww

附件: K11.png (2022-7-4 11:19, 1.51 MB) / 下载次数 0
https://www.txrjy.com/forum.php?mod=attachment&aid=NTM1NjQ2fGMyZWFiZTc0fDE3NTQzMzkzOTd8MHww

附件: K11.png (2022-7-4 11:20, 1.51 MB) / 下载次数 0
https://www.txrjy.com/forum.php?mod=attachment&aid=NTM1NjQ3fGQ0OTM3ZTE3fDE3NTQzMzkzOTd8MHww

时间: 2022-7-4 11:45

作者: Chianti2018

小鬼子，洋洋洒洒扯了半天糊弄媒体。

追根究底，是不是核心网的license 的扩容，没及时买？license activation fee也拖着。

时间: 2022-7-4 13:08

作者: xf008

没看懂日文，是哪个厂家的核心网？出什么事故了？

时间: 2022-7-4 15:44

作者: piview

本帖最后由 piview 于 2022-7-4 15:46 编辑

还是核心数据的原因吧。

时间: 2022-7-4 16:04

作者: tianzhongshan

看不懂

时间: 2022-7-4 16:21

作者: wxy1972

好

时间: 2022-7-4 17:29

作者: rghost

本帖最后由 rghost 于 2022-7-4 17:29 编辑

中间有单节点？不该啊

时间: 2022-7-4 17:34

作者: 马云的云

看不懂日文，我猜是不是就是服务雪崩造成的？

没有做好服务限流熔断呗？

时间: 2022-7-4 17:41

作者: user2020

有没有辞职的？有没有剖腹的？

时间: 2022-7-4 17:43

作者: 莫名的寻道者

user2020 发表于 2022-7-4 17:41
有没有辞职的？有没有剖腹的？

鞠躬就行，现在不流行泡芙

时间: 2022-7-4 20:04

作者: coffee198375

说了一堆废话，切腹吧。。。。

时间: 2022-7-4 21:59

作者: NE90E

割接核心路由失败后，进行网络回退，然后遭遇信令风暴，进而全网瘫痪。

时间: 2022-7-4 23:29

作者: bowdler99

楼上NE90E分析得对，极有可能是这个原因

时间: 2022-7-5 01:02

作者: 无糖麦片

Chianti2018 发表于 2022-7-4 11:45
小鬼子，洋洋洒洒扯了半天糊弄媒体。

追根究底，是不是核心网的license 的扩容，没及时买？license activa ...

那难道还要学某地某运营商出事的时候就发个微博说“为提升通信服务质量，我公司近期进行网络升级”？

时间: 2022-7-5 08:51

作者: tyunicom

这种割接方法对于核心设备来讲就是严重的错误，正确的做法是新建核心路由系统，新旧并行，然后慢慢将旧设备上承载的业务转接到新设备上，这样才能防止这种重大故障。因此KDDI的问题是人祸不是天灾。

时间: 2022-7-5 10:16

作者: funboy

冗余备份，考虑的仅是正常业务量承载，信令风暴则是机制问题。15#说法有道理，这种核心设备替换，应该是承载的转移，不能采用传统硬割接的方法。

时间: 2022-7-5 10:43

作者: 老周部落

tyunicom 发表于 2022-7-5 08:51
这种割接方法对于核心设备来讲就是严重的错误，正确的做法是新建核心路由系统，新旧并行，然后慢慢将旧设备 ...

换一套 CR 要重建一套网络重新对接上下游不现实吧，肯定是新设备配置好完了到点把线换过去完事啊。

时间: 2022-7-5 10:51

作者: K9999Nameless

我只关心有没有补偿所有用户
至少送些流量送些通话送些话费或者免除当月费用做为补偿

时间: 2022-7-5 13:56

作者: shine612

有无好心翻译

时间: 2022-7-5 15:28

作者: bfworld

这个故障报告挺难写的

时间: 2022-7-6 08:44

作者: yugalee

这个关键的位置，热备不做，冷备也不做
这个是不让中国厂家进入，不让早被搬走了

时间: 2022-7-6 10:01

作者: yuanfengding

这个事故值得产业界的深思，基于IP的语音要比传统的PSTN脆弱，基于IP的移动语音要比电路的GSM脆弱，接入注册导致的信令风暴在PSTN是不存在的，在GSM中信令要比LTE/NR少。Everything Over IP？是否会引起潜在的更大的风暴？值得反思

时间: 2022-7-6 10:10

作者: 老周部落

yuanfengding 发表于 2022-7-6 10:01
这个事故值得产业界的深思，基于IP的语音要比传统的PSTN脆弱，基于IP的移动语音要比电路的GSM脆弱，接入注册 ...

Everything Over IP 现在已经实现了，信令爆炸的也只有少数运营商。
思考肯定是需要的，不过这个案例中主要是设备余量不够，后续日本应该加大一点设备冗余系数。

时间: 2022-7-6 10:11

作者: yuanfengding

突然想起来别人的一句话，大意是：事故基本都是人为引起的。

时间: 2022-7-6 10:14

作者: 老周部落

yuanfengding 发表于 2022-7-6 10:11
突然想起来别人的一句话，大意是：事故基本都是人为引起的。

毕竟网络这玩意就是纯粹的人造物，推原因总能到人身上，这个很正常。

时间: 2022-7-6 10:59

作者: happy990

日本运营商又没有工信部考核

通信人家园 (https://www.txrjy.com/)