業務系システムのインフラ運用から、Web系のアプリ開発に移って、今日はクラッシュ調査をしていました。
ふと、「そういえば障害対応どうしてたっけ？ 会社変わったけどやり方なんか使えるものあんのかな？」と思ったので、障害対応について書いてみます。
業務系システムの障害対応の流れ
初動
- 関係者に報告する
- 報・連・相
- 影響を調べる
- 必要があれば緊急対応
- 情報共有担当の人がいると捗る
- ホワイトボードに時系列で起こったことを書くとか
- これをやると、遅れて来た人が状況を把握できて、戦力になる
原因調査
- ログを調べる
- エラーメッセージ特定
- エラーメッセージで過去の障害事例を検索する
- ググる、または社内イントラを検索
- ロジックを追うorダンプを読む
- ダンプ読むのはあんまない？
- OSやプロダクトの問題と特定できたら、ベンダーに質問を投げる
対応検討（原因が特定できた前提）
- 復旧対応を行う
- 止めていたバッチ処理を再開する、壊れたDBをなおす、など
- 恒久対応策を検討する
- 発生確率が極めて低いわりに対応コストが高かったら、リスクを許容する判断もアリ
- ここまでできたら解散！
障害対応の難しさ
エラーメッセージの逆引きで原因を突き止めないといけないのが難しさだと思います。
類似事例が見つかればよいですが、調査が難航すると、テスト環境でひたすら条件そろえて再現テストすることもありました。
数日に渡って終電まで調査することも😱
で、モバイルアプリでは
Web系でも、基本的な対応の流れは一緒なのかなと思っています。
インフラだったらほぼ一緒かな？
DevOps体制でやっているので、保守部門が障害対応マニュアル引き継いでひたすら対応みたいな世界ではないです。
「できる人がやる」みたいな雰囲気は、障害対応のときは前職でもあって、
やむを得ないところもあんのかな〜と思いましたが、Web系だとより強い気がします。
モバイルだと、障害対応という言葉自体あまり使わない気がします。
対応するとしても、ストアにアップデートする必要があるので、業務系のシステム屋さんみたいな即対応が仕組み上できない面があります。
firebaseのCrashlyticsなど、アプリがクラッシュした情報を収集できるツールを入れて、
クラッシュ数が多いエラーを調査していって、次回のアップデートに盛り込んでいくスタイルになるかと。
障害対応というよりかは、バグ対応・クラッシュ対策という名前がつくみたいですね。
業務系と比べると、リスク許容度が高いです。
また、ユーザーの実行環境が多種多様であり、Android/iOSの内部仕様もDeveloperは知らないので、影響が小さければ無視するという選択は結構とられます。
（たとえばiPhone 3GS使っているユーザーの動作まで保証していられません。
どこまでサポート対象にするか、線引は微妙ですが）
エラーメッセージの逆引きから問題を特定する、という思考プロセスは同じです。
情報共有が活発なので、社内イントラよりもQiitaやStack Overflowが役立ちます。
英語情報が多いので、語学力があると有利です。
できなければ、Google翻訳が最近はだいぶ優秀なので、割り切っておまかせでもいいと思います。