饿了么技术往事（中）( 六 )

故障和意外一样，难以避免。我们能做的是减少人祸，敬畏生产环境，因为一次故障影响的可能是骑手一天的生计、商户一天的营收、用户的一日三餐。同时，提高系统的健壮性和自愈的能力，在故障发生的时候，尽可能的避免演变成更大的灾难，及时止损。
2. 黑天鹅
这个阶段，我们经历了一个大事故，起因就是核心交换机挂了，可能有人问，不都堆叠的吗，不都有主备吗，不都自动切换的吗，说得都对，但是都挂了。因为交换机的一个bug ，主备切换后，备机也很快被网络风暴打挂，没经历过我们也不相信。这次又“饿死了” ，我们只能坐等供应商的工程师抱着设备打车到机房更换，这个时候，一群人挤在应急响应指挥室（NOC作战室）里一点办法都没有。
在第一次517大促之后，我们就开始第一次容灾尝试了，当时采取的是最快最简单粗暴的方案，用最短的时间，在云上搭建一个了灾备环境并跑通了业务链路。但这是一个冷备的环境，冷备最大的风险，就是日常没有流量，真正 failover 切换的时候，有比较大的不确定性。这次事故再加上另一个因素，我们下决心将技术体系推进到下一个阶段。
体会和教训——上云
2016年第一次517大促， 10点开抢的瞬间，我们系统崩掉了，要不是当时一个很稳的运维工程师，淡定操作限流，可能不少人在饿了么的职业生涯当时就结束了。因为对当时的基于Nginx和部分自研插件的网关层比较自信，不相信网关层会顶不住，所以全链路压测的时候根本没有压这一层，事后复盘的时候发现是操作系统一个参数配置的问题，如果压测一定能重现。
因为业务的效果很好，大促就成为常态，事实上第一次大促，我们是在自己的IDC里面用常规业务系统来扛的，所以影响到了非大促的正常交易。后面专门针对大促高并发大流量的场景设计了一套系统，也是隔离、排队、CDN、限流这些常规的套路，没什么特别的。但是，对我们影响更深远的在于，这套体系完全是在云上搭建的， 2016年之前虽然云上有系统，但是生产环境流量很少，顶多是短信触达这类系统在上面，更多是用于搭建测试环境。在当时看来，云上强大的流量清洗、资源 scale out 能力，很适合大促的场景，后面，这套体系经历了多次大促，没有波澜。
在云上搭建大促体系以及灾备节点的经历，让我们后续在云上搭建全站的网关，并进一步构建整个数据中心，有了非常大的信心。下一篇我将继续介绍饿了么架构演变到了Cloud-Ready的状态，技术体系演进为业务发展提供了更多可能性。
作者介绍：黄晓路（脉坤）， 2015年10月加入饿了么，负责全局架构的工作。
本文为阿里云原创内容，未经允许不得转载。