排查思路示例:服务器故障
口网站服务器崩溃的可能性原因■服务器硬件故障或者系统内核Bug■并发的多线程出现了死锁，或者后端数据库崩溃■存放业务数据变动的磁盘空间耗尽■流量过高，系统超载◆服务器硬件配置过低，正常流量增长下的系统超载◆正常的短暂性流量突增◆遭受攻击，出现异常流量尖峰■触发了应用程序未曾测试出的潜在Bug，例如死循环或内存泄露等导致系统资源耗尽■系统参数设置不合理，例如fd数量过低，，或者是并发连接数上限过低■人为误操作等口处理思路■若处于“假死”状态，可以kill并restart业务进程;■分析监控数据，尤其是注意排查宕机前的异常指标数据，比如CPU或内存尖峰等■查看系统日志，获取详细信息◆查看/var/log/messagcs文件，分析宕机前后的系统日志，注意排查错误信息◆若启用了kdump，还要分析宕机生成的crash文件 #需要系统级工程师◆硬件故障相关的日志通常位于/var/log/dmcsg
故障自愈
口基于“主备”的冗余设计存在切换不成功、切换后状态不一致等通病要主节点故障导致主备切换后，一般需要尽早跟进问题并修复节点
口基于“负载均衡”的设计
口基于平台的设计云平台，包括k8s系统上的自动恢复和扩缩容功能本身就是故障自愈的实现
口基于业务架构的设计许多分布式自身就能支持自愈机制，且大部分都涉及到了CAP原则例如Zookeeper、Etcd等
灾备建设
口同机房灾备通常在同一机房跨机架基于两个以上的服务做主备集群运维工程师需要了解服务器的真实物理连接和部署拓扑容灾能力:同一机房内涉及到的单机或单机柜口同城双活将业务部署至同一城市的两个机房中距离要足够远(不会被同一故障影响)，又不太远(方便管理及建立起高速专用线路)，50公里以内能确保网络延迟低于3ms两个机房间的通信链路需要高可用和高容量，需要双线，且应该基于不同的ISP链路口异地数据灾备数据成为业务的关键资源时，进行异地灾备，能给影响到全市范围的灾害事件后储备恢复业务的基础口两地三中心两个城市，三个数据中心的灾备方式，可以在城市级的灾害中，快速恢复上线业务，甚至是确保线上业务不离线需要从数据底层开始设计，通常的设计是数据库多写，然后互相进行数据同步需要对业务模块有清晰的认识，尽量降低应用请求的跨机房操作需要定制专门的数据同步工具，要支持数据路由和多路复制等功能口分布式多活理论上出现故障，系统均能通过切换流量和数据的方式，确保业务继续运行系统自带数据同步和数据一致性逻辑，通常会基于Raf、Paxos等协议实现，支持全自动的灾备切换
