有人的地方就有江湖

有江湖的地方就有圈子

有圈子的地方就有——

鄙-视-链

打个游戏就有鄙视链：

主机玩家看不起PC玩家

PC玩家看不起手机玩家

非游戏玩家看不起所有玩家

用什么浏览器上网也有鄙视链：

Chrome、Firefox看不起Safari、Opera

Safari、Opera看不起360、QQ浏览器

当然

它们都看不上IE

单位里也有鄙视链：

财务部门看不起质控部门

质控部门看不起业务部门

业务部门看不起后勤部门

但他们，都看不起信息中心的

作为一个信息中心的运维

我自己眼中的工作是这样的

其他部门眼中我的工作是这样的

我，站在公司鄙视链底端的男人

挣着卖白菜的钱

操着卖白粉的心

平时的小透明

出问题时的背锅工具人

作为一个运维

最可怕的不是发生故障

而是故障发生后找不到问题

找不到问题就划不清责任

划不清责任就没法证明自己

没法自证就意味着——

背锅

那么

该如何避免背锅呢？

我们先对故障本身来做一下分析。

事实上，几乎所有的故障都是后知后觉的。我们很难去预测故障何时会发生，在大多数情况下，我们只有在故障发生之后才有反应。

那这是否就代表运维人员只能听天由命，祈祷设备不要出问题了呢？

其实不然。虽然无法预测故障何时发生，但最大程度减小故障发生的概率还是可以做到的。

按照著名的海恩法则：

每一次大的投诉其实都藏在平时一次次的小故障之中，这些小故障可能是没有被发现，或是发现了但看起来不重要而被忽略。俗话说“千里之堤，溃于蚁穴”，即使信息化建设、等保建设等项目投入得再多，可能也会因为对这些小问题的处理不得当，而大打折扣。这时候或许领导的批评就来了：

对于上面的问题，监控工具做到以下几点是十分重要的：

蚁穴之所以是蚁穴，就是因为它太小，以至于常常被我们忽略。因此，需要的是对业务流量进行应用级的，最细粒度的识别、分析与展示。不光监控道路，还对道路上的每一辆车都进行清晰的识别与监控，从而发现诸如“某用户的某个特定应用卡顿”的情况。

举个例子，每300s采集一次数据的SNMP，如果在这段时间间隔内网络发生了天翻地覆的变化，SNMP也将浑然不知；而如果采集的间隔缩短，又可能导致网络设备和服务器CPU过载。因此，要想快速发现问题，在兼顾性能的情况下，实时是非常重要的。

记录的留存，目的在于对故障溯源时，能够拿出证据，让故障汇报有据可依。对于需要留存的记录，可以是每一条会话的日志信息，也可以是原始数据包本身。但最重要的是留存得要全，让一切发生过的问题都有迹可循。

对于使用者来说，监控工具还需要具备简单易用的特点，毕竟运维的时间是很金贵的。可视化程度高，分析方式便捷，能够一眼看出问题所在才最好。

那么，哪里有这种设备呢？

以上的所有特点，Panabit的NTM都可以帮您一一实现。

作为一款强大的网络可视化产品，NTM既可以单独部署，又可以与作为探针的Panabit配合。网络的整体情况如何、业务的访问质量如何、每个用户的网络质量如何，一目了然。

赶快扫描下方的二维码，联系我们吧。