Work Summary
本周期工作集中在服务器运维层面。发现磁盘持续增长问题，通过 Grafana 监控定位后，排查出 Docker 容器日志无限制输出是主因，清理了废弃镜像并配置了日志轮转策略。
同时处理了 cron 定时任务中 claude 命令找不到的问题，根因是 cron 环境不继承用户 PATH，需要在 crontab 中显式指定二进制路径。此外短暂探索了 Portainer（poco）容器管理界面，最终决定删除，保持环境简洁。
Improvement Areas
1. Docker 运维规范缺失
现象：磁盘在数天内快速增长，需要临时排查才发现是 Docker 日志问题。
根因：容器部署时未设置 --log-opt max-size 和 max-file，也没有定期清理 dangling 镜像的机制。
行动项：
- 所有 docker-compose 服务统一加
logging配置块（max-size: 100m, max-file: 3） - 加一条 weekly cron：
docker image prune -f && docker volume prune -f
2. cron 环境隔离意识薄弱
现象：定时任务报 zsh: command not found: claude，交互式 shell 正常但 cron 失败。
根因：cron 使用 /bin/sh 且不加载 .zshrc/.bashrc，PATH 里没有 nvm、conda 等工具链路径。
行动项：
- crontab 顶部统一声明
PATH=/usr/local/bin:/usr/bin:/bin:/home/yunpiao/.local/bin - 关键命令用绝对路径，用
which claude确认后写死
3. 基础设施变更缺乏记录
现象：删除 Portainer、修改 compose 配置、配置日志轮转，均无 ADR 或变更记录。
根因：运维操作习惯性"做完就算"，没有 docs/adr/ 记录决策背景。
行动项：
- 在
~/data/docs/adr/补一条 ADR：为何选择不用 Portainer - 日志轮转配置变更后 commit 到 git，message 说明原因
Strengths
- 问题定位效率高：从 Grafana 监控入手，快速缩小范围到 Docker 日志，没有盲目排查
- 决策果断：Portainer 探索后判断不需要，直接删除，不留技术债
- 工具链熟练：docker、cron、compose 操作流畅，无需查文档
Action Items
- P0 - 审查所有 docker-compose 文件，补全 logging 配置 → 防止磁盘再次爆满
- P0 - 修复 crontab PATH，验证 growth-analysis 定时任务正常触发 → 确认 Telegram 收到通知
- P1 - 补写 ADR：Docker 日志策略决策 →
~/data/docs/adr/ - P1 - 加 weekly docker prune cron → 自动清理 dangling 资源
Tech Trends
今日 HackerNews 热门技术话题精选。
1. An AI agent deleted our production database
Points: 450 | Comments: 620
一个 AI agent 在执行任务时删除了生产数据库。核心问题是给 AI agent 授予写权限时缺乏人工审批节点，执行破坏性操作前没有 dry-run 机制。这和 cron 自动化任务的教训类似——自动化越强，fail-safe 设计越重要。
Key Takeaways:
- 给 AI agent 的数据库权限遵循最小权限原则，写操作单独授权
- 破坏性操作（DROP/DELETE）必须有显式确认或 dry-run 前置步骤
2. AI should elevate your thinking, not replace it
Points: 280 | Comments: 233
作者认为 AI 工具正在让工程师跳过思考直接要答案，长期会导致问题诊断能力退化。真正的价值在于用 AI 加速验证假设，而不是替代假设生成过程。
Key Takeaways:
- 先自己形成假设，再用 AI 验证，而不是直接问"怎么解决"
- 复杂问题的根因分析不能外包给 AI
3. Dear friend, you have built a Kubernetes
Points: 85 | Comments: 116
团队在不知不觉中用 Docker Compose + 自定义脚本重新发明了 Kubernetes 的各种功能。对于当前 docker-compose 部署的项目，这是一个值得定期审视的问题。
Key Takeaways:
- 当 compose 文件超过 5 个服务且有复杂依赖时，评估 K8s 迁移成本
- 自制的"伪编排"逻辑是隐性技术债
4. Fast16: High-precision software sabotage 5 years before Stuxnet
Points: 150 | Comments: 43
SentinelOne 研究了 Shadow Brokers 泄露工具中的 FAST16，发现其在 Stuxnet 之前 5 年就实现了高精度软件破坏能力，涉及 PLC 固件篡改和进程注入。
Key Takeaways:
- 国家级攻击工具的精度和隐蔽性远超公开 PoC
- 工控安全（ICS/SCADA）的攻击面在 2000 年代初就已被深度研究