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