不过业务层在设计架构之初，应该考虑到网络不稳定的情况。针对上面的隐患，大概有三个方法。
第一个就是做全链路的演习，模拟一个真实的场景，经过模拟演习，还是多多少少能暴露出来一些问题。我们可以针对这些问题，去完善我们的故障预案、修复线上漏洞，做演习的时候也能验证我们的报警系统是否正常运转。
第二个是SLA，对于服务定一个比较严格的稳定性指标，并针对这个指标持续不断的优化。比如我们线上HTTP接入的服务，针对accesslog中的状态码和响应时间提炼出一个稳定性指标，这对于服务本身的稳定性情况，就多了一个可参考数值了。稳定性指标波动服务必然有问题，这时候我们就要针对它波动的点进行相应的分析，根据分析，最终能找到一些隐患。指标这块，要做到用真正的数据来反馈出线上的稳定性。
第三个就是做故障的管理，每个故障都能找到问题，TODO能落实，各个故障的经验总结，也能共享到多个业务线。
经验总结 事故之前（比如标准SOP、容量评估、流量压测）的核心就是要防范于未然。 事故之中的核心是快速止损，查找问题是一个相对来说难度比较大，也比较漫长的过程，因为这个时间是不可控的。但是如果我们提前有好的应急预案，就能达到快速的止损。此外，还要有服务的自我保护，还有一点，沟通也是很重要的。最开始出现问题的时候，其实是比较乱的，因为大家发现问题都很急，很多人都在问原因，这时候你问原因是没有用的，因为大家大部分是不知道，知道的话就能给出解决方案了。所以这时候需要一个完善的沟通机制，正确的时间反馈正确的消息，反馈的原则是少说表面现象，尽量说一些对于问题定位或者是对于止损方面能够有帮助的信息。 事故之后，像TODO落实、完善预案之类的，核心点就是吃一堑长一智，相同的问题不能发生第二次。
用户体验优化
首先从用户端开始，用户在访问我们线上业务的时候，流量是从公网到私有云，再到Server。公网问题主要有网络劫持、多运营商环境、不可控的公网链路等。对于Server的话，主要就是一些传输层的协议，或者应用层的协议的问题，目前大部分业务交互还是用的HTTP 1.0/1.1，其实HTTP这个协议也是需要改进的，它不太适合做频繁的业务交互。
针对这些问题，我们都做了一些尝试：
首先在公网接入这块启用BGP，我们现在已经做了自建的BGP网络，不用再关心多运营商接入的问题。只需要采用BGP网络，数据包在公网传输寻址的时候，就可以进行最优的选路了。 面对劫持问题，我们尝试了HTTP DNS的方案，同时也在尝试Shark，就是类似于公网链路加速，相当于我在用户的近端部署一个Server，在App上嵌入SDK，用户通过App发起的请求不用做DNS解析，而是先发到Shark（参考之前的博客《美团点评移动网络优化实践》）上，再由Shark与后端服务交互。目前通过多种手段的持续优化，劫持问题已经少了很多。 针对业务交互的协议，上线了SPDY协议，对于频繁交互的业务提升还是很明显的。目前正在测试HTTP 2.0，Server端对于HTTP 2.0的支持还存在少量bug，努力修复中，希望能早日用上。
未来展望
首先技术上，目前我们自动化这块做得比较好，还会持续做，下一步就是智能化。为什么要智能化呢？其实主要面临到一个瓶颈点，有些问题是不能通过自动化解决的，比如说前面提到自动故障定位，它的决策性很强，需要很多步的决策，并不是通过程序就能直接搞定的。我们现在正在尝试一些AI的算法，引入人工智能来做突破。
产品方面，我们现在做的所有工具，经过线上业务大规模的校验，正在往产品化的方向发展，希望能把它做成成型的产品，放在美团云上，能给美团云的用户提供服务。不只服务于我们自己，也服务于他人。
最后是技术架构，美团点评发展过程中一些疑难问题的解决方案，或者针对挑战的经验积累，经过线上大规模业务的校验，最终能形成一些成熟的方案，它能为美团云上的用户提供最前沿的技术参考。
云是大势所趋，它能把很多底层的问题封装起来，让我们有更多精力去做更重要的事情。
【作者简介】普存，2014年加入美团SRE团队，现任美团点评应用支持组负责人，带领团队为美团外卖、餐饮平台、金融服务等多个业务提供运维支持及业务稳定性保障工作。