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

在我的组织中，我与一组NOC员工，刚起步的初级工程师和少数高级工程师一起工作。所有的重点都放在Linux上。公司培养人才的一个有趣步骤是，从NOC到高级工程师队伍之间存在一条道路。将人才库视为一个相对较新的人才，我发现技能组中的差异会随着时间的流逝而逐渐增加...

• 有些工程师非常了解一种或几种特定技术，并且经常沉浸其中……例如，MySQL，防火墙，SAN存储，负载均衡器...
• 还有其他一些通才，可以使用多种技术。
• 所有人都学习了足够的Linux（命令，进程）以执行他们每天需要和使用的内容。

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

在上下文看着这个令人难以置信的高要求在就业市场上的DevOps技能，我很好奇其他组织如何培养这些技能的发展和壮大自己的内部人才。脚本似乎不是一个特别可教的概念。

• 系统管理员如何改善其Shell脚本？
• 对于那些不/不能跟上DevOps范例的工程师，还有地方吗？
• 我们是否只是简单地假设随着这些技术的发展就会有人落后？这样可以吗？

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

如果您的员工能够在不自动化的情况下执行大部分工作，那么我认为您的人员过多。任何可以全天工作，主要由人工流程组成的IT员工都没有动力去实现自动化。为什么要学习一种新技术，这种新技术被认为不是必需的，甚至可能是令人恐惧的？毕竟，创新才是准妈妈。

因此，在组织中的某个时候，您将成长为一个会挣扎和崩溃的规模，或者您将开始使几乎所有事物都变得自动化并表现出色。当然，高级工程师应该在这里领导工作，甚至可以与初级工程师和NOC员工一起工作以自动化他们的一些工作量。这给小。工程师有机会使用许多脚本的框架，他们可以根据需要为每个租户和新的硬件版本进行调整。这消除了“哦，我的天哪，我什至从哪里开始”的艰巨想法。从方程式开始，并为他们提供了解决实际问题的起点。这将我带到了最后一点。书和例子很好，但是有他们面临的问题。给他们一个目标，就像租户x的所有新服务器都应该安装某些ESXi模块，然后与他们一起完成它。然后修改脚本以在多租户环境中工作。

系统管理员如何改善其Shell脚本？

如上所述，通过需要。

对于那些不/不能跟上DevOps范例的工程师，还有地方吗？

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

我们是否只是简单地假设随着这些技术的发展就会有人落后？

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

tl; dr除非他们看到其中的价值，否则您将永远没有真正投资于学习它的人。如果他们可以手动完成日常任务，那么您的人员过多，没有任何动力。

•系统管理员如何改善其Shell脚本？

练习，与驱动混合。这听起来很老套，但你必须要变得更好，除了实践。如果您不真正喜欢脚本，那么您可能不得不这样做很多年，而永远不会真正擅长于此。如果您不想变得更好，那么您每天可以在工作中坐在世界上最好的脚本编写者旁边，而不会掌握本该拥有的技巧。

我知道那些人，尽管从事IT工作，但仍然顽固地拒绝学习任何脚本。对于这个行业的人们来说，很快将没有地方。他们是垂死的一代的一部分。

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

•对于那些仍然/无法跟上DevOps范例的工程师，还有地方吗？

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

我认为也许我们永远都不应称他们为“工程师”。IT行业为自己使用了“工程师”这个词已经很糟糕了，我认为这是对那些花了多年时间在高等教育计划中并获得法律认证的实际工程师的侮辱，以便他们可以设计桥梁，摩天大楼，强子对撞机等等...那些才是真正的工程师。

但是有一个相似之处……如果您想称自己是IT行业的“工程师”，那至少意味着您在创造东西。您很有创造力，并且以前所未有的新方式将点滴连接起来。您构建的东西，直到您实现它之前，没有人知道它的价值。

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

•我们是否只是简单地假设随着这些技术的发展某些人会被甩在后面？

市场将适应。可能是有些人在实际上没有应得的薪水时不会赚6位数字的薪水，这在这个行业中经常发生。

我发现创造力，而不仅仅是编码/脚本技巧，是关键因素。就是您需要对自己说的创造力，“ 哦，嘿，我可以自动化！ ”然后技能才发挥作用。如果您发现自己只是在老板告诉您之后才编写脚本，那么您可能没有那种我一直在谈论的动力或创造力...而这是两种很难讲授的素质，也许是不可能的。

系统管理员如何改善其Shell脚本？

一个人如何变得更好？阅读书籍，参加课程，然后运用学到的原理。（或这些方法的组合。）这是有意简化的，因为学习脚本和学习烹饪或修理汽车没有什么特别的。

对于那些不/不能跟上DevOps范例的工程师，还有地方吗？

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

我们是否只是简单地假设随着这些技术的发展就会有人落后？

以目前的发展速度来看，是的。你们中的大多数人可能在自己的工作场所中进行观察。您绝对应该跟上职位列表，知道市场当前的需求。（您所在的地区有很多Hadoop的职位清单？了解Hadoop。）如果您不能跟上市场的发展，您就有被落伍的风险。

通常，通常不会派遣初级工程师进入至关重要的复杂生产环境。您有为此的高级工程师。初级队伍应被允许在开发/测试沙箱中工作。

如果您需要技术X的工程师并希望在内部担任该职位，请找到愿意学习它的人，找到有条理的培训，然后将两者结合起来。

找出部门需要哪些技能。寻找愿意学习的人。教/分发钱进行培训。

对于那些不/不能跟上DevOps范例的工程师，还有地方吗？

“ devops”只是系统管理员数十年来一直在做的事情的新词。

我们是否只是简单地假设随着这些技术的发展就会有人落后？

恰恰相反。随着时间的流逝，对技术人员的需求越来越多。具有任何工程知识和技术技能的任何人都将有一个工作场所。