全体構成図の重要性（２）

こちらの記事の続きです。

何を書くか

暫定対応は何をするのか。その対応をするとなににどれくらい影響がでるのか。

これが実は、一番の肝だったりします。

障害対応のパターンってある程度設計時に考慮していたり、他のシステムんリカバリ方法をまねたりしてある程度方針ってあるだろうと思います。
その情報は、とても大切です。

暫定対応は、私の経験上、だと

1. サーバ毎（OS毎）停止、もしくは再起動する。

2. クラスタのグループごと停止/再起動する。

3. ミドルウェアの管理グループごとに停止/再起動する

4. OSのプロセス単位で停止/再起動する

5. 業務機能ごとに停止/再起動する

のいずれかになります。
根本原因がわからない状態でも回復させなければならないのですから、ある程度ヤマ勘を張って対応する必要があります。
となれば、障害になっている部分を再起動するのが手っ取り早いのがコンピュータの世界。これはきっと誰もが同意してくれると信じています。
その再起動の単位がなんなのか、というのが上記の例となります。

全体構成図も、その再起動単位の粒度まで落として箱を書けば、影響もわかりやすいですし、判別もしやすくなります。
私は２か３の粒度になりますね。
４のプロセス単位も悪くはないのですが、昨今ミドルウェア系のプロセスも非常に多く起動しているので、管理に限界があると思われます。なので、おすすめは２や３のレベルになるのです。

他に記載するもの

接続線

つながっている線は必須です。どことどこがつながっているのかを正しく記載します。
サーバ同士がつながっているのはわかりますが、先ほどの粒度ごとにどこにつながっているかを記載する必要があり明日。

負荷分散

負荷分散がかかっているのであれば、それも記載すると一層いいかもしれません。ランドロビンにしているのか、傾斜をかけて分散しているのか。
なども記号にするとわかりやすいですね。

すべてを記載する

漏れがないように、運用系（監視とかバックアップとか）も含めて記載しておいたほうがいいです。

これだけでもダメです

今回は、サーバ処理に限定しているのですが、実はほかにも必要なものがあったりします。

NW系

NW障害には、これだけでは足りません。
ＮＷだと物理接続が重要になってくるので、今回説明した論理的な接続だとあまり役に立たないためです。
（ただし、ＮＷ機器の障害の場合は、その配下につながっているシステム一覧が出せるようになることが必要です。）

クライアント系

複雑なクライアント処理がある場合は別だししてもいいのですが、代表的なクライアントは、全体構成図に入れておくほうがいいです。
端末も社内ＮＷ内からアクセスするものなのか、インターネットからアクセスしてくるものなのか、それとも専用線のようなものがあるのか、サーバへの接続元がイメージできるように記載することが必要です。

一枚に収める

できれば1枚の紙に記載すし、一覧ることが必要です。
A3で何かあったときに印刷して、張り出して共通認識を持つことが大切です。し、どんな障害のときでも１枚に

最後に

全体構成図は、

• 運用を想定して、設計書の中につくる

• 一覧性があること

• 網羅性があること

• 視覚的に、わかりやすいこと

が大切です。
設計書として表にしていることは多いでしょうが、それを視覚的にわかりやすく図にすることは、障害の説明にも使えますし、共通認識が持ちやすくなります。
関係者で共通認識を持つことできっと障害対応もスムーズにいくはずです。