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

在起草服务水平协议时，更重要的是在客户的设备和预算的约束范围内，与客户达成他们所期望的（并负担得起）与您愿意支持的服务。

例如：单个非群集服务器不适用于需要99.999％的正常运行时间和24小时随时待命支持的客户，以及在重大故障时需要1小时“返回运营”的客户。 接受这一点并不合理，客户需要了解这一点。

是的，Windows 2003 Server是可靠的，可以很好地执行。 品牌服务器具有可靠的可靠性和坚实的保证。 服务器上的定期监控和TLC可以保持多年。

你需要“最好的希望，但最坏的计划”。

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

您需要将保持服务器活动所需的所有附加设备（networking，交换机，防火墙，操作员时间，备份）合并在一起。

最后，您需要testing您的应急计划，并保持基础架构的灵活性，以便以多种不同的方式解决故障。

没有一个真正的标准数字我们可以引用你自己的服务器2003是一个非常稳定的系统，但你可以预期的正常运行时间取决于一些可变因素。

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

从理论上来说，这一切都很好，但是我们都知道服务器也出于其他原因脱机，硬件故障，networking问题，软件挂起，这些都不是你可以轻易预测的事情，但是build议适时地处理不可预知的事件。

最后，你会想要计划升级或更改的时间，因为服务器的使用可能会随着时间的推移而增加，是否需要升级来应对变化？

所有这些因素都会给你预计的正常运行时间，如果你没有错误，没有升级等等，你的实际正常运行时间可能会比这更好，但是最好是谨慎的。

根据我对Server 2003 Standard R2的经验，我可以告诉你，如果你没有任何硬件/networking问题，这是很高的。

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

从正常运行中崩溃2003会花费很多。

您可以计划更新的SLA，即每周下调一次，最多2小时，假设一切正常。 但是，除非你使用故障转移等方式启动集群，否则你无法为所有其他事情做SLA。 如果你做更新会发生什么，重启服务器，它不会出现？ 或者它得到病毒，或驱动器控制器死亡，问题可能是无止境的。

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

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

Windows，任何版本，定期重新启动的好处。 操作系统本身有内存泄漏，甚至没有考虑到应用程序和服务。 更新也需要重新启动。 您可以轻松地将这两个操作组合在一起，每周只需要重新启动一次就可以停机。

尝试了很多方法来应用更新并定期重新启动之后，我学会了最好的方法是脚本更新，但不允许更新过程重新启动机器。 我经历了多种情况的服务器，或者没有正确closures，或者在脚本更新触发重启时没有正常恢复。 重新启动单独执行。 我安排更新从星期六晚上11点开始安装，星期天上午3点到凌晨4点重新开始在服务器间交错。

监控系统在此期间不会发出警报，以防止产生不必要的警报。 另外，服务器在重新启动后给我一个emai。 当我星期天早上醒来的时候，我检查了我的电子邮件。 如果有任何警报或我没有从每个重新启动的服务器的电子邮件我知道我有一个问题。 尽pipe如此，还没有发生。

在一个30天的一个月里，有四点三〇〇分钟。 99.75％的正常运行时间是3992 – 这使您有108分钟的停机时间来执行任何计划的维护。 这应该是绰绰有余的，虽然我认为可以写SLA主要的维护（包括但不限于升级）预先计划的SLA不包括在内。

困难的部分是在紧急情况下 – 需要多长时间才能到达服务器，找出问题并加以解决。 在这种情况下，四个小时可能是不够的（99.44％）。

自2000年以来，我一直在寻找同步的Windows服务器，在那段时间内，我可以回想起因防火墙故障（单独的硬件，2个灾难性的），1个DoS攻击（不是针对我们的服务器但受到影响）以及数据中心需要的几个重要的定期维护窗口。 Windows服务器本身…除了应用补丁或服务包，我想不出任何。 （快速touchwood）

我会期待什么？ 最低99.5％（这听起来很低），但至less给你一个机会。 大多数月份你会接近100.00％。 如果客户不付钱，不要高出（99.5）。