今、仕事でウェブサービスの信頼性向上のためにいろいろやってます。
もう少し具体的に言うと、サービスの障害にいかに対応していくかという点です。タイトルに「ウェブサービスの」と書きましたが、別にウェブサービスに限った話ではありません。もっと一般的な（IT以外の分野にも）言えることですが、仕事柄ウェブサービスに多く関わっているのでこう表現します。
今回は、障害対応関連について現在取り組んでいることをツラツラと書いていきます。とは言っても、きちんと対応している人・組織にとっては別に目新しい内容は何もありません。目からウロコが落ちるようなことも多分ありません。
そのへんを踏まえてお読みください。
4種類の障害対応
障害対応と一言で言っても、方法はいくつかあります。大雑把に分類すると以下の4種類でしょうか。
- そもそも障害を発生させない
- 障害が発生してもサービスは継続できるようにする
- 障害が発生したときに、迅速・適切な対応を行う
- 一度発生した障害は、次回以降より迅速・適切に対応できるようにする
そもそも障害を発生させない
アプリケーションの徹底したテストやミドルウェアの定期的な更新により、そもそも障害自体を発生させないというやり方です。当たり前ですが、できるのであればこれがベストな方法であることは言うまでもありません。
ミドルウェアの更新には「いつ」「何を」「どのように」更新するかといった手順書を用意しておきましょう。リリースサイクルが一定で定期的に更新する必要のあるものは、Slackなどにアラートを仕込んでおくと更新忘れがなくなります。
障害が発生してもサービスは継続できるようにする
冗長化や多重化、フェイルオーバーなどにより障害が発生してもサービスを正常に可動させるというやり方です。特にネットワークがらみの障害は完全に潰すことは不可能なので、こういった対応は必須です。
また、単一障害点が存在しないように設計する必要もあります。
障害が発生したときに、迅速・適切な対応を行う
どんなにアプリケーションをテストしても、システムを冗長化しても、障害は発生するときは発生してしまいます。それは仕方のないことですが、ここで大切なのは実際に障害が発生した際にきちんと対応できるような体制を整えておくことです。
技術的な点だけでなく、チームを組んでいるのであれば連携も重要です。障害発生時の第一報はどこに届くのか、エンジニアチームとサポートチームはどこでやり取りするのか、障害情報ページにはどんな内容をどのタイミングで載せるのか、顧客へはいつどのように連絡するのか、夜間・休日は誰が対応するのか…等々、チームとして必要なことは山ほどあります。
一度発生した障害は、次回以降より迅速・適切に対応できるようにする
障害復旧までに一番時間のかかる作業は、障害原因の特定です。外形監視などで障害が発生したことに気づいても、具体的にどこに問題があるのか（アプリケーションのどの部分か、どのマシンのどのミドルウェアに原因があるのか等）を特定するのにとても時間がかかります。
それを教訓として、次回以降同じ問題が発生した場合、より適切に対応できるようにしましょう。人間は学習する生き物です。同じミスを二度も三度もしては人間である意味がありません（←言い過ぎです）
具体的には、障害の原因がアプリケーションのバグであればバグを修正すれば二度と同じ不具合は発生しないはずです。それは「そもそも障害を発生させない」に繋がります。
また、ネットワーク障害のように今後も発生する可能性のあるものについては、直接の原因となった箇所に監視を入れ、異常を検知したときに「どのサーバーの」「どのミドルウェアが」おかしいのか、そして「どうすれば直るのか」を第一報のアラートとして通知すればより迅速に対応できるでしょう。もしできるのであれば自動復旧をするのがより望ましいことは言うまでもありません。例えば、デーモンの再起動で直る障害であり、問答無用で再起動しても問題ないようであれば異常検知と同時に自動的に再起動をかけてしまうなど。
どれからとりかかるべきか
以上の4項目はいずれも競合せず全て並立するものなので、理想的には全てを行うのが望ましいということは言うまでもありません。しかし、現実的には人員や予算等に制限があるため、全てに対応することは難しい場合が多いでしょう。
その場合、まずは3番目の「障害が発生したときに、迅速・適切な対応を行う」から始めましょう。どうやっても障害は発生してしまうものなので、発生したときにチーム内の統制がとれず、顧客への報告を忘れて信頼を失った…なんてことにならないよう、まずはチーム内できちんと連携できるような体制をつくることが大事です。
体制が整ったら、次は4番目の「一度発生した障害は、次回以降より迅速・適切に対応できるようにする」にとりかかりましょう。上でも書きましたが、直接の原因となった箇所に監視を入れ、異常を検知したら以下の情報を報告する仕組みを作りましょう。
- 異常が発生したマシン
- 異常が発生したソフトウェア（ミドルウェア・デーモン等）
- 異常の内容
- 異常の修正方法
- 異常に関するドキュメントへのリンク（新しく入ったメンバーのためのドキュメント）
今はSlackなどの便利なツールがあるので、障害通知用チャンネルなどを作って自動的に報告するスクリプトを組むことも難しくありません。
障害対応表
組織内で障害のノウハウを溜めるために、以下の項目をまとめた障害対応表を作りましょう。
- 障害発生日時（例: 2020年08月23日 09:00 JST）
- 障害の概要（例: HTTPS接続ができなくなった）
- 障害の直接の原因（例: SSL証明書の期限が切れた）
- 直接の原因を引き起こした要因（例: SSL証明書の更新を忘れた）
- 対応の内容（例: SSL証明書を更新した）
- 影響範囲（例: 全ての接続）
- 再発可能性の有無（例: 有）
- 今後の対応策（例: 有効期限の1ヶ月前にSlackに通知する / 有効期限の1ヶ月前に自動更新する）
Redmineなどに専用のプロジェクトを作らなくても、最初のうちはExcelやGoogleスプレッドシートでも十分活用できます。
おわりに
障害対応はUXだけでなく、サービスの信用にもかかわる大事な内容です。エンジニアは技術（開発）以外にあまり関心のない人も少なからずいますが、チーム内の連携も心得ておかないといざというときに慌てふためく羽目になります。
障害対応を疎かにすればサービスの信用が落ち、サービスの信用が落ちればひいては飯が食えなくなることを頭に入れて、しっかり対応していきましょう。
0 件のコメント:
コメントを投稿