在我的组织中，我与一群 NOC 员工、崭露头角的初级工程师和少数高级工程师一起工作；他们都专注于 Linux。公司培养人才的一个有趣步骤是，从 NOC 到高级工程师队伍有一条道路。将人才库视为一个相对较新的群体，我发现技能组合的分化随着时间的推移而加剧......
- 有些工程师精通一门或几门特定技术，并不断沉浸其中……例如 MySQL、防火墙、SAN 存储、负载均衡器……
- 还有一些人是通才，能够运用多种技术。
- 所有人都学习了足够的 Linux（命令、流程）来满足他们日常的需要和使用。
一些员工之间的区别在于他们对脚本、自动化和配置管理方法的接受程度。例如，我们有两名工程师负责亚马逊的大部分阻止某些类型的 Cookie 的话会影响到您的网站体验。您可以随时单击此网站页脚中的 Cookie 首选项来对您的 Cookie 首选项进行更改。要了解有关我们及经批准的第三方如何在网站上使用 Cookie 的更多信息，请阅读 AWS Cookie 声明。另一个人负责大部分木偶基础设施。大约四分之一的工程师精通 BASH shell 脚本。
从难以置信需求量很大就业市场中的 DevOps 技能，我很好奇其他组织如何促进这些技能的发展并培养内部人才。脚本编写似乎不是一个特别容易教授的概念。
- 系统管理员如何改进他们的 shell 脚本？
- 对于那些不符合或不能遵循 DevOps 范式的工程师来说，还有一席之地吗？
- 我们是否只能假设随着这些技术的发展，有些人会被抛在后面？这样可以吗？
答案1
我很了解您环境的规模和复杂性。鉴于您为云/托管提供商工作，可以肯定您拥有大量中小型环境（10-100 台服务器）。初级工程师和 NOC 员工肯定会每天重复执行一些任务（创建用户帐户、配置备份代理等）。同样，高级工程师可能也会手动执行一些任务，例如在新硬件上安装 ESXi 或配置 MPIO 之类的内容或为特定硬件组安装 VMware 模块。所有这些事情都可以而且应该实现自动化。
如果你的员工能够在没有自动化的情况下完成大部分工作量，那么在我看来，你人手过多了。任何能够全天工作主要是手动流程的 IT 员工都没有动力实现自动化。为什么要学习一项不被视为必要的甚至可能可怕的? 毕竟，需要是创新之母。
因此，在组织中的某个时候，你会成长到一定规模，陷入困境并分崩离析，或者你会开始自动化几乎所有事情并取得卓越成就。当然，高级工程师应该在这里发挥带头作用，甚至可能与初级工程师和 NOC 员工合作，自动化他们的部分工作量。这让初级工程师有机会拥有许多脚本的框架，他们可以根据需要针对每个租户和新的硬件版本进行调整。这消除了“哦，天哪，我该从哪里开始？”的令人畏惧的想法，并让他们能够快速开始解决一个问题真实的问题。这让我想到了最后一点。书籍和例子都很好，但没有什么可以取代解决问题的成就感。实际的他们面临的问题。给他们一个目标，比如租户 x 的所有新服务器都应该安装某些 ESXi 模块，然后与他们一起实现目标。然后调整脚本以在多租户环境中工作。
系统管理员如何改进他们的 shell 脚本？
经过需要如上所述。
对于那些不符合或不能遵循 DevOps 范式的工程师来说，还有一席之地吗？
当然，有很多组织不能或不会转向 DevOps 方法。他们似乎越来越无聊的选择，但它们毕竟是选择。
我们是否可以简单地假设随着这些技术的发展，有些人将会被抛在后面？
正如任何新技术一样——是的。
tl;dr 除非人们看到它的价值，否则你永远不会真正投入学习它。如果他们可以手动完成日常任务，那么你就会人手过剩，而且没有动力。
答案2
• 系统管理员如何改进他们的 shell 脚本？
练习，并努力。这听起来很老套，但你必须想除了练习之外，还有一种方法可以让你变得更好。如果你不是真的喜欢写脚本，你可能会被迫花好几年时间写，而且永远也不会真正擅长它。如果你不想为了变得更好，你可以每天工作时坐在世界上最好的脚本编写者旁边，但你却不会学到你所拥有的一小部分技能。
我知道有些人尽管从事 IT 工作，却顽固地拒绝学习任何类型的脚本。这些人很快就会在这个行业中失去立足之地。他们是正在消亡的一代人。
（我不是在谈论老年人，我指的是比喻。:P）
• 对于那些不符合或无法遵循 DevOps 模式的工程师来说，还有一席之地吗？
不会。他们所做的每件事都可以而且最终都会被自动化取代。
我认为，我们可能根本不应该称他们为“工程师”。IT 行业将“工程师”一词用于我们自己，这已经够糟糕的了，在我看来，这有点侮辱实际的工程师们花了数年时间接受高等教育，并获得法律认证，以便能够设计桥梁、摩天大楼、强子对撞机等……这些就是真实的工程师。
但有一点相似之处……如果你想称自己为 IT 行业的“工程师”，那么这至少意味着你创造事情。你是有创造力的你用以前从未想到过的新方法把这些点连接起来。你创造的东西在你创造之前，别人都不知道它有多么宝贵。
如果您不编写代码或脚本，那么您除了维护计算机和安装一两个软件包之外，无法用计算机做很多事情。也许会将新硬盘放入旧 MSA。在这种情况下，我当然会称您为管理员，但不一定是工程师。而且我认为您的大部分工作都面临着被自动化取代的危险。
• 我们是否可以简单地假设随着这些技术的发展，有些人将被抛在后面？
市场会适应的。有些人可能拿不到六位数的薪水，因为他们实际上不配得到这些薪水，这种情况在这个行业经常发生。
我发现，创造力（而不仅仅是编码/脚本编写技能）是一个关键因素。你需要对自己说的是这种创造力：“哦，嘿，我可以自动化这个！“然后技能才会在那之后发挥作用。如果你发现自己正在编写一些脚本仅有的在你的老板告诉你之后，你可能就不会再有我所说的动力或创造力了......而这两种品质是很难教的，甚至不可能教的。
答案3
系统管理员如何改进他们的 shell 脚本？
一个人如何才能在某方面变得更好？读书、上课，然后运用学到的原则。（或者将多种方法结合起来。）这是故意简化的，因为学习脚本编写与学习如何烹饪或如何修理汽车相比并没有什么特别之处。
对于那些不符合或不能遵循 DevOps 范式的工程师来说，还有一席之地吗？
这个问题很难在本站的范围内回答（因为需要对提出的问题给出明确/明确的答案）。我们可以预测答案会是肯定的，但 DevOps 模型存在问题。我觉得一个人很难精通这两个学科。目前，二合一员工的成本节约对企业来说非常有吸引力，但很难说这种趋势是否会持续下去。短期内肯定是这样的。
我们是否可以简单地假设随着这些技术的发展，有些人将会被抛在后面？
按照目前的发展速度，是的。你们大多数人可能都在自己的工作场所观察到了这一点。你一定要关注招聘信息，了解市场目前的需求。（你所在地区有很多 Hadoop 招聘信息？学习 Hadoop。）如果你不跟上市场的步伐，你就有可能落后。
答案4
对于那些不符合或不能遵循 DevOps 范式的工程师来说，还有一席之地吗？
“devops” 只是一个新词，但系统管理员几十年来一直在做的事情。
我们是否可以简单地假设随着这些技术的发展，有些人将会被抛在后面？
恰恰相反。随着时间的推移，对技术人员的需求只会越来越大。任何拥有某种工程知识和技术技能的人都会有工作的地方。