阿里云核心底层系统叫飞天，是自研云计算操作系统，上线运行十多年。它的设计思路，把分布在各地数据中心的百万台服务器整合为一台巨型计算机，通过在线服务对外输出算力。飞天内部多个模块各司其职：神龙管控调度计算资源，盘古负责存储，洛神管理网络，安全防护独立搭建体系。用户日常使用的ECS云服务器、OSS对象存储、SLB负载均衡，全部搭建在飞天底座之上。
从用户可接触层面划分，阿里云产品分为三层。底层IaaS，提供裸算力、存储、网络资源，用户自行安装系统配置环境。中间PaaS，RDS数据库、ACK容器服务、消息队列等中间件预先就绪，开发者直接部署代码。顶层SaaS，直接交付成品应用，浏览器打开即可使用。选择哪一层，取决于自主运维程度，同时决定故障排查范围。
服务器宕机是很头疼的问题，故障不会凭空出现。阿里云ECS宕机原因大致分为三类：底层物理硬件故障、实例内部软件与内核异常、外部网络攻击。分类看着笼统，排查需要顺着线索逐步定位。
内核panic和OOM是最常见崩溃类型。panic就是操作系统内核遭遇无法处理错误，直接停止运行。OOM全称Out Of Memory，内存耗尽，系统为自保，杀掉占用内存最高的进程。阿里云售后统计，非硬件宕机事件里面，OOM Killer触发占比接近三成。1GB内存服务器运行Java应用，夜间流量突增，内存耗尽，内核终止Java进程，低配实例很容易出现这类情况。
排查第一步查看日志，不能只看末尾几行。推荐以崩溃时间为中心，截取前后三到五分钟日志，同时查看/var/log/messages和dmesg输出。日志出现Out of memory: Kill process，记录被杀进程名称和当时占用内存。如果看到soft lockup，代表CPU被单个任务长时间占用，结合top快照判断单核满载还是全局调度异常。还有容易忽略的点，如果没有提前配置kdump，内核崩溃无法生成vmcore文件，排查直接中断，缺少分析素材。
磁盘相关报错也要重视。日志频繁出现Buffer I/O error，有可能宿主机存储波动，也可能云盘老化。这时打开控制台查看云盘IOPS和时延监控曲线，判断读写指标是否触达上限。日志反复出现nf_conntrack table full，代表连接跟踪表占满，一般并发连接超出实例承载上限，源头可能是业务连接池配置或者外部扫描流量。
阿里云自带宕机诊断工具，入口在云监控控制台或者操作系统控制台。登录ECS洞察，找到系统诊断入口，诊断模式选择节点诊断，诊断项选择宕机诊断，选定故障实例ID执行诊断。目标实例未安装SysOM组件，系统会自动部署组件再执行诊断。等待一两分钟生成诊断报告，报告包含宕机标题、现场进程、RIP函数地址、内核版本，附带初步宕机判定结论。报告同时展示宕机时刻内核调用栈、错误日志，IO异常、硬件异常信息都会列出。
这套诊断工具把手动读取日志、加载vmcore、调试命令的流程自动化。过去分析Linux内核崩溃，光是理解vmcore加载、crash工具版本适配，就要耗费大量时间。现在诊断结论和修复建议直接输出，省去大量繁琐排查工作。
工具只是辅助，基础排查能力依旧需要掌握。看到kernel panic附带Attempted to kill init，就要思考用户态init进程崩溃原因，glibc版本不兼容、容器运行时缺陷都是常见诱因。CPU持续满载，先排查异常进程，再确认业务流量上涨。实例状态显示运行中，SSH无法连接，可以使用控制台VNC登录，查看系统卡在哪个启动环节，比外部盲目排查效率更高。
运维层面，预防故障远比故障之后应急处理重要。提前配置kdump，崩溃之后才有可供分析的文件。日志持久化写入磁盘，重启之后日志不会丢失。设置内存告警阈值，不要等到OOM Killer触发才发现问题。这些操作难度不高，但故障发生时，前期准备是否到位，排查效率差距巨大。