企业官网建设流程全解析

摘要：医生护士说"电脑卡得用不了"，我一般不当成电脑问题先去看机器，而是先分三层：整台机器都慢＝终端自己的事；就某一个功能慢＝应用软件或它背后接口的事；就某几台机器慢＝网络或链路的事。三层排完还卡，才往最底下查数据库——服务正常不等于数据库正常。这篇记录一次真实报修：服务器各模块正常、网络 ping 不到 1ms，最后查出好几个会话卡在阻塞上。

各位亲爱的读者，大家好，愉快的假期已经结束，是该收心好好"搬砖"了，下个假期就要等明年元旦的时候了。

之前写的几篇，大多是网络、服务器、系统底层这些运维的事，今天咱们第一次往应用软件和数据库这一层走。作为运维，日常经常会接到这样一句"我的电脑卡的不行，直接用不成……你来帮我看看。"

其实遇到这样的报修，我们只盲目的去看终端，不一定能解决问题，科室或是临床医生、护士只知道我操作软件时很卡，但他们是分不清是电脑运行卡，还是这个软件有问题导致的整个系统响应缓慢，有时候甚至打不开操作软件的功能还报错。但使用的人只会全部归结到电脑出问题了。

记得那也是一个工作日的早上，刚九点，体检中心打来电话，说前台扫体检指引单的二维码，电脑上打开特别慢，点开来要等半天，后面排队的百十号人等着，客户已经开始抱怨了。我告诉前台，我先确认一下是不是服务器的问题，然后就下来了。

我当时就是照这个思路处理的：先上服务器看了一眼，各服务功能模块、数据交换接口都正常。又到前台电脑上 ping 了一下，网络非常好，<1ms。服务和网络都没问题，差点就以为不是服务器的事了——结果连上数据库一查，好几个会话都卡在阻塞上，几个锁死的进程互相拽着，报告界面自然就打不开、慢得要命。

和前台沟通好，回办公室，连上数据，用 sp_who 把当前所有进程拉出来，看 blk 不为 0 的（那就是被阻塞的会话，blk 那一列显示的就是堵住它的那个进程号），一查，堵头的进程号果然在里头。

这里多提醒一句：动手之前先确认它确实是阻塞的源头、不是在跑的关键业务，确认无误再用 kill 加上那个进程号结束掉。比如这回堵头的是 86，就 kill 86。杀掉之后，再问前台，报告界面果然秒开了。

这次卡在哪一层：三层判断法

所以对这种"变慢"的报修，我第一步不是急着去修，而是先把范围缩到某一层。我一般分三层看：

第一层，整台机器都慢——先问清楚使用终端表现情况，是开机就卡、点啥都转圈、风扇狂响……那这多半就是这台终端自己有问题，跟功能软件没关系，只能是先清灰、查病毒，还是不行，就得重装系统。重装了系统改善不大，那就得考虑升级硬件了，加内存、换固态，提升是最明显；

第二层，就某一个功能慢——别的都正常，唯独"扫个码看报告"要点半天，那是应用软件或者它背后接口服务的问题。

第三层，就某几台机器慢——同一个功能，A 电脑秒开，B 电脑卡死，那多半是网络或者链路的问题，不是软件本身。

把层分清楚，再去对应的地方查，就不乱了。往下拆其实就三个地方要查：客户端与终端、服务与接口、数据与锁。

排查顺序：先看服务器端，再看终端

所以对这种报修，我习惯先看服务器端，再看终端。但不是看了服务接口正常就万事大吉——服务正常，不等于数据库正常，这一层得单独查。

确认服务器端大体没事，我才去终端上排查；终端上先 ping 一下网络通不通，网络没问题，再查装的软件和电脑本身的系统故障。

总结一下这套顺序

电脑软件响应慢，别一上来就怪终端。先分清楚是哪一层——整台机器慢是终端自己的事，要是某个功能慢，多半是应用或接口的事，如果是某几台慢，多半是网络的事；都排除了，最底下还有一层最容易漏的——数据库。客户端、服务接口、数据库这三处，数据库往往最后才想到。而数据库这边，服务正常不等于它正常，锁表或阻塞照样能让前端卡得动不了。看到阻塞，确认是堵头、还要确认不是关键业务，再 kill 掉。

常见问法

问：电脑卡、系统慢，是不是加根内存就好了？

答：先别急着加内存。同样一句"卡"，可能是终端自己的事、可能是应用或接口的事，也可能是数据库堵了。得先分清楚卡在哪一层，再决定怎么办——不然内存加了也白加。

问：怎么判断是终端的问题，还是软件、数据库的问题？

答：我一般分三层看：整台机器都慢（开机就卡、点啥都转圈、风扇狂响）＝终端自己的问题，先清灰查病毒、不行就重装系统；就某一个功能慢（别的都正常）＝应用软件或它背后接口的问题；就某几台机器慢（同一个功能 A 秒开、B 卡死）＝网络或链路的问题。

问：服务和网络都测了没问题，为什么系统还是卡？

答：因为服务正常不等于数据库正常，这一层得单独查。这回我就是——服务器各模块正常、ping 也<1ms，最后连上数据库一看，好几个会话都卡在阻塞上。数据库这一层往往是最后才想到的，也最容易漏。

问：查到是数据库阻塞，能直接把那个进程结束掉吗？

答：别急。动手之前先确认两件事：它确实是阻塞的源头，而且不是在跑的关键业务。两点都确认无误，再用 kill 加上那个进程号把它结束掉。这一步省不得。

问：怎么找出是哪个进程在堵？

答：连上数据库，用 sp_who 把当前所有进程拉出来，看 blk 那一列不为 0 的——那些就是被阻塞的会话，blk 显示的数字就是堵住它的那个进程号，顺着这个号就能找到堵头的那个进程。

你遇到过这种"看着像电脑卡、其实是数据库堵了"的情况吗？评论区聊聊，相互学习印证一下！

文中案例均已脱敏，不出现系统账号、服务器地址与人员信息。

作者：老刘说医信，医院信息科运维。