饿了么技术通告

[201647][P4]饿了么技术通告－12月6日热卖美食返回商家列表为空事故

张贴在 2016年12月6日 通过 饿了么 — 暂无评论 ↓

事故时间：

2016年12月6日

事故现象：

APP端热卖美食链接打开提示“无推荐餐厅”

事故原因：

1. 日志使用的同步写，没有用异步写，并且开启了可以下线的syslog。

2. 以下三个原因导致GC频率高，并且Young Gen转移到到Old Gen以后容易导致Old Gen碎片化严重，引发Full GC。

     a.单条日志体较大，容易造成内存碎片。

     b.大量HashMap存在内存中,HashMap本身内存使用率不如数组效率高。

     c.单个请求耗时较长（高峰期upper95时间达到300ms左右），导致内存不能快速释放，从而升级到Old Gen，而在Old Gen中太大的内存容易导致碎片。

 

事故定级：

 [P4]

事故责任人：

数据运营部

事故复盘：

11:06  Noc反馈大屏热卖美食qps监控指标曲线异常。

11:13  DT（大数据）执行回滚[第一次回滚，此次回滚版本错误]。

11:21  Noc测试热卖美食入口，安卓手机首页的热卖美食是可以打开，ios手机首页热卖美食打开提示异常。

11:25  架构师反馈需要加业务指标，大屏的监控指标难以反映异常状态。

11:29  DT（大数据）执行回滚[第二次回滚]。

11:34  热卖美食接口降级。

11:37  后台业务研发反馈首页的热卖美食入口已经替换成一元霸王餐。

12:14  架构师反馈很多的thread夯仔写日志上。

12:15  DT（大数据）反馈异常原因找到，是执行回滚版本时第一次出错。

12:33  架构师反馈get_guess_you_like_banner   dt.hotfood调用量是从哪里进来的

           DT（大数据）反馈从app的发现页，如果热卖美食入口异常，发现页的显示热卖美食界面就消失。

13:34  DT（大数据）加入异步async日志同步。

13:41  后台业务研发反馈热卖美食入口已经恢复正常。

13:49  后台业务研发首页霸王餐替换成热卖美食。

 

改进措施：

1、async写log。

2、gc策略调整。

3、timeout机制调整。

4、扩容机器（暂时）。

5、大屏业务指标拆分开。

6、代码层面优化：

   a.压缩日志大小，算法Feature Log只打印前20条记录。

   b.提高Rank性能，下线耗时较高的三个算法版本，等待优化完成再上线。

   c.代码层面减少HashMap使用，提高内存使用率。

7、Etrace增加GC 数量告警。

事故现场：

1. 事故期间响应时间变化曲线

2.期间GC曲线变动

3. 日常正常情况下请求响应时间

4. 日常正常情况下Rank核心逻辑耗时

事故上下文：

热卖美食目前需要输出大量Feature Log到磁盘，12月6日的时候还是使用的同步写日志方式，并且日志较大，一方面容易产生较多大块内存，不利于内存快速回收。

另一方面增加了请求响应时间，也间接影响内存回收。优化的方向还是从两个方面入手，一是减少日志大小。二是优化Rank速度，提高响应时间。

 

注：

1.运营事故分级规范 v 1.2

2.关于事故赔偿规范及流程

张贴在2016年饿了么技术通告分享

[201649][P2]饿了么技术通告－12月2日zookeeper故障事故

张贴在 2016年12月2日 通过 饿了么 — 暂无评论 ↓

事故时间：

2016年12月2日

事故现象：

导致从app首页面大部分入口进入二级页面后页面显示异常，商家列表无法正常显示。

事故定级：

[P2]

事故原因：

rootcasue待定（后续补充）

事故责任人：

框架组工具部、平台内容研发部

判定依据：1、故障主因zookeeper不可用导致（rootcause待查 ）。

2、zeus.ers业务在发布时判断业务是否正常的标准不充分，未能正确、有效履行灰度策略。

事故复盘：

12月1日

20:24 QC  zookeeper出现 outstanding request 告警

12月2日

21:10 biz.booking发布。

21:20 框架组同步信息：灾备zookeeper重启。

21:28 框架组反馈某云内网络ping的延迟100ms。

21:36 框架组反馈某机房 zookeeper有问题。

21:44 zeus.ers,napos.operation.service.lucifer 准备发布。

21;46 zeus.ers发布。

21:49 noc&框架组发布群同步:[暂停一切发布]。

此时zeus.ers发布一半，已发机器async1、async2、async3、async4、async5、async6、sync1、sync2。

21:49 app外卖首页正常，打开二级入口进入提示异常界面。

22:33 框架组zookeeper出现故障建议:1、xg重建一套zookeeper集群，按恢复数据流程来；如果恢复在原zookeeper集群上建haproxy把流量导入新集群。 2、灾备开始切灾备，紧急切换是有演练的。3、紧急修复zookeeper。

22:43 框架组反馈已经在新建新的zookeeper集群

22:55 ops同步老的zookeeper停掉了。

23:08 框架组反馈新的集群已经新建完毕，正在测试。

23:08 业务正在恢复，已经有正常的数据出现。

23:22 ops反馈下单错误量还是没下降，zeus.ers那边的连接仍然存在问题。

23:26 框架组反馈暂时恢复不是因为新建的 zookeeper, 而是因为关了 zookeeper。新zookeeper上线以后依然存在问题，关闭新zookeeper。SYN flooding 应该是切换的瞬间大量客户端重连 zookeeper导致的。

23:34 SRE组反馈time_wait升高，显示是zookeeper主动断开的，然后syn recv升高，显然客户端重连恢复了。 当时5台机器tcp sync ack有问题。

23:36 框架组新 zookeeper集群通过 HAProxy 转发后 某机房的kafka-5 机器上没有连接机房的kafka -1,-2,-3,-6 有连接，其中kafka-2 机器上有两万连接，其余连接数每台约为 4k。

23:40 切掉QC请求

23:51 故障业务完全恢复

 

改进措施：

1. zookeeper 集群的 voter 节点迁移到新服务器。

2. 完善 zookeeper 集群的监控指标 。

3. ZeusCore 应用从直连 zookeeper 改为连接 huskar api 。

4. zues.ers新增服务检测脚本。

 

事故上下文：

SOA 使用 zookeeper 作为数据存储方案, Python(zeus_core) 程序会直连 zookeeper 程序获取配置和服务列表信息等.作为 SOA 的中枢, 在某机房维护 5 个 voter 节点, 在某云中维护 3 个 observer 节点. 但因早期上某云原因, 还有部分应用在直连 某机房的 zookeeper。

注：

1.运营事故分级规范 v 1.2【草案】

2.关于事故赔偿规范及流程

张贴在2016年饿了么技术通告分享

[201646][P3]饿了么技术通告－11月21日热卖美食返回商家列表为空事故

张贴在 2016年11月21日 通过 饿了么 — 暂无评论 ↓

事故时 间：

2016年11月21日

事故现象：

APP端热卖美食链接打开提示“无推荐餐厅”

事故定级：

[P3] 

事故原因：

写kafka和落地文件是都先转化为json格式，日志体又比较庞大，而写kafka&文件的线程池数量过小（最大），导致生产速度远远超过消费速度，

都积压在内存中，导致GC频繁并且GC作用不大。

事故责任人：

数据运营部

事故复盘：

11月21日

11:09 Noc&Banshee［监控工具］通知告警，接口响应时间超时，打开热卖美食页面，提示没有找到商家。

11:15 尝试重启，短时间恢复，但是不久之后迅速又进入超时状态。

11:20 查看Etrace［监控工具］，发现4台线上服务器Old GC时间均过长。

11:50 问题排查，再次尝试重启，之后响应时间慢慢恢复，原因是业务高峰已经过去。

11:54 业务曲线恢复正常

11月22日

00:30 问题排查，1. 初步排查问题是内存设置不合理（16g），选择一台尝试修改java最大内存数为12g，2 soa 

worker线程数设置过小（单台50*4），导致QPS过高容易worker不够，后修改为单台线程200。

11:04 修改后的方案再次出现请求时间超时问题，尝试重启恢复后短时间再次出现超时。

11:14 跟踪异常日志发现一个异步写kafka&文件日志的线程池出现RejectedExecutionException报错，而这个写日志文件

是近期新上线的一个功能，作用是替换kafka方案，但是由于下游的日志文件落地方案还在进行中，所以原来的kafka方案还没有下线；紧急关

闭写kafka&文件，服务恢复正常。

11:28 由于算法统计需要，尝试重新打开feature日志写文件，服务正常。

11:32 再次打开kafka日志，服务迅速重新超时，紧急再次关闭，服务慢慢恢复正常。

改进方案：

1. 下线kafka写日志，只保留写日志文件。

2. kafka写由同步写修改为异步写。

3. 开发对新功能上线缺少必要的性能测试，对线上服务没有警惕性；再次强调线上服务的重要性。

4. 开发流程缺少必要Review过程，导致对于潜在的风险点没有及时发现，后续所有上线代码强制发送Merge Request并组内相互Review。

5. 强制上线大的feature必须进行性能测试。

6.GC加监控。

7.线程池队列，连接池，SOA队列，worker数量等参数设置合理。 

事故现场：

事故上下文：

大数据热卖美食线上服务推荐需要将日志落地方式从kafka实时修改为通过文件定时传输。在文件落地方式完全替换kafka方案前，需要测试文件传输方案可行，同时线上kafka方案还需要存在用于落地数据，所以保留了两个方案同时存在。写文件和写kafka使用同一个后台线程池，同时写线程池处理速度小于生产速度，导致数据堆积在队列内，jvm堆内存迅速消耗殆尽。

注.

1.运营事故分级规范 v 1.2

2.关于事故赔偿规范及流程

张贴在2016年饿了么技术通告分享

[201645][P4]饿了么技术通告－11月6日餐厅活动显示异常事故

张贴在 2016年11月6日 通过 饿了么 — 暂无评论 ↓

事故时间：

2016年11月6日，持续8min

事故影响：

餐厅活动展示异常

事故定级：

[P4] 

事故责任人：

技术运营创新中心

事故原因：

服务器某机器的网线从千兆衰变到百兆导致带宽被打满（1Gbps）

事故复盘：

11:01 监控系统出现大量eps（活动展示）报警，同时noc发现下单等业务曲线出现异常，noc第一时间联系运维排查问题。

11:05 noc oncall相关产研、运维上线排查，并升级。

11:07 平台内容开发表示先降级eps（活动展示）展示接口，只保留5%

11:08 noc降级eps（活动展示）接口并保留5%，此时活动显示已基本恢复正常，但是由于eps（活动展示）降级接口存在问题，会影响到活动满减，在eps（活动展示）降级后，活动满减开始异常

11:12 noc 操作eps（活动展示）接口降级恢复到15%并观察业务是否正常

11:13 noc 操作eps（活动展示）接口降级恢复到30%并观察业务是否正常

11:15  noc操作eps（活动展示）接口恢复到70%，发现eps（活动展示）告警又开始增加，回退至50%。

11:20 noc操作eps（活动展示）接口恢复到100%，平台内容研发发现日志有大量报警，表示再次降级eps（活动展示）接口恢复到70%

11:32 通知所有相关运维、产研人员到noc复盘。

12:05 产品研发提供一个新的降级开关替代之前有影响的降级开关，并将有影响的降级开关恢复至100%，逐渐将新降级开关恢复至90%，活动满减基本恢复。

12:25 所有已降级的接口恢复，线下反馈、大屏曲线均恢复正常。

改进措施：

1、和业务达成一致，硬件故障时及时通知业务方，并markdown服务(SOP：业务运维：半天，DBA:三天内)，再进行硬件修复，修复后通知相关业务运维or DBA做业务恢复。

2、提前完成机器初始化和redis 部署，准备扩容使用的命令和脚本。

3、提升 redis 迁移速度，初期使用脚本来提升迁移速度，长期做资源半自动化扩容。

4、剔除异常节点，并压测。

5、提升网卡故障修复优先级，现有故障的12台服务器已经修复完毕。

6、提高网卡故障检测频率，由一天一次改为1小时一次。

7、全面核查现有bond异常的列表，并修复(不包括老网段和老机器) 。

8、对优化硬件故障检测频率，并建立故障同步、修复机制 。

9、对marketing（红包分享）服务的机器和redis集群扩容。

10、marketing（红包分享）优化代码，减小缓存在redis里数据量的大小（曹浔超－11月6日完成）

11、marketing（红包分享）对redis超时从3000ms设置为30ms。

12、针对项目核心get接口，定期在全链路压测时单独压测，完善全链路压测case覆盖以及接口比例优化。

13、EPS对marketing（红包分享）的超时从500ms降低到250ms，快速失败保护餐厅列表页的展示。

事故现场：

eps（活动展示）接口出现大量报错，餐厅列表无法显示，接口降级后活动满减出现异常

注.

1.运营事故分级规范 v 1.2

2.关于事故赔偿规范及流程

张贴在2016年饿了么技术通告分享

[201644][P4]饿了么技术通告－11月4日 DAL（框架工具）单节点内存耗尽导致订单支付相关业务异常事故

张贴在 2016年11月4日 通过 饿了么 — 暂无评论 ↓

事故时间：

2016年11月4日，持续24min

事故定级：

［P4］

事故责任人：

框架工具组

事故原因：

dal单节点内存耗尽几乎无响应，因此触发了客户端C3P0连接池一个bug（是否触发C3P0的bug待最终确认），

从而导致订单支付相关业务曲线下掉。

注：关于C3P0的bug已复现，需要更进一步的源码分析和测试。

事故复盘：

17：09  NOC发现大屏支付相关指标开始下掉，第一时间升级到上级，同时联系DBA排查，确认网络无异常以及线下无反馈。

17：11   NOC同步应急群及相关业务群，联系DAL和业务运维排查。

17：16  NOC联系用户交易研发紧急降级eps（餐厅活动展示）相关接口（此操作属于常规应急操作）。

17：18  用户交易研发开始降级eps（餐厅活动展示）相关接口。

17：20  NOC拉群继续排查跟进。

17：25  DAL同事重启有问题的dal应用。

17：32  大屏曲线开始恢复正常，同时用户交易研发恢复降级的eps活动展示接口。

17：33  NOC及时同步客服群：降级已恢复，可以引导用户重试。

改进措施：

1.支付优化C3P0参数maxstatements size的设置。

2.DAL优化内存使用。

3.业务运维灰度去掉DAL节点的SWAP（交换分区）。

4.goproxy（框架工具）调研完善七层心跳协议。

事故现场： 

dal单节点内存耗尽导致大屏订单支付相关曲线下降抖动

事故上下文：

17：08分，NOC发现大量报警频发，同时看到大屏支付相关曲线下降，第一时间升级上级并联系DBA、业务运维和DAL进行排查。随后拉群处理，并联系相关人员来NOC监控室进行排查，相继确认eos无变更、数据库正常。

17：16分联系用户交易研发降级eps（餐厅活动展示）相关接口，以防业务影响扩散。随后发现一个dal节点内存不足，重启有问题的dal节点。

17：32分大屏曲线开始恢复正常。

注：

1.运营事故分级规范 v 1.2

2.关于事故赔偿规范及流程

张贴在2016年饿了么技术通告分享

[201643][P4]饿了么技术通告-11月1日餐厅列表无法刷出事故

张贴在 2016年11月1日 通过 饿了么 — 暂无评论 ↓

事故时间：

2016年11月1日， 持续18min

事故定级：

[P4]

事故责任人：

平台内容研发部

事故复盘：

10:09 一线运营反馈部分餐厅无法下单

10:13 Noc拉群处理部分餐厅无法下单问题（影响可忽略）

10:28 平台内容开发同事反馈由于餐厅上了不合法的活动导致无法下单，11月1日napos（商户端）开发上活动，导入数据，导入完成后数据并不一致

10:34 平台内容开发计划通过手工跑脚本的方式开始下掉不合法的活动

10:50 平台内容开发开始跑脚本下线活动，此刻redis已经达到瓶颈，由于脚本会再次调用redis，导致redis流量超上限

10:54 Noc发现下单曲线下掉约15%左右，部分app餐厅列表无法显示，eps（餐厅活动平台）超时，Noc联系相关运维开发进行处理

11:00 平台内容开发伙伴反馈redis延迟从小于1ms达到75ms，需紧急扩容，dba同事进行紧急扩容

11:09 平台内容开发停止跑脚本操作，报服务线程数不足，业务并没恢复

11:11 平台内容开发开始降级eps（餐厅活动平台）相关接口并重启napos.marketing（商户营销）相关服务

11:14 平台内容开发降级完成，此刻业务恢复正常

11:49 平台内容开发100%恢复前端美食活动展示

事故原因：

诱因：11月1日凌晨五点导入活动数据后数据不一致，导致部分餐厅无法下单

根因：从eps（餐厅活动平台）导入数据到marketing，开发未同步信息至运维 ，开发跑脚本下线不合法活动，此刻redis延迟已经达到瓶颈，脚本

再次调用redis造成redis网络流量超

上限，造成redis大量请求超时，同时由于eps（餐厅活动平台）降级未及时导致业务恢复慢。

改进措施：

1.开发做关键路径业务迁移，属重大变更，需同步给相关业务运维与Noc同时加强高峰期谨慎操作意识，严谨评估自身操作影响

2.应急措施：（1）noc需做好消息扩散方案，第一时间所有相关人员知晓问题

                        （2）“高峰期”遇到关键路径变更意外影响事件，一切“以小损失替换大损失”的操作为准

                        （3）事故期间，以NOC为调度指令为准，进行调度的时候相关团队执行力有待改进

3.eps（餐厅活动平台）相关降级同步noc与业务运维，进行演练操作

4.调整redis容量报警为50%，预估最高峰流量值提前做好redis预警，多为redis预留两个机器节点避免redis扩容慢

5.合理设置eps调用napos.marketing接口的超时时间

6.设置marketing降级开关并同步给noc和业务运维

7.刷redis（数据库）预热缓存，关注redis相关容量

8.redis使用姿势，是否把redis当作queue（消息队列）来使用，排查etrace（监控和排障系统），是否有对redis有相关于lpush的操作

9.灰度之前需提前准备好灰度回退方案

事故现场：

平台内容开发为修复部分餐厅无法下单做业务变更导致餐厅列表无法刷出

事故上下文：

平台内容开发于10月25日开始上线美食活动，在11月1日凌晨5点全量灰度导入数据，导入后由于数据不一致导致部分餐厅无法下单，在得到前线运营反馈部分餐厅

无法下单的消息后，平台内容开发跑脚本下线活动有问题的餐厅导致数据量暴增，redis没有及时扩容，一下子打爆了redis（redis本身已达到瓶颈，之前没有做好容

量预估），造成redis请求超时，从而导致eps无法获取marketing的redis请求数据导致餐厅列表无法刷出，业务异常。

注：

1.运营事故分级规范 v 1.2

2.关于事故赔偿规范及流程

张贴在2016年饿了么技术通告分享

[201642][P4]饿了么技术通告－10月25日某机房网络故障导致下单业务抖动

张贴在 2016年10月25日 通过 饿了么 — 暂无评论 ↓

事故时间：

10月25日，持续38min。

事故定级：

［P4］ 

事故责任人：

技术运营创新中心

事故原因及解决方案：

由于运营商xx网内链路中断，导致部分xx运营商方向流量绕行xx运营商，xx运营商部分出口拥堵， 造成部分 BGP 客户xx运营商、xx运营商方向品质下降，

经上报运营商并持续疏导优化流量至其他出口后，线路恢复。

事故复盘：

19：57分：大量报警频发，大屏订单主业务曲线出现波动，noc发现网络有异常，noc立刻联系基础运维&xx机房进行排查；

20:  01分:  noc oncall基础运维跟进了解排查进度，xx机房工程师查看其内网未发现异常；

20:  05分：xx机房工程师测试与运营商物理链路正常，公网排查发现电信路由异常绕行联通；

20:  09分:  业务仍未恢复，noc oncall业务运维做出口切换评估和准备；

20：10分：xx机房工程师定位故障为xx运营商路由异常，导致部分流量绕行xx运营商，同时xx机房工程师开始临时疏导流量；

20：22分：基础运维切到第二出口，业务开始恢复，但微信支付没有恢复；

20：25分：xx机房工程师完成流量疏导；

20：35分：基础运维再次切回第一出口，业务恢复。

改进方案：

xx机房方：

1. 已要求运营商，在网络故障发生第一时间，优先为xx机房调优出口；

2. 已联系运营商并要求对方升级近期常出故障设备，并保障xx机房的网络品质 ；

3. 加快监控系统的升级，以便能够在发生故障的第一时间发送具有饿了么信息的告警邮件，并迅速定位故障原因 ；

4. 告警邮件已加入xx机房和饿了么接口人邮箱，xx机房接口人发现告警后会第一时间通知到饿了么联系人，以便饿了么了解信息，加快故障响应和处理速度。

我方：

不定期进行切换演练（技术运营部 长期进行）

事故现场：

在线支付下单业务曲线下掉抖动

事故上下文：

下单业务受直接影响下掉，导致napos（商户系统）接单和物流运单同比下跌。

注：

1.运营事故分级规范 v 1.2。

2.关于事故赔偿规范及流程。

张贴在2016年饿了么技术通告分享

[201641][P4]饿了么技术通告－9月29日物流系统异常事故

张贴在 2016年9月29日 通过 饿了么 — 暂无评论 ↓

事故时间：

2016年9月29日，持续时间14min

事故定级：

[P4] 

事故责任人：

商业策略产品研发部

事故现象：

大物流曲线异常，商家无法呼叫配送。

事故原因：

      （1） zion.srv.invoker(配送后端服务)发布之前没有在huskar(配置管理系统)上配置HUNMING_KA_PRODUCT_ID这个key，因为zion.srv.invoker是从其他组接过来的，在alpha和beta(测试环境)都有配置，之前是里面相关接口没有消费这个配置，接手过来之后有新的需求，提供给物流的接口需要消费这个配置，但是发布之前线上没有进行配置，导致发布的时候zion.srv.invoker出现大量熔断；

      （2）zion.srv.invoker异常时，开发第一时间没有发现业务异常，同时没有严格遵守灰度发布的规范，在较短时间内发布zion.srv.broker(配送组外接口)，发布完毕之后才发现问题，从而较长时间影响到物流相关业务。

事故影响：

       大物流系统异常，导致物流运单生成异常，生成不了运单。

事故复盘：

       14：20 napos(商户系统)开发灰度发布zion.srv.invoker，当时etrace(监控和排障系统)刷新的比较慢，所以短时间内没有发现异常；

       14：22 为了要全量上线好让另一个系统快速线上验证，所以两个appid灰度时间比较短，进而对zion.srv.broker进行发布。期间noc发现大屏物流所有业务曲线异常；

       14：23 noc通知运维进行排查；

       14：25 运维通过etrace曲线以及日志查找到zion.srv.broker有大量熔断；

       14：28 运维查看到发布系统有对应的appid发布记录，noc联系napos开发紧急处理；

       14：30 napos(商户系统)开发回滚zion.srv.broker，回滚之后业务未恢复；

       14：32 发现zion.srv.invoker缺失一项huskar配置；

       14：34 对zion.srv.invoker进行回滚；

       14：36 回滚完毕之后，物流系统恢复正常。

改进方案：

       1. 线上huskar配置，在读取时添加线上默认值，配置完毕之后进行doublecheck，防止出现huskar配置丢失，避免影响到相关业务。

       2. 开发发布时如果发现异常，先对全部appid进行回滚，保障第一时间恢复业务，然后再排查原因。

       3. 严格遵守灰度发布规则，并且开发在发布时密切关注etace上exception曲线，第一时间发现问题，进行回滚。

       4、物流内部apollo(物流流转平台)有异常时关闭proxy，让订单临时堵在rmq里面，下游问题修复之后，再打开，减少丢单。

       5、产品改进方案（全推补偿逻辑）（下面是apollo与eos讨论的结果）

     （1）对于运单生成失败apollo需要生成消息给eos进行后续处理（对于新eos接口调用方式，考虑设置内部补偿的超时时间）；

     （2）eos(负责整个订单状态的流转)这测会做出各种超时情况的兜底策略（不管物流怎么样，eos在发现运单状态卡死后强制单侧兜底并通知运单进行取消）；

     （3）接下来会慢慢考虑apollo和主站以及napos的解耦，三步，不封装状态，不做短信推送，不和UI呈现挂钩。

   备注：此方案后续由运单中心和订单中心的双方产品共同梳理细化方案。

事故现场：

     （1）物流相关的曲线在故障时间段出现异常;

     （2）zion.srv.invoker;zion.srv.broker熔断了。

事故上下文：

        napos开发灰度发布zion.srv.invoker，上层支付和订单没有受到影响，下层物流业务受到大范围的影响，导致商家的订单扭化不成运单，无法通知骑手配送。

注：

1.运营事故分级规范 v 1.2。

2.关于事故赔偿规范及流程。

张贴在2016年饿了么技术通告分享

[201640][P4]饿了么技术通告－9月18日某机房网络故障

张贴在 2016年9月20日 通过 饿了么 — 暂无评论 ↓

故时间：

2016年9月18日，持续18min

事故定级：

P4

事故责任人：

技术运营创新部

事故现象：

 订单无法推送到物流团队

事故原因：

docker做测试时，服务器网络信息配置与某机房xxx网段的网关冲突，导致xxx网段不可用

事故影响：

大物流系统、log日志系统异常，期间各群里大量反馈物流系统不可用

事故复盘：

15：34 大物流监控指标曲线出现异常

15：35 noc反馈给物流运维和开发

15：37 发现某房内网xxx网段ping不通，访问数据库连接不上

15：38 noc联系基础运维人员进行排查

15：45 联系技术运营创新部的云平台相关人员进行确认，在做docker在做测试

15：47 基础运维人员关闭有问题的机器集群

15：48 关闭准时达的开关

15：52 物流系统恢复，业务也恢复正常

16：10 恢复准时达的开关

改进措施：

1.将docker测试环境迁移到某机房的单独网络环境。

2.与生产环境网络变更提交给基础运维人员进行审核和评估，并且报备给NOC。

张贴在2016年饿了么技术通告分享

【20160910】【CTO训练营*上海站专场】

张贴在 2016年9月12日 通过 饿了么 — 暂无评论 ↓

分享嘉宾：技术运营部高级总监 ，徐盎

分享主题：饿了么技术运营经历

演讲ppt已经上传至百度文库，供大家阅览。

分享地址：

百度云盘：http://yun.baidu.com/share/link?shareid=635711486&uk=4116257951

 

张贴在Are you hungry Technology sharing