第0周：开启为期16周的 Platform Engineering 之旅

Source: Dev.to

规范 URL

为什么要这样做？

在接下来的 16 周里，我正朝着成为一名拥有真正 SRE 责任的后端/平台工程师的方向努力。这不是为了收集证书或完成教程，而是要构建真实的系统，有意让它们出错以观察其失败方式，并从这些失败中提取持久的经验教训。

有何不同？

典型的学习路径教你如何构建功能。我专注于更难的事情：学习如何运维系统。在你的笔记本上写出可运行的代码与在生产压力下保持服务可靠之间有着关键的区别。

• 与其仅仅构建一个服务，我更关注在出现问题时如何运维它。
• 与其只写代码，我会部署它，监控其行为，并在出现故障时练习恢复。
• 与其记忆模式，我会做出有意的架构选择，并在足够长的时间内与其后果共处，以直观地理解权衡。

计划

整个旅程分为四个阶段，每个阶段都在前一个的基础上构建。

第 1 阶段（第 1‑4 周）：服务基础

从构建后端服务开始，但要明确关注边界和契约。我从一开始就实现全面的故障处理，而不是事后补救。可观测性不是以后才添加的——它是基础的一部分，因为看不见的东西无法运维。

第 2 阶段（第 5‑8 周）：生产现实

将该服务部署到真实的云环境中，面对真实的成本和真实的故障模式。这时引入混沌工程：有意注入故障以观察哪些会崩溃以及如何崩溃。我会练习事件响应和恢复，培养在警报触发时保持冷静的肌肉记忆。

第 3 阶段（第 9‑12 周）：平台思维

将视角从单一服务转向可复用组件。我将定义服务等级目标（SLO）和错误预算，将可靠性视为具有明确权衡的产品特性，而不是理想的追求。这是开始像平台工程师一样思考的阶段：如何让其他工程师更容易构建可靠的服务？

第 4 阶段（第 13‑16 周）：沟通

认识到技术工作需要清晰的文档和解释。我会撰写技术文档，展示所有权，并创建对他人真正有用的文档。目标是打造一个作品集，展示的不仅是我能构建什么，更是我如何思考可靠性和运维。

Learning in Public

我所做的一切都将是可见且有记录的。每周，我会发布帖子，涵盖我构建的内容、出现的故障以及从中学到的东西。每个星期五是 Failure Friday（失败星期五），我会对当周的问题撰写诚实的事后分析。我会记录决策日志，解释为何选择某种方法而非另一种，包括我所考虑的权衡。所有代码都托管在 GitHub，任何人都可以看到实际的工作，而不仅仅是精炼的摘要。

三个问题

每个星期五，我都会回答三个特定的问题，以保持自律：

1. 本周出现了什么失败或差点失败的情况？
   如果我的答案是“没有”，那么我就知道自己没有足够努力，或者没有对自己诚实。

2. 是什么信号捕捉到了这次失败，或者应该捕捉但没有捕捉到的信号是什么？
   这迫使我思考可观测性，以及在真实的生产环境中我是否能够发现问题。

3. 哪一个人为决策最为关键？
   技术选择固然重要，但关键时刻往往取决于判断——我如何排序优先级、决定调查什么、何时选择简化而不是增加复杂性。

跟随

您可以在以下几个地方观看此过程：

• GitHub 仓库 – 包含所有代码和随开发进展的文档。
• Notion – 我的学习系统，用于跟踪进度和组织笔记。
• 此博客 – 每周更新。
• 电子表格 – 跟踪相对于计划的进度。

我想说明一点：我并不是以专家的身份开始这个项目。我在记录从一名称职的开发者成长为能够自信运营生产系统的平台工程师的过程。如果你也走在类似的道路上，欢迎在评论中分享你的经历。

下一步？

第 1 周将在明天开始。我正在搭建一个学习系统，以支撑接下来的 16 周。我会先定义我要构建的第一个服务，并在动手写代码之前先编写它的 OpenAPI 规范——练习先思考合同和接口的纪律。

如果这与你产生共鸣，请关注我的旅程。如果你也在学习类似的技能，或已经经历过这种转变，欢迎在评论中分享你的看法。