每位有抱负的 DevOps 工程师应该知道的 5 条法则

优秀的工程师遵循这些规则,就能成为卓越的工程师。
663 位读者喜欢这篇文章。
How has open source changed your life?

Opensource.com

“有人会说,“优秀的工程师是懒惰的工程师”。在某种程度上,这是真的:如果你正在自动化重复性任务,那么懒惰是一种很好的品质。但是,懒惰与学习新技术和完成新工作背道而驰。在初级系统管理员和高级 DevOps 工程师之间,懒惰不再成为优势。”

让我们讨论一下有抱负的 DevOps 工程师如果想成为卓越的 DevOps 工程师应该遵循的五条法则。

1. 忘记“我不知道”

卓越的工程师应该做的第一件事就是从他们的词汇中消除“我不知道”这句话。“我不知道”这句话给人的印象相当于(在你开始之前)举手投降。消除这句话很难做到。但是说“我需要做一些研究”,或者“我知道有人可能会给我指明正确的方向”,听起来要好得多。重点是:如果你正在讨论某件事作为一个可能的任务,那么你最终会做这件事的可能性很大。你或房间里的任何其他人对此一无所知这一事实是无关紧要的。

将每项任务都视为学习的机会。投入必要的时间,成为手头任务的常驻专家。向自己证明你可以教会老狗新把戏。向你的同事证明你可以使团队走得更远。寻求新知识,并改进你构建和维护的东西。不要害怕投入到你一无所知的事情中。你对知识的渴望应该是永不满足的。你今天可能不知道,但你明天就能知道。

2. RTFM

文档无处不在。复杂问题的解决方案触手可及。努力不要在没有先阅读文档的情况下询问你的同事某件事是如何工作的。

你的同事花时间编写文档是有原因的。时间是生命最宝贵的资源。不要浪费他们的时间。如果你在阅读文档有疑问,请随时提问。man 手册也是如此。开发人员花时间创建了这些文档。操作系统供应商为你提供了安装和阅读它们的工具。在某件事上花费的精力越多,阅读就变得更加重要。

在没有文档的情况下,阅读代码。它肯定包含有关影响其工作方式的决策的注释或说明。至少,确保你理解代码存储库的内容。如果 repo 没有遵循 十二要素应用 的方法,请确保你了解它的不足之处。当你最终提出问题时,请确保以积极的方式提出。保持积极有时很难做到。作为局外人,你错过了导致该决策的背景。永远不要忘记迭代改进是运作方式。RTFM!

3. 先搜索再提问

你读过多少次关于如何做某事的指南,然后还需要问如何做?答案很可能是“零”。你可能拥有可以回答你大部分问题的团队成员。在极少数情况下,你必须咨询你的经理,请确保你至少搜索过可能的答案。很久以前,有人告诉我,“不要给我带来问题。给我提出解决方案。”这是一个非常简单的陈述,但在 DevOps 中却有着深刻的含义。如果你正在讨论一个问题,你很可能会在它的解决方案中发挥作用。不要带着问题去找你的领导。而是提出问题以及它的解决方案。

你问题的解决方案不会从天而降。解决新问题需要寻找新的答案。我们生活在一个令人惊叹的时代:只需敲击几下键盘,人类的大部分智慧就可以供我们使用。如果你在没有至少搜索答案的情况下求助于领导,你让他们失望了。

你担任这个角色是为了完成你的领导层确定他们需要其他人而不是自己来解决的工作。你至少可以做到的是自我管理问题的解决方案。

4. 一切皆有可能。永不言败。信任但要核实。

我经常看到团队成员中有一种感觉,认为有些事情是不可能的。在 DevOps 中工作的美妙之处在于,物理学是你环境中唯一的限制。你无法通过连接发送比物理上可能更多的电子。你无法在硬盘上存储比物理上可能更多的块。你也受到时间的限制(业务截止日期和时间是最常见的限制因素)。这意味着你拥有惊人的能力来完成你付出努力的任何事情。在这个领域,只要有适当的时间、协调和努力,一切皆有可能。你和你的团队成员应该定期提醒自己这一点。

你的存在是因为技术债务。

在涉及复杂的分布式系统——甚至简单的脚本——时,你永远不应该假设任何事情。记住,一切皆有可能。这意味着好的解决方案和差的解决方案都可能最终投入生产。几乎我工作过的每个地方都有一个团队对他们的系统工作方式做出了假设。这些假设存在的原因有很多。这些假设存在的原因有很多,但没有人进行深入研究以确保系统按照他们假设的方式工作这一事实应该令人费解。你应该始终信任你的队友;但是,如果某些事情感觉很奇怪或无法按预期工作,你需要验证该假设实际上是否属实。

5. 承认技术债务

技术债务是某人在做出决策时认为合理的决策的结果。但这些决策现在很可能正在引起问题,因为它们不再合理。一年前在紧迫的期限内使产品上市的东西很可能会阻碍你今年做同样的事情。如果你在一个 DevOps 团队中,你要么是在帮助消除技术债务,要么是在将其推向生产环境。通常,你必须在计划会议中成为理性的声音,说明为什么某些事情从长远来看行不通。如果你不小心,这会让你成为一个被排斥的人。将这些时刻视为教导你周围的人一些新事物的机会。不要对人们不明白他们正在讨论的内容为什么会在以后增加复杂性而感到惊讶。理解你正在支持的系统和堆栈的复杂性是你的工作(而不是他们的)。如果需要,请坚持你的立场。但请记住,如果你不得不坚持立场,那么你可能需要让自己更接近项目反馈循环的早期阶段。

你的存在是因为技术债务。

结论

对基础系统知识的永不满足的渴望对于在 DevOps 中取得成功是必要的。卓越的 DevOps 工程师不断寻求问题的答案和问题的解决方案。为了成为他们中的一员,将预防未来的技术债务作为你工作的 постоянный 重点。永不停止学习。懒惰无法让你达到目标。

本文是《开放组织 IT 文化变革指南》的一部分。

Chris Short
开源外交官 | Kubernetes 贡献者 | 残疾退伍军人(肯定在疼痛中)| 底特律 | AWS Kubernetes | 他/他/他的 | 仅代表我个人观点

4 条评论

我再补充一点对我帮助很大的:尽早报告错误。我说这话不是因为它是一件负责任的事情,而是因为我通常发现,报告错误并必须重现我认为不可避免的问题的行为通常会揭示一些愚蠢的用户错误。我想说,我坐下来报告的 75% 的错误实际上从未被发送出去,因为尝试报告它们的行为揭示了它们的解决方案。

>忘记“我不知道”
我不同意。说你不知道可以设定现实的期望。我不是 DBA——问我数据库问题只会让我茫然地盯着你看——说我要研究一些东西对任何人都没有好处。最好是他们直接问 DBA,而不是我作为中间人并转达我可能弄错的信息。

>先搜索再提问
这应该是所有工作都应该遵循的原则,而不仅仅是 DevOps。

如果解决问题是你的责任,那么询问 DBA 或做任何你需要做的事情来获得答案是你的工作。如果这不是你的工作,你仍然可以礼貌地为对方指明正确的方向。不管我们是否喜欢,回答“我不知道”通常会被理解为“我不关心”。

我同意这五项建议几乎适用于当今任何技术工作,而不仅仅是 DevOps。

回复 ,作者:zenmaster (未验证)

我完全不同意你的第一句话,即禁止说“我不知道”。当你谦虚地承认你不知道某件事时,你才能开始学习并最终了解事物。

这正是笛卡尔用他的“我思故我在”所说的,如果我可以引用一些哲学 :)。

对于其余部分,是的,你需要阅读、理解、综合和设计一个好的(即最好的)解决方案来解决你可能遇到的每个问题。这就是工程师所做的事情。

我的一点看法,

知识共享许可协议本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。

下载《开放组织 IT 文化变革指南》

开放原则和实践,交付无与伦比的商业价值。

© . All rights reserved.