版权声明：本文为博主原创文章，未经博主允许不得转载。如果感觉文章哪里写的不对或者存在疑问，欢迎留言，共同学习、进步！ https://blog.csdn.net/ydm19891101/article/details/84337825
上一篇文章中我简单介绍了一次线上服务的可用性下降追查过程，今天我们接着上次的内容来学习如何保证服务的高可用性。
具体分为开发阶段、测试阶段、上线阶段、监控阶段等几大项。这些内容就像是一套组合拳，练好了你也是一个江湖高手了。哈哈！
一、开发阶段
- 遵循（公司/业界）代码编写规范，并通过git进行版本管理；代码git 合入前需要经过他人的code review；经过专业漏洞扫描工具的评估，不存在明显的注入漏洞
- 各种容错调度机制完善，有完整的重试机制（但不能无限重试）、健康检测、心跳检测
- 功能解耦、上下游解耦，核心服务和非核心服务解耦
- 防攻击，如果是直接部署在外网环境下一定要开启服务器的防火墙功能。
二、测试阶段
- 代码规范测试，不仅关注与业务，还要关注于代码规范
- 模块级测试，前提是各个模块之间的耦合度较低
- 系统级测试
- 定好免测规范，对于免测需求，由RD直接上线
- 部署各种自动化测试脚本，这个是最主要的，原因你懂的。
三、上线部署阶段
- 明确上线的时间点，只在正常的时间点上线，避免出了问题无人力跟进。
- 分机房部署，灰度发布再到全量发布
- 逻辑服务单元拆分，分idc多机房部署
- 满足n+1的冗余，做好容错，快速切换故障机器
- 部署网段打散，如不要将一个机房的机器都部署在一个交换机下，如果交换机除了问题，会造成该机房整个服务的不可用
- 消除单点，这里的单点是广义，单机房部署也属于单点
四、线上运行阶段
- 规范运维操作，RD不具有线上机器写权限，机器由OP统一管理
- 做好流量规划，如流量预估、流量真实压测
- 监控完善，合理配置监控项，在收到服务报警时快速响应。
五、发现线上服务可用性下降
通过运营商或公司内部的监控快速定位服务，先通报，后止损，最后追查问题。
一定要保证自己第一时间收到报警。
六、止损
根据服务可用性下降应急预案，快速响应，大致有以下几种。
- 流量调度，如果某机房可用性整体下降，由OP将该机房的流量分散转发到其他机房
- 回滚发布操作，如果是通过git进行的代码管理，可以发布最近一次的无问题的代码
- 降级/流控，丢失非核心功能或者丢失低质流量
- 由OP紧急扩容/缩容机器
七、灾备恢复
备份永远是第一位的！备份永远是第一位的！备份永远是第一位的！重要的事情说三遍！！！
备份就是你的“后悔药”，不到事故出现的那一刻，你永远不知道备份的重要性。当然，一定要保证你之前的备份是有效的。
八、事故复盘
前事不忘后事之师，做好事故复盘。
如果是流程规范问题，加强完善流程规范；如果是机器流量等问题，扩充（下掉）机器；
以上总结的是本人日常工作中在实践运用的，分享出来希望对大家有帮助！
扫描二维码关注公众号，回复：
4594362 查看本文章
