文章总体在讲系统的可用性问题，即如何从技术层面解决这个问题。李运华老师将演讲文章内容提炼出一句精华之语：“把运维的锅让研发去背！”即高可用的系统是设计出来的，不是靠运维保障出来的！
可用性的目标是面向整个业务，这个目标就是几分钟来定位问题，几分钟能恢复业务，而且问题发生的频率不能太高，几个月发生一次（其中的“几”要根据我们的业务目标来定）高可用性整体架构可以分为用户层、网络层、服务层、运维层四层。
用户层包括客户端重试，如果遇到后端故障，最快的、对用户影响最小的解决方式是立刻去重试，服务器1有故障的话，我们重新发一个请求到服务器2，就能够正确处理业务。重试有一个关键点需要特别注意，重试的时候必须保证这个请求不要再发到原来有问题的服务器上面，否则这个重试只是浪费时间。
网络层包括HTTP-DNS，即域名和服务器的对应关系，它有三个优点：①灵活。可以基于自己的业务特点做很多个性化的东西。②快速。因为它不存在缓存的问题，一旦运维人员甚至是测试同学把这个服务器下掉后，用户这个请求能够立刻拿到最新的结果，避免重复返回到原来有故障的机器。③方便。这个系统是运营商自己维护的，想做什么样的操作都可以，如果是公共的DNS那无法实现这个效果。
服务层包括架构解耦、业务降级、异地多活，架构解耦包括业务分离和服务中心，业务分离即把系统中的功能分开，因为对于游戏玩家来说，只有登录注册是强相关的，业务分离就是把核心业务和非核心业务拆分到不同系统中，调用时通过接口访问；服务中心类似于DNS，是实现整个内部系统之间服务调用时候的调度功能。业务分离将核心业务和非核心业务分开后，可能会出现一些极端情况，比如非核心业务启动不了了，或者数据库崩了，它就会影响核心业务。但是，在这种比较极端的情况下，我们可以通过人工的方式下发降级指令，把这个非核心业务系统的功能给停掉，这个停掉并不是把程序停掉，而是说把其中的一个接口或者url停掉，核心系统去访问的时候就得到一个500或者503错误。异地多活的优点有业务层数据业务、二次读取、可重复生成唯一数据。
运输层：要对系统实时监控。这是为了更快的找到故障点，这样的话可以更快的解决故障，增加系统的可用性。比如这篇文章中说：“为了能够快速处理这个故障，我们进行了详细的分析，把真正出故障的时候要关注哪些信息、关注哪些指标，都通过预先的日志采集、计算、分析完成，放在那里等我们要处理故障或者问题的时候，直接看就可以了。”其次还要对系统的监控指标进行可视化展示，比如，今日的访问量、今日的正确率、最近一分钟的平均响应时间、错误率等，系统的状态一目了然，这样的话可以快速的定位问题。
经过这些技术的修改，大大提高了系统的可用性，虽然设备还是会出现故障，但是系统对这些故障的处理很及时，最重要的是不影响用户的使用。