概述

　本文评价了 Microsoft® Solution for Internet Business（MSIB）2.0 版的性能和容量、可扩展性和可用性等特征，并为检验和测量这些特征提供了一个流程。 您可以利用这一流程判断用户负载如何影响硬件资源以及资源如何变成性能的瓶颈。 您可以将这些信息用于：

• 评估增添资源的性能。
• 确定哪些资源可以满足更大的容量需求。
• 计算某一特定硬件配置的最大能力。

本文中用于计算 MSIB 2.0 站点容量的方法被称为交易成本分析（TCA）。 如需了解对 TCA 过程更为深入的讨论，可以参见以下网址上的 Capacity Planning Using Transaction Cost Analysis Methodology ： http://go.microsoft.com/fwlink/?LinkId=9498。

本文假设：

• 您是一位 IT 人士，对 MSIB 2.0所用的所有软件和硬件技术都有实际工作经验。 本文特别着重介绍了 Microsoft Internet Security and Acceleration ( ISA ) Server、SQL Server ®2000、SharePoint? Portal Server 和带 MSIB 2.0 的 IIS 5.0 组件的 Windows® 2000 Advanced Server。
• 您对 MSIB 2.0 的基础和企业部署都比较熟悉。

如需了解关于 MSIB 2.0 及其相关组件以及其基准和企业部署方面的更多信息，可参见下面地址处的 MSIB Overview http://www.microsoft.com/china/technet/itsolutions/techguide/mso/msib/default.mspx.

本文分成三个部分论述。 下表介绍了这三个部分

性能和容量

• 在企业部署中的 Web 服务器为两处理器 1.4 千兆赫兹 （GHz）的，在六天零 19 个小时的期间内，每台服务器的处理能力都维持在每秒 82.88 次请求的级别上， CPU 的利用率约为百分之75左右。 这相当于预定使用方案中所定的 3027 名并发模拟用户的情况。
  
• 在基准部署中的 Web 服务器为两处理器 1.4 千兆赫兹 （GHz）的，在六天零 20 个小时的期间内，每台服务器的处理能力都维持在每秒 92.43 次请求的级别上， CPU 的利用率约为百分之75左右。 这相当于预定使用方案中所定的 3376 名并发模拟用户的情况。
  
• 一台四处理器的带足够的驱动器容量的 1.4 GHz SQL 服务器在用于数据库存储的时候可以支持大约七台 Web 服务器的网上需求。 在本文所述的测试中，Microsoft? SQL Server 2000 Enterprise Edition Server 内包括了所有的 MSIB 数据库。 在本文所述的使用概况和站点概况下， MSIB 项目组进行了测试，结果表明 SQL 服务器上的 磁盘吞吐量需求并未在性能上产生瓶颈。 这是因为 Web 服务器上的请求都是高度缓存的。 要决定一个实际站点需要的确切配置和 SQL 服务器数量，必需要利用准确的客户数据进行更为详细的交易成本分析 （TCA）。如需了解关于进行详细 TCA 的信息，参见“Capacity Model for Internet Transactions and Using Transaction”用于站点容量规划的成本分析，地址在 http://go.microsoft.com/fwlink/?LinkId=9498。

可扩展性

• 在 SQL 服务器等支持数据层服务器适当增加不致造成瓶颈的时候，可以使用网络负载均衡(NLB) 服务对多台 Web 服务器进行线性升级。

可用性

• MSIB 2.0 的企业部署计算得到的系统可用性为 99.616%，这一结果是通过测量群集要素的故障切换和恢复时间得出的。 这一可用性计算结果意味着每个服务器群集的平均无故障时间为一星期。 如果目标平均无故障时间 ( MTTF) 增加到一个月，那么系统计算得到的可用性为 99.910%。

第一部分——性能和容量规划

　这一部分提供了关于监控 MSIB 2.0 站点的信息以及根据这些性能数据利用交易成本分析(TCA)方法进行容量规划的信息。 对 MSIB 2.0 进行容量规划的目的是利用可接受的响应时间支持交易吞吐量，而同时将主机平台的总拥有成本降到最小。 传统的解决方案常常试图从一般基准测试的测量结果进行推论得到使用成本。 然而，更为有效的方法是基于交易成本分析（TCA）的。 本部分还介绍了 MSIB 2.0 项目组如何利用 TCA 方法改善了 MSIB 2.0 站点的代码以及软硬件配置的。

本部分包括：

• 性能监控
• 交易成本分析
• 性能监控

MSIB 2.0 Web 站点是围绕着企业级内容易管理 Web 站点的概念设计的。 本站点是为那些希望利用类似功能创建站点的企业设计的快速上市的平台。 与大多数软件情况类似，该站点尚未得到完全优化，总有改进的余地。 您应当利用以下的性能计数器监控您的 MSIB 2.0 站点的性能。

关键性能的计数器

很多性能目标都是内置于 Microsoft Windows? 2000 操作系统及其他 Microsoft 应用程序和服务中的。 您利用性能计数器可以跟踪这些目标的性能。

　MSIB 项目组利用以下的性能计数器分析 MSIB 2.0 站点的性能。 下面给出的性能计数器是以如下格式编写的： 性能目标\ 性能计数器

如需了解建议用于监控您的 ISA 服务器性能的性能计数器的信息，参见 http://go.microsoft.com/fwlink/?LinkId=14746。

交易成本分析

　这一部分介绍了 MSIB 项目组用以为 MSIB 2.0 站点计算交易成本分析(TCA)的使用概况和站点概况，并总结了 MSIB 项目组在典型的企业和基准 MSIB 2.0 部署中进行的交易成本分析(TCA)得到的操作成本。 此外，该部分还介绍了如何使用 TCA 方法在 MSIB 2.0 站点上进行容量规划。 从最开始的意义上说，利用该分析方法的最符合逻辑的地方是在销售阶段中决定许可证数量的时候。

部分包括：

• 使用和站点概况
• 操作成本摘要
• 使用 TCA 方法进行容量规划
• 使用和站点概况

本部分介绍了 MSIB 项目组用以为 MSIB 2.0 站点计算交易成本分析 (TCA) 的在线使用概况、 MSIB 使用概况和站点概况。 要执行一个 MSIB 2.0 站点的 TCA ，您必须首先创建一个使用概况和站点概况。 然后您才能够利用 TCA 方法计算您的站点容量，这种方法将在本文后面的部分加以介绍。 编制使用概况的过程在“Commerce Server 2002 Creating a Usage Profile for Site Capacity Planning”中有详细介绍，地址在 http://go.microsoft.com/fwlink/?LinkId=9498。

　在线使用概况

在线概括描述了在线时 MSIB 2.0 站点的使用情况。 这一概括不包括 MSIB 2.0 站点离线时可能发生的任何操作。 下表列出了本文中 MSIB 项目组所用的在线使用概括。 峰值乘数用于计算与平均负载有关的系统的最大容量。 如果每秒钟的平均请求数量是 50 ，如果您的峰值乘数是 3 的话那么预期峰值将会是每秒钟 150 次请求。 为了对实施 MSIB 2.0 进行容量规划，您应当为系统的峰值容量做规划。

下表列出了本文中 MSIB 项目组测试的 MSIB 2.0 操作使用概况。 这些测试值是通过分析 Web 站点信息流量得到的。 注意以下方面：

其中 分布权重 一栏给出拉某类操作占总请求数的百分比。

其中 标准化 一栏表示分布百分比乘以前表给出的每用户每次访问请求数得到的结果。 注意这一栏合计达6。

其中 每个操作的请求数 一栏给出了执行某一操作所用的用户请求数量。 由于回帖或服务器重定向等原因，有些操作会产生多个 ASP.NET 请求。

　其中 每个会话的请求数 一栏给出了用户在每次会话中发起的对某一操作的请求数量。

　

　站点概况

MSIB 项目组为本文进行的测试中所用的目录数据库包含了四种语言编写的一百万条项目。 搜索页组是利用均匀分布方式在一万个项目的子集中挑选的。 UPM 数据库中包含了一百万个用户。 MSIB 项目组测试了一个有 100 条信道，每条信道 100 条记录的 MSIB 2.0 站点。

操作成本摘要

本部分列出了用户访问 MSIB 2.0 站点时可以执行的每种操作的典型核心成本。 这些成本是根据 MSIB 企业部署和基准部署计算的，这些部署中使用的软硬件配置如“附件 A -hardware and Network Topology Details”所述。 成本以 P4EM 描述，如本文前面部分“术语定义”所述。 注意，两种部署下的 SQL P4MC 是一样的。

下表给出的一些操作涉及到多个 ASP.NET 页面或 HTML 请求和发布。 每一种成本都表示系统运行在最佳吞吐量下，在这些测试中前端 Web 服务器的 CPU 利用率采用百分之 85，计算得到了这些成本。

为了进行数学分析，在后面的方程中将会把该表看成一个矩阵。

使用 TCA 方法进行容量规划

本节提供了为 MSIB 2.0 站点进行容量规划所用的数学计算方法。 您可以利用交易成本分析 (TCA) 方法将站点中的每项操作隔离开来，以便进行性能调节。 利用 TCA 方法您还可以利用不同的使用配置文件和类似的页面组计算 Web 站点的容量。 类似地，当您要改变 Web 站点的单个页面组的时候，您可以简单计量一下与单个页面组相关的新成本从而规划其容量。

每用户频率的操作

The 每用户频率的操作 如下表所示。 这个频率是根据定义的使用配置文件获得的统计结果。 每秒钟每位用户的操作次数 一栏给出了每位并发用户的操作频率、或请求比率。

每秒钟的请求频率 = 每个会话的请求数/会话的平均时间

其中 每个会话的请求数 来自于 每个会话的请求数 一栏，位于 MSIB 使用配置文件 表中，而 会话的平均时间 来自于 联机使用概况.

这样一来，对于 匿名主页 操作来说；

　1.64 每个会话的请求数 / (6分钟*60秒) =0.004556 每个用户每秒钟的请求数。.

　频率乘以成本

下一步是要将频率乘以 Web CPU 和SQL CPU 等硬件资源的成本。 例如，一项操作的 CPU 成本是：

每个用户每秒钟的操作成本 ( 单位：P4EM ) = 频率 * P4MC 成本

其中 频率 来自于 上表的每秒钟每位用户的操作次数 一栏，而 P4MC 成本 来自于 本文操作成本摘要部分中表格的 Web P4MC 栏。 columns of the table in the Operation Costs Summary section of this document.

这样一来，对于 匿名主页 操作来说；

0.004556 每秒钟每位用户的操作次数 * 11.54 P4MC = 0.05258 P4EM

这样就得到了每位并发用户如下的成本矩阵：

　
　根据 CPU 容量计算最大并发用户数

下一步是要根据 CPU 容量按照如下方式计算最大并发用户数：

一个系统的 CPU 容量 是用处理器数量乘以 CPU 的 MHz 定额得到的。 因此，对一台安装了两个 2 GHz 处理器的计算机来说；

CPU 容量 = 2 x 2000 MHz = 4000 P4EM

The 工作载荷下的系统目标 CPU 容量 通常由 IT 部门决定。如果没有这方面的标准可循，那么您应比照着平均的长期载荷对峰值载荷进行分析，据此决定这一目标值，确保 CPU 在100％容量以下运行。 假设一台计算机在 85％ 的容量下运行，那么应该按照如下方式计算其目标 CPU 容量：

目标 CPU 容量 = 4000 P4EM 的 CPU 容量x0.85=3400 P4EM

为了 根据目标 CPU 容量和总用户成本计算 Web 服务器的目标用户容量， 在前表中找到每位并发用户 Web CPU 的总成本（0.55000）。 然后将这一成本分成目标 CPU 容量。

目标用户容量 = 目标 CPU 容量 每个用户 Web CPU 总成本 Web CPU cost per user (基础 Web P4EM)

= 3400/ 0.5500 = 6182 并发用户

服务机会

您应当把交易成本分析（TCA）和可用性规划看作是一种服务机会。 应当将本文祥述的步骤看作是用于管理 MSIB 2.0 站点可用性的最佳做法。

　第二部分——MSIB 2.0 站点的性能和可扩展性

　这一部分简单介绍了 MSIB 项目组在实现站点代码和实际 MSIB 2.0 部署所需的吞吐量和可扩展性需求时所采用的步骤。 这一部分并不介绍 ASP.NET 编码做法、Microsoft Internet Information Services (IIS) 5.0 调节参数或 SQL 服务器的调节参数。

为了优化 MSIB 2.0 站点的性能，MSIB 开发组对以下内容做了调查：

• 分析 SQL 服务器
• 使用高速缓存方案
• 调节硬件
• 调节 IIS
• 横向扩展 Web 群

分析 SQL 服务器

优化站点软件性能和可扩展性的第一步就是分析后端 SQL 服务器的使用情况。 MSIB 项目组为站点内的每个页面进行了一次 SQL Query Analyzer 追踪。 以下是免费文本搜索页面的输出结果：

EventClass TextData CPU Reads Writes Duration SPID StartTime
　SQL:BatchCompleted SET NO_BROWSETABLE ON 0 0 0 0 52 2000-12-05　11:07:16.513
　SQL:BatchCompleted select * from CatalogGlobal where [CatalogName] =N'ANVIL0' 0 2 0 0 52 2000-12-05 11:07:16.513
　SQL:BatchCompleted SET NO_BROWSETABLE ON 0 0 0 0 52 2000-12-05　11:07:16.513
　SQL:BatchCompleted SELECT A.* FROM CatalogAttributes A, syscolumns SWHERE S.id = OBJECT_ID('ANVIL0_CatalogProducts') AND A.propertyname =S.name ORDER BY A.PropertyName 15 55 0 16 52 2000-12-05 11:07:16.513
　SQL:BatchCompleted EXEC sp_GetResults_for_AllColumns N'ANVIL0', N'*',N'FREETEXT (*, N''testasdf'' )', '', 1,11,1,39 32 1147 0 76 52 2000-12-05 11:07:16.530
　SQL:BatchCompleted EXEC sp_CheckCatalog '*', 'ANVIL0', 'FREETEXT (*,N''testasdf'' )' 0 29 0 0 52 2000-12-05 11:07:16.607

　MSIB 项目组的第一项查询优化措施就是在追踪分析过程中发现的。 MSIB 项目组在页面上查找重复的查询并减少冗余的 Select 语句。 MSIB 项目组很好地跟踪了目标的信息并对代码重新排序，使得查询操作只能进行由条件调用，从而完成了这一步骤。

接下来， MSIB 项目组从磁盘读取的角度确定了最为昂贵的查询。 为了简化这些操作，MSIB 项目组尝试着降低查询操作的 I/O 复杂性。 例如，改变 Select * 语句，使其归入隔离更好的返回子集中。

最后，MSIB 项目组通过 SQL 服务器调节向导重放了记录下的跟踪结果。 该向导建议对表格索引进行一些变更。 所有这些页面级变更的组合降低了后端 SQL 服务器的负荷并因此改善了 MSIB 2.0 Web 站点的可扩展性。

在 SQL Server 服务器上，MSIB 项目组保留了与性能有关的所有默认配置。

使用高速缓存方案

提高吞吐量的下一步就是利用应用服务器中的高速缓存。 MSIB 项目组利用了以下的高速缓存方案以优化 MSIB 2.0 站点的性能。

页面输出高速缓存

Microsoft .NET Framework 系统内内置了页面输出高速缓存。 关于 MSIB 项目组如何使用这种功能的详细情况在 MSIB Developers Guide 中有所介绍，该资料随 MSIB 2.0 提供。 这种高速缓存方案对于未经个性化的页面是有效的，例如那些未用个性化内容对象（PCO）显示 Microsoft Content Management Server （MCMS）的页面。

MCMS 服务器的性能

Microsoft Content Management Server (MCMS) 2002 可以在纵横两个方向上进行扩展。 目前正在编写一份关于 MCMS 部署的文件，其中讨论了各种可用于 MCMS 的高速缓存方法。 在编写完成之后，可以从以下地址得到该文件 http://go.microsoft.com/fwlink/?LinkId=15170。如需了解关于 MCMS 2002 高速缓存的更多信息，参见 MCMS 2002 Help 中的“Optimizing MCMS Site Performance”。 如需了解关于利用 MCMS 2002 SCA 设置高速缓存属性的更多信息，参见 MCMS 2002 Help 中的“Specifying cache properties”部分。 如需了解 MCMS 性能的更多信息，参见 MCMS 主页，地址在 http://go.microsoft.com/fwlink/?LinkId=8426.

调节硬件

在进行性能分析的过程中，为 Web 服务器和 SQL 服务器选择正确的硬件发挥着非常重要的作用。 此外知道如何为这些服务器选择正确的硬件还能够让您为其他用户提供相关硬件的建议。 这一部分介绍了 MSIB 项目组是如何为本文所述的测试选择 SQL 服务器的。

Web 服务器

在为 Web 服务器选择硬件的时候， MSIB 项目组考虑了以下几个方面：

• 内存
• 磁盘子系统
• 网络系统
• CPU

内存

MSIB 项目组为 Web 服务器配置了较大的随机存取存储器（RAM），所配容量超出了服务器运行任务所需的量。 为了确定服务器可以减少多少物理 RAM 内存，之后项目组计算了在工作负载下服务器的最大工作集。 一个典型部署所需的 RAM 数量取决于您为该部署对高速缓存和内存的需求。 不过，在大多数情况下，1GB 的物理 RAM 已经是足够的了。

磁盘子系统

MSIB 站点前端 Web 服务器的磁盘子系统作为一个只读设备，是用来存储自举分区和站点内容的。 这一子系统必需要有读/写设备才能进行文件分页操作，不过如果有足够的物理存储器支持系统的话，这些操作都是最低限度的要求了。 Web 服务器确实是利用磁盘子系统写事件日志和 Web 日志的。 这种操作已经由 Windows 2000 操作系统进行了很好的调节，很少需要超过一个内存芯片才能达到所需性能的。

网络系统

Web 服务器上的网络系统至少应当包括一块 100BaseT 的网卡。 要实现更高的安全性、可管理性和可用性，服务器应该配备两块甚至三块网卡。 在 MSIB 项目组的测试中，web 服务器的网路吞吐量并不足以用完一块 100 兆位的网卡能力。

CPU

最后，应当为服务器选用当前最好的 CPU 和处理子系统。 在可以预见到的将来，这个特别的硬件子系统仍将是该服务器的瓶颈。 这是因为动态 Web 页动态和过程全面的性质造成的。

确定适当的 CPU 数量是 Microsoft Server 每处理器许可计划的一项要求。 要确定这一需求，需要对您的 MSIB 2.0 站点进行一次 TCA 分析，在本文前面的“使用 TCA 方法进行容量规划”一部分对此做了介绍。

SQL 服务器

MSIB 项目组利用本部分介绍的指南建立起了 SQL 服务器，使之并未成为 MSIB 2.0 部署中的瓶颈。

在为 SQL 服务器选择硬件的时候， MSIB 项目组考虑了以下几个方面：

• 内存
• 磁盘子系统
• 数据库

内存

大量的随机存取存储器（RAM）对于 SQL 服务器是有好处的，因此您应当依照数据库的工作集权衡 RAM 的数量。 在运行的时候测试网络的输入/输出 （I/O）。 SQL 服务器的处理负荷将是访问 SQL 服务器数据库的前端服务器数量以及负荷配置文件的正函数。

磁盘子系统

一般情况下， SQL 服务器最重要的调节选项就是安装物理磁盘子系统。 为了获得最佳性能，数据库应当与它们在不同物理驱动器上的业务处理记录分离开来。 您应当建立起所有的数据库、业务处理记录和 TempDB ，这样才不致让单个的磁盘子系统成为瓶颈。 在 MSIB 项目组的测试方案中，磁盘子系统并未成为一个问题。 不过，对于正在运行中的站点来说，您应当认真地将磁盘成本和交易联系起来考虑，以便为增加的磁盘需求做好规划。

数据库

MSIB 2.0 的设计使其可以进行横向扩展并为后端数据库系统分区。 用于营销、用户配置文件管理、目录、数据仓库、交易、内容和管理的数据库可以分离开来，放到物理 SQL 服务器数据库中。 这样一来您就能够轻松地按照数据库将部署系统分配到独立的服务器或群集上去。 关于如何做到这一点的详细介绍在随 MSIB 2.0 附带的 MSIB 2.0 部署指南中可以找到。

调节 IIS

为了进行本分析，MSIB 项目组对前端 web 服务器进行了最小限度的调节。 在默认 Web 站点的 Properties 页面的 Performance 选项卡上，性能调节块被改变为每天超过 100000 次命中的数值。 所有其他的设置都保持原状。 如果您必需要在测试站点或实际站点中改变任何参数的话，那么请每次只改变一个，然后将新的结果与旧结果加以比较。

重要事项： 对这些参数中的任何一个进行不适当的改变可能会给站点管理带来麻烦。

Web 群：MSIB 2.0 站点的扩展

如果所需的 CPU P4EM 比单台服务器所能提供的能力大，那么 Web 群将需要用到多台 Web 服务器。 出于可用性和可靠性的考虑，MSIB 项目组建议在任何部署中最少都要使用两台 Web 服务器。

第三部分 — MSIB 2.0 站点的可用性

　可用性规划和可扩展性规划是非常类似的两项工作。 可用性规划的第一步就是要确定您的业务需求。 作为一项指导，建议您重新审查一下您现有站点的行为，然后将您的站点与竞争对手们的站点加以比较。 如需获得各个竞争对手的可用性和页面等待时间等信息的列表，参见 http://www.keynote.com，地址在 http://go.microsoft.com/fwlink/?LinkId=15046。

有两个站点提供了全面的 Internet 性能和一般性能指导性原则，它们是www.mediametrix.com ，地址在 http://go.microsoft.com/fwlink/?LinkId=15045 和“http://Nielsen-netratings.com”，地址在 http://go.microsoft.com/fwlink/?LinkId=15043。

您可以按照不同级别的可用性部署 MSIB 2.0 解决方案。 应当在规划阶段中确定您的 MSIB 2.0 站点的可用性目标。

这一部分介绍了可用性，概述了可能会造成您的 MSIB 2.0 站点不可用的事件，提供了高可用性技术和建议，介绍了如何避免单点故障，并讨论了 MSIB 2.0 企业部署的恢复模型。

本部分包括：

什么是可用性？

使站点不可用的三类事件

高可用性技术和建议

避免单点故障

MSIB 2.0 企业部署的恢复模型

确定预期的可用性

什么是可用性？
　本文中使用了可用性的定义，因为它是 Internet 站点涉及到的一个概念。 可用性包括可靠性、故障恢复和故障几个方面。 最常用的可用性计量标准之一就是“九的个数”。“这一数字可以转换为某一系统可正常工作的时间百分比。 例如，一个运行时间百分比为 99.999 的系统可以说成其可用性为五个九。 下表给出了九的个数和时间之间的对应关系。

　从运行时间的角度来看可用性

从上表可以看出，可接受运行时间为百分之 99.9 的系统平均每天只有 86.40 秒钟或每月只有 43 分钟是不可运行的。 要获得更多个九的可用性，必需要对系统部署、软件和解决方案实施的管理加以改进。 要预测一个系统何时甚至是隔多久会发生故障是非常困难的，因此要获得更好的可靠性，一个关键的规划方法是要缩短故障的恢复时间。 如果您的系统可以在 86.4 秒钟之内从故障中恢复过来，那么系统即使每天发生一次故障，仍然能够达到三个九的可用性。

从成功交易角度来看可用性

上述的可用性概念是作为运行时间的函数分析的，与此相反是将可用性作为成功交易的函数来分析可用性这个概念。 换句话说，如果某一个 Web 站点每天处理 100000 个请求，那么百分之 99.9 的可用性就意味着每天有 100 个请求是失败的。 如果您将此作为衡量可用性的标准，那么在业务规划中对可用性的要求就可能会发生变化。 例如，在一天之内一个 Web 站点的通信量是在改变的。 在凌晨两点的时候，您的站点每小时的访问次数可能还不到 100 。 如果您的站点在这期间发生故障，那么此时发生的失败请求数量大约要比下午 5 点时少四倍，那个时候是一天中的峰值时刻，每小时的访问次数为 400 次或更多。

使站点不可用的三类事件
　有三类时间可能会造成您的 MSIB 2.0 站点无法工作，从而造成其不可用：人为错误、硬件故障和软件故障。如果规划不当的话，这些事件中的任何一个都可能会使站点的目标可用性无法实现。

人为错误

人为错误是最需要认真对待的一类事件。 在用户和正在工作的站点交互作用的时候，他们可能会执行某些对站点管理造成不良影响的操作。 因此，强烈建议对管理操作首先在专门测试环境中加以测试然后再编写脚本。 当新的管理操作第一次用于实际运行站点的时候，应当对其进行仔细监控，观察其对整个系统的影响。 认真的规划会有助于站点实现最高的可用性。 参见 MSIB Solutions Operations Guide 地址在 http://go.microsoft.com/fwlink/?LinkId=15047 ，其中介绍了可以减少人为错误的主意和最佳做法。

硬件故障