网络管理员应该如何应对系统宕机？

在去年的世界杯比赛期间，Nate Silver和他在地窖里的通灵巫师也犯了错误——他是如何做到如此精准的预测呢?确实错了。他们完全预测错了德国与巴西的比赛结果。正如Silver所描述的，这是一场完全不可能预测准确的比赛。

在体育和范围更小的政治领域，遇到这种事情也只能是吞下苦果，接受这个偶然事件——统计行业中称为黑天鹅，然后继续原本的生活。

但是作为网络管理员，我们知道在IT行业中不应该采取这种方式。

按照我的经验，当IT系统出现黑天鹅事件时，管理层通常会对这种事件讳莫如深。随后就会召开一个“经验总结会”，目的是传递精神保证以后不再发生类似的系统宕机事件。

警告：

不要花太多的时间去研究可能发生的事情

这里我并不是说，在发生故障之后，我们就可以无忧无虑地忽视所有已经学到的经验教训。相反，我们要远离它。在故障消失之后，你通常能够发现未来避免 问题发生的方法。在发生意外事件之后，一个IT组织应该做的第一件事就是未来是否能够预测故障，或者说是否有时候历史数据不足以确定一种固定的概率。

如果是后者，那么我可以告诉你，你更应该将精力投入到其他地方。更好的方法是什么?不要花时间都确定一种可能性是否存在，而应该去发现和克服IT每天都会遇到的常见问题。现在很多人都忽视了这种策略。

不信?那我们来看另一个例子，这不是一个虚构的公司，我知道这个公司曾经遇到一次严重的IT故障，因此遭受了近10万美元的损失。管理层当然非常不安。公司很快建立了一个工作小组去确定故障的根源，然后推荐一些措施避免将来发生相同的故障。听起来很合理，是吗?

这个工作小组由5位来自于服务器、网络、存储、数据库和应用程序团队的成员构成。他们花了三个月时间和每个月超过100个人时的时间去调查问题根源。保守地估算，假设这家公司的每小时人力成本为50美元。那么5人、100个小时、3个月折算过来就是近12.5万美元。

现实：

并非想象的那样合理

是的，最终不仅所有根源问题都找到了——至少找到了大部分，而且也添加了代码，(可能)预测下次相同事件的爆发。听起来似乎并不差。但是要记住一 点：这家公司花费了比原先故障的损失还多2.5万的资金去创建一个系统宕机解决方案，而这个方案还不一定能准确地预报类似事件的发生。

似乎它并不是很合理。

你可能会想：“但是，你觉得我们应该关注于什么呢?毕竟，我们的职责就是和公司其他同事一起守住底线(不让系统宕机)。”

我明白这一点，我要强调的重点并不是这个。我们来对比一下前面的黑天鹅例子，一起来看看一个更常见的问题：网络接口卡(NIC)故障。

在这个例子中，另一个并非虚构的公司发现带宽使用峰会并且一直很高。当传输速率下降到最低，然后NIC招聘错误，并且最终卡死。问题是，在监控带宽 使用率时，停止响应或消失的网卡上并没有发出警报(公司监控了最后连接的IP，因此远程终端中断时WAN链路并没有发出警报。)

我们假设一个NIC故障平均需要一个小时才能被发现和正确诊断原因，然后网络管理员需要两个小时才能修复问题，而他们的人力成本是53美元每小时。 在线路中断时，公司每小时要损失1000美元的收入，并且还会失去市场机会等等。这意味着这样的宕机会让公司损失3106美元。

经验：

设置一个包含警报和监控的框架

现在可以这样考虑，按照我的经验，正确的监控和警报可以将发现和诊断这种NIC故障问题的时间缩短为15分钟。仅此而已。不需要任何其他的措施，至少在这个案例中不需要。但是，这种简单的措施可以将宕机损失减少750美元。

我知道这些数字听起来并不太震撼。但是，要知道中等规模的公司可能每年就可能轻松遇到100次NIC故障。如果没有监控这些问题，加起来就是30万美元的损失，而如果部署警报则每天可以节省7.5万美元。

这还不算预测NIC故障和提前更换网卡所避免的损失。如果我们估计使用预测监控能够避免掉50%的故障，那么可能节省的费用可能在19万美元以上。

同样，我并不是说不应该去做好应付黑天鹅事件的准备工作，但是如果预算比较紧张，有时候一些针对常见问题的简单警报所能避免的损失要高于去预测和防止可能不出现的“大问题”。

毕竟，NIC故障并不是大问题。甚至我认为Nate Silver也认同这一点。