周日早上，我刚刚在凌晨4点45分发生了服务器中断，并查看了2006年所有正常运行时间logging，除了在晚上11点到早上6点之间发生的4次中断之外。 （仅查看Web和数据库服务器上的计划外停机时间，而不检查内部LAN上的应用程序服务器。）
其他人也发现他们的服务器类似的行为？ 这只是一个侥幸吗？
编辑：这是因为许多中断（这些是计划外的，而不是定期维护，并发生在我们的硬件上，而不是ISP的networking）已经发生在晚上11点至上午6点，这让我不知道是只有我们…
服务器在下午1点到晚上10点之间访问量最大，而数据库备份全天进行，每天早晨大约在4.30左右进行大型备份（压缩使用更多的CPU）。 但是在这个窗口中的任何时候中断都会发生（这20个中断事件是5台服务器中的1台或2台防火墙发生的事件 – 其中约三分之一是由于两台不同机器的硬盘故障导致的）。 没有任何信息表明服务器正在做任何事情，因为那是凌晨一小时。
典型的“工作时间”一周不超过40小时。 在世界的一些地方较less。 一个星期共计168小时。 40/168 =每周不到24％是“工作时间”。
这表明，在非工作时间内，24/7全天候运行的系统故障将比工作时间多3倍。
显然，还有很多其他的考虑可以考虑到这一点。 多次轮class，高峰时间（对许多人来说，这可能会进一步偏向于非工作时间的失败）等等。
是的，我们find了，不，这不是侥幸。 我敢肯定，你的服务器憎恨你。 我知道我的服务器恨我，虽然他们很高兴地看到我死了，如果他们觉得自己挂了，我相信他们坚持下去，直到他们的ntp守护进程在他们的耳边耳语，这是深夜，现在是一个很好的时间去死。 他们知道，如果在1030时失败将会毁了我的一天，但在0345失败将会毁了我的夜晚，在黑暗中把我拖到伦敦，第二天也毁了。 他们喜欢这个。
由于硬盘故障导致企业防火墙在最不方便的时候失效，我把磁盘控制器板从硬盘中分离出来，切成四块，然后穿上了它的四分之一，头上挂着我的“办公室链”（带有所有我使用的各种访问令牌的挂绳）。 我清楚地看到，这件可怕的遗物，在他们清楚的看法下，其兄弟和姐妹的服务器在今后大体上保持一致，因此对失败的惩罚被清楚地显示出来。
（如果有人感到幽默失败，这篇文章是一个笑话，除了关于硬盘控制器，这是绝对正确的，工作。）
从晚上11点到上午6点之间的时间，似乎是一个典型的夜间工作。 也许其中一些给你的服务器带来了一些额外的压力，增加了当时正在发生的失败风险。
一夜之间，大部分基础设施发生变化。 networking和其他资源可能会减less。 您正在使用远程监控，您将看到您的网站因为无法访问而closures。 了解各种资源的维护窗口将有助于消除实际中断的这些中断。
正如其他人所指出的那样，平均中断时间更可能是在办公时间以外的时间之外。 鉴于工作日可用性和8小时工作日，在办公时间内只有1/3的中断发生。 周末添加，甚至更less的中断发生在工作日。
跟踪中断的原因，以及如何检测。 由于networking资源不足，你会发现一些中断。 这些网站可能会在网站消失几分钟后出现神秘的中断，并在没有干预的情况下返回。 我预计你的很多隔夜停电是基础设施的变化。
基础设施的变化通常是安排的，所以你应该能够安排通知他们。 然后您可以相应地调整您的回应。 您的停机日志应该反映停电是由于变化。 同时logging所需的干预。 您可能需要将恢复代码添加到您的应用程序来处理数据库重新启动或其他此类资源更改。
了解各种资源的维护窗口可以帮助识别哪些资源导致意外中断。 您可能需要跟踪您的资源依赖性，因为networking磁盘和数据库将取决于networking基础架构。 同样，数据库可能依赖于networking磁盘存储。
在过去的三个月里，我有一台VoIP服务器死在我身上。 模具，也许不是最好的词，因为机器内核恐慌后，将启动。 通常情况下，机器将在上午7点至晚上7点之间完美运行。 然后，在间隔1-30天的随机间隔中，当我在上午7点返回办公室时，系统控制台将被locking和无响应。
经过大约12次这种情况的迭代…总是发生在晚上11点到早上7点之间，确定了主板失败了，特别是电容器的责任。 我想我在某个地方读到极端温度会加速死亡。 我想我的小办公室并不罕见，但我通常允许在下class时间内将温度上调至华氏15度以上，在75度以下20度。 因此，我相信，那些不使用冷藏数据中心的小型作业，可能会在上午的凌晨时间内遭受由温度引起的故障。
我的回忆又一次是，在我们早上开店之前的8个小时里，日志显示了失败 – 总是。