Windows Server 2003 可用性/正常运行时间

在起草 SLA 时，更重要的是要与客户达成一致，他们期望（和负担）什么，而不是您愿意在设备和预算限制内支持什么。

例如：单个非集群服务器不适合需要 99.999% 正常运行时间和 24 小时待命支持以及在发生重大故障时 1 小时“恢复运营”的客户。接受这一点在技术上是不合理的，客户需要理解这一点。

是的，Windows 2003 Server 是可靠的并且性能非常好。品牌服务器具有久经考验的可靠性和坚如磐石的保证。服务器上的定期监控和 TLC 可以使其运行多年。

你需要“抱最好的希望，但做最坏的打算”。

您还需要准确计算可用性统计数据并与客户商定计算（凌晨 2 点的 1 小时停机时间与周二上午 11 点的“成本”不同）。

您需要整合保持服务器运行所需的所有附加设备（网络、交换机、防火墙、操作员时间、备份）。

最后，您需要测试您的应急计划，并保持您的基础架构灵活，以便您可以通过几种不同的方式解决故障。

我们并没有真正可以引用您的标准数字，server 2003 本身是一个非常稳定的系统，但是您可以预期的正常运行时间取决于许多可变因素。

理论上，您需要让服务器离线的唯一事情是应用更新，这应该最多每周一次。您可以通过计算服务器重启所需的时间来计算这些停机时间。

理论上这一切都很好，但我们都知道服务器下线也有其他原因，硬件故障、网络问题、软件挂起，这些都不是您可以轻松预测的，但建议及时适应不可预测的事件.

最后，您要考虑计划升级或更改的时间因素，服务器的使用是否会随着时间的推移而增加，是否需要升级以应对变化？

所有这些因素都会为您提供预测的正常运行时间，如果您没有故障，没有升级等，您的实际正常运行时间可能会比这更好，但最好谨慎。

根据我使用 Server 2003 Standard R2 的经验，我可以告诉您，如果您没有任何硬件/网络问题，那就太高了。

我有两台运行 Server 2003 的服务器，从来没有单独崩溃过一次。一台服务器的正常运行时间达到创纪录的 240 天！！！请注意：这是因为他们从未在系统上安装更新。

2003 年从正常运行中崩溃需要很多时间。

您可以为更新计划一个 SLA，例如，假设一切正常，每周关闭一次最多 2 小时。但是，除非您使用故障转移等方式启动集群，否则您真的无法为其他所有内容制定 SLA。如果您进行更新，重新启动服务器并且它没有出现，会发生什么？或者它感染了病毒，或者驱动控制器死了，问题可能无穷无尽。

您最好指定用于应用更新的 SLA 和用于响应出现的问题的 SLA。

执行 SLA，因为我将在 1 小时内响应中断，但解决或解决该中断的时间会有所不同，因为它无法预料。

Windows，任何版本，都可以从定期重启中受益。操作系统本身存在内存泄漏，甚至没有考虑应用程序和服务。更新也需要重新启动。您可以轻松地将这两个操作结合起来，每周停机时间只需重新启动所需的时间。

在尝试了一大堆方法来应用更新并定期重新启动后，我了解到最好的方法是编写更新脚本，但不允许更新过程重新启动机器。当脚本更新触发重新启动时，我经历过多种服务器未正确关闭或未正确恢复的情况。单独执行重新启动。我安排更新从周六晚上 11 点开始安装，并在周日早上 3 点到 4 点之间在服务器上交错重新启动。

监控系统在此期间不会发出警报，以防止产生不必要的警报。另外，服务器在重新启动后会向我发送电子邮件。当我周日早上醒来时，我会查看我的电子邮件。如果有任何警报或者我没有收到来自每个重新启动的服务器的电子邮件，我知道我有问题。不过还没有发生。

一个月 30 天有 43,200 分钟。99.75% 的正常运行时间为 43,092 - 这让您有 108 分钟的停机时间来执行任何计划的维护。这应该绰绰有余，尽管我认为可以将提前计划的 SLA 主要维护（包括但不限于升级）写入 SLA 中。

更难的部分是在紧急情况下——你需要多长时间才能到达服务器，找出问题并修复它。在这种情况下，四个小时可能不够（99.44%）。

自 2000 年以来，我一直在照顾托管的 Windows 服务器，在那段时间里，我记得 4 次由于防火墙故障（单独的硬件，2 次灾难性）导致的中断，1 次对网络的 DoS 攻击（不是针对我们的服务器，但受到了影响），以及数据中心所需的几个重要的定期维护窗口。Windows 服务器本身......除了应用补丁或服务包之外，我想不出任何东西。（快速触摸木头）

我会期待什么？最低 99.5%（听起来很低），但这至少给了你一个机会。大多数月份你将接近 100.00%。如果客户不为此付费，请不要高于（超过 99.5）...