看看项目背后的故事，
不只是技术名称。

我编写的训练应用。 在应用中选择动作，直接录入训练日期以及每组的重量和重复次数。保存的训练数据用于历史记录、训练量计算和进度图表。公开的 Kraftwerk 页面提供这些训练历史的只读展示。 了解 Kraftwerk 的开发故事 →

数据需要上下文。 训练指标、总训练量、步数和时间范围选择，让单次训练可以放进每周、每月的变化中理解。

为后续改进留出空间。 CSV 与健康数据导入让历史记录可以迁移。展示层则能增加新指标，而不必重写底层记录。

KRAFTWERK / MISSION LOG

从纸笔记录到看见进步。

一款源于个人训练需求的应用，走过四个阶段。

01手写笔记02数字化03自己的应用04现在的进步

阶段 1 / 4

一切从笔记本开始。

找不到合适的训练应用，我便手写日期和次数。这是我的原始俯卧撑记录。

小环境，越来越多的盲点。 最初只有少量服务器和分析日志的脚本。随着平台增长，这种方式既难以扩展，也难以应对复杂度。更重要的是，它是被动的：反映的是已经发生的事情。

老板和客户不是监控工具。 为什么要等故障发生后才发现？如果最先报告问题的是管理者或客户，运维响应就已经晚了一步。故障之外，团队在公司内部和客户心中的信任也会受影响。

典型例子：即将到期的 TLS 证书。 2000 年还没有今天这样的自动续期工具，Let’s Encrypt 到 2015 年才出现。我们需要提前监控证书到期时间，而不是等连接失败才发现。即使后来使用了自动续期，证书要求和签发机构可能各不相同，监控仍然不可少。

发现、通知并保留数据。 最初我们选择了 Nagios 和 Zabbix。检查要能发现问题，告警也必须送达有能力处理问题的人，尤其是全天候待命的 24/7 值班响应团队。当时出于成本考虑，网站还没有高可用架构，及时发现和快速响应就格外重要。当然，监控本身不能消除停机风险。后来，通知渠道逐渐包括短信、WhatsApp 和 PagerDuty，并不是说这些工具在 2000 年就已全部使用。

从单次告警到趋势。 记录性能指标，可以研究负载、延迟和可用容量如何随时间变化，而不仅是看一个告警。后来，Grafana 和 Checkmk 也加入工具集。目标始终是更早发现恶化，并用数据理解系统的发展方向。

不变的原则。 监控不仅是一组仪表盘。它应该让团队有机会在别人必须指出问题之前采取行动。

历史来源：Let’s Encrypt 首个公开证书公告（2015 年）。