网站突然打不开，是站长最紧张的时刻。这时候最忌讳的是慌：一会儿重启服务、一会儿改配置、一会儿怀疑被攻击，改了一堆东西，问题还在，而且不知道是哪一步改坏的。访问异常排查有一套固定顺序，按顺序走，八成的问题十分钟内能定位。
第一步永远是确认是不是真挂
很多人跳过这一步，直接登服务器。结果发现是自己本地网络的问题，白折腾半小时。
正确的确认方式是用三个不同出口访问：手机流量打开一次、用在线检测工具（比如各类站点监控网站）测一次、让朋友帮忙打开一次。三个都打不开才是真挂。只有自己打不开，大概率是本地 DNS 缓存或者运营商的问题，换个 DNS 或者等十分钟就好。
确认的时候还要区分现象：是完全打不开（连接超时）、能打开但报错（五百）、能打开但空白、能打开但很慢。四种现象的排查方向完全不同，先定现象再动手。
按层排查，从上往下
把整条链路拆成五层，一层层往下查，别跳。
第一层，域名解析。用 dig 或者 nslookup 查一下域名指向的 IP 对不对。解析错了或者解析不到，后面全白搭。国内域名还要看备案状态，备案被注销会导致访问被拦。
第二层，网络连通。从本地 ping 服务器 IP，能通说明网络没问题；再用 telnet 或者 curl 测 80 和 443 端口，端口不通说明防火墙或者服务没起。
第三层，Web 服务。看 nginx 或者 apache 进程在不在，配置文件有没有语法错误（nginx -t 一条命令就能测）。这一步最常见的问题是配置文件改错导致服务起不来。
第四层，应用层。PHP 或者 Java 进程在不在，端口通不通。看应用日志有没有致命错误。五百错误九成出在这一层。
第五层，数据库。连不连得上，连接数有没有打满，慢查询有没有堆积。数据库挂了，前台通常表现为五百或者一直转圈。
五个最高频的原因
按出现频率排，这五种占了绝大多数。
第一，磁盘满。用 df -h 看一眼，使用率百分之百的时候数据库写不进去，站点直接五百。清理日志和临时文件就能恢复，但要顺手查一下是什么把磁盘写满的，不然明天还满。
第二，数据库连接数打满。show processlist 看连接数，一堆 Sleep 状态的连接占着不释放，通常是程序没关连接或者有慢查询卡住。
第三，证书过期。浏览器直接报不安全，用户以为站点挂了。用 openssl 或者在线工具查一下到期时间，提前三十天就该续。
第四，配置改错。刚改完 nginx 或者 php 配置就出问题，八成是这里。用备份文件覆盖回去，五分钟恢复。
第五，被攻击或者被刷。访问日志里同一 IP 高频请求，或者带宽跑满。这时候先上防火墙限流，别急着分析攻击手法。
日志怎么读才有效率
日志文件动辄几个 G，直接打开是灾难。三个命令解决大部分问题。
先看错误日志的最后几十行：tail -n 50 error.log，时间最近的问题都在这里。再看访问日志里的状态码分布：awk 提取状态码字段做统计，能立刻看出是五百多还是四零四多。最后按 IP 排序找异常来源：把访问日志里的 IP 字段切出来排序去重，看哪个 IP 请求量高得离谱。
读日志要带着问题读。先假设一个原因，再去日志里找证据，比漫无目的地翻效率高十倍。
几个常被误判的情况
现象看着严重但原因很简单的几种。一是“站点打开是空白页”，多半是 PHP 内存限制被触发，日志里有 allowed memory size exhausted，改一下 memory_limit 就行。二是“只有部分页面打不开”，通常是伪静态规则写错，某类 URL 匹配不上，检查 nginx 的 rewrite 配置。三是“图片全裂了”，检查图片目录权限，常见是 chown 改错了，www 用户读不了。
还有一种看着像故障其实不是：访问特别慢但能打开。这种情况多半是 DNS 解析慢，或者页面上引用了打不开的第三方脚本，浏览器一直在等。打开开发者工具看网络面板，哪个请求卡住一目了然。
恢复之后还要做什么
站点恢复正常不等于事情结束。三件事要做：一是把这次故障的时间、影响范围、根因写进记录；二是检查有没有数据损坏，尤其是数据库异常退出过的情况，跑一次表检查；三是核对备份是不是最新的，故障期间产生的数据有没有丢。
如果这次故障影响超过半小时，还要发一条公告说明情况。用户只看到站点恢复但不知道为什么，下次再出问题就会流失。
什么时候别自己硬扛
有几种情况超出个人能力，别硬扛。一是数据被删或者被改，自己没把握恢复；二是被持续攻击，流量大到影响正常用户；三是硬件故障，磁盘有异响或者服务器无故重启。这三种第一时间联系服务商或者找人协助，同时停止一切写操作，把现场保护好。硬扛的代价通常是数据永久丢失。
排查记录必须留
每次故障处理完，写三行：现象是什么、根因是什么、怎么修的。存到一个文档里，按时间排列。
这份记录的价值在于，同一个问题第二次出现的时候，你不用从头排查。而且积累到十几条之后，你会发现有些根因反复出现，那就该从机制上解决，而不是每次救火。
还有一件事：修复动作要一件一件做，做完一个验证一个。同时改三个地方，修好了不知道是哪个起作用，修坏了也不知道是哪个搞坏的。慢一点，稳一点。
排查的本质是缩小范围，不是碰运气。按层走、按频率排、按证据判断，这套方法用熟之后，绝大多数故障都能在十分钟内定位到具体环节。
