PDF系统管理中的协作
对于系统管理员来说，解决问题通常需要与他人协作。我们如何才能使其更有效？
Eben M. Haber，IBM研究院，Almaden
Eser Kandogan，IBM研究院，Almaden
Paul Maglio，IBM研究院，Almaden
乔治遇到了麻烦。一个看似简单的部署花费了整个上午，而且似乎没有结束的迹象。他的经理不断进来询问他的进展，因为客户非常希望尽快完成部署。他本应该去参加一位即将离职的同事的告别午餐，这更加增添了他的压力。他已经请求了各种帮助，包括同事、一位应用架构师、技术支持，甚至还有一位系统开发人员。他使用了电子邮件、即时通讯、面对面交流、他的手机，甚至他办公室同事的手机与所有人沟通。而且乔治并不是新手。他已经担任Web托管管理员三年了，并且拥有计算机科学学士学位。但似乎所有投入的专业知识都远远不够。乔治为什么会遇到麻烦？我们稍后会 выяснить。
但首先，我们为什么要关注乔治？乔治是一位系统管理员，他们是在幕后工作的人员之一，负责配置、操作、维护和排除故障，以支持现代生活的大部分计算机基础设施。他们的工作至关重要——而且成本高昂。总系统拥有成本中的人力部分几十年来一直在增长，现在已经超过了硬件或软件的成本。2,3,4
为了了解原因，并尝试学习如何更好地支持管理，我们一直在系统管理员的自然工作环境中观察他们。在几年的时间里，我们配备了摄像机、照相机、录音带、电脑和笔记本电脑，进行了16次访问，每次长达一周，遍布六个不同的地点。我们观察了管理员管理数据库、Web应用程序和系统安全；以及存储设计师、基础设施架构师和系统操作员。无论他们的具体职称是什么，我们都将他们统称为系统管理员，或简称sysadmin。
在研究开始时，我们对系统管理员的刻板印象是大学计算机中心后屋里的那个家伙（而且总是男人），他无所不知，可以独自解决所有问题。当我们深入企业数据中心时，我们意识到现实要复杂得多。要充分描述我们的发现需要一本书（我们目前正在撰写）。6 在这篇短文中，我们将自己限制在几个 эпизодах 中，这些 эпизоды 说明了我们在系统管理工作中看到的协作类型以及主要问题所在。正如我们将从我们收集的真实故事和我们对工作模式的分析中展示的那样，这真的不仅仅是后屋里的一个家伙。
乔治的故事
乔治是一家大型IT服务交付中心的Web管理员。我们观察了他一周，在此期间他为不同的客户从事各种规划、部署、维护和故障排除任务。1 乔治是一个Web管理员团队的成员；他经常与其他团队成员互动，因为工作是分配的。他们需要协调行动，交接长期运行的任务，并互相咨询（尤其是在故障排除期间）。他还与其他负责不同领域的团队互动，例如网络、操作系统、邮件服务器等。
在我们观察的一周中，乔治的任务之一是为客户设置Web访问电子邮件。这涉及到在防火墙外部的现有机器上创建一个新的Web服务器实例，并通过防火墙内部的中间件认证服务器连接到后端邮件服务器（图1）。乔治以前从未在现有机器上安装过第二个Web服务器，但他收到了同事通过电子邮件发送的说明，并且可以访问在线文档。这项任务涉及来自不同团队的几个人。在本周初，乔治要求网络团队创建一个新的IP地址并在防火墙上打开端口。在整个一周中，我们看到他与同事Ted进行了广泛的协作，Ted正在排除认证服务器的一些问题。乔治的进度受到Ted工作的制约，因此他们一直通过即时消息交流，并经常到彼此的办公室一起解决问题。
到星期五早上，乔治已经完成了所有准备工作。最后的步骤应该只需要几分钟，但这才是真正行动的开始。一个神秘的错误出现了，乔治花了两个多小时排除错误，主要与他人协作。他似乎顺利地创建了新的Web服务器实例，并且它在中间件认证服务器上注册了自己。然而，当他发出命令给中间件服务器，允许前端Web服务器与后端邮件服务器通信时，他收到了一个错误
错误：无法连接到服务器（状态：0x1354a424）
考虑到涉及到三台不同的服务器，错误消息给他提供的信息不足。在线文档和对该消息的Web搜索没有提供其他详细信息，因此他寻求帮助。（有关错误消息的更多信息，请参阅“错误消息：问题是什么？” ，2004年11月。7）
乔治的经理建议打电话给应用架构师Adam，乔治和Adam开始一起排除故障，通过电话交谈并交换系统日志、错误消息、配置文件以及通过IM和电子邮件发送示例命令（图2）。Adam无法访问有问题的系统，因此乔治充当他的眼睛和手，收集信息并执行命令。
他们无法找到错误，因此大约一个小时后，Adam建议乔治致电技术支持。他使用了他办公室同事的电话（因为他自己的电话仍然与Adam连接），但很快将与技术支持的沟通转移到IM。在接下来的20分钟左右，乔治继续通过电话与Adam以及通过IM与技术支持进行故障排除，Ted也不时走进办公室提供建议。过了一会儿，乔治对技术支持的回答感到厌烦，因此Adam将他与中间件的开发人员之一联系起来，他们开始通过IM讨论问题。自始至终，乔治仍然是唯一有权访问系统的人——所有命令和信息请求都通过他进行。随着问题仍然无法解决，他变得越来越紧张。
最终，Ted回到自己的办公室并独立研究了这个问题。他发现乔治误解了前端服务器的一个网络配置参数，该参数在文档中含糊地描述为“内部端口”。乔治认为这个参数（端口7137）指定了从前端到中间件服务器的通信端口，但实际上方向相反。实际上，乔治犯了两个错误：他没有意识到每个前端服务器都使用端口7135与中间件服务器通信（防火墙允许，参见图1），并且他为从中间件服务器到前端的通信指定了一个端口7137，该端口被防火墙阻止。通信在一个方向上工作，但在另一个方向上不工作。软件仅在一个方向上测试通信，因此直到配置中间件认证服务器后才报告错误。Ted找到了解决这个复杂情况的方案，并试图通过IM向乔治解释，但没有成功
Ted 我们应该使用7236。取消配置该实例，然后...
乔治 无法指定返回端口...你只能指定一个端口
Ted 你做错了。
乔治 不，我没有。
Ted 是的，你做了。你需要输入7236。
乔治 我们只是没有告诉它双向通信。另一个端口与此无关。
Ted 好吧，我只知道我在配置文件中看到的内容。
乔治 我们认为那是返回端口。那不是返回端口。
Ted 目前在 [中间件服务器] 上端口7137上没有监听器。所以使用7236。照做！
Ted没有表达清楚他的意思，乔治变得越来越沮丧。乔治告诉他的办公室同事给Ted打电话（Adam还在另一部电话上），对话立即切换了模式。凭借口语的细微差别，Ted开始意识到乔治从根本上误解了正在发生的事情。Ted不再不断地告诉乔治该做什么（“照做！”），而是解释了原因。任务已从调试系统转变为调试乔治，他们试图建立对哪些网络端口朝哪个方向的共同理解。
乔治 你在说什么？7236？我们以为它从端口7137进来，然后从端口7236返回，但我们错了，那个7236端口就像一个HTTPS监听端口之类的？
Ted 显然它仍然会通过端口7135与 [中间件] 服务器通信...
乔治 对吗？
Ted 发生的事情是它实际上试图通过端口72...嗯，实际上试图通过端口7137返回到实例...但没有发生。
乔治 我知道。我知道。但我无法告诉它...
Ted 只需使用7236创建它。相信我。
乔治 为什么？那个端口不是...，那是错的方向...，那也是单向的。
Ted 相信我。
乔治 那是单向的。你明白我在说什么吗？
Ted 因为是 [中间件] 服务器回过头来与 [Web服务器] 实例通信。
乔治 是的，但是 [Web服务器] 如何与 [中间件] 服务器通信以发出某种请求？
Ted 7135是它在所有情况下使用的标准端口。所以我们搞错了。我们对它的工作方式的假设是不正确的。
乔治 好吧，好吧。
Ted 如果不起作用，你可以之后揍我。
乔治 我现在就想。[双方都笑了]
乔治是如何陷入困境的？像许多失败一样，有许多促成因素。乔治误解了一个前端配置参数的含义，没有意识到它与防火墙规则冲突。前端没有测试双向通信，因此前端端口配置中的错误直到配置中间件服务器后才报告。错误消息肯定没有帮助。也许最重要的是，在大部分故障排除会话中，乔治是唯一一个可以直接访问系统的人。所有其他参与者都通过乔治过滤获取信息。
通过详细检查录像带，我们发现了几次乔治错误报告或误解他所看到的内容的情况，通过他自己的误解过滤信息并错误地报告回来。（一个例子是乔治误读了网络跟踪的结果，他的误解过滤掉了一条关键线索。）这妨碍了Adam和技术支持有效地帮助他。只有当Ted独立查看机器状态时才找到问题——然后他也不得不调试乔治。乔治有很多工具可以共享有关系统状态的信息，但没有一个工具能向其他人提供完整的画面。
有什么教训？协作至关重要，尤其是在发生误解时（从我们看到的情况来看，对高度复杂系统的理解不正确或不完整是系统管理员问题的常见根源）。然而，只有当共享正确的信息时，协作才能发挥作用，而误解和通信工具的局限性会阻碍信息的共享。适当的系统设计可以首先帮助避免误解，而改进的信息共享工具可以帮助更快地纠正发生时的误解。
我们分析了乔治2个半小时的故障排除会话，对乔治所做的每30秒时间段进行编码（参见图3）。我们发现这些时间段中有91%花在了与他人的协作上，无论是通过电话、即时消息、电子邮件还是面对面。只有6%的时间他实际上是在与系统交互，无论是发现状态还是进行更改，因为每次交互之后都会进行长时间的讨论，讨论所见内容的含义以及下一步该怎么做。
虽然我们目睹的并非每个故障排除 эпизод 都具有如此极端的协作水平，但我们看到人们一起工作解决问题的频率远高于单个人单独工作。我们还对协作主题进行了编码，其中包括预期的主题，例如配置详细信息、系统状态、正在进行的策略以及要执行的命令。令人惊讶的是，21%的沟通涉及讨论协作本身——例如，“我给你打电话”或“请通过电子邮件将该日志文件发送给我”。
在需要调试个人的理解的情况下，协作尤其重要，正如我们在乔治的故事中看到的那样。误解是生活中的事实，在这里，糟糕设计的错误消息和延迟报告的错误配置加剧了误解。一个人甚至意识到他或她的理解是不正确的可能需要很长时间。额外的眼睛确实可以帮助识别和纠正误解，但误解会影响一个人报告的内容——因此，只有当协作者获得系统的准确画面时，对问题获得第二意见才会有所帮助。
另一个教训是，不同的通信媒介适用于不同的事物：电话和面对面接触的细微差别和交流有助于传递复杂的想法和评估其他人知道什么。IM非常适合快速逐字交换命令和错误消息，但微妙的个人线索会丢失。即使对于像乔治和Ted这样的长期同事来说，通过IM建立信任也很困难。电子邮件非常适合交换冗长的项目，例如日志文件和说明，或需要持久存在的事物。不同的通信媒介暗示了对协作的不同程度的承诺。鉴于需要协作来帮助系统管理员分享他们对系统的理解，可以想象更好的工具来共享系统状态。这些工具应充分利用不同的通信形式，以更完整地共享系统和系统管理员的状况。
现在，我们将转向我们在系统管理员中观察到的另一个协作示例，他们正在处理一个复杂得多的系统，该系统出现了一个需要难以置信的努力才能理解的问题。
紧急情况处理
紧急情况处理，或 crit-sit，是一种实践，当IT系统性能变得不可接受时，IT服务提供商必须投入特定资源以尽快解决问题时，就会调用这种实践。几位系统管理员——不同组件的专家——被带到一个房间，并被告知要一起工作，直到问题得到解决。紧急情况处理的发生频率高于系统管理员的预期（我们采访的一位估计每年参加四次紧急情况处理），它们可能持续数天、数周甚至数月。
我们观察了一次紧急情况处理的一天，就在它开始之后，并在两个月内跟踪了它的进展，直到找到解决方案。对于紧急情况处理来说，这异常漫长。它涉及由Web应用程序服务器和后端数据库的微妙交互引起的间歇性Web应用程序故障。在此过程中发现了并修复了其他潜在问题，但专门的专家团队花费了80多天时间才确定真正的根本原因。
在微观层面，在紧急情况处理期间在房间里非常有趣。八到十个人坐在大会议室里，要么坐在两张桌子旁，要么在房间里走动交谈；另外四到六个人通过电话会议和聊天室加入（包括所涉及的各种软件产品的技术支持代表）。起初，我们感到惊讶的是，这么多人被指示在一个房间里一起工作，直到问题解决。事实上，房间里的一个人通过即时消息向一位场外同事抱怨
“我们正在做大量的PD [问题确定]，但没有什么是我不能在家里做的。”
然而，在观察人们工作后，我们看到了将所有人聚集在一个地方的真正价值。房间里充满了不同的对话，通常一次有许多对话分散和重新加入，不同的专家交流想法或提出问题。人们会使用白板来绘制理论图，并且可以看到和补充其他人正在写的内容。当发生重要事情时，房间里所有人的注意力都会立即集中起来。群聊室也被用作系统状态、错误消息和想法的历史记录。聊天也用于房间内外和房间外的私人对话，以及交换技术信息。在某个时刻，我们看到他们通过交谈、查看彼此的屏幕以及通过房间内外和房间外的IM交换代码片段来协作构建监控脚本。
毫不奇怪，房间里的人似乎比远程参与者更投入。在同一个房间里意味着参与者对承诺的程度。电话会议上的人只有在被直接点名时才发言；我们假设他们在做其他工作，并且只听着房间里的讨论。远程参与者也可能无法跟上房间里混乱、不断变化的讨论。
在宏观层面，跟踪11周的故障排除日志也非常有趣。它讲述了一个重大而复杂的问题的故事，该问题无法在任何测试系统上成功重现——这个问题是，打开日志记录会使系统在引起故障所需的负载水平下减速到无法使用的程度。这个故事展示了紧急情况处理团队与各种产品的支持团队互动，升级到最高级别，应用补丁程序后又一个补丁程序，并尝试配置设置、新硬件和特殊版本的软件。该过程涉及许多不同团队的大量工作。
总的来说，紧急情况处理是一组专家为理解和修复由许多组件组成的复杂系统的行为而进行的协作努力。他们使用了各种各样的技术工具：IM、电子邮件、电话和屏幕共享，但似乎他们从面对面互动中获得了最大的价值。通过在同一个房间里，当听到关键短语时，人们可以快速地从一个对话切换到另一个对话，并且向某人提问或提出想法的障碍非常低。虽然紧急情况处理看起来很笨重和浪费，但我们没有其他方法可以复制一群人困在一个房间里寻找共同问题解决方案的协作互动。如果开发出一种工具，可以使远程协作者像我们在紧急情况处理室中看到的那样投入，这将是系统管理的革命性进步。
接下来，我们将描述我们在美国一所大学的安全管理员中观察到的各种协作。
“ettercap”事件
当我们第一次见到一所大型大学计算机中心的安全管理团队时，5 他们似乎有些多疑，说出这样的话：“我永远不会在Windows机器上输入我的密码，因为我无法真正判断它是否安全。” 在观察他们两个星期后，我们意识到他们有充分的理由保持谨慎。通常，IT系统没有意愿，也不关心它们的配置方式或是否对它们应用补丁程序。然而，安全管理员面临着人类对抗者，已知这些对抗者在被锁定在系统之外时会生气，并格外努力地寻找新的漏洞并对锁定他们的人的数据造成损害。
这些安全管理员的工作以监控为中心。新的攻击每隔一两周就会出现。病毒、蠕虫和恶意入侵可能随时发生。他们拥有一系列自动监控软件，用于查找系统日志和网络流量中的攻击痕迹。自动入侵检测系统需要偏向谨慎，由系统管理员最终决定可疑活动是否真的是攻击。这些系统管理员依靠通信工具来共享信息，并帮助他们保持对他们的中心、他们的校园以及世界各地正在发生的事情的意识。
安全管理团队共享相邻的办公室，因此关于系统活动的来回聊天很常见。他们开玩笑说要拆掉墙壁，腾出一个大的工作空间。他们还使用了全校范围的MOO（多用户域，面向对象），这是一个文本虚拟环境，所有系统管理员都会在那里闲逛，不同的“房间”用于不同的主题。事件的开始会导致MOO安全房间中的活动水平很高，因为来自校园不同部分的安全管理员会比较他们自己的系统上正在发生的事情。在日常工作中，MOO可能会就最新发现的漏洞或病毒如何进入网络的理论进行对话。管理员描述了MOO的持久性功能非常有用，可以让他们在离开后回来时，即使是一天，也能赶上正在发生的一切。他们还使用了MOO的“耳语”功能进行点对点通信（类似于传统的IM）。
当我们观察到一个专注于黑客工具的会议时，MOO用于快速交换安全状态的一个例子出现了。安全管理员讨论了一个名为“ettercap”的软件包。由于不熟悉此工具，我们中的一人开始使用无线网络在Web上搜索有关它的信息。几分钟后，房间里的一位管理员告诉我们，一位远程工作的安全管理员检测到此流量并在MOO上询问了此事
远程 有人知道是谁在查找ettercap吗？DHCP日志显示 [观察员的机器名称] 是一个NetBIOS名称。电子邮件日志中没有任何内容（例如来自该IP地址的POP）。
远程 看起来更像是研究。
远程 该主机上的SMTP端口已打开，但它没有响应为SMTP。那可能是一个黑客防御端口。
本地 我们正在展示 [黑客] 如何下载ettercap。一位访客开始搜索它。
远程 啊，好的。谢谢。
在短短几分钟内，系统管理员检测到对危险的ettercap软件包的Web搜索，识别了有问题的机器的名称，检查了该机器的其他活动日志，并探测了机器上的端口。他可以看出这可能是某人在进行研究，但检查了MOO以验证这实际上是合法的。
参与者还在更广泛的范围内进行协作。在我们访问期间，该站点正在处理一个全球性的安全事件，该事件针对美国和欧洲各地的军事、教育和政府站点。这是一次特别持久的攻击——每次检测到入侵并关闭漏洞时，攻击者都会使用新的漏洞利用程序返回。攻击者会在机构之间跳转，在一个地方入侵一台机器，收集密码，然后在其他机构的机器上尝试这些密码（因为用户通常在不同站点的帐户中使用单个密码）。
这种广泛的攻击需要广泛的响应，因此来自受影响机构的安全管理员组成了一个临时社区，以监控和共享有关攻击的信息，目标是将攻击追溯到其来源。当发现受感染的机器时，他们会让它保持受感染状态，以便他们可以跟踪攻击者并查看他们还连接到哪里。这种协作就像信息战：与受信任的同事共享有关已知受感染机器和漏洞利用程序的信息非常重要，但必须对攻击者保密信息。你不希望攻击者知道你已经检测到他们的攻击并正在监视他们的活动。当我们第一次观察他们时，安全管理员使用电话会议进行社区会议。后来他们找到了一个特殊的加密电子邮件列表服务器来保密他们的信息——但由于这个工具无人维护，他们不得不自己采用和维护它。
安全管理的世界似乎非常动荡，每天都会发现新的漏洞和漏洞利用程序。虽然保密性比我们观察到的其他系统管理员更受关注，但协作是他们工作的基础：共享正在发生的事件和系统状态的知识，尤其是在攻击可能开始且时间至关重要时。
结论
我们研究系统管理员的动机之一是IT管理成本不断增加。部分原因当然可以归因于计算机每年变得更快更便宜，而人却没有。然而，复杂性也是一个巨大的问题——今天的网站建立在比15年前复杂得多的基础设施之上。随着复杂性的增加，IT管理也变得专业化。随着当今企业需要全天候运营，协调也是必不可少的。系统管理员需要共享知识、协调工作、沟通系统状态、发展共同理解、寻找和分享专业知识，以及建立信任和发展关系。系统管理本质上是协作的。
起初，很容易认为乔治的故事表明了糟糕的调试实践，或者更糟糕的是，糟糕的技能，但我们不这么认为。系统很复杂，文档很差，错误消息令人费解，而且没有人对所有这些负责。更好的错误消息或更好的文档肯定会有所帮助，但这偏离了重点。总会有一些情况被遗漏，并且复杂性会被隐藏，直到为时已晚。现代IT系统非常复杂，以至于人们通常会对它们的操作有不正确或不完整的理解。这就是IT的本质。紧急情况处理的故事和安全的故事也表明了这一点。在这些案例中——以及在我们观察到的几乎所有案例中——唯一不变的是协作。
我们观察到许多层面的协作：在一个小团队内、在一个组织内以及跨组织。我们观察到正在使用的几种不同的协作工具。我们观察到人们随着需求的变化从一种工具切换到另一种工具。我们还观察到同时使用多种协作工具用于不同的目的。毫不奇怪，系统管理员使用的协作工具与我们其他人相同，但这些工具并未针对系统管理员的需求进行优化——无论是团队头脑风暴和调试还是安全信息共享。
虽然可以为系统管理员实施特定功能，但我们清楚地看到，由于系统管理员之间的需求多样，单一的协作工具无法适用于所有人。需要有各种各样的工具，并且协作需要成为系统管理工作本身中的头等公民。更好的协作支持可以减轻个人在沟通和建立共享上下文方面的负担，从而避免遗漏信息并启用持久化通信存储。我们相信，改进的系统管理员协作工具具有巨大的潜力，可以显着影响系统管理工作——甚至可能有助于减少IT总拥有成本中不断增长的人力部分。
问
参考文献
1. Barrett, R., Kandogan, E., Maglio, P. P., Haber, E. M., Prabaker, M., Takayama, L. A. 2004. Field studies of computer system administrators: analysis of system management tools and practices. In Proceedings of the Conference on Computer-Supported Collaborative Work.
2. Gartner Group/Dataquest. 1999. Server Storage and RAID Worldwide (May).
3. Gelb, J. P. 1989. System-managed storage. IBM Systems Journal 28(1): 77-103.
4. ITCentrix. 2001. Storage on Tap: Understanding the Business Value of Storage Service Providers (March).
5. Kandogan, E., Haber, E. M. 2005. Security and Usability: Designing Secure Systems that People Can Use. In Security Administration Tools and Practices, ed. L. F. Cranor and S. Garfinkel, 357-378. Sebastopol: O'Reilly Media.
6. Kandogan, E., Maglio, P. P., Haber, E. M., Bailey, J. (forthcoming). Information Technology Management: Studies in Large-Scale System Administration. Oxford University Press.
7. Maglio, P. P., Kandogan, E. 2004. Error messages: what's the problem? Queue, 2(8): 50-55.
喜欢它，讨厌它？请告诉我们
Eben M. Haber 是位于加利福尼亚州圣何塞的IBM研究院Almaden的研究人员。他获得了威斯康星大学麦迪逊分校数据库组的博士学位，但此后一直在堆栈中向上移动，研究人机交互，从事的项目包括数据挖掘和可视化、IT系统管理的民族志研究以及最终用户编程工具。
Eser Kandogan 是IBM研究院Almaden的研究人员。他的兴趣包括人与复杂系统的交互、系统管理员的民族志研究、信息可视化和最终用户编程。他拥有马里兰大学帕克分校计算机科学博士学位。
Paul P. Maglio 是IBM研究院Almaden的研究科学家和经理。他正在研究一个系统，该系统可以组合松散耦合的异构模型和模拟，以为健康和健康政策决策提供信息。自加入IBM研究院以来，他一直从事可编程Web中介、专注的用户界面、多模式人机交互、自治计算的人为因素和服务科学的研究。他拥有加利福尼亚大学圣地亚哥分校认知科学博士学位，并且是加州大学默塞德分校的副兼职教授，他在那里教授认知科学和服务科学。
© 2010 1542-7730/10/1200 $10.00
最初发表于 Queue vol. 8, no. 12—
在数字图书馆中评论本文
更多相关文章
Adam Oliner, Archana Ganapathi, Wei Xu - 日志分析的进展与挑战
计算机系统日志提供了运行系统状态的一瞥。仪表偶尔会生成简短消息，这些消息被收集在特定于系统的日志中。日志的内容和格式可能因系统而异，甚至在系统内的组件之间也可能有所不同。打印机驱动程序可能会生成指示其与打印机通信时遇到问题的消息，而Web服务器可能会记录请求了哪些页面以及何时请求。
Mark Burgess - 可测试的系统管理
系统管理的方法在过去20年中几乎没有变化。虽然核心IT技术在许多方面都得到了改进，但对于许多（如果不是大多数）组织而言，系统管理仍然基于生产线构建物流（又名配置）和被动事件处理。随着我们进入信息时代，人类将需要减少像他们使用的机器一样工作，并拥抱基于知识的方法。这意味着利用简单的（免提）自动化，使我们不受束缚地发现模式并做出决策。
Christina Lear - 系统管理软技能
系统管理既令人感到压力重重，也令人感到很有成就感。压力通常来自外部因素，例如系统管理员（SA）和同事之间的冲突、资源不足、高强度中断的环境、相互冲突的优先级，以及系统管理员对他们无法控制的失败负责。系统管理员和他们的经理可以做些什么来减轻压力？有一些众所周知的人际关系和时间管理技巧可以有所帮助，但这些技巧在危机时刻或仅仅是由于习惯使然可能会被遗忘。
托马斯·A·利蒙切利 - 系统管理员给软件供应商的呼吁 - 10 项须知
我的一个朋友是汽修工——就是那种汽车爱好者，会在周六晚上为了乐趣而重建引擎。他向我解释说，某些品牌的汽车在设计时就考虑到了如何让机械师的工作更轻松。 然而，另一些品牌的设计却好像该公司与阿司匹林产业达成了某种协议，以确保有大量的机械师会头痛。 他说那些汽车公司讨厌机械师。 我完全理解，因为作为一名系统管理员，我能看出软件供应商何时讨厌我。 这在他们的产品中体现出来。
© 版权所有。