全体構成図の重要性（１）
全体構成図やシステム構成図って皆さんが担当するシステムに用意されていますか？
一応ある、というところは多いですが、全体を記載しても荒すぎたり、逆に部分部分の記載になっていて網羅性がなかったりと、中途半端な構成図っていっぱいあると思います。
構成図は、その目的によって記載する内容は大きく異なりますよね。
であれば、どんなものがあればいいのでしょうか。
今回はオンライン処理（リアルタイム処理）について考えてみたいと思います。
全体構成図は何に使うものか、を考える
構成図を使う場面って、どんな時でしょうか。
私が使うのは、ほぼ「障害のとき」です。
もちろん、システムの最初に勉強するときにも使いますが、そのあとの保守で必要になる障害のタイミングで理解するために必要となっている、と感じます。
では障害のときに何を知りたいのか。もちろんそのシステムによってはいろいろありますが、主に以下のような内容ではないでしょうか。
業務影響はどれくらいか
周りのどのシステムに影響がでるのか
暫定対応は何をするのか。その対応をするとなににどれくらい影響がでるのか。
もちろん、それぞれの会社で方針があるはずなので、他にもあると思いますが、一般的にこんなものかな、と思います。
構成図は、この判断に役立つように作ればいいのです。
何を書くか
では一つ一つ、どういった情報が必要か確認していきましょう
業務影響はどれくらいか。
例えば、Web/AP/DBの3層構造のシステムがあって、それぞれWeb:2台、AP
3台、DB2台で動いているとします。APサーバの1台に何かしらの障害が起きたときに、そのAPサーバは使えなくなりました。業務影響ってどうなりますか？
APサーバは並列で構成することが多いので、業務の1/3の取引ができなくなる、もしくは処理が他の2台に集中するのでその分トランザクション量が増えレスポンスに影響が出る可能性がある、といったところでしょうか。
次の例。
DBサーバで障害がおきました。DBサーバは2台でが稼働/待機構成です。その場合の影響はどうなりますか。
この場合、たとえば、全トランザクションがいったんDB接続ができなくなるのでエラー（処理によってはリトライだったりロールバック）が置きます。
APサーバから再接続されるまでの数秒間の取引もエラーになる、といったところでしょうか。
とすると書くべきポイントは見えてきました。
APサーバは
3台ある。
それぞれが並列に稼働している。
おそらくその処理に違いはない。
障害時は、そのAPサーバに振り分けがされないような仕組みになっている。
ことが分かるように記載されていれば、構成図を見ると一目瞭然で分かるということになります。
DBサーバの障害の例ではどうでしょうか。
2台構成
稼働待機構成
（稼働系に障害がでると業務影響はでるが、待機系に障害が起きても業務影響はない。）稼働待機が切り替わる仕組みになっている
APサーバからの接続は通常稼働系のみにつながっており、待機系がアクティブになったときに貼られる仕組みになっている
こんなところです。
周りのどのシステムに影響がでるのか
これは、一覧（Excelの表）で用意しているところも多いと思います。でも構成図でインターフェイスのすべてを記載してしまうと、絵がビジーになってしまい、逆に見づらくなってしまいます。
私のお勧めは、全体構成図には、接続先システムに向かって線をかいて、その線の上で鵜後している細かな業務は一覧を見てもらう方式です。
プロトコルごとに線を描くのもありですが、そこは絵の混み具合で判断していいかと思います。
なぜ、このレベルで全体構成図に落すかというと、障害があったときにの思考として、（１）どこに影響があるのかを理解して、（２）次に何の業務に影響あるか、というロジックで進むことが多いからです。
システム屋さんは、基盤的なところから抑えて、その後アプリで確認する、というのが、なんとなく身についている人が多いんですよね。
続きは次の投稿で。