这是系统管理员基础知识系列文章的第二篇。如今，DevOps 的兴起甚至让“系统管理员”这个职位名称都显得有些过时，就像它取代的“系统分析师”头衔一样。这些 DevOps 职位与过去的系统管理员工作截然不同。它们更加强调软件开发，远远超出基本的 shell 脚本编写，因此，这些职位通常由具有软件开发背景但没有太多系统管理员经验的人担任。过去，系统管理员会在初级职位入职，并由团队中的高级系统管理员指导，但在许多情况下，公司在首次聘请 DevOps 工程师之前，会进行相当长时间的云外包。因此，DevOps 工程师可能会在没有导师的情况下，以初级职位被推到这个角色上，唯一的依靠就是搜索引擎和 Stack Overflow 帖子。

在本系列文章中，我将阐述多年来我学到的一些经验教训，这些教训对于资深的系统管理员来说可能是显而易见的，但对于刚刚进入这个职位的人来说可能是新闻。

在本系列的第一篇文章中，我讨论了系统管理员如何处理警报和随叫随到的轮换。在本文中，我将讨论如何通过自动化让自己从工作中解脱出来。在系统管理员圈子里，你时不时会看到这样一句话：“小心点，否则我会用一个微小的 shell 脚本取代你。” 优秀的系统管理员讨厌执行单调乏味的任务，并不断寻求将这句话应用到自己身上。 话虽如此，自动化有很多不同的方法，并非所有方法都能节省时间。在这里，我将讨论我在自动化方面的经验，并描述您应该（和不应该）自动化什么、何时自动化、为什么自动化以及如何自动化。

您应该采取措施自动化系统管理员工作的原因有很多

1) 它可以解放您花费在单调乏味任务上的时间，让您专注于更重要的工作。

凭借如今服务器中内置的所有自动化功能，人们很容易认为系统管理员过去不得不执行多少单调乏味的任务是理所当然的。日志并非总是自动轮换；备份通常是自行开发的，而且通常是手动触发的。即使现在，仍然有系统管理员手动安装每台服务器，手动登录机器并安装或更新软件，以及手动配置主机上的服务器配置文件。

让我们以服务器操作系统安装为例——现代交互式服务器操作系统安装可能需要系统管理员花费 15 分钟到 1 小时的时间来完成并回答问题。这些行为实际上并不需要系统管理员的专业知识，一旦您对服务器的设置方式做出初步决定。通过自动化这些单调乏味的任务，您可以回到更困难的工作，而这些工作确实需要您的专业知识。

2) 自动化减少了日常任务中的错误。

手动重复执行相同的任务很容易出错，而且如果这是您每天都做的事情，最终您甚至可能会停止关注您的任务是否成功。此外，您执行特定任务的方式可能与团队中其他管理员的方式略有不同。通过自动化任务，团队可以就执行任务的理想方式达成一致，并知道当您运行自动化脚本时，它每次都以相同的方式执行，不会跳过步骤或命令顺序错误。

3) 自动化使团队中的每个人都能够高效工作。

通过自动化，您可以将即使是复杂的过程也简化为一个命令。然后，该命令将成为团队中的任何人都可以运行的东西，而复杂的过程可能需要团队中更资深的成员。例如，如果您以生产软件部署为例，通常可能需要复杂地安排触发负载均衡器和监控维护模式、要检查的软件版本、要同步的镜像以及要重启和测试的服务。即使这些单独的步骤可能是单调乏味的，但组合起来，它们也会变得非常复杂，并且可能会让团队中的初级成员感到不知所措——尤其是在生产正常运行时间岌岌可危的情况下。通过自动化该过程，高级管理员可以将他们所有的专业知识投入到创建执行正确检查的正确流程中，并且他们可以去度假，因为他们知道团队中的任何其他人现在都可以以正确的方式执行任务。

4) 自动化减少了文档编制工作量。

通常，系统管理员团队不会自动化任务，而是花费时间记录流程。文档仍然很重要，在下一节中，我将讨论何时文档有意义，何时没有意义。但事实是，如果您将整个流程放入一个自动化任务中，您就不再需要完整的维基页面文档（这不可避免地会过时），因为您已将其简化为“运行此命令”。由于该过程现在是自动化的，因此您也知道该过程会保持最新；否则，脚本将无法工作。

并非所有事情都适合自动化，甚至可能适合自动化的事情今天也可能不适合（下一节将介绍您应该何时自动化）。以下是几种不同类型的任务，它们是自动化的良好候选对象。

1) 日常任务。

一般来说，您经常执行的任务（至少每月一次）是自动化的良好候选对象。理论上，任务越频繁，您从自动化中获得的时间节省就越多。您每年只执行一次的任务可能不值得花费精力来构建自动化，相反，这些类型的任务受益于良好的文档记录。

2) 可重复的任务。

如果您可以将一个流程记录为一系列命令，然后在终端中逐个复制粘贴它们，并且任务将完成，那么这是一个可重复的任务，可能是一个自动化的良好候选对象。另一方面，一次性任务，具有自定义输入或您可能永远不必再次做的事情，则不值得花费时间和精力来自动化。

3) 复杂任务。

任务越复杂，如果您手动执行，您就越有可能犯错。如果一个任务有多个步骤，特别是需要您获取一个步骤的输出并将其用作另一个步骤的输入的步骤，或者使用带有复杂参数字符串的命令的步骤，那么这些都是自动化的绝佳候选对象。

4) 耗时的任务。

任务完成所需的时间越长（尤其是在运行命令、等待其完成以及然后使用该命令的输出做某事的时间段内），它就越适合自动化。操作系统安装和配置就是一个很好的例子，因为当您安装操作系统时，有时您需要输入安装设置，有时您需要等待安装完成。所有这些等待都是浪费时间。通过自动化长时间运行的任务，您可以去做其他工作，然后返回自动化（或者更好的是，让它提醒您）以查看它是否完成。

我的同事知道我喜欢通过自动化让自己从工作中解脱出来，而且有时在过去，他们惊讶地发现我还没有自动化一项在所有衡量标准下都是自动化的最佳候选对象的任务。我的回答通常是“哦，我计划自动化，只是还没准备好。” 事实是，即使您有一个非常适合自动化的任务，现在也可能不一定是自动化它的正确时机。

当我需要执行一项新的任务，该任务是一系列单调乏味的手动步骤时，我喜欢强迫自己在开始自动化之前至少“在野外”逐步执行几次。我发现我通常需要执行一项任务几次才能了解自动化最有意义的地方、任务的哪些领域可能需要特别注意以及我可能为该任务遇到的各种变量。否则，如果我只是向前冲并编写脚本，我可能会发现自己在几周后从头开始重写它，因为我发现该过程需要适应任务的新变体。如果我对流程的某些部分不太确定，我可能会首先自动化我确定的部分，并确保这些部分是正确的。稍后，当流程的其余部分开始在我脑海中凝固时，我再返回并将其合并到我已经完成的自动化中。

如果我不确定自己能否安全地自动化任务，我也会避免自动化任务。例如，许多组织非常喜欢使用 ChatOps（使用聊天室内的机器人自动化任务）进行自动化。尽管我知道许多机器人可以在执行任务之前对其进行身份验证，但我仍然担心在整个公司共享的服务中滥用的可能性，更不用说生产更改是由生产环境之外的主机触发的事实。根据我当前的威胁模型，我必须在开发环境和生产环境之间保持严格的分离，因此让公司中的任何人都可以访问的机器人，或者让开发环境中的 Jenkins 持续集成服务器执行我的生产任务，这根本行不通。在许多情况下，我已经完全自动化了任务，直到仍然需要具有适当访问权限的管理员转到生产环境（从而证明他们有权在那里）才能按下“按钮”。

由于自动化的整个目标是节省时间，因此我不喜欢浪费时间重构我的自动化。如果我觉得自己对流程及其变量的理解不足以自动化它，我会等到我理解为止，或者只自动化我感觉良好的部分。总的来说，我非常喜欢构建一个已完成工作的基础，然后在该基础上进行构建。我喜欢从自动化能够给我带来最大时间节省或鼓励最大一致性的任务开始，然后在它们的基础上进行构建。

我喜欢在前期做艰苦的工作，以便以后更容易，这就是为什么我非常喜欢使用配置管理来自动化服务器配置。一旦类似的东西到位，推出配置更改就会变得微不足道，并且创建与现有服务器匹配的新服务器应该很容易。这些大型任务可能需要前期的时间，但从那时起，它们可以提供巨大的成本节省，因此我尝试首先进行自动化。

我还喜欢可以在未来以多种方式使用的自动化任务。例如，我认为如今所有管理员都应该有一种简单、自动化的方法来查询他们的环境中是否安装了软件包以及安装在哪些主机上，然后能够轻松地在安装了该软件包的主机上更新该软件包。一些管理员将此称为编排的一部分，我在几个月前关于 MCollective 的系列文章中介绍了这个主题。

软件包更新是系统管理员经常做的事情，既包括频繁更改的内部软件，也包括需要安全更新的系统软件。如果安全更新成为一种负担，许多系统管理员就不会费心。拥有自动化来简化软件包更新意味着管理员可以节省他们必须经常执行的任务的时间。然后，系统管理员可以将该自动化软件包更新过程用于安全补丁、内部软件部署以及软件包更新只是许多组件之一的其他任务。

在编写自动化时，请务必检查您的任务是否成功，如果失败，请提醒系统管理员注意问题。这意味着 shell 脚本应检查退出代码，并且错误日志应转发到引起管理员注意的地方。自动化某些东西然后忘记它太容易了，但几周后回头查看，却发现它停止工作了！

总的来说，将自动化视为一种解放您的大脑、时间和专业知识，使其专注于实际需要它们的任务的方法。对我来说，我发现这意味着花费时间改进自动化以及处理异常情况——超出正常日常工作范围的事情。如果您坚持下去，您最终会发现，当没有危机或新项目时，日常工作应该自动化到您的任务只是密切关注您的良好机器以确保一切正常运行的程度。那时您就知道您已经用 shell 脚本取代了自己。