一切系统管理员 - @YesThatTom
PDF自动化应该像钢铁侠，而不是奥创
“剩余原则”需要越来越多高技能的人才。
Thomas A. Limoncelli
问： 亲爱的汤姆：几年前，我们自动化了系统管理团队的一个主要流程。现在这个系统变得无法调试。没有人记得旧的手动流程，而且自动化程度已经超出了我们任何人的理解能力。我们感觉自己把自己逼到了墙角。难道所有的运维自动化注定都要这样吗？
答： 问题似乎在于，这种自动化被设计得像奥创，而不是钢铁侠。
钢铁侠的外骨骼增强了托尼·斯塔克本身的能力。托尼是一个聪明、强壮的人。他可以自己计算力量和轨迹。然而，通过让他的外骨骼为他做这些，他可以专注于其他事情。当然，如果他不同意或想做一些程序没有编码的事情，他可以覆盖轨迹。
另一方面，奥创的目的是完全自主。它完成所有事情，而且基本上非常复杂，以至于当需要调试它时，唯一的选择就是（剧透警告！）摧毁它。
如果编剧/导演乔斯·韦登咨询过我（乔斯，如果你正在读这篇文章，你真的应该咨询我），我会找到一种方法插入布莱恩·克尼汉的名言：“调试的难度是编写代码的两倍。因此，如果你尽可能巧妙地编写代码，那么根据定义，你就不够聪明来调试它。”
问题的根源
在讨论如何预防这种情况之前，我们应该讨论一下我们是如何陷入困境的。
我们陷入这种陷阱的第一种方式是自动化简单的部分，而将剩下的部分留给手动完成。这听起来像是自动化事物的显而易见的方式，事实上，直到约翰·奥尔斯波的优秀的两部分博客文章“自动化的成熟角色”（http://www.kitchensoap.com/2012/09/21/a-mature-role-for-automation-part-i）提高了我的意识，我通常都鼓励这样做。
你当然不应该首先自动化困难的情况。我们在自动化简单情况时学到的东西使我们更好地准备自动化更困难的情况。这被称为剩余原则。你自动化简单的部分，而“剩余”的部分则由人类完成。
从长远来看，这会造成一个非常严重的问题。留给人们做的工作，根据定义，变得更加困难。在这个过程开始时，人们做的是简单和复杂任务的混合。过一段时间，这种混合越来越倾向于复杂。这是一个问题，因为人们不会随着时间的推移变得更聪明。《摩尔定律》预测计算机的性能会随着时间的推移而变得更强大，但不幸的是，对于人类，没有这样的预测。
工作变得更加困难的另一个原因是它变得更加稀有。更容易的工作，经常做，可以保持一个人的技能新鲜，并使我们为罕见但困难的任务做好准备。
从逻辑上讲，这种范式导致需要雇用极其聪明的人来做极其困难的工作。也许这就是为什么谷歌的招聘人员在打电话邀请人们加入他们的SRE团队时听起来如此痛苦和绝望的原因。
避免剩余原则问题的一种方法称为补偿原则。有些任务是人类擅长的，而机器不擅长。同样，有些任务是机器擅长的，而人类不擅长。补偿原则认为，人和机器应该各自做他们擅长的事情，而不是尝试他们不擅长的事情。也就是说，每个群体都应该弥补对方的不足。
机器不会感到无聊，所以它们更擅长重复性任务。它们不睡觉，所以它们更擅长必须在深夜完成的任务。它们更擅长一次处理多个操作，以及需要平稳或精确运动的操作。它们更擅长字面复制、访问限制和定量评估。
人类更擅长即兴创作和灵活应变、运用判断力以及应对书面材料的变化、感知情感。
让我们将这个原则应用于监控系统。监控系统每五分钟收集一次指标，存储它们，然后分析数据，用于警报、调试、可视化和解释。
一个人可以每五分钟收集一次关于系统的数据，并且通过轮班工人，他们可以全天候进行。然而，人们会感到无聊和马虎。因此，很明显数据收集应该自动化。警报需要精确性，这也最好由计算机完成。然而，虽然计算机更擅长可视化数据，但人们更擅长解释这些可视化。调试需要即兴创作，这是另一项人类技能，因此再次将这些任务分配给人类。
约翰·奥尔斯波指出，只有极少数项目可以像这样分解为如此明确的功能案例。
做得更好
更好的一种方法是基于互补性原则做出自动化决策。这个原则从人类的角度看待自动化。它通过考虑人们的行为将如何因自动化而改变来改善长期结果。
例如，规划自动化的人员应该考虑通过手动执行流程随着时间的推移所学到的知识，以及如果流程自动化，这种知识将如何改变或减少。当一个人第一次学习一项任务时，他们专注于实现目标所需的基本功能。然而，随着时间的推移，他们了解了围绕该流程的生态系统，并获得了全局视野。这使他们能够执行全局优化。当流程自动化时，自动化封装了迄今为止的学习，允许新人在不必经历学习的情况下执行任务。这阻碍或阻止了未来的学习。这种分析是认知系统工程（CSE）方法的一部分。
互补性原则将CSE与联合认知系统（JCS）方法相结合。JCS检查自动化和人如何协同工作。联合认知系统的特点是它能够控制局面。
换句话说，如果你看着一个高度自动化的系统，并认为“它不是很漂亮吗？我们不知道它是如何工作的”，你可能正在使用剩余原则。如果你看着它并说，“我们共同学习和成长，共享对系统的控制，这不是很美妙吗？”那么你就很好地应用了互补性原则。
使用互补性原则设计自动化是一个相对较新的概念，我承认我不是专家，尽管我可以回顾过去的项目，看看成功来自于偶然应用这个原则的地方。即使是瞎猫也能碰上死耗子！
例如，我曾经在一个团队中维护一个非常庞大的（在当时）云基础设施。我们负责支持数千台虚拟机的数百台物理机器。
我们需要自动化物理机器的维修过程。当出现硬件问题时，必须将虚拟机从物理机器上迁移走，必须诊断机器，并且必须向数据中心的硬件技术人员发送维修请求。机器修复后，需要重新集成到云中。
我们创建的自动化遵守了互补性原则。它是人类和机器之间的伙伴关系。它没有限制我们学习和成长的能力。对系统的控制在自动化和相关人员之间共享。
换句话说，我们没有创建一个接管集群并运行它的系统，而是创建了一个与人类合作以处理大部分工作的系统。它自主地完成了它的工作，但我们没有互相妨碍。
自动化分为两个部分。第一部分是团队用来完成各种相关任务的一组工具。只有在这些工具工作了一段时间后，我们才构建了一个自动化全局流程的系统，并且它的作用更像是一个外骨骼助手，而不是一个独裁者。
维修过程在功能上分解为五个主要任务，并编写了一个工具来处理每个任务。这些工具是：（a）疏散：物理机器上运行的任何虚拟机都需要实时迁移到不同的机器；（b）复苏：在必须从虚拟机的最新快照重新启动虚拟机的极端情况下所需的疏散过程；（c）恢复：尝试通过简单的方法（例如关闭电源并重新打开电源）使机器再次工作；（d）发送到维修站：生成一份工作单，描述需要修复的内容，并将此信息发送给实际修复机器的数据中心技术人员；（e）重新同化：一旦机器被修复，配置它并将其重新引入服务。
随着工具的完成，它们取代了各自的手动流程。然而，这些工具提供了广泛的可见性，了解它们正在做什么以及原因。
下一步是构建可以将所有这些工具结合在一起的自动化。该自动化是基于一些特定原则设计的
• 它应该遵循与人类团队成员相同的方法。
• 它应该使用与人类团队成员相同的工具。
• 如果另一个团队成员正在机器或集群（机器组）上进行管理工作，自动化会在被要求时让开，就像人类团队成员会做的那样。
• 像一个好的团队成员一样，如果它感到困惑，它会退后一步，并向团队的其他成员寻求帮助。
该自动化是一个状态机驱动的维修系统。每台物理机器都处于特定状态：正常、出现问题、恢复进行中、已送去维修、正在重新同化等等。通常在出现问题时向人们发出警报的监控系统改为向我们的自动化发出警报。根据警报系统是否有关于机器出现问题、死机或恢复生命的消息，相应的工具被激活。工具的结果决定了分配给机器的新状态。
如果自动化感到困惑，它会暂停在该机器上的工作，并通过在我们的请求跟踪系统中打开一个工单来向人类寻求帮助。
如果人类团队成员正在机器上进行手动维护，则会告知自动化不要触摸该机器，这类似于人类团队成员之间的做法，只不过人们现在可以键入命令，而不是向周围隔间中的同事大喊大叫。
自动化非常成功。以前，值班人员每天会被呼叫一到两次。现在，我们通常每周被呼叫不到一次。
由于这种设计，人类团队成员继续参与到系统中，以至于他们一直在学习。有些人专注于改进工具。另一些人则专注于改进软件发布和测试流程。
如前所述，剩余原则的一个问题是，留给人类的工作需要越来越高的技能水平。有时我们经历了相反的情况！随着剩余任务数量的减少，我们更容易理解剩下的任务。没有那么多其他任务的精神负担，我们能够更好地评估剩余的任务。例如，技术含量最高的任务涉及一个特别英勇的恢复程序。我们重新评估了我们是否应该甚至执行这个特定的程序。我们不应该。
英勇的方法冒着数据丢失的风险，以避免重新启动虚拟机。这是错误的优先级。我们的客户更关心数据丢失，而不是快速重启。我们实际上通过用一个已经自动化的现有程序替换了这个剩余任务，从而消除了它。如果我们的头脑仍然被如此多的其他任务所困扰，我们就不会看到这个机会。
另一个剩余流程是构建新的集群或机器。它发生的频率不够高，不值得完全自动化。然而，我们发现，如果我们创建正确的元数据，使其认为所有机器都刚刚从维修中返回，我们可以让自动化“汤姆·索亚式”地为我们构建集群。很快，集群就为我们构建好了。
需要临时即兴创作、创造力和评估的流程留给了人类。例如，认证新型号的硬件需要即兴创作和在模糊的要求下采取行动的能力。
最终的系统感觉很像钢铁侠的战衣：增强我们的技能并处理琐事，以便我们可以专注于全局。一个人可以完成许多人的工作，而且由于我们有一个助手来处理繁琐的工作，我们可以更好地完成我们的工作。学习没有停止，因为它是一项协作努力。自动化处理了枯燥乏味的工作和深夜工作，我们可以专注于为我们的客户优化和增强系统的创造性工作。
我没有一个可以始终实现互补性原则的好处的公式。然而，通过仔细关注人们的行为将如何因自动化而改变，并通过保持对系统的共享控制，我们可以构建更像钢铁侠，更少像奥创的自动化。
进一步阅读
约翰·奥尔斯波的文章“自动化的成熟角色”。 (http://www.kitchensoap.com/2012/09/21/a-mature-role-for-automation-part-i)。
大卫·伍兹和埃里克·霍尔纳格尔的著作《联合认知系统：认知系统工程的基础》。泰勒和弗朗西斯出版社，博卡拉顿，佛罗里达州，2005年。
《云系统管理实践》第12章，作者：Thomas A. Linomcelli，Strata R. Chalup 和 Christina J. Hogan。(<http://the-cloud-book.com)
喜欢它，讨厌它？请告诉我们 [email protected]
Thomas A. Limoncelli 是一位作家、演讲家和系统管理员。他是纽约市 Stack Overflow, Inc 的 SRE。他的著作包括《云管理实践》（the-cloud-book.com）和《系统管理员的时间管理》。他的博客地址是 EverythingSysadmin.com
© 2015 1542-7730/15/0500 $10.00
最初发表于 Queue 第 13 卷，第 8 期—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非密码哈希函数的标准
虽然密码哈希函数和非密码哈希函数无处不在，但在它们的设计方式上似乎存在差距。针对各种安全需求，存在许多针对密码哈希的标准，但在非密码方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布非常有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者凭直觉接受，良好的开发者体验可以实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过介绍使用基于代码、低代码和极端低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。低代码技术显然显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，新的工具、技术和技巧不断被开发出来以服务于商业和社会，但它也很健忘。在其快速前进的运动中，它容易受到时尚的影响，并且可能会忘记或忽略已证明的解决其面临的一些永恒问题的解决方案。用例，最初于 1986 年引入并在后来普及，就是这些已证明的解决方案之一。
© 保留所有权利。