diff --git "a/\350\220\245\351\224\200\346\224\257\346\222\221\344\271\213\350\267\257.md" "b/\350\220\245\351\224\200\346\224\257\346\222\221\344\271\213\350\267\257.md"
index d7669df..5bcdb58 100644
--- "a/\350\220\245\351\224\200\346\224\257\346\222\221\344\271\213\350\267\257.md"
+++ "b/\350\220\245\351\224\200\346\224\257\346\222\221\344\271\213\350\267\257.md"
@@ -53,7 +53,7 @@ MT平台的出现并不是一个偶然。在这样一个环境下，前端不得
 ## 故障
 目前MT平台每天都会有大量页面在前端不介入的情况下发布上线，即使今天手淘前端集体休假运营也不会受多大影响。但事总有意外，今年（2015年）双11就差点出大问题。
 
-双11预热的第一天，由于担心系统状态我们执了一夜的班。所幸当晚什么事也都没发生，但是第二天我们正准备回去休息的时候手机突然手到报警说集群负载过高。于是们立马冲出会议室开始排查问题，得益于阿里完善的监控机制我们很快的发现原来在上午的活动页面中引用了一个`404`的资源。导致CDN回源压力过大，单机qps到了1500左右。很快我们找到这个页面将404的引用问题修复了。但对于一个集群来讲这样修复只能算是暂时避免了故障的产生，其实并没有解决问题。同时单机qps 1500这个值也略低了点……但这个时间点我们已不能够对集群作太多的变更，每一步操作都可以会引起更大的问题。终于当晚21点左右集群再次被流量打死，集群开始出现不断的可用与不可用之间抖动。结果排查发现我们在CDN端的配置出错了，于是又立马通知CDN修正配置才恢复了服务。搞定这个问题的同时我们开始担心，双11当天会不会还会挂掉。于是和几位同事连续三天的奋斗把系统中所有可能存的故障点都排查了一圈，也确实发现了不少问题。经过了一系统不再愚蠢的优化之后，最终我们将单机qps稳定在了2400左右，这样整体服务的可靠性就大大提升了。
+双11预热的第一天，由于担心系统状态我们值了一夜的班。所幸当晚什么事也都没发生，但是第二天我们正准备回去休息的时候手机突然手到报警说集群负载过高。于是们立马冲出会议室开始排查问题，得益于阿里完善的监控机制我们很快的发现原来在上午的活动页面中引用了一个`404`的资源。导致CDN回源压力过大，单机qps到了1500左右。很快我们找到这个页面将404的引用问题修复了。但对于一个集群来讲这样修复只能算是暂时避免了故障的产生，其实并没有解决问题。同时单机qps 1500这个值也略低了点……但这个时间点我们已不能够对集群作太多的变更，每一步操作都可以会引起更大的问题。终于当晚21点左右集群再次被流量打死，集群开始出现不断的可用与不可用之间抖动。结果排查发现我们在CDN端的配置出错了，于是又立马通知CDN修正配置才恢复了服务。搞定这个问题的同时我们开始担心，双11当天会不会还会挂掉。于是和几位同事连续三天的奋斗把系统中所有可能存的故障点都排查了一圈，也确实发现了不少问题。经过了一系统不再愚蠢的优化之后，最终我们将单机qps稳定在了2400左右，这样整体服务的可靠性就大大提升了。
 
 ## 全栈化
 营销业务是一个看起来杂乱但又有线可寻的业务，因此需要做这块业务的同学不断的总结从中找到业务的价值的规律。我们尝试在这个过程中不断挖掘业务的潜在条理，并从前到后的解决问题。手淘前端团队在这个过程中自然的走向了全栈之路，所不同的是我们在后端没有选择Node.js的方案，而是采用了传统的Java。说到这里可能会有人会问，难道Node对前端来说不是更容易上手么？我们选择Java主要是因为以下几点因素：