宕机这个词，源自英文down，意思就是系统停止运行。日常聊天说某个平台宕机，就是站点挂掉，页面打不开，业务没法正常使用。和“死机”有一点区别，死机大多用来描述个人电脑卡死，宕机一般指代服务器、网站、大型业务系统停止工作。网络语境里这个词使用范围已经很宽泛，有时候App刷不出内容，大家不会说服务不可用，直接简称为宕机。
网站宕机，站在用户视角就是页面打不开，或者页面加载完成但无法执行任何操作。从技术层面分析，诱因分为多种情况。服务器硬件故障，磁盘空间耗尽，内存占用爆满，CPU资源被占满。软件层面，代码bug造成进程崩溃，数据库连接失败，配置文件修改出错。流量层面，短时间大量请求涌入耗尽资源，或是遭遇DDoS攻击。DNS解析故障、CDN节点异常、机房断电断网，这些情况同样会让外部用户看到网站无法访问。
遇到网站宕机，第一步不要慌乱，先确认故障影响范围。你自己访问失败，不等于所有人都打不开。切换手机4G网络测试，更换浏览器，找同事或者朋友帮忙访问测试。如果只有你无法访问，大概率是本地网络问题，或是CDN调度分配到了故障节点。多人都无法访问，才属于真正的宕机。有不少在线检测工具可以辅助判断，像downforeveryoneorjustme这类服务，输入网址之后会从多个地点探测，判断故障是否为全局范围。
确认全局宕机之后，快速定位故障层级。打开命令行，先ping服务器IP，如果ping不通，大概率是网络层或者主机层面故障。ping能够连通但是网站无法访问，问题大概率出在Web服务或者应用层。使用curl或是浏览器开发者工具查看返回状态码，502一般代表网关后方应用进程未启动，504是应用响应超时，503代表服务临时不可用。这些状态码可以缩小排查范围。
如果是自己运维的服务器，登录主机查看几项关键信息。系统负载，通过top或者htop查看CPU、内存占用是否打满。磁盘空间，df -h查看磁盘是否占满，磁盘写满之后MySQL和Nginx都会出现异常。服务状态，systemctl status nginx、systemctl status mysql查看核心服务是否处于active运行状态。日志文件，Nginx错误日志、应用日志、系统日志，查看近期报错信息。如果发现某个进程耗尽全部资源，优先终止进程恢复业务，后续再排查根源。
如果是攻击造成的宕机，比如DDoS或是CC攻击，处理思路不一样。优先切换高防或者CDN，将流量导入清洗中心，源站IP不要对外暴露。没有采购高防的情况下，可以临时接入Cloudflare这类免费CDN进行防护，修改DNS解析指向CDN，能够抵挡一部分攻击。CC攻击识别难度更高，访问特征贴近正常用户，依靠WAF访问频率限制与人机验证拦截。实在无法承受攻击流量，可以临时暂停域名解析，挂载静态维护页面，至少让用户看到维护提示，而不是超时报错。
如果故障根源在云服务器本身，比如宿主机故障、机房断电，自行排查没有作用，尽快提交工单联系云厂商。正规云服务商的SLA协议一般包含赔偿条款，宕机时长超过约定阈值可以申请补偿。提交工单时写清楚故障起止时间、影响范围、观测到的现象，不要只简单写一句网站打不开，会增加客服定位难度。
业务恢复之后还有几项工作要完成。复盘故障原因，代码问题就修复代码，配置出错就修改配置，遭受攻击就补齐防护手段。检查备份文件是否为最新版本，验证备份可以正常恢复。更新监控告警规则，保证同类异常再次出现可以提前预警，不用等到用户反馈才发现故障。宕机持续时间较长的话，可以在社交平台或者官网发布简短公告，说明故障情况、当前恢复状态以及后续优化方案。用户对于宕机本身容忍度不算低，但无法接受故障发生之后完全没有任何说明。
日常可以做的预防手段，没有特别复杂的方案。部署监控工具，Zabbix、Prometheus、UptimeRobot都可以，监控CPU、内存、磁盘、带宽、HTTP状态码。定期执行备份，并且验证备份文件可正常恢复，不要等到故障发生才发现备份损坏。核心业务做冗余部署，数据库主从架构、Web多节点、负载均衡，不要把全部业务部署在单台服务器。上线前做压力测试，摸清系统承载上限，避免真实流量涌入之后超出负载。这些操作平时看着不起眼，故障发生时能够减少损失。