最近和一些朋友做了一些线下的沟通，大家都是互联网技术同行， 自然会谈一下各自工作中遇到的一些问题。聊完后我有一个感受，就是大家在各自业务中实施高可用过程中，踩了一些坑，然后再反过来不断优化自己的系统，但是实际上如果我们一开始就能在运维端打下基础，就可以避免里面的很多问题。所以今天来简单谈谈这一块我个人的一些实战经验。
简单来说，就是做好三件事：
故障发现机制
系统恢复机制
线上故障复盘机制
接下来，我们再细说这三件事如何来落地。
1. 故障发现机制
1. 报警的移动化，故障出现后的第一步，自然是报警，系统不会自我修复，需要工程师来处理，所以需要通知到处理人。在24x7的时间维度下，只有报警系统通过短信或者语音电话才能有效通知。如果你闲报警不带劲，可以考虑换志玲JJ的语音。
2. 报警的实时化， 这一点不必多解释，时间就是系统的生命，所以报警的延迟必须控制在1-3分钟的延迟内，不能再多了。
3. 监控的可视化，光靠报警短信，是很难第一时间定位问题的，所以这就需要做好监控的可视化，无论是系统打点还是日志搜集，具体拿石投来说，我们日志收集的ELK方式或者通过系统打点，走kafka + Storm全链路监控我们都做了，然后通过控制台清楚的定位问题，所有业务的关键数据，我们也有通过grafana做实时的采样。
2. 系统的恢复机制
其实恢复机制也没有什么神秘的地方，就是努力做好运维的四项关键任务：回滚、重启、扩容、下机器。
回滚，每次发布前，本次发布的服务必须做好回滚的准备，PlanB要想好，绝不能等线上故障后，才开始考虑如何回滚。一键回滚是家中常规武器。
重启，还是要落实到心跳或者服务监听，通过系统脚本做到服务自动重启，除非无法正常重启，再引入手工操作。
扩容/下机器，落实到镜像的快速生成，有一套现成脚本做到一键上线或者下线。现成的轮子已经很多，二次开发一下很快。
除此之外，平时需要做好主备切换、集群迁移、异地容灾等等的演练，“平时多流汗，战时少流血”，一直都是真理。
3. 线上故障复盘机制
即便是做到以上提到的第1点和第2点，还是无法保证系统不会出问题，所以我们需要有一套机制来分析线上故障，通过复盘，分析从故障发生前到发生后的应急处理过程，然后系统思考故障未来的解决方案，再逐渐落地。同时，系统在任何时候都要考虑不可用的时候，如何提供降级方案。
为什么复盘很重要？因为平常的功能测试也好，性能测试也罢，其实都是无法100%难覆盖到各种情况的，而线上的真实流量能如实地反映出系统当前的状态，能真实地评估出系统目前的短板或者瓶颈在哪里。
复盘不只是运维或者开发参加，而是相关技术团队（开发、测试、运维），拉上产品乃至运营人员，一起进行，从各个角度分析，出现线上故障很多时候都是多方面原因。珍惜每次线上故障复盘，上一层楼看问题，下一层楼解决问题。
扫描二维码或手动搜索微信公众号【架构栈】： ForestNotes
欢迎转载，带上以下二维码即可
