公開後30日を無理なく運用する
一人で運用すると、すべての数字と通知を追いかけたくなります。しかし、確認項目が多すぎると、本当に必要な異常を見落とします。公開後30日は、利用者への影響を中心に、見るものと時間を先に決めます。
最初の一週間は入口から結果まで見る
毎日短い時間を取り、中心となる利用の流れを確認します。
サイトへ到達できるか
中心操作を完了できるか
エラーが急に増えていないか
問い合わせに共通点がないか
読み込みや操作が極端に遅くないか
数字が変わったときは、すぐに機能を追加せず、利用者への影響と再現条件を記録します。GoogleのSRE Bookでは、監視をリアルタイムの定量データを収集、処理、集約、表示することとして整理し、外から見た動作と内部の状態を区別しています。小さなプロダクトでも、利用者が使えるかという外側の確認を忘れないことが大切です。
通知は行動できるものに絞る
通知を受けたとき、自分がすぐに判断や対応をできるかを確認します。できない通知は、週次の確認へ回すか、条件を見直します。
緊急通知には、少なくとも次を含めます。
何が起きているか
どの利用者や機能に影響するか
どこを確認するか
一時的に戻す方法があるか
通知の数ではなく、必要なときに気づき、迷わず行動できることを目標にします。
毎週、事実と仮説を分ける
問い合わせや行動記録を、事実、原因の仮説、次に試す変更へ分けます。
事実: 初回入力の途中で戻る人が多い
仮説: 必須項目の理由が分からない
変更: 説明を一行追加し、一週間比較する一度に複数箇所を変えると、何が効いたか分かりません。影響が小さく元へ戻せる変更から試します。
30日目に続け方を決める
月末には、利用者数の大小だけで判断せず、次を見直します。
誰のどの困りごとを解決できたか
繰り返し起きた失敗や問い合わせは何か
維持にかかった時間と費用はどれくらいか
続ける、絞る、止めるのどれが妥当か
停止や縮小も、運用の失敗ではありません。利用者データの扱い、告知、書き出し手段を確認し、安全に終えられる計画を持つことで、次の開発へ進みやすくなります。
30日分の運用カレンダーを作る
公開前に、確認時刻と上限時間を予定へ入れます。常に画面を見る運用は続かないため、頻度を分けます。
| 時期 | 確認すること | 終了条件 | | --- | --- | --- | | 公開直後 | 中心操作、決済、通知、エラー | 重大な失敗がなく一周できる | | 1〜7日目 | 到達可否、失敗率、問い合わせ、費用 | 毎日15分で記録を残す | | 2〜4週目 | 繰り返す問題、利用継続、性能傾向 | 週一回、一変更だけ選ぶ | | 30日目 | 価値、維持時間、費用、継続判断 | 続ける・絞る・止めるを決める |
数値には平常時の範囲と、対応を始める境界を付けます。「エラーが増えた」ではなく、「中心操作の失敗が直近の通常範囲を外れ、複数利用者で再現した」のように判断できる形にします。利用者が少ない時期は割合が大きく揺れるため、件数と具体的な失敗内容も併記します。
障害時の最初の15分を決める
異常に気づいたら、新機能の修正と混ぜず、影響を小さくすることを優先します。
何が、いつから、誰に起きているかを書く
自分の端末だけでなく外側から再現を確認する
直前の変更を止めるか、既知の安全な状態へ戻す
利用者へ伝える必要があれば、事実と次回更新時刻を案内する
復旧後に原因、検知、再発防止を短く残す
推測を事実として告知せず、分かっている影響と回避策を先に示します。通知、復旧、振り返りを同じ記録へ残すと、次の異常で迷う時間を減らせます。