使用 wiki 维护 AIX 文档

5Seven

简介

与系统管理相关的最困难的任务之一是维护一个最新的、全面的、涵盖所有系统的集中式文档存储库。文档存储库也是任何业务连续性计划的关键部分，它为所有培训、支持、维护和灾难恢复活动提供基础。本文为维护使用业务连续性概念实现的、用于 IBM® AIX® 技术文档的 wiki 服务器，提供一种结构、配置和自动化方法。

这里讨论的 wiki 服务器基于 MediaWiki 软件，为编写和维护文档存储库提供一个协作环境。除了协作功能之外，它还为存储库中的所有文档创建标准的外观和感觉。本文中提供的结构为存储库的所有贡献者提供一个容易维护的环境。

手工与自动化文档

技术文档的难题之一是，文档一编写好，马上就会变得陈旧、过时和不可靠。这是因为现代数据中心环境中的大多数系统是动态的，总是在不断地升级、改进和调优。由于现代数据中心具有动态性，如果手工编写技术文档，文档就不可能可靠。编写文档要花费时间，而大多数管理员没时间及时地在文档中完整地记录对每个系统的更改。总是有比更新系统文档更重要、更紧迫的任务。

本文提出的主要观点之一是，系统管理员应该不再编写文档，而是应该自动地生成文档并把文档上传到集中式文档服务器。系统管理员编写文档花费的时间实际上是浪费了，因为文档完成之后马上就过时了。数据中心环境中的所有文档必须定期地（每小时、每天、每周或每个月）自动生成。系统管理员应该花时间编写生成文档的自动化过程，而不是编写文档。按更一般化的说法，AIX 系统管理员的工作是把所有任务都自动化，包括文档。

从手工编写文档转换到自动生成技术文档要求系统管理员编写自动执行这些过程的程序和脚本。手工编写技术文档通常很乏味、无聊而且很耗时间。因此，大多数管理员都尽可能回避它。把这个任务由手工编写变成编程任务，会重新唤起管理员的热情，因为编程有意思多了。让他们更新和改进自动化过程可以保持他们的热情。结果是，技术文档总是最新且可靠的。

在系统管理方面，相当多的精力花费在培训和重新培训系统管理员上。通过提供围绕业务连续性概念设计的标准化自动文档存储库，可以显著减少这方面的工作量。这种存储库能够立即提高管理员的生产力和交流水平。

自动生成技术文档的另一个好处是减轻管理员的工作负担，这会降低管理企业的总成本。

由于现代数据中心具有动态性而且管理员的工作负担很重，技术文档必须是从系统和应用程序生成的，这样才能确保文档是最新的、一致的和可靠的。任何业务连续性计划都包含自动生成技术文档的需求。

在这里，“业务连续性” 这个词可能会引起一些读者的误解，因为许多组织把业务连续性等同于灾难恢复。对于本文的主题，这两个词的意思并不相同。本文中使用的 “业务连续性” 的定义如下：

“业务连续性由一些每天都要执行的活动组成，其目的是确保业务在当前和以后都正常运营。可以把业务连续性计划看作运营日常业务的方法或全企业范围的思想观念。”

用于 AIX 技术文档的 wiki 结构

为了辅助生成技术文档的自动过程，必须创建一个集中式文档存储库，它应该允许世界上任何地方的系统创建/上传/更新相关的文档。它还应该为文档提供标准的外观和感觉以及标准的结构。

当前能够满足所有需求的最好的解决方案是 "wiki" 服务器。wiki 提供一个协作性的文档环境，它维护文档历史、安全性以及外观和感觉，允许几乎无限的定制。有许多种 wiki 服务器；本文主要关注 MediaWiki 的开放源码 wiki 服务器。

但是，仅仅下载并安装 wiki 服务器作为集中式文档存储库使用是不够的。必须有与服务器相关联的结构，从而确保以一致的方式组织文档。本文讨论的结构是一个业务连续性结构。这种文档结构完全针对现代数据中心环境的需求，提供支持任何业务场景所需的灵活性。本文为搭建和维护用于 IBM AIX 技术文档的 wiki 服务器提供一种业务连续性结构、配置和方法。

与维护集中式文档存储库相关的另一个困难的任务是，对存储库中的文档实施标准。通过实现基于标准业务连续性结构的集中式文档存储库，实施标准会变得容易得多。在把文档上传到存储库时，选择（而且要求有）预定义的类别，这样就可以消除组织存储库中的数据时存在的一些不确定性。另外，从存储库结构形成一套系统管理方法，用来构建、支持和维护全世界范围的多数据中心的大型 IBM AIX 环境。这套方法覆盖 IBM AIX 系统的整个生命周期，从计划和部署直到退役和回收。

wiki 环境有助于为文档创建标准的外观和感觉；但是，搜索并找到想要的文档很麻烦。本文提供的业务连续性类别结构为存储库的所有贡献者提供一个容易维护的环境，它包括：

• 用于业务连续性的类别结构
  
  • 策略
  • 方针
  • 标准
  • 过程
  • 组织结构
  • 资源利用
    
• 用于灾难恢复的类别结构
• 业务影响分析
• 服务水平协议，RPO，RTO
• 威胁和风险
• 缓解和意外情况
• 备份和恢复过程
• 恢复场景
• 恢复测试
• 指挥中心
• 用于 shell 脚本的类别结构
• 用于电子商务的类别结构
  

业务连续性 wiki 结构的目的是，整合并自动处理世界各地数据中心中的 IBM AIX 系统的技术文档。

用于用户与 wiki 服务器交互的自动脚本

为了自动构建业务连续性 wiki 结构，本文提供几个 shell 脚本。这些脚本自动地执行相关过程，包括上传文件、创建新页面、修改现有页面、创建/修改类别、创建/修改模板等等。

wikiAutoLoad

wikiAutoLoad 是自动的 wiki 内容上传脚本，它为 shell 程序员或系统管理员提供一种把 wiki 内容上传到 MediaWiki 服务器的自动机制。可以在组织中的任何系统上运行此脚本，把信息自动地上传到集中式 wiki 文档服务器。

wikiAutoLoad 提供以下特性：

• 能够动态地把内容上传到世界上任何地方的任何 MediaWiki 服务器。
• 根据包含上传内容的文件的名称动态地决定页面名称。
• 在上传内容时，可以给页面分配多个 wiki 类别。
• 任何 wiki 用户都可以使用此脚本上传内容，不要求是管理员。
• 可以大批量上传任何基于文本的文件的内容。
• 在大批量上传时，根据文件名自动地生成 wiki 页面标题。
• 对于单一文件上传，用户可以指定 wiki 页面标题。
  

wikiAutoLoad shell 脚本假设要上传到 wiki 服务器的内容存储在本地系统上的文件中；每个 wiki 页面存储在单独的文件中。这个脚本使用 wget 命令发送文件并从 wiki 服务器接收 cookie。

其他几个脚本创建业务连续性 wiki 结构的特定部分。bcupload2wiki_k93 脚本和 mkbcupload_k93 脚本创建本文讨论的业务连续性结构。mkbcupload_k93 脚本包含整个业务连续性结构并生成 bcupload2wiki_k93 脚本。bcupload2wiki_k93 脚本与 wiki 服务器通信，创建并修改页面。用户可以使用它们修改业务连续性结构以满足自己的需要，然后重新生成 bcupload2wiki_k93 脚本，最后修改 wiki 服务器本身。

bcupload2Wiki_k93

使用这个 脚本 把业务连续性类别结构上传到 wiki 服务器，这要用到 wikiAutoLoad 脚本和 wget。

mkbcupload_k93

mkbcupload_k93 脚本使用其中定义的类别列表生成 bcupload2wiki_k93 脚本。很容易定制这个脚本以满足自己的需要。

mkdrupload_k93 脚本包含整个灾难恢复结构并生成 drupload2wiki_k93 脚本。drupload2wiki_k93 脚本与 wiki 服务器通信，创建并修改页面。用户可以使用它们修改灾难恢复结构以满足自己的需要，然后重新生成 drupload2wiki_k93 脚本，最后修改 wiki 服务器本身。

drupload2Wiki_k93

drupload2Wiki_k93 脚本把灾难恢复类别结构上传到 wiki 服务器，这要用到 wikiAutoLoad 脚本和 wget。

mkdrupload_k93

mkdrupload_k93 脚本使用其中定义的类别列表生成 drupload2wiki_k93 脚本。可以定制这个脚本以满足自己的需要。

mkebupload_k93 脚本包含整个电子商务类别结构并生成 ebupload2wiki_k93 脚本。ebupload2wiki_k93 脚本与 wiki 服务器通信，创建并修改页面。用户可以使用它们修改电子商务类别结构以满足自己的需要，然后重新生成 ebupload2wiki_k93 脚本，最后修改 wiki 服务器本身。

ebupload2Wiki_k93

ebupload2wiki_k93 脚本把电子商务类别结构上传到 wiki 服务器，这要用到 wikiAutoLoad 脚本和 wget。

mkebupload2Wiki_k93

这个 脚本 使用其中定义的类别列表生成 ebupload2wiki_k93 脚本。很容易定制这个脚本以满足自己的需要。

下面的脚本生成 wiki 结构的其他部分，可以根据自己的需要使用它们。

shupload2Wiki_k93

shupload2Wiki_k93 脚本把 shell 脚本类别结构上传到 wiki 服务器，这要用到 wikiAutoLoad 脚本和 wget。

mkshupload_k93

mkshupload_k93 脚本使用其中定义的类别列表生成 shupload2wiki_k93 脚本。很容易定制这个脚本以满足自己的需要。

aeupload2Wiki_k93

使用 aeupload2Wiki_k93 脚本把 AIX Expert 网站类别结构上传到 wiki 服务器，这要用到 这里 提供的 wikiAutoLoad 脚本和 wget。

mkaeupload_k93

mkaeupload_k93 脚本使用其中定义的类别列表生成 aeupload2wiki_k93 脚本。用户很容易定制这个脚本以满足自己的需要。

结束语

已经使用本文介绍的业务连续性 wiki 结构构建了示例网站 AIX Expert。本文提出的主要概念是不应该编写 AIX 技术文档；文档应该由系统本身定期地（每小时、每天、每周或每个月）自动生成并上传到主/辅集中文档存储库。

转变观念

在计算环境中使用 AIX 系统的根本目的是自动化，从而在多方面节省成本。如果 AIX 管理员以交互方式部署、管理、支持、维护和监视 AIX 环境，那么使用 AIX 环境就没有意义了。如果您的 AIX 环境是这种情况，那么需要采取以下措施之一：

• 用真正的 AIX 管理员替代当前的管理员（显然您的管理员只是会在 google 上搜索 AIX 的桌面管理员）；
• 或者马上在整个企业范围建立业务连续性和数据中心自动化意识。利用这种观念指导您的组织（和 AIX 管理员）遵从现代数据中心管理方法。
  

实际上，第二种措施应该是每个组织运营日常业务的正常方法。

对于任何 AIX（或 UNIX®）管理员，自动化方面的经验规则是：在第一次执行一个任务时，应该记录命令以便以后实现自动化。第二次执行任务时，管理员应该根据以前记录的命令为任务编写脚本。第三次执行任务时，管理员应该自动执行并监视任务，以后应该一直按调度计划自动执行此任务。

但是，这条经验规则并不适用于文档，因为文档任务必须定期执行，这是确定无疑的。因此，从最初部署系统开始，应该从每个系统生成文档，并在系统的整个生命周期中一直这么做。

在对任何任务进行自动化时，过程应该包含生成文档的步骤，或者编写标准，让文档生成器能够从过程创建文档。

在现实环境中，完全自动的文档可能难以实现，但是应该以此为目标。至少应该把每个系统上实现的自动脚本和过程定期上传到集中式文档服务器。应该定期这么做，这样当脚本有变动时，文档存储库会及时地反映这些变动。通过使用按业务连续性概念分类的 wiki 服务器，文档会与业务连续性结构相关联，有助于文档任务的自动化。

关于作者

French 先生在 IT 行业中的从业经验已有三十多年，所涉及的行业也非常之多。他的工作重点主要是业务连续性、灾难恢复以及高可用性等领域，并且他设计和编写了许多软件包，以实现灾难恢复和高可用性过程的自动化。他最大的贡献是将系统管理作为一项自动化的、面向业务的过程（而不是面向系统的、交互的过程）。他还是 Korn Shell 编程领域的著名专家。

http://www.ibm.com/developerworks/cn/aix/library/au-wiki_structure/index.html