iis修复

IIS崩了。早上九点，客户电话打过来，说后台登录页转圈圈，十分钟后直接白屏。远程连上去一看，事件查看器里一堆w3svc报错，应用程序池停在那儿，像死鱼一样翻着白眼。这种场面我见过太多次了，每次都是同一个套路——先重启，再查日志，最后发现是配置被谁动过或者补丁没打。

修复IIS这事儿，说穿了就三板斧。第一板斧砍向应用程序池。打开IIS管理器，找到那个变灰的池子，右键启动，如果启动失败，八成是w3wp.exe进程卡死了。这时候别犹豫，直接开任务管理器，把所有w3wp.exe进程全杀掉，再重启池子。九成情况能救回来。别问我为什么这么暴力，问就是IIS这玩意儿有时候就是得物理超度一下才肯听话。

要是池子重启了还报错，那就得看第二板斧——检查站点绑定的端口是不是被占了。有次我修一个客户服务器，IIS怎么都起不来，折腾半天发现是Skype偷偷占了80端口。那玩意儿躲在系统托盘里，平时不声不响，一到关键时刻就出来捣乱。把Skype退出，IIS立马活蹦乱跳。还有一回更离谱，是SQL Server Reporting Services抢了8080端口，两个微软自家产品打起来了，你说可笑不可笑。

第三板斧就涉及权限问题了。IIS修复里最阴险的就是这个，表面上看一切正常，池子在跑，绑定也对，但网站就是返回403或者401。这种时候十有八九是应用程序池的标识账户没权限读站点目录。我曾经遇到个案例，运维把站点文件夹挪了个位置，忘了给IIS_IUSRS组授权，结果整个部门一下午没法访问内部系统。最后就一条命令的事：icacls D:\website /grant "IIS_IUSRS:(OI)(CI)RX" /T。搞定。

不过说实话，修IIS最怕的不是技术问题，是那种间歇性故障。客户说“偶尔打不开，刷新就好”，这种描述最让人头疼。你人在现场的时候它好好的，你一走它又犯病。这种时候就得查HTTP错误日志和Failed Request Tracing，把那个跟踪功能打开，设置成抓500错误，等它再犯病的时候就能抓到具体是哪个模块抛的异常。有一次我抓了三天，最后发现是某个DLL文件被杀毒软件隔离了，导致请求处理到一半就断。你说这种问题，不看日志谁能猜到？

还有个坑必须提——Windows更新。微软每个月第二个星期二发补丁，有时候补丁跟IIS的某些模块不兼容，装完就出幺蛾子。我吃过这个亏，那次是装了某个.NET Framework更新，结果所有ASP.NET应用全挂了，页面直接报500.19。最后把那个补丁卸了才恢复。后来我学乖了，服务器上都设了维护窗口，补丁先装测试机，观察两天没问题再推生产。

说到底，IIS修复这事没那么多玄学。先把进程杀了重启，再看端口和权限，最后翻日志找深层原因。流程走完，九成问题都能解决。剩下那一成，多半是硬件挂了或者系统文件损坏，那就不是IIS的锅了，得重装系统。不过那种情况我一年也碰不上两回，真碰上了，我也就一句话：兄弟，备份数据，重装吧，别跟它耗了。