はじめまして。私はとあるSIerで、とある大規模サービスのITサービスマネージャをやっています。相対しているサービスは歴史のある金融系サービスでベストプラクティスもさまざま取り揃えています。近年はクラウド化や一つの機能を提供するのに複数のサービスを組み合わせるなどして、サービスはどんどん複雑化するし、故障箇所はタテにもヨコにも増えており稼働率を稼働箇所の掛け算と考えると、残念ながら稼働率で捉えた信頼性を向上させるのが難しい状況です。
外部サービスを含めた横串でのサービスレベルの向上というのは、一つの重要なテーマですが、今回の記事はそっちではなく、故障発生時の迅速な復旧について書きます。私が相対しているサービスのうち、複数のサービスで故障の長時間化が発生し、問題になったためベーシックリカバリという早期復旧の手順整備に取り組んだ時の話です。
ベーシックリカバリとは
故障原因が特定／確定できない状況下において、故障原因を含むと思われる部位の状態を初期化することで、原因を除去し復旧を行う考え方
要は、試しに再起動やフェイルオーバをやってみるというやつです。
皆さんもやったことがあったりするのではないでしょうか？
ベーシックリカバリとして考えられるのはおおよそ以下の手段です。
1.再起動
2.リストア
3.機器交換
4.DRサイトへの切り替え
ベーシックリカバリの適用は案外難しい
メモリリーク、ファイルディスクリプタやプロセスが上限に達したなど、ポチッと再起動で治る場合は多いのですが、思い切って再起動するのは難しいです。仕掛かり中のバッチの復旧のさせ方や、状態の一貫性などあとで辻褄を合わせないといけない項目が想像以上に多く、頑張って復旧させたと思っても、2、3日後に実は一部がおかしいことが判明なんてこともあります。
サービス停止の長時間化は悪という共通認識
それでも最近は、サービスが少しでも止まると、新聞、ネットニュース、テレビなどシステム障害に関するニュースバリューが高いのかすぐに報道されます。技術者としては、原因究明を行い、原因を除去した上で安全に復旧させたい気持ちもわかります。
が、それはお客様ファーストの考えではありません。原因究明に走ると、作業者は作業に潜ってしまい、お客様への経過報告も滞りがちになります。
故障が起きたら、まずは以下を行う必要があるのです。
1.サービス提供状況の把握
2.速やかな復旧
3.お客様への情報提供
故障対応で潜るのも悪
私の相対するサービスは50程度あり、大規模な故障が起きると、開発、維持、営業と運用ですぐに100人以上が集まります。
原因がわからないと、調査も何をやったらいいのかわからず、それでも何かをやっていないと気まずいので、マネジメントやガバナンスの力が弱いと個々人が思ったことをやります。ログの調査、技術情報の収集などそれっぽいことです。効果のあるなしに関わらずです。。。なぜか？
役に立ってないと思いつつ、何かをやっていることで、エクスキューズができるからです。
しかしこれでは復旧に向けて一直線に動いているとはいえません
（この問題の対策は機会があれば記事にします）
ベーシックリカバリ手順の整備の意義
ベーシックリカバリ手順を整備する意義は、迅速な復旧の実現に他なりません。長時間停止は悪、故障対応で潜るのも悪という共通認識ができれば、みんな対処方法がわからないときにベーシックリカバリで行こうという共通認識が持てます。たとえ、仕掛かりバッチの復旧が大変でも、利用者向けのサービス提供をまずは復旧させることが優先なのは明白だからです。
手順書整備の目的は、運用担当者が復旧を行えるということです。
開発担当者が復旧できるではダメで、24/365サービスを多く抱える私の部門では、夜中に故障が起きて開発が駆けつけて対応すると2、3時間はすぐに経過してしまうので、
24時間張り付いている運用担当者ができることがとても重要です。
運用担当者ができるための手順ー標準化された運用受け入れ
50もサービスがある私の運用部門では、かねてから運用受け入れの手続きが決まっていて、手順書に対する要求事項も標準化されており、サービスごとに必要な教育はできるだけ小さくなるようにしています。
ベーシックリカバリにおいても、さまざまな構成のサービスの故障部位に対して、公約数となるようフロントエンド、バックエンドなどの要素ごとにグルーピングし、各サービスには統一された考えで復旧方法、手順を運用に示すことを要請し、運用担当者はどのサービスが故障しても、ベーシックリカバリと聞けば、ああ、あれをやるのかと頭の切り替えができるようにしています。
手順は作ったら終わりではない。実効性とメンテの問題
私たちの運用部門では、運用受け入れ会議というセレモニー？で正式に運用が承認されます。ここに至るまでに作成された手順は
運用部門で検証され、実際に打鍵され、作業時間や、オペミス回避の工夫など要求所用時間を満たしているか確認され、合格する必要がある
のです。
また、作成された手順書は陳腐化してはなりません。昔は変更管理の仕組みで陳腐化をカバーしようとしていましたが、棚卸しを開発部門に要求することと、運用部門から新しい要求事項への対応（例えば自動化に向けた準備のステップの推進）を行う中で、
必要な変更がなされているか定期的に検証する
仕組みを作り、開発部門に要求をしています。
緊急対応で暫定的に受け入れた手順を本格手順に叩き直すのもこの棚卸しの意義だったりします。
日頃の訓練の「やり方」の重要性
ベーシックリカバリに限らずですが、やると決まっていることが簡単なことでも案外できません。これは訓練を繰り返し、作業を分解し、一人一人できることできないことを把握し、組織として
どこが難しいのかを分析し、次の訓練では弱点にフォーカスして集中的にやることが重要
だと思います。
これまで訓練をやってきて効果が出ないと思ってる組織は試してください。1人1人評価することで、個人として頑張るところ、組織として引き上げる部分、フォーカスできるようになります。
もちろん営業も故障対応がある
訓練は開発と運用がやればいいのではなく、顧客アナウンスの面では営業に活躍してもらわねばなりません。運用部門が発出する故障報でカバーしきれな情報、細かな顧客からの問い合わせの管理、サービス停止の状況によっては返金対応や、会社としてのニュースリリースの掲載など営業部門も組織化されている必要があり、故障時に必要な体制を故障対策本部運営マニュアルとして定義して、それが実効的であるための確認を営業を含めた故障対応訓練として実施しておくことが必要なのです。
以上、ベーシックリカバリを通じて、私が故障対応で気にしていることも併せてお伝えしました。不定期にこのような発信ができればと思います。引き続きよろしくお願いします。