肝心な心得を記録するのを失念していましたので、以下、１．２章の心得です。
さて、それでは設問イ、章で言うと２章についての考察となります。
■設問イについて
流れ上、設問アの１．１が『起』、１．２が『承』なら、設問イは『転』のように思われます。
例によってH24（2012年度）の問１の場合だと、
◆２．重大なインシデント回復作業中のトラブル ８００字以上１６００字以内
◆２．１トラブル発生内容
”転”の章、つまり２．１章で、文章中で提示されている、基幹業務の障害から起こる、
全社認証基盤の停止、およびメールシステムの停止を起こすというものであるが、
それらの事前に用意した対策も”穴”があり、トラブルを引き起こし、それはどういう”穴”
なのかをここで論じるのだと思われる。
この内容は前の設問アで論じた前もって用意した対策の盲点が障害を引き起こすという事なので、僕が考えるに、例えば、よくある盲点として、自分は完璧だったときにおこる障害ですね。
え？作業は完璧だったら、障害とか起らないだろうって？
まぁ自分1人で最初から最後まで他に関係者が絡まないならば！です。
つまり、普通だったら数名のチームがいるばかりでなく、他の業者なども関係するとなれば、
色々な情報共有できなかった”穴”は少なからず存在してしまうわけです。
そうすると、事前に用意した対策に関して実は同じチームの中の人、もしくは他業者で影響した
かもしれない部分の周知がなかったら、間違いなく、なんらかの障害が出ると思われます。
そうですね。。。例えば同じチーム内であった場合は、
同じチームでも掛け持ってるやつがいて、そいつが途中で修正した他システムとの連携機能追加の周知が不完全な状態で周知されてしまったために、連携機能を忘れた状態でサーバ再起動を行い、連携機能障害を引き起こすとか・・・
または、連携先の他業者の場合、他業者側でも連携時間を変更してしまい、例えば夜８時までで連携を終わるのがその日はユーザからの要望で１０時まで連携時間を延長していたことが周知されなかったために、夜９時にサーバを再起動してしまい、連携停止で・・・とか。
まぁ複数の人が関わったために引き起こされる２次障害（トラブル）は盲点として格好のモジュールかなと思われます。（って実際に起こった場合を想定するとガチブルですが（苦笑））
◆２．２ トラブル発生時の関係者の協議
しかしながら、例によって対策を勝手気ままに論じるのではなく一定の流れに沿っての構成は
本文中で用意されており、2次障害（トラブル）に対する対策立案について、以下の指定があるので要注意です。
①その対策は安全で迅速である点に留意した内容で論じているか？
②その対策は、サービス再開としての検討方法は以下の検討観点で論じているか？
・サービスを全面的に再開する
→全面再開なので、もはや迅速性が懸念され、再開ポイント（個所）も増えて安全度も下がる？
・サービスを部分的に再開する
→部分的であるため全面よりも安全で迅速性は増すがその分、ユーザニーズに合ったサービス
であることが絶対の条件となるため、その見極めが大事と思われる。
・代替サービスの提供
→サービス自体の代替であるため、ユーザが違和感の無いサービス利用、ましてや使いずらいなどのクレーム等で利用頻度や信用を失うのは言語道断のため、代替えできるという絶対の自信と顧客と利用ユーザからの信頼実績があり、了承されている製品（サービス）が条件となるため、
日頃からそういった体制でいる以外はかなりリスキーな選択であると思われる。
といったような内容を対策に対する検討内容として論じる必要があるのですが、とにかく上記の架空障害の場合だと、基幹業務再開だけでなく連携データのリカバリも加わってしまってます。
今回のパターンで言うと、架空の１次障害も考えてませんでしたので考えてみます。
とにかく基幹障害のために、認証やメールなどが停止です。
停止したのか、停止させたかは書かれていないようですねぇ。
全社だったら、その影響でそうなった感じですが、後者はこれ以上影響を広めないための対応という風に分かれるのではと思います。
個人的にこの場合、特に触れられてませんから、どっちでもいいにしてほしいです（笑）
というのも、後者の場合でも良いなら、基幹が停まる影響で、認証を止めるのはつまりこれ以上使われると良くないという事、メールを止めるのも同じように自動でメール通知するような仕組みを止めるための臨時処置という風に考えれば良いかなと思ったからです。
前者のような連動で停止するのは、実際、基幹サーバ、認証サーバとメールサーバは別物ですから、同時にとまるのなんてサービス停止で連動するのは考えづらく、あるとしたら同一ネットワーク上に乗ってるであろうから、やはりネットワーク障害しかないと思われます。
そうなると、１次障害がネットワーク障害でそれから２次障害（トラブル）を起こさせるエピソードはなかなか思いつかないので、もし思い当たるエピソード有りましたら教えて頂きたいです。
いずれにしろ、基幹を停止させてこれ以上使われたら困るという状況はやはり容量的なものかなと。つまり例えば、基幹サーバ内のDBサーバのDB容量が枯渇してレスポンス遅延でAPサーバがフリーズしたとか、まぁそんな感じでまず基幹DBサーバがやばい状況となれば、ユーザがこれ以上システムでデータ更新されると困りますし、恐らくその画面もフリーズしてしまってますので、画面を使う前の認証画面で止めてしまえばよいので、認証サーバを止めて、DB情報を読み込んでメール送信する仕組みがダウンしてしまうので、メールサーバを止める必要も出てくるというのは、まぁ苦しいですが架空の障害ですので（苦笑）
で、この場合の予め予定されていた臨時対処が、認証、メールサーバも止めるであり、
その場合の対策が、DBの中身を整理・拡張、チューニングし、AP→DBサーバの順で再起動後に、基幹サービスの動作確認が問題なければ認証、メールサーバも起動させるという流れであったために上記に示す再起動時間の決定の盲点という感じで２次トラブル突入！というシナリオでどうでしょうか？
で、ここの問題の本題であるのはそんな想定外トラブルの立案をどうしたかとなります。
当然、サービス復旧が先決なわけで、なぜ連携が失敗したのかは後回しでしょう。
という事は、連携機能復活させるための連携データのリカバリを行い、データ同期をとる必要がありそうです。
ここで問われているのは関係者とどのような検討をしたかです。
まずは、データ同期の取り方と、その際の影響、そしてその作業の時間・他などを、基幹システム側関係者と連携側の担当を交え、お客様との間で至急、以下の観点で協議を行った。
今回の障害を基幹だけでなく連携機能も含めて全面的に再開させるか、その場合、
連携機能の再開は、リカバリとして基幹DB側の同期必須なので、基幹をそれまで止める必要がある。
連携機能は後回しで基幹のみ部分的に先行で再開させるか、その場合、
連携機能が停まった場合の連携側での機能が業務に影響しないかの確認が必要
もしくはサービス全体の再開を別のサービスで再開まで凌ぐ事が可能か、その場合、
別のサービスに詳しい担当者にも同席願って意見を聞く必要が出てくる。
さぁ、どうしましょう？というような感じで論じれそうです（笑）。
◆２．３ トラブルに対する対策立案
２．２で対策協議の結果、お客様から連携機能は、職員が業後に日計表を作成するためのDBサーバを兼任しているため、日中のリアルタイムな連携が滞ってもそれほど深刻でなく、業後で構わないと。
連携担当側の意見も、お客様の承認が取れれば、業後に基幹DBの利用止めて頂き基幹DBと連携側DBとの同期バッチを実行さえできればリカバリ復旧可能という事で合意できた。
既に前述の手順で基幹DBのデータは再起動され、基幹システムとしても復活しているが一応、認証およびメールシステムは止めたままである。
結果、日中は基幹システムの利用を先決とし、この後、まず認証サーバおよびメールサーバの起動で各システムの再開を行いそれとどうじに関係各位へのアナウンスを開始を行うという方針で関係各位全体で合意となった。
という事で、設問イはなんとか論じれそうかなぁって思われますが、ここで肝心な事がありました！！
そうです、字数制限です。
２章は、僕の場合、２．１～２．３の３節に分けましたので、８００字以上１６００字以上だと、
１節平均、最低２７０字くらいで収めればよいのかなと思います。
え？大変だって思いますか？でも、今、２．３の文だけで３３３文字ですのでもう越えてますので字数的にOKではないかと思いたいです（笑）
というわけで、次回は設問ウで、またH24の問1を例で考察してみます。
でわ。
0 件のコメント:
コメントを投稿