为何我把个人作品集当作生产系统来运维

大多数开发者的作品集都是静态网站。而我的作品集有SLO。

这不是过度工程化。而是为了展示一种在面试中很难体现的特定技能：运维成熟度。

"生产级作品集"意味着什么

我的作品集网站 (sageideas.dev) 具备：

• SLO目标： 仪表盘可用性99.9%，遥测数据新鲜度<24小时，P95响应时间<500ms
• 故障演练： 4种故障场景，附带已测试的响应方案
• WAF速率限制： CloudFront Web ACL，附带攻击模拟证据
• OIDC联合身份： GitHub Actions → AWS，无需静态凭证
• 质量遥测： 实时仪表盘，实时拉取CI产物
• 安全凭证： IAM策略、威胁模型，以及每项声明的证据

为什么要费这个劲？

因为"我能构建东西"和"我能运维东西"之间的差距，正是高级岗位的立足之地。

初级工程师构建功能。中级工程师构建系统。高级工程师运维系统——他们思考故障模式、爆炸半径、成本、合规性，以及凌晨三点出问题时该怎么办。

通过把作品集当作生产系统来维护，我在展示：

1. 我在故障发生前就思考它——每个外部依赖都有降级方案
2. 我衡量真正重要的指标——SLO，而非虚荣指标
3. 我为下一个人做文档——运行手册、应急预案、架构文档
4. 我在安全上不偷工减料——哪怕只是一个作品集网站

故障演练模式

每个季度，我会演练4个场景：

每次演练遵循：检测 → 分类 → 缓解 → 验证 → 记录

演练报告在我的产物库中公开可见。

招聘经理注意到什么

当我面试高级/主管岗位时，我不谈论作品集的设计。我谈论它的运维：

• "这是我的SLO仪表盘。本月达到99.94%。"
• "这是我上周运行的WAF速率限制测试。100次请求/5分钟触发429状态码。"
• "这是IAM策略。Lambda只有一个权限：对单个键执行s3:GetObject。"

这能把对话从"你会写代码吗？"转变为"你能运维系统吗？"——而这正是年薪20万美元以上的岗位真正需要的。

如何自己动手

你不需要AWS。从小处着手：

1. 定义一个SLO——"本月我的网站可用性将达到99%。"监控它。
2. 添加一个质量门——在部署流水线中加入Lighthouse CI。如果性能下降，构建失败。
3. 记录一个故障模式——"如果我的API密钥过期了，会发生什么？"把答案写下来。
4. 运行一次故障演练——故意搞坏某个东西，练习响应流程。

目标不是完美。而是证明你思考的是生产环境，而不仅仅是开发环境。

相关系统：AI原生工作室实际构建什么 解释了为什么作品集同时被当作产品界面、操作系统和增长循环来对待。