Linux 管理员如何提高他们的 shell 脚本和自动化技能？

Question

在我的组织中，我与一群 NOC 员工、初出茅庐的初级工程师和少数高级工程师一起工作；所有这些都专注于 Linux。公司培养人才的一个有趣步骤是，有一条从 NOC 到高级工程队伍的途径。将人才库视为一个相对较新的人，我发现随着时间的推移，技能组合存在分歧……

• 有些工程师非常了解一种或几种特定技术并不断沉浸其中……例如 MySQL、防火墙、SAN 存储、负载平衡器……
• 还有其他人是通才，可以驾驭多种技术。
• 所有人都学习了足够的 Linux（命令、进程）来做他们每天需要和使用的事情。

一些员工之间的一个区别因素是他们对脚本、自动化和配置管理方法的接受程度。例如，我们有两名工程师负责 Amazon AWS CloudFormation的大部分工作，另一名负责处理大部分Puppet基础设施。也许四分之一的工程师精通 BASH shell 脚本。

在就业市场对DevOps 技能的需求非常高的背景下，我很好奇其他组织如何促进这些技能的发展并培养他们的内部人才。脚本编写似乎不是一个特别可教的概念。

• 系统管理员如何改进他们的 shell 脚本？
• 没有/无法跟上 DevOps 范式的工程师还有一席之地吗？
• 我们是否只是假设随着这些技术的发展，有些人会被抛在后面？可以吗？

Answer 1

• 系统管理员如何改进他们的 shell 脚本？

练习，混合驱动。这听起来很陈词滥调，但除了练习之外，您还必须想要变得更好。如果您不是真正喜欢编写脚本，那么您可能会被迫在不得不这样做的时候做很多年，而且永远不会真正擅长它。如果您不想变得更好，您可以每天在工作中坐在世界上最好的脚本编写者旁边，而不是掌握您可能拥有的一小部分技能。

我认识那些尽管从事 IT 工作，但顽固地拒绝学习任何类型的脚本的人。这个行业很快就会没有这些人的位置。他们是垂死的一代的一部分。

（我不是在谈论老人，我的意思是比喻。：P）

• 没有/无法跟上DevOps 范式的工程师还有一席之地吗？

不。他们所做的每一件事都可以并且最终将被自动化。

我会争辩说，也许我们无论如何都不应该称他们为“工程师”。IT 行业将“工程师”这个词用于我们自己，这已经够糟糕的了，在我看来，这对在高等教育项目中花费多年并获得法律认证以便他们可以设计桥梁、摩天大楼、强子对撞机的实际工程师来说是一种侮辱等等……那些才是真正的工程师。

但有一个相似之处...如果你想称自己为 IT 行业的“工程师”，那么这至少意味着你在创造事物。你很有创造力，你以前所未有的新方式将点连接起来。你建造的东西在你做出之前没有人知道它有多么有价值。

如果您不编写代码或编写脚本，那么除了维护它们之外，您无法对计算机做太多事情，并且可能安装一两个软件包。也许将新硬盘放入 ol' MSA。在这种情况下，我会称您为管理员，当然，但不一定是工程师。我想说你的大部分工作都面临着被自动化的危险。

• 我们是否只是假设随着这些技术的发展，有些人会被抛在后面？

市场会适应。可能有些人实际上并不配得上 6 位数的薪水，这种情况在这个行业中经常发生。

我发现创造力，而不仅仅是编码/脚本技能，是一个关键因素。这就是你需要对自己说的创造力，“哦，嘿，我可以自动化这个！ ”然后技能才会发挥作用。如果你发现自己只是在你的老板告诉你之后才编写脚本，那么你可能没有我所说的那种动力或创造力……而这两种品质很难甚至不可能教。

Answer 2

了解您的环境的规模和复杂性，这让我受益匪浅。当您为云/托管服务提供商工作时，可以安全地假设您拥有大量中小型环境（10-100 台服务器）。肯定有 jr 完成的日常任务。重复的工程师和 NOC 员工（创建用户帐户、配置备份代理等）。同样的，大概有一些手工的事情是sr做的。工程师喜欢在新硬件上安装 ESXi 或配置 MPIO 或为特定硬件集安装 VMware 模块。所有这些都可以而且应该自动化。

如果您的员工能够在不自动化的情况下完成大部分工作，那么在我看来，您的工作人员过多。任何可以全天工作（主要由手动流程组成）的 IT 员工都没有自动化的动力。为什么要学习一项不被视为必要甚至可能令人恐惧的新技能？毕竟，需要是创新之母。

因此，在您的组织中的某个时刻，您将发展到一个规模，您将陷入困境并分崩离析，或者您将开始自动化几乎所有事情并取得卓越成就。当然，高级工程师应该在这里带头，甚至可能与初级工程师和 NOC 员工一起工作，以自动化他们的一些工作量。这给了 jr。工程师有机会使用许多脚本的框架，他们可以根据需要针对每个租户和新的硬件版本进行调整。这消除了“天哪，我该从哪里开始？”的令人生畏的想法。并让他们快速开始解决实际问题。这让我想到了最后一点。书籍和例子很好，但有'他们面临的问题。给他们一个目标，就像租户 x 的所有新服务器都应该安装某些 ESXi 模块，然后与他们一起完成它。然后调整脚本以在多租户环境中工作。

系统管理员如何改进他们的 shell 脚本？

根据需要，如上所述。

没有/无法跟上 DevOps 范式的工程师还有一席之地吗？

当然，有很多组织不能或不会转向 DevOps 方法。他们似乎越来越无聊选项，但它们仍然是选项。

我们是否只是假设随着这些技术的发展，有些人会被抛在后面？

与任何新技术一样 - 是的。

tl;dr 你永远不会让任何人真正投入学习它，直到他们看到它的价值。如果他们可以手动完成他们的日常任务，那么你就人满为患，没有动力。

Answer 3

系统管理员如何改进他们的 shell 脚本？

一个人如何在任何事情上变得更好？阅读书籍，上课，然后应用学到的原则。（或这些方法的组合。）这是有意过度简化的，因为与学习如何做饭或如何修理汽车相比，学习脚本并没有什么特别之处。

没有/无法跟上 DevOps 范式的工程师还有一席之地吗？

这在本网站的范围内很难回答（要求对所提出的问题有明确/定义的答案。）我们可以预测它会，但 DevOps 模型存在问题。我觉得一个人很难同时精通两门学科。2 对 1 员工的成本节省目前对企业非常有吸引力，但很难说这种趋势是否会持续下去。这当然是短期的。

我们是否只是假设随着这些技术的发展，有些人会被抛在后面？

按照目前的发展速度，是的。你们中的大多数人可能会在自己的工作场所观察到它。您绝对应该紧跟职位列表并了解当前的市场需求。（在您所在的地区有很多 Hadoop 的招聘信息？学习 Hadoop。）如果您跟不上市场的步伐，您就有可能被甩在后面。

Answer 4

人们通常不会将初级工程师派到任务关键的复杂生产环境中。你有高级工程师。应该允许初级级别在开发/测试沙箱中工作。

如果您需要技术 X 的工程师并希望在内部填补该职位，请找愿意学习它的人，找到结构化培训并将两者结合起来。

弄清楚你在一个部门需要什么技能。找一个愿意学习它们的人。教学/分发培训资金。