最近半个月的工作[14P]

5 月发生的事，6 月补充完，9 月发出来 😉

5 月 13 日周二

开始我们另外一个核心 IDC 最后一次常规性 10G 升级，下面的一部分我们后来把他总结成了《5 月故障总结(post-mortem)》

回家睡了会儿，3:00 am 起床，4:00am 开始连续干了 6h

回公司休息了 1h，塞了点巧克力复活

中午去水立方进行了常规的 1h 训练

回来面(对了，我们目前招高级应用运维工程师 PE，有兴趣的给我简历，邮箱是 w 在 umeng 点 com)了一个候选人，结果在我问到第二个问题的时候就怂了，第一个问题是常规性的自我介绍，第二个问题也是我最喜欢问的问题之一，最近半个月在做什么

由于 uplink 依然在老的网络环境中，我们老的 3750X 到新的 Nexus 中间的 8G port channel 链路中的一条物理链路由于 LB 的算法不科学，导致其打满丢包的状态，当机立断，直接让 NE 更改了 LB 的算法，效果明显

5 月 14 日周三

由于 uplink 这个不稳定因素的存在，开会讨论最后一次也是最重要的升级以及收尾工作，由原本的周四凌晨升级提前到了周三凌晨进行

10G 的最后一次也是最重要的升级，应为涉及到切换我们的 uplink，迁移我们的 GW 以及我们两地双机房中间的互联链路迁移

晚上去和颐休息了 3h，凌晨 3 点干到早上 7 点，期间除了 uplink 切换成功之外，其他的均已失败回滚告终，回酒店休息了 3h

中午回公司继续，讨论了凌晨出现的一些问题以及解决方案，其中我们两地双机房互联链路不通的问题最后发现是 HSRP 的问题

凌晨 GW 迁移失败之后，我跟我们 ne, director 回公司模拟了一下当时出现问题的场景，想了几种可能的原因，不过都被实际的模拟结果所否定，唯一的可能性就是服务器会自动的更新 arp 表，找到新的 GW 地址

下班之前，上面遇到的所有问题都已经找到了问题的根源，想到了对策，唯独 GW 的问题，这个对我们整个生产环境的影响绝对是毁灭性的，一旦 GW 迁移失败，我们所有跨 VLAN 的访问都将失败，由于当时时间太紧迫，根本没有时间让我去 debug 就回滚了，我也就无法得知当时真正的现象以及后续的细节

临走之前，我们 director 问我要不要他过去帮忙，我当时是拍着胸脯说的「相信我，你回家休息吧」，虽然我当时有 95% 的把握确认了上面提到的迁移失败的原因以及 80% 左右的把握让我在非常短的时间内 debug 找到问题并且修复，其后者是最具有挑战性的

现在看到的我们的还是 1G 的上联，等你看到这篇博客的时候，应该已经升级到了 10G 的上联了

5 月 15 日周四

这次升级提前预留了充足的时间，从 3:30 – 6:00，我觉得 3h 的时间足够我 debug 一个中等难度的线上问题了

跟昨晚一样，先是回酒店休息了一下，凌晨 2 点开足马力一直干到了早上 8 点多，GW 的问题也在我们开始的第一步被我很快的发现了问题的原因并且修复，两地双机房互联 HSRP 的问题也后续被我们 ne 一举解决，「基本完美」收官，为什么这么说？因为后续的几天出现了若干的问题，好在都不是我们核心的 Nexus 引起的

回酒店休息到 11 点，打车回家准备继续休息，结果在车上就收到报警说我们的一台前端的 ngx 挂了，当时电话跟我们工程师沟通了下，看现象不大像是新升级的网络造成的，回家又花了 1h 时间救了把火，最后查明原因发现确实跟网络没有关系，只不过在这个敏感的时间点上，出现任何的问题，正常人都会不由得往网络上面倾斜

下午先赶到公司跟我们 director 沟通了进展的，然后赶到清华，在那儿度过了下午剩余的时间，干嘛的了？我花了 3h 的时间去拜拜 RMS 大神，花了 1h 的时间跑到教室外面的走廊插上了 3G 网卡排查了一起路由问题

RMS 大神确实蛮有意思的，下面这三段视频是我当时在现场拍的，虽然 RMS 说不要把这些视频照片传到 youtube, instgram 上，但我还是本着共享的精神跟大家分享了:

下午在会场收到反馈说，我们某个 storm cluster 的处理性能出现了问题，时间点跟我们升级网络的时间几乎吻合，但是从我们内网的各项监控指标来看，数值得到了前所未有的好转，pkg loss 由原来的 8% 直接变为了 0，latency 也由原来高峰时期动辄 4, 5ms 直接下降到了 0.2ms 以下，直觉告诉我几乎不可能是核心网络引起的，但是，没有更有力的数据来证明这些

看码农们在邮件里面以「猜测」、「推脱」的姿态开始了问题的 debug 之后，我直接以「明天人齐了一起讨论下吧。」结束了这场闹剧

听完演讲之后本想回公司报个销就回去休息的，结果的结果，碰巧我们一个核心业务线上出现了很严重的性能问题，伴着麦当劳雪碧继续搞到了接近凌晨，没找到的问题原因，但是紧急扩容了一些机器，情况有所好转

两个出口的 ngx 都挂了

两个出口的流量一个跌没了一个直接爆了

5 月 16 日周五

早上 11 点到了公司，看人没齐就延后了今天的问题讨论，干脆早点吃饭

吃完，去水立方，结果游不到 300m 就扶额上岸，第一次感觉体力不支，前所未有前所未有啊

下午面了个胖小伙子，感觉到了停滞不前是个什么情况

接下来开会讨论目前出现的各种情况，最主要的两个问题，一个 storm cluster 处理能力上不去，一个昨晚出现的问题

结果，晚上 8 点不到又崩了，我当时在超市买八喜，没辙打着车赶回了家，跟我们的 director 一起在线上 debug 到了凌晨，发现了不少可疑的因素

5 月 17 日周六

是个好天气，准备走走，结果依然苦逼的在排查昨晚的问题，好在这次，花了不到 30min 时间，找到了导致连续这几天 outage 最主要的问题，说来好笑，我们前端到后端的某个 ngx 由于路由问题，导致了所有的请求都压在了某几台配置很烂的机器上，不挂才真的见鬼了

出去把接下来几年要穿的裤子都买齐了

5 月 19 日周一

虽然那起 outage 最主要的原因已经找到，但是由于这只是若干次历史原因里面的一次缩影，所以，可以肯定的说，代码肯定是有问题的

结合前两天观察到的现象，帮我们开发 debug 代码，最后定位到了 backlog 的问题，意外的是，我们开发用的 netty 框架不知道有 backlog 这回事

5 月 21 日周三

github 官方快递给我们的 hoodie, shirt, stickers 终于到了，大吃一惊的是，既给我们的是满满一大箱，我原本以为就是几件 shirt 的，我司的工程师们高兴的菊花绽放

晚上，老罗的锤子发布了，我是从他的《我的奋斗》看起来，我非常尊敬以及欣赏的一个人，这个 curl 所要表达的也蛮有意思的，虽然我猜测不过是拿了 nginx 源码改了改

5 月 22 日周四

storm cluster 的问题终于查明，验证了我之前说的「90% 的可能是业务或者代码引起」这句话

5 月 22 日至今

准确的说，是从 19 号开始，我就开始着手解决我们线上带公网服务器跨 VLAN 访问的问题，基本上这半个月都是在 debug 中度过，好在最后找到了问题的根源

5 月 24/25 日周六/周日

去 Fudconf&Gnome Asia Summit 2014 现场酱油了一把，结果又碰到了 RMS；提问环节问了两个问题，还获得了一件 shirt，虽然我已经很就不用 Ubuntu 了，但是穿上经过本地山寨之后的 Ubuntu Kylin 还是蛮有趣的

周日在场外蹲守了 2h，配合不给力的 Cisco 北京工程师线上 debug，结果什么都没 debug 出来，接下来的两台依然是陪着他们满地打滚，还好有美帝人民友情相救