致初级DevOps工程师的自己：请不要做这10件事

介绍

错误一：没有后援，就没有怜悯

我学到了什么

您可以使用的工具

太长不看

错误二：像个天才一样无视文档

我学到了什么

值得收藏的文档

太长不看

错误三：草率地通过SSH接入生产环境

我学到了什么

让你不再像牛仔一样行事，而更像工程师的工具

太长不看

我学到了什么

提高可观测性的工具

太长不看

错误五：周五部署（为什么要这么做？）

我学到了什么

“YOLO部署”的智能替代方案

帮助你减轻痛苦的工具

太长不看

错误#6：我的Dockerfile简直一团糟

我学到了什么

清洁容器的工具

太长不看

错误#7：将秘密提交到 GitHub

我学到了什么

避免泄露秘密的工具

太长不看

错误 8：日志？什么日志？

我学到了什么

Log Nirvana 的工具

太长不看

错误九：事事都要手动操作

我学到了什么

与ClickOps分手所需的工具

太长不看

错误十：试图（默默地）当英雄

我学到了什么

可倚重的文化工具

太长不看

结论：从混乱到自信

本月博客赞助商：UpCloud

我弄坏了一些东西，这样你们就不用再弄坏了。以下是我从混乱中学到的东西。

介绍

嘿，年轻的我。

我知道你很兴奋。你刚刚获得了那份令人艳羡的全新 DevOps 职位，你的终端也从未如此赏心悦目。htop一个标签页里正在运行程序，另一个标签页里 Jenkins 流水线部署进行到一半，而你刚刚发现了它的功能kubectl。

你感觉自己势不可挡。

当然，除非你在周五推送代码到生产环境。
或者在没有备份的情况下删除关键配置文件。
或者将敏感信息硬编码到代码库中，以为没人会注意到（剧透：有人注意到了，GitHub 的自动扫描器也注意到了）。

这不是一本写给完美工程师的指南，而是一份生存日志，记录了我犯过的10个错误。这些错误浪费了我的时间，造成了混乱，或者让我感觉自己一窍不通（因为我确实不知道）。每个错误都附带了我希望当时有人能告诉我的教训。不是那种说教式的，而是像队友把我拉到一边，说：“嘿，别那样做。相信我。”

所以，如果你是 DevOps 新手，还在琢磨一半的日志是什么意思，并且还在学习为什么在周五部署基本上就是与墨菲定律签订血契，那么这篇文章就是为你准备的。

错误一：没有后援，就没有怜悯

一切都始于一个 YAML 文件。难道不总是这样吗？

我当时在调整生产环境中的 Kubernetes 配置，你知道，只是个“小改动”（危险信号#1）。我通过 SSH 连接到集群，打开文件vim，做了些修改，点击保存……然后就感觉有点不对劲。

十分钟后，整个应用程序瘫痪了。

为什么？因为那“小小的改动”竟然毁掉了一个关键的卷挂载路径。你猜怎么着？
没有备份，
没有之前的版本，
也没有回滚脚本。
只有我，我那崩溃的生产环境，以及Slack上令人窒息的沉默——因为还没人注意到这个问题。

那一刻，我明白了两件事：

1. 你可以很快地从 DevOps 过渡到OOPS 。
2. “我以为其他人有备份”并不是有效的灾难恢复策略。

我学到了什么

• 版本控制适用于一切：如果不在 Git 中，就等于不存在。
• 自动化备份：设置好、测试好，即可高枕无忧。像Velero（用于 Kubernetes）或Restic（用于文件级备份）这样的工具是你的最佳帮手。
• 测试恢复：未经测试的备份只是一个希望文件。
• 设置备份失败警报，因为如果备份悄无声息地失败，那就相当于没有备份一样。

您可以使用的工具

• Velero：用于 Kubernetes 集群备份和恢复。
• Restic：一款快速、安全、高效的备份工具。
• Duplicati：非常适合加密云备份。
• GitHub Actions：按计划自动运行备份脚本。

太长不看

备份并非可有可无。它们就像生产环境中的撤销按钮。务必做好备份，经常测试，确保未来的自己不会后悔。

错误二：像个天才一样无视文档

你知道那种感觉吗？你会想，“嗯，我不用看文档了——我能搞定。”
是的，我经历过这种感觉。而且不止一次。

我曾经尝试配置一个 CI/CD 流水线，但我对 YAML 一窍不通，之前也从未接触过这个平台。我花了一整天的时间调试一个莫名其妙的错误，结果发现，文档的前三行就解释了这个问题。我只是……没仔细看而已。

为什么？傲慢。急躁。或者，也许只是那种典型的初级开发人员的想法：自己摸索才能让自己更聪明。

剧透：并不会。它只会让你的速度变慢。

我学到了什么

• 文档的存在是有原因的，它们不是可有可无的，它们是作弊码。
• 官方文档永远应该是你的首选，而不是 Stack Overflow，也不是三年前的博客文章，而是真正的官方文档。
• 学会高效搜索文档， Ctrl + F 是你的好帮手。
• 发现文档存在漏洞时，及时贡献内容。这是一种提升自身能力和积累良好声誉的行为。

值得收藏的文档

• Kubernetes 文档
• Docker 文档
• Terraform 文档
• GitHub Actions 文档
• AWS 文档

额外提示：Dash（Mac）或DevDocs（基于浏览器）等工具可以更轻松地离线或更快地浏览文档。

太长不看

成为一名DevOps工程师的关键不在于死记硬背所有内容，而在于知道去哪里查找信息。“RTFM”（阅读手册）不仅仅是一句玩笑话，而是生存之道。

错误三：草率地通过SSH接入生产环境

不久前，我还自诩为DevOps领域的神枪手。

生产环境出问题了？我会立刻打开终端，直接通过 SSH 连接到服务器，然后像黑客电影里的英雄一样开始调试。top、tail、vim，重启服务。搞定！问题解决。

至少……直到它不再是之前那样了。

有一天，我/etc直接在生产服务器上修改了一些设置，手动“修复”了一个服务。它确实生效了。但我忘记在代码或配置中同步这个改动。一周后，另一次部署又把它搞坏了。你猜怎么着？又出问题了！

那时我才明白：如果结果无法复现，那就是个累赘。

我学到了什么

• 永远不要把生产环境当成开发环境。它不是游乐场，而是神圣的土地。
• 基础设施即代码 (IaC) 是你的安全网。你的配置应该保存在 Git 中，而不是你的内存中。
• CI/CD 应该负责部署，而不是让你手动操作。你按的按钮越少，出错的几率就越小。
• 可审计性至关重要。如果无法追踪变更，则变更不存在。

让你不再像牛仔一样行事，而更像工程师的工具

• Terraform以代码形式定义基础架构。
• Ansible自动化配置和设置。
• GitHub Actions / GitLab CI/CD建立安全、可重复的流水线。
• 堡垒主机：如果必须使用SSH，请确保其安全性和可审计性。

太长不看

生产环境中的手动修复或许能暂时奏效，但它们就像定时炸弹，迟早会引爆。必须编写脚本、建立流水线、进行版本控制，否则就等着重蹈覆辙吧。

在我从事 DevOps 工作的早期，我曾莫名地自信，认为如果出了问题，我肯定会知道。

旁白：他不会轻易知道。

有一次，我们的测试环境一夜之间悄无声息地崩溃了。没有警报，没有指标，也没有日志收集。我还是因为一位产品经理随口问了一句：“嘿，测试环境现在应该是一片空白吗？”才发现的。

结果发现，一个服务器舱已经因为内存不足而宕机6个小时了。而我们却像盲人摸象一样，因为我没有设置任何监控或警报机制。

并非我不想要可观测性，我只是觉得那是我们可以“以后再考虑”的事情。
剧透一下：以后总是太晚了。

我学到了什么

• 如果看不到问题，就无法解决。监控不是附加功能，而是核心基础设施。
• 提前设置提醒没人喜欢凌晨 3 点接到 PagerDuty 的提示音……但这总比接到客户电话要好。
• 跟踪指标和日志。指标告诉你哪里出了问题，日志告诉你为什么。
• 仪表盘不仅仅是漂亮的图表，它们是你的预警系统。

提高可观测性的工具

• Prometheus：强大的指标和时间序列警报功能。
• Grafana：真正有意义的仪表盘。
• Loki：轻量级日志聚合。
• ELK Stack：来自各处的日志，集中在一个地方可搜索。
• Datadog、New Relic、Sentry：付费但非常优秀的全栈解决方案。

太长不看

监控并非可有可无，而是你的第一道防线。在问题出现之前，而不是之后，就应该设置指标、日志和警报。

错误五：周五部署（为什么要这么做？）

那是一个美好的周五下午。
拉取请求 ✅
测试 ✅
流水线 ✅
我：“看起来不错，周末前发布吧！”

配上激昂的音乐。

那次看似无害的部署最终演变成紧急回滚、依赖关系破裂，以及周六凌晨 2 点我穿着连帽衫盯着日志——只有披萨盒和对存在的恐惧陪伴着我。

是什么原因造成的？一个不起眼的配置问题。
为什么这么麻烦？因为没人想在周五晚上十点调试生产环境。你不想，你的经理不想，就连云服务提供商也不想。

我学到了什么

• 周五部署简直是噩梦，墨菲定律在周末突击部署场景中尤为灵验。
• 时间很重要。要在团队成员都在场的时候部署，以便快速发现并解决问题。
• 缓解措施 > 逞强好胜使用能够让你安全失败的发布策略。

“YOLO部署”的智能替代方案

• 功能开关：部署代码但不激活。准备就绪后再启用。
• 金丝雀发布：先向一小部分用户推出。密切注意错误。
• 蓝绿部署：在两个环境之间切换流量，实现零停机时间部署。
• 回滚脚本：如果其他方法都失败了，则快速恢复到安全状态。

帮助你减轻痛苦的工具

• LaunchDarkly或Flagsmith：大规模功能标记。
• Argo Rollouts：Kubernetes 原生渐进式交付。
• Spinnaker：高级发布策略。
• GitOps：将部署视为 Git 提交，轻松回滚。

太长不看

部署可不会因为今天是星期五就放任不管，它们照样会出问题。除非你对回滚操作完全有把握，否则最好等到星期一再操作。未来的你会感谢你的。

错误#6：我的Dockerfile简直一团糟

我第一次接触 Docker 的时候，觉得它简直太神奇了。就像每个拿到新魔杖的初级巫师一样，我很快就滥用了它。

我的第一个 Dockerfile 简直一团糟。
我把所有东西都装进去了——Python、Node、curl、unzip，还有一些“以后可能用到”的随机依赖项，​​甚至还有一个 GUI 包（别问了）。
结果呢？一个 4.2GB 的容器镜像，构建时间长得要命，一半时间都失败，而且推送到镜像仓库都需要很强的 Wi-Fi 信号。

我甚至COPY . .没有.dockerignore……你好，node_modules还有秘密配置文件。

它确实奏效了。但这就像是用胶带把服务器勉强粘起来一样，是DevOps领域的“凑合之作”。

我学到了什么

• Dockerfile是你的应用程序蓝图——保持简洁易读。
• 使用.dockerignoreDocker的默认设置.gitignore，可以防止垃圾文件进入。
• 利用缓存层，正确排列命令顺序，以免每次更改都破坏缓存。
• 使用多阶段构建：在一个阶段编译，在另一个阶段运行。这样可以生成更小、更安全的镜像。

清洁容器的工具

• 深入：分析和探索 Docker 镜像层。
• Hadolint：Dockerfile 的代码检查工具。它会（以一种好的方式）提醒你。
• DockerSlim：大幅缩小容器大小。
• BuildKit：更快更智能的构建。

太长不看

容器的大小不应超过代码库的大小。清理你的 Dockerfile 文件。使用缓存。看在 DevOps 的份上，别再复制整个代码库了。

错误#7：将秘密提交到 GitHub

这件事至今仍让我耿耿于怀。

我当时正在开发一个新功能，需要测试一个 API 集成。我把 API 密钥放进一个.env文件里，
然后运行了命令git add .
，提交了代码，
最后推送到了一个公共仓库。

我没注意到。但GitHub注意到了——然后我就收到了那封可怕的邮件：

⚠️ 我们在您的公共存储库中检测到了一个密钥……

我慌了。我撤销了密钥，轮换了密钥，删除了提交记录，并重写了历史记录git filter-branch。
但为时已晚——密钥在几分钟内就被窃取了。

那一刻我意识到：Git 不会忘记，互联网也永不眠。

我学到了什么

• 秘密不应该出现在代码中。永远不应该。无论是在代码中.env，还是在其他任何地方config.json，哪怕是“意外”出现也不行。
• 使用环境变量，并使其不纳入版本控制。
• 使用能够自动加密和轮换的密钥管理工具。
• 推送代码库之前务必先扫描代码库。

避免泄露秘密的工具

• git-secrets：扫描提交以查找密钥。
• 松露猪：发现历史中的秘密。
• 护身符：用于防止敏感文件提交的预提交钩子。
• Doppler、Vault、AWS Secrets Manager：安全地存储、管理和轮换密钥。

太长不看

泄露机密信息不仅仅是失误，更是一起安全事件。务必像对待密码一样对待您的凭证：隐藏、保护，并且永远不要添加版本号。

错误 8：日志？什么日志？

在我刚开始从事DevOps工作的时候，我把日志当作杂物抽屉里的东西。它们确实存在——散落在不同的服务器上，以不同的格式记录，就像被遗忘的怪物一样，隐匿在黑暗中。

每当出现故障时，我都会通过 SSH 连接到服务器并运行以下命令：

tail -f /var/log/whatever.log

……然后就只能祈祷了。
如果那个文件里没什么有用的东西呢？那就换下一个。如此反复，直到找到问题所在——或者干脆放弃，重启服务，希望它能自行修复（但通常不会）。

没有日志聚合，没有搜索，没有警报。只有感觉和grep。

我学到了什么

• 集中式日志记录不是“锦上添花”，而是必不可少的。
• 规范日志格式，无论是 JSON、结构化日志还是其他任何格式，都要保持一致。
• 日志应该可以搜索，无休止地滚动查找日志并不能解决故障。
• 设置日志警报，不要等到别人告诉你哪里出了问题。

Log Nirvana 的工具

• ELK Stack（Elasticsearch、Logstash、Kibana）：经典的日志记录平台。
• Loki + Grafana：轻量级日志聚合，搭配强大的仪表盘。
• Fluentd：可在多个系统上运行的日志收集器。
• CloudWatch Logs：适合喜欢受苦（但仍然有用）的 AWS 用户。
• Logtail：简洁的云端日志记录工具，即时设置。

太长不看

如果你还在逐个查看日志文件来调试生产环境问题，那你就像生活在日志黑暗中。集中管理、整理和搜索你的日志——因为生产环境没有时间浪费在这种事情上grep -r doom。

错误九：事事都要手动操作

我以前所有事情都是手动完成的。

启动 EC2 实例？打开控制台。
配置安全组？点击。
设置新服务？点击……点击……滚动……点击。

每个任务都像是一场穿越用户界面迷宫的小冒险。起初感觉很快。但ClickOps的问题在于：
它无法扩展，没有
文档，
而且容错率极低。

有一天，我需要从头开始复现我们的测试环境。我心想：“没问题，我照着以前的方法做就行了。”
结果，我记不清以前都做了些什么。
你猜怎么着？新环境出现了一个奇怪的bug——而这一切都源于一个我根本找不到原因的配置错误。

我学到了什么

• 手动操作 = 不可靠。如果无法用代码重现，就不能相信它。
• 自动化就像你的备用大脑，脚本永远不会遗漏任何步骤。
• 基础设施即代码 (IaC)可以节省时间、防止错误，并让您对设置进行版本控制。
• 通过代码进行文档化，才是真正能够保持更新的文档化方式。

与ClickOps分手所需的工具

• Terraform：定义、部署和版本控制云基础设施。
• Ansible：实现跨服务器的自动化设置和配置。
• Pulumi：使用真正的编程语言的 IaC。
• AWS CloudFormation：如果您完全依赖 AWS 平台，那么它非常适合。
• 额外提示：即使是bash脚本和 Makefile 也比点击 30 次然后祈祷好运要好得多。

太长不看

手动设置既不可靠又无法重复。尽可能实现自动化，让代码胜于点击操作。

错误十：试图（默默地）当英雄

刚接触DevOps的时候，我脑子里一直有个想法：
真正的工程师都是自己解决问题的。
所以当我遇到难题时，我没有寻求帮助。我埋头苦读日志、文档，甚至翻阅2013年的Stack Overflow帖子，结果越陷越深。几个小时过去了，几天也过去了。

最糟糕的是什么？很多时候，解决方案都很简单，比如我漏掉了一个标志位、少了一个分号、权限问题等等。
这些问题队友十秒钟就能指出来。

但我太担心显得自己缺乏经验，所以没敢说：
“嘿，有人能和我一起看看这个吗？”

我学到了什么

• 不寻求帮助既浪费时间，也保不住面子。默默承受痛苦没有任何好处。
• 即使是资深工程师也会寻求帮助。最优秀的工程师都是团队协作进行调试的。
• 结对编程是一种作弊方法，尤其适用于复杂系统或未知领域。
• 及早提问比无休止地搜索要节省更多时间。不要成为自己的绊脚石。

可倚重的文化工具

• Slack 还是 Teams？请在公共频道提问。其他人也能从答案中学习。
• 每日站会？尽早提出遇到的障碍。
• 使用Tuple或VS Code Live Share等工具进行结对编程。
• 事后把你学到的东西写下来，既能帮助他人，也能提升你在公司内部的声誉。

太长不看

你不需要单打独斗。DevOps 是一项团队运动。多提问、多协作、多学习，你的进步速度会比单打独斗埋头苦干快得多。

结论：从混乱到自信

如果说我从所有这些错误中学到了什么，那就是：DevOps 与其说是追求完美，不如说是构建能够容忍不完美的系统。

刚入行的时候，我以为犯错就意味着我能力不够。但事实是，每一次事故、每一次部署失败、每一次手心冒汗的回滚，都是我成长的必经之路。
你不可能通过避免犯错成为资深人士，而是通过从错误中吸取教训、帮助后来者避免重蹈覆辙来获得成功。

所以，对于年轻时的自己，以及所有正在经历创业初期的人，这才是真正的教训：

• 破坏东西（但不要戳）。
• 尽早提出问题。
• 一切自动化。
• 请阅读文档。
• 为了保证系统正常运行，千万不要在周五进行部署。

这十个错误让我成为了一名更优秀的工程师。它们在我身上留下了伤疤，如今这些伤疤就像一份宝贵的文档。如果你能因为这篇文章而避免哪怕一个
错误？ 在我看来，那就是莫大的胜利。

持续学习。持续（安全地）探索。持续发布。

本月博客赞助商：UpCloud

UpCloud是一家总部位于芬兰的欧洲云托管服务提供商，以其卓越的可靠性、速度和性能而闻名。UpCloud 专为追求控制力和效率的开发者打造，提供强大的基础设施、透明的定价和遍布全球的数据中心。

UpCloud为我们的读者提供价值50 欧元的免费额度，可享受30 天的免费试用期。使用此注册链接或在注册时使用优惠码DEVLINK50即可体验该平台。

试过了吗？请在下方留言，我们很想听听您的反馈和体验。