2011年1月31日
第9卷，第1期

可测试的系统管理

不确定性模型正在改变IT管理。

马克·伯吉斯

在过去的20年里，系统管理的方法几乎没有改变。虽然核心IT技术在许多方面都得到了改进，但对于许多甚至大多数组织来说，系统管理仍然基于生产线构建物流（又称配置）和被动事件处理——一种工业时代的蛮力机械化方法，用于放大手动流程。随着我们进入信息时代，人类需要减少像他们使用的机器一样工作，并拥抱基于知识的方法。这意味着利用简单的（免提）自动化，让我们不受束缚地发现模式并做出决策。如果IT本身能够迎接长期以来就应该迎接的自动化核心挑战——即如何放弃确定性神话并期待意外，那么这个目标是可以实现的。

我们不必深入挖掘就能发现确定性管理信仰体系中的裂缝。经验丰富的系统从业人员内心深知，他们不能将系统管理视为一个简单的可逆事务的手动管理过程；然而，很容易看出这种信念是如何源于古典教义的。至少一半的计算机科学源于离散建模文化，它处理数据库理论中的绝对概念，在数据库理论中，理想条件仍然可以被出色地模拟。相比之下，起源于物理学和工程学的随机模型，如排队论和纠错，通常被认为对于大多数基础计算机科学课程来说太难了。其结果是，系统设计者和维护者对于意外事件的现实准备不足。委婉地说，“系统”是在理想条件下的实验室圈养中长大的，然后被释放到多样化和具有挑战性的环境野外。今天，系统管理在很大程度上仍然假设世界是简单和确定的，但这与事实相去甚远。

在20世纪90年代中期，包括我在内的几位研究从业人员主张采用不同的系统管理模型，拥抱自动化以实现实施的一致性，并使用策略来描述理想状态。这种方法的核心支柱是稳定性。^2,4 我们提出，通过将稳定性置于中心位置，人们将获得更好的可靠性（或者至少是可预测性）。毕竟，IT这样的工具只有在能够带来始终如一的可预测结果时才有用。这是一种管理的进化方法：只有能够生存下来的东西才能成功

作为一名受过物理学训练的人，我对缺乏一种可行的模型来解释实际计算机行为感到惊讶。似乎不是将行为视为充满内在不确定性的经验现象，而是隐含地期望计算机能够按照编程方式运行。每个人都知道这过于简单化；然而，系统管理员只有在故障或事件报告了相反情况时才会担心行为。

从拆除到维护

当问题发生时，许多组织会将受影响的系统停止服务，擦除它们，然后从备份恢复或从头开始重新安装。这是他们确保系统状态的唯一方法，因为他们不知道有什么简单的方法可以在没有费力的手动调查的情况下发现发生了什么变化。这个过程很粗糙，就像拆掉一栋建筑来换灯泡一样。但原因是可以理解的。当前的工具是为构建而不是修复而设计的——如果你的唯一工具是 sledgehammer... 那么你就重建吧。

人们越来越接受一种测试驱动或诊断方法来解决这个问题。这最初是由Cfengine⁵引入的，然后部分地在其他软件（如Puppet¹¹）中采用。在测试驱动的方法中，系统状态通过微观层面的持续重新评估来调节，就像有一个场地管理员持续监视庄园，拔除杂草或在需要的地方涂上一层油漆。这种方法需要概念上的飞跃，即维护的可计算概念。维护可以通过参考理想系统状态的策略或模型来定义。如果能够以可预测的、可操作的修复来描述这样的模型，尽管存在环境不确定性，那么自动化维护将成为一个简单的现实。从本质上讲，这就是Cfengine改变IT管理格局的方式。

术语合规性今天经常用于表示状态相对于模型的正确性。如果系统偏离其模型，那么通过适当的自动化，它可以自我修复^2,4，有点像自动驾驶仪将系统带回正轨。有趣的是，当你可以修复系统状态（包括静态配置和运行时状态）时，系统的初始条件变得不重要，你可以完全专注于期望的结果。这就是企业希望思考IT的方式——以目标而不是“建设项目”来思考——从而也使我们更接近现代IT行业。

收敛到期望状态

建立一个用于修复的参考模型听起来很简单，但它需要一种具有正确属性的语言。软件工程中常用的语言不太适合这项任务，因为它们描述的是从固定起点开始的顺序步骤，而不是最终目标。通常，我们不知道机器在发生故障时的起始状态。此外，跟踪模型需要大量的冗余计算，这会影响清晰度。解决这个问题的方法是构建声明式DSL（领域特定语言），这些语言隐藏了细节并提供可预测的语义。虽然Cfengine是处理不确定性的首次尝试，但早在之前就有人提出了特殊的语言。⁹

许多软件工程师不相信声明式DSL的论点：他们想使用传统编程的熟悉工具和方法。然而，对于数学家甚至地毯安装工来说，这完全有道理。如果你试图将解决方案拟合到已知的边缘状态，那么从另一端开始，使用一系列假设世界是固定的方向是很麻烦的。例如，当你编程GPS时，你输入的是期望的目的地，而不是旅程的开始，因为当意外发生时，例如道路封闭，你经常需要重新计算路径。Cfengine⁵在90年代中期采用了这种GPS方法。它表示：相对于模型的期望最终状态工作，而不是初始基线配置，因为最小的意外更改会破坏基于初始状态的配方。这被比作Prolog。⁷

简单来说，这种方法的工作原理是使每次更改都满足一个简单的算法

更改（任意_状态）→ 期望_状态 (1)
更改（期望_状态）→ 期望_状态 (2)

这种构造是“笨拙”稳定性的表达，因为如果你将期望状态扰动到某个任意状态，它就会像自动航向校正一样被推回到期望状态。它代表一个系统，该系统将通过重复一个笨拙的口头禅来从意外或偶然的错误中恢复，而无需智能推理。

例如：假设你想重新配置Web服务器以支持PHP并关闭安全漏洞。服务器及其所有文件通常是软件包的一部分，并通过包含许多设置的复杂文件进行配置

# >10kB 的复杂内容 MODULES = SECURITY_HOLE JAVA OTHERS # >10kb 的复杂内容

要同时解决这两个问题，只需更改此列表（例如，期望的结果）

# >10kB 的复杂内容 MODULES = JAVA OTHERS PHP # >10kb 的复杂内容

传统上，人们会用手动管理的模板替换整个文件，甚至重新安装一个新的软件包，迫使用户从头开始处理所有事情。使用期望状态方法，我们可以简单地说：在文件上下文中webserver.config，确保任何匹配"MODULES = something"的行都满足"something"包含"PHP"且不包含"SECURITY HOLE"。在Cfengine中，这可能看起来像这样

bundle agent webserver_config { vars "add" slist => { "PHP", "php5" }; "del" slist => { "SECURITY_HOLE", "otherstuff" }; column_edits "APACHE_MODULES=.*" edit_column => edit_listvar("$(add_modules)","append"); "APACHE_MODULES=.*" edit_column => edit_listvar("$(del_modules)","delete"); }

[注意：语法（包含隐式保护和迭代）具有以下形式

type_of_promise "Atom" property_type => desired_end_state; ]

因此，代码定义了两个内部列表变量以方便使用，并将它们传递给专门定义的方法edit_listvar,它是从收敛原语构建的。对于列表中的每个项目，Cfengine将确保列出原子存在或不存在，而不会触及其他任何内容。通过这种方法，你不需要重建整个Web服务器，也不需要了解它的其他配置方式（例如，在"复杂内容"中有什么），甚至不需要知道谁在管理它：相对于未知的起始状态，已经指定了期望的最终状态。这是一种高度压缩的信息形式。

我将这种方法称为收敛维护（也将这种行为比作人类免疫系统²），因为所有更改都收敛于策略参考框架中系统的目标或健康状态。后来，一些作者采用了数学术语幂等性（意味着在重复下不变），专注于你可以应用这些规则任意次数，系统只会变得更好这一事实。

受保护的策略

用最简单的术语来说，这种方法类似于Dijkstra的受保护命令方案。⁸ 实际上，Cfengine的语言实现与受保护命令语言的共同点与Prolog的共同点一样多。⁷ 将X声明为语句可以解释为

如果不是 model(X)，则设置 model(X)

例如

"/etc/passwd" create => "true";

无限次重复不会改变结果。事后看来，这似乎是一个微不足道的观察结果，几乎算不上革命性的技术，但最简单的见解往往是最难获得的。该语句的含义是，X不仅是你想要的，而且是你应该拥有的模型。将预期与实际分离是相对性的本质。

这个难题还差一块。仅仅知道期望状态是不够的；我们还必须知道它是可以实现的。我们必须将期望状态的可达性添加到语义中。

陷入局部最小值

从人工智能及其现代应用中众所周知，算法在搜索参数 landscape 以获得最佳状态时可能会陷入困境。当你认为自己处于山谷底部时，你怎么知道在山坡上方没有更低的山谷？为了避免出现虚假或局部最小值，你必须确保搜索空间的每个独立维度都只有一个最小值，并且没有障碍物。然后有两个因素在起作用：独立性和收敛性。独立性可以用许多名称来描述：原子性、自主性、正交性等。所有这些的本质是，系统中的基本对象应该没有依赖关系。

我们正在讨论的是属性空间中策略原子的理论。如果你仔细选择向量（文件权限、文件内容、进程等），以便每次更改都可以在不影响另一个的情况下完成，则无需操作排序即可达到期望的最终状态，并且只能有一个最小值。事实上，只要运算符形成不可约群，就可以通过周期性维护来证明顺序独立性。^3,6

如此简单的解决方案的发现暗示了一种万能药，预示着一个完美的新世界的到来。唉，这种方法只能部分应用于实际系统，因为没有实际系统是使用这些纯粹的结构构建的。通常，多种更改机制以不可预见的方式将此类原子束缚在一起（例如，将软件捆绑在一起并阻止访问详细信息的软件包）。然而，在许多情况下，这种近似方法效果非常好，今天数百万台计算机在最严格的环境中运行此软件就证明了这一点。为什么？最有可能的是，一种体现这些原则的语言鼓励管理员以这些术语思考并保持良好的实践。

依赖关系缠结——打包的缺点

这种系统部件的自由原子化的对立面是软件设计人员今天越来越多地做的事情：将原子和更改捆绑到软件包中。在现代系统中，打包是对软件管理过程复杂性的回应。然而，通过打包数据来解决一个管理问题，我们失去了定制软件包内部内容的所需分辨率，并用另一个问题取代了它。在需要高度定制的情况下，解压缩标准“软件包更新”就像在托管环境中引爆智能炸弹一样——抹去定制——并回到拆除管理学校。

我们不知道是否可以使用收敛操作完全管理任何操作系统，也不知道这是否会是一个理想的目标。任何这样的系统都必须能够解决外科手术般精确的定制需求，以适应环境。当今真正庞大的数据中心（谷歌、Facebook等）非常庞大，并且通常比最具挑战性的环境更简单。银行或军队等机构更具代表性，其增长和收购文化推动了对规模的各种挑战。已知的是，没有当今的操作系统使这成为完全可行的命题。充其量，人们可以近似管理操作的子集，但即使这样也会大大提高流程的可扩展性和一致性——通过允许将人从流程中移除。

从要求合规性到提供能力

这种测试驱动的管理方法的未来是什么？要理解挑战，你需要意识到计算机科学中普遍存在的第二种文化：通过义务进行管理的假设。义务是模态语句：例如，X必须遵守Y，A应该做B，C被允许做D，等等。假设你可以强制系统屈服于外部做出的决定。这种观点多年来一直是基于策略的系统的支柱¹²，并且存在许多根本性的缺陷。

第一个缺陷是，通常不能在没有软件或硬件系统另一部分自愿同意的情况下对其施加强制性影响。缺乏权威、缺乏邻近性、缺乏知识以及直接的不可能性都是不切实际的原因。例如，如果计算机已关闭，则无法强制其安装新版本的软件。因此，基于义务的维护模型充其量是乐观的，最坏的情况是徒劳的。第二点是，义务会导致网络中无法解决的矛盾。两个不同的当事方可以坚持认为第三方将遵守完全不同的规则，甚至彼此都不知道。¹

意识到这些弱点导致人们重新思考义务，将义务完全转变为“自愿合作”或承诺理论的原子理论。¹ 毕竟，如果义务需要自愿同意才能实施，那么自愿合作是更根本的观点。事实证明，承诺模型正是提供了一种保护伞，系统管理的所有方面都可以在其下建模。结果是一种基于代理的方法：每个系统部件都应尽可能在没有外部帮助的情况下信守自己的承诺，并尽可能少地期望其不可预测的环境。

部件的独立性由信守自己承诺的代理表示；收敛到标准由承诺被遵守的程度表示；对初始条件的不敏感性由承诺描述结果而不是初始状态这一事实来解决。

事实证明，承诺理论是对合作模型构建的相当广泛的描述，它从自下而上的角度而不是自上而下的角度进行思考。它可以同等地应用于人类和机器，因此也可以描述人类工作流程——联合管理的简单方法。它尚未获得广泛接受，但其主要发现现在正被用于重组银行和制造业中的一些最大型组织，使他们能够根据稳健的预期状态对复杂性进行建模。今天，只有Cfengine是有意基于承诺理论原则的，但Chef的分散化¹⁰的某些方面与之兼容。

知识的局限性

在系统测量中潜伏着更微妙的问题，到目前为止我们只是草草带过。这些问题可能会在未来几年内挑战研究人员和从业人员。要验证模型，你需要测量系统并检查其与模型的合规性。你对系统状态的评估（即，它是否信守承诺？）需要信任测量过程本身才能形成结论。这种依赖性是不可避免的。

当你测试系统与模型的合规性时会发生什么？事实证明，测量链中的每个中间部分都可能扭曲你想观察的信息，从而导致越来越少的不确定性。不确定性是可观测性的核心。如果你想通过假装完全了解系统来管理系统，你将会失望的。

考虑一下：环境对系统和测量者的影响可能直接导致不合逻辑的行为，例如不可判定的命题。假设你有一个断言（例如，承诺系统属性为真）。在逻辑上，此断言必须为真或为假，但考虑以下情况

* 你没有观察系统（所以你不知道）。

* 观察系统需要与其交互，这会改变其状态。

* 你不完全信任测量设备。

* 存在对阻止进行测量的某物的依赖性。

如果你相信经典的一阶逻辑，那么任何断言都必须为真或为假，但在遵循这些情况中的任何一种的不确定世界中，你根本不知道，因为没有足够的信息来选择真或假。系统只有两种状态，但你无法知道哪种状态是这种情况。此外，假设你在某个时间t进行测量；在你可以不再确定状态之前，必须经过多少时间？

这种情况以前在量子力学中见过。就像薛定谔的猫一样，如果不进行主动测量，你就无法知道两种可能性（死或活）中的哪一种是这种情况。你所能知道的只是探针事后报告的每次测量的结果。另一方面，物理学的教训是，即使不完全了解系统，也可以通过使用不依赖于不确定细节的指导原则来取得出色的进展。

回到稳定性？

系统可能不是完全可知的，但它仍然可以是自洽的。自然界和工程学中反复出现的一个明显的例子是平衡。无论你是否知道复杂系统背后的细节，你都可以知道其稳定状态，因为它们会持续存在。持久状态是计算机等工具的适当策略——如果工具变化太快，它们就会变得无用。拥有一个几乎是你想要的坚固工具，比拥有你想要的确切事物但使用一次后就散架要好（你想要的和你需要的不一定是同一件事）。同样，如果系统管理员不能拥有他们想要的东西，他们至少可以从我们能做的最好的东西中选择。

系统可以是稳定的，要么是因为它们一成不变，要么是因为许多较小的变化随着时间的推移而平衡（维护）。基于此想法的非常实用的工具不胜枚举：拉格朗日点（优化）、纳什均衡（博弈论）、佩龙-弗罗贝尼乌斯定理（图论），等等。如果这听起来像是纯粹的学术胡说八道，那么请考虑一下，通过Google PageRank或Web of Trust等依赖于相同想法的技术，这些胡说八道在我们的日常生活中占据了多少。

但是请注意，本文倡导的稳健性，使用原子化和部件独立性原则，与现代编程知识完全矛盾。我们积极鼓励构建依赖的、专门对象的层次结构以实现可重用性。这样做，我们必然会在其中隐含地构建脆弱性和局限性。曾经有一段时间，分层组织被认为是公认的智慧，但今天越来越清楚的是，层次结构是脆弱且难以管理的结构，存在许多故障点。原子集承诺稳定配置空间补丁的替代方案无异于异端邪说。然而，集合是比图更基本的构造。

对于许多系统管理员来说，这些知识分子的沉思与登月对特氟龙锅的用户来说一样无关紧要。他们看不到自己与这些问题的关联，这就是为什么研究人员而不仅仅是开发人员需要研究这些问题的原因。最终，我相信使用这些方法在系统管理方面仍然可以取得巨大的进步。系统管理的未来更多在于更好地理解我们已经拥有的东西，而不是试图用工业力量过度简化必要的复杂性。

结束语

令人好奇的是，拥抱不确定性应该让你更充分地理解某些东西，但简单的事实是，围绕你不了解的东西工作对于决定你实际上可以做什么既有效又低成本。

规模和复杂性的主要挑战困扰着当今的行业。我们现在知道，可扩展性不仅关乎提高吞吐量，还关乎能够理解系统随着系统的增长。如果没有模型，不了解你所遵循的课程的风险很容易失控。最终，管理关于系统的总知识是根本挑战：测试驱动的方法是关于更好的知识管理——知道你能知道什么和不能知道什么。

系统管理是管理还是工程是一个经常讨论的话题。当然，如果没有某种形式的工程，管理就会变成一件碰运气的事情。我们仍然在圈养中饲养计算机，然后将它们释放到野外，但现在有了生存的希望。期望状态、持续应用“笨拙”的基于规则的维护以及相对于模型进行测试是量化知识的关键。
问

参考文献

1. Burgess, M. 2005. 基于自主性和自愿合作的策略理解方法。提交给IFIP/IEEE第16届分布式系统操作和管理国际研讨会（DSOM）。

2. Burgess, M. 1998. 计算机免疫学。第12届系统管理会议论文集 (Usenix/LISA)。

3. Burgess, M. 2004. 用于进化人机系统的可配置免疫力。计算机程序科学 51 (3): 197-213。

4. Burgess, M. 2003. 关于系统管理理论。计算机程序科学 49: 1-46。

5. Cfengine; http://www.cfengine.org。

6. Couch, A., Daniels, N. 2001. 激流：通过“无效程序”进行网络服务调试。第15届系统管理会议论文集 (Usenix/LISA): 63。

7. Couch, A., Gilfix, M. 1999. 这很简单，亲爱的沃森：将逻辑编程应用于收敛系统管理流程。第13届系统管理会议论文集 (Usenix/LISA): 123。

8. Dijkstra, E. http://en.wikipedia.org/wiki/Guarded_Command_Language。

9. Hagemark, B., Zadeck, K. 1989. Site：一种用于将多台计算机配置为一个计算机站点的语言和系统。第三届大型安装系统管理研讨会论文集 (Usenix): 1; 另请参阅 http://www2.parc.com/csl/members/jthornton/Thesis.pdf。

10. Opscode; http://www.opscode.com/chef。

11. Puppet Labs; http://www.puppetlabs.com/。

12. Sloman, M. S., Moffet, J. 1993. 分布式系统管理的策略层次结构。网络和系统管理杂志 11(9): 1,404。

喜欢它，讨厌它？让我们知道

[email protected]

马克·伯吉斯 是奥斯陆大学学院的网络和系统管理教授，是第一个获得此头衔的人。他在纽卡斯尔获得了理论物理学博士学位，为此他获得了伦科恩奖。他目前的研究兴趣包括计算机作为动态系统的行为以及应用物理学思想来描述计算机行为。他是流行的配置管理软件包 Cfengine 的作者，并且是 Cfengine 公司的创始人、董事长兼首席技术官。他为自动化和基于策略的管理理论做出了理论和实践贡献，包括操作员收敛和承诺理论的思想。

最初发表于 Queue vol. 9, no. 1—
在数字图书馆中评论本文

更多相关文章

Adam Oliner, Archana Ganapathi, Wei Xu - 日志分析的进展与挑战
计算机系统日志提供了运行系统状态的一瞥。仪器偶尔会生成简短消息，这些消息收集在特定于系统的日志中。日志的内容和格式可能因系统而异，甚至在系统内的组件之间也可能不同。打印机驱动程序可能会生成指示其与打印机通信时遇到问题的消息，而 Web 服务器可能会记录请求了哪些页面以及何时请求。

克里斯蒂娜·利尔 - 系统管理软技能
系统管理既有压力又有回报。压力通常来自外部因素，例如系统管理员（系统管理员）及其同事之间的冲突、资源匮乏、高中断环境、相互冲突的优先级以及系统管理员对超出其控制范围的故障负责。系统管理员及其经理可以做些什么来缓解压力？有一些众所周知的人际交往和时间管理技巧可以提供帮助，但在危机时期或仅仅是由于习惯的力量，这些技巧可能会被遗忘。

托马斯·A·利蒙切利 - 来自系统管理员对软件供应商的恳求 - 10 条须知和禁忌
我的一个朋友是汽车修理工：那种汽车爱好者，他们会在周六晚上为了乐趣而重建发动机。他向我解释说，某些品牌的汽车在设计时就考虑到了让机械师的工作更轻松。然而，另一些汽车的设计却好像该公司与阿司匹林行业达成了协议，以确保有大量头痛的机械师。他说这些汽车公司讨厌机械师。我完全理解，因为作为一名系统管理员，我可以分辨出软件供应商何时讨厌我。这体现在他们的产品中。

埃本·M·哈伯、埃塞尔·坎多根、保罗·马格里奥 - 系统管理中的协作
乔治遇到麻烦了。一个看似简单的部署花费了整个上午，而且似乎遥遥无期。他的经理不断进来查看他的进度，因为客户渴望完成部署。他本应离开去参加一位即将离职的同事的告别午餐，这增加了压力。他请求了各种帮助，包括同事、应用程序架构师、技术支持，甚至其中一位系统开发人员。他使用电子邮件、即时消息、面对面联系、他的电话，甚至他办公室同事的电话与每个人进行沟通。而且乔治不是新手。