对于运维稳定性建设的一些思考

我们做运维的，无非追求的就是三个字，稳定性
其实就两个目标
第一：努力避免故障的发生
第二：发生了故障要第一时间发现和修复

如何避免故障：

开发层面：

避免不合理的代码逻辑，导致比如疯狂创造节点导致ZK内存溢出，疯狂写入MQ导致队列积压，海量循环操作导致REDIS慢查询，不合理的SQL导致DB慢查询等

良好的系统架构设计，避免冗余设计，避免服务间的强依赖和不合理的重试逻辑。系统太复杂，可以拆分为多个子系统，分布在不同的节点上运行，实现负载均衡和故障隔离

良好的代码规范：比如SOLID原则，让代码可维护性更高，更好理解，更容易扩展，避免代码量的增加导致越来越复杂难维护，尤其是版本混乱问题，往往会出现兼容性问题

良好的建库建表规范，主键和索引一定要有，大表该拆就拆，优化查询语句，避免全表扫描

避免代码漏洞被黑客利用，尤其是很多代码框架要及时更新升级打补丁，停止维护的框架尽量不用

完善的业务指标监控，比如订单量、成单量、取消量、成功率、QPS、交易量以及耗时。需要在代码层面打标记，第一时间发生业务数据的异常

运维层面

保证充足的资源。需要做好容量模型，结合开发团队和业务量，评估需要的资源，避免资源不足导致不稳定。比如网络带宽不足，网络服务不稳定，物理设备不可靠，磁盘性能不足，服务器或容器CPU内存等资源不满足业务需求(容量评估失察)等，必要时还需要引入自动扩容机制。

做好服务的隔离和冗余设计：避免服务之间互相影响，业务量大的服务最好彼此隔离，再比如k8s集群的控制节点与业务节点隔离，控制节点打上污点不要跑业务。

完善的监控告警：包括完善的指标收集，完整好用的监控大屏，以及科学全面合理的告警指标。需要思考的是，故障会有哪些，会从何处引发，需要监控哪些东西，如何设置告警阈值。

完善的变更流程和严格的变更规范。一多半的故障来自变更。要对生产环境有敬畏之心，评估每步操作可能带来的影响，从而制定出完整的变更流程和规范，尤其是不同的业务集群，规范会有所不同。变更完成要做好功能测试。任何变更都要有回归的方案，保证发生异常第一时间回退和恢复，这中间也包含了必要的备份。

做好冗余设计和高可用：核心组件都要引入高可用方案。比如DB和中间件的高可用方案，比如服务同城双活甚至多活(GSLB)，比如异地灾备。适时进行灾难演练，比如混沌工程注入故障，或者模拟压测，检查告警的可靠性，以及事故恢复的速度和能力。

做好灾难预案以及灾备，必要的前后端代码，数据，日志和文件都要有备份规范，可以配置备份检测的监控告警以防止备份失败。还要考虑到一旦不得不用备份恢复，如何以最快的速度完成

必要的服务降级以及熔断机制。如果流量超过了预期，或者是系统故障导致无法承担正常的流量，就要采取限流熔断措施，比如Nginx/Apisix/Kong都有这样的限流熔断插件。

三自基本要求：
故障自愈，比如告警触发自愈脚本。比如自动清理磁盘，清理冗余数据和日志，清理积压MQ队列等等。
开机自启，任何服务都要保证开机自动就启动了，这是最基本的要求，但往往就出现机器一重启该起的服务没起来导致故障迟迟不能恢复
配置自检，比如应用调用DB和中间件的配置，一旦发生了错误的变更就会导致故障，如果能自动检测这些配置是否正确，或者页面有一个环境一键检测的功能，则可有效避免这类故障的发生。