为了下降设计的庞杂性，加强通用性和兼容性，盘算机收集互联都设计成条理构造，例如典范的运用性架构TCP/IP协定簇，它响应地也遵守OST的七层理论模子(所有收集架构构成的理论框架)，这种分层系统可以或许使多种分歧硬件体系和软件体系可以或许便利地衔接到收集。恰是基于这一收集构造特色，收集治理员在剖析和排査收集故障时，可充足应用收集这种分层的特色，把收集故障条理化、简略化，快速精确地定位并消除故障。然而在现实故障排查进程中，这种分层办法往往被疏忽，导致故障排査效力下降。

OSI的条理构造把每层功效及职责规模界说得异常清楚，为治理员剖析和排查故障供给了异常好的组织方法。因为各层相对自力，按层排査可以或许有用地发明和隔离故障，因而一般应用逐层剖析和排查的办法。平日有两种逐层排查方法，一种是从低层开端排査，实用于物理收集不敷成熟稳固的情形，如组建新的收集、从新调剂收集线缆、增长新的收集装备；另一种是从高层开端排查，实用于物理收集相对成熟稳固的情形，如硬件装备没有更改。无论哪种方法，最终都能到达目的，只是解决问题的效力有所差异，第一种办法较为广泛。

具体采取哪种方法，可依据具体情形来选择。例如，碰到某客户端不克不及访同Web办事的情，假如治理员起首去检讨收集的衔接线缆，就显得太消极了，除非明白知道收集线路有所更改。比拟好的选择是直接从运用层着手，可以如许来排查:起首检讨客户端Web阅读器是否准确设置装备摆设，可测验考试应用阅读器拜访另一个Web办事器:假如Web测览器没有问题，可在Web办事器上测试Web办事器是否正常运行:假如Web办事器没有问题，再测试收集的连通性。即使是Web办事器问题，

从底层开端逐层排查也能最终解决问题，只是消费的时光太多了。假如恰巧是线路问题，从高层开端逐层排查也要糟蹋时光。在现实运用中往往采取折中的方法，凡是涉及收集通讯的运用出了问题，直接从位于中央的收集层开端排查，起首测试收集连通性，假如收集不克不及连通，再从物理层(测试线路)开端排查:假如收集可以或许连通，再从运用层(测试运用法式自己)开端排査。

据统计，网站扶植收集故障有35%在物理层，25%在数据链路层，12%在收集层，10%在传输层，8%在对话层，7%在表现层，3%在运用层。由此可以看出收集故障平日产生在收集七层模子的下三层，即物理层、链路层和收集层，对应于现实的收集也就是我们应用的网线、衔接模块、网卡、交流机、路由器等装备故障。这些故障可能因为产物的质量或机能、磨损老化、工资误操作、不准确的设置以及治理缺点等原因而经常性地产生。厥后果轻则影响单个站点的信息传送，重则可能造成收集主要装备:办事器、交流机和路由器的宕机，导致全收集的瘫痪。