降低发布风险
　　严格的发布流程
　　目前点评的发布都是开发自己负责，通过平台自己完成的。上线的流程，发布的常规流程模板如下：


　　
　　灰度机制
　　服务器发布是分批的，按照10%、30%、50%、的发布，开发人员通过观察监控系统的曲线及系统的日志，确定业务是否正常。
　　线上的流量灰度机制，重要功能上线能有按照某种流量灰度上线能力。
　　可回滚是标配，好有坏情况的预案。
　　时间要快：缩短故障的恢复时间
　　如果目标要保证全年不出故障或者出了故障在5分钟之内能解决，要对5分钟进行充分的使用。5分钟应该这样拆解：1分钟发现故障，3分钟定位故障出现在哪个服务，再加上后面的恢复时间。是整个时间的分解，目前我们系统大致能做到前面2步，离整体5个9的目标还有差距，因为恢复的速度跟架构的设计，信息在开发、运维、DBA之间的沟通速度及工具能力，及处理问题人员的本身能力有关。
　　生命值：

　　持续关注线上运行情况
　　熟悉并感知系统变化，要快要熟，熟能生巧，所以要关注线上运营情况。
　　了解应用所在的网络、服务器性能、存储、数据库等系统指标。
　　能监控应用的执行状态，熟悉应用自己的QPS、响应时间、可用性指标，并对依赖的上下游的流量情况同样熟悉。
　　保证系统稳定吞吐
　　系统如果能做好流量控制、容错，保证稳定的吞吐，能保证大部分场景的可用，也能很快地消化高峰流量，避免出现故障，产生流量的多次高峰。
　　故障时
　　快速的发现机制
　　告警的移动化
　　系统可用性的告警应该全部用微信、短信这种能保证找到人的通信机制。
　　告警的实时化
　　目前我们只能做到1分钟左右告警。
　　监控的可视化
　　我们系统目前的要求是1分钟发现故障，3分钟定位故障。这需要做好监控的可视化，在所有关键service里面的方法层面打点，然后做成监控曲线，不然3分钟定位到具体是哪个地方出问题，比较困难。点评的监控系统CAT能很好的提供这些指标变化，我们系统在这些基础上也做了一些更实时的能力，比如订单系统QPS是秒级的监控曲线。

　　有效的恢复机制
　　比如运维的四板斧：回滚、重启、扩容、下服务器。在系统不是很复杂、流量不是很高的情况下，这能解决问题，但大流量的时候很难了，所以要更多地从流量控制、降级体验方面下功夫。
　　几点经验
　　珍惜每次真实高峰流量，建立高峰期流量模型。
　　因为平常的压力测试很难覆盖到各种情况，而线上的真实流量能如实地反映出系统的瓶颈，能较真实地评估出应用、数据库等在高峰期的表现。
　　珍惜每次线上故障复盘，上一层楼看问题，下一层楼解决问题。
　　线上出问题后，要有一套方法论来分析，比如常见的“5W”，连续多问几个为什么，然后系统思考解决方案，再逐渐落地。
　　可用性不只是技术问题。
　　系统初期：以开发为主；
　　系统中期：开发＋DBA＋运维为主；
　　系统后期：技术＋产品＋运维＋DBA。
　　系统较简单、量较小时，开发同学能比较容易地定位问题并较容易解决问题。
　　当系统进入较复杂的中期时，需要跟运维、数据库的同学一起来看系统的瓶颈。
　　当系统进入复杂的后期时，系统在任何时候都要考虑不可用的时候如何提供柔性体验，这需要从产品角度来思考。
　　单点和发布是可用性大的敌人。
　　可用性要解决的核心问题是单点，比如常见的手段：垂直拆分、水平拆分、灰度发布；单机到主备、集群、异地容灾等等。
　　另外，系统发布也是引起系统故障的关键点，比如常见的系统发布、数据库维护等其他引起系统结构变化的操作。