停電・災害対策としてのサーバー停止手順: 依存関係の視覚化

Visio 使っていますか?

ここでは、MSN の運用チームでやっていた経験を基に箇条書きですが留意点を記載してみたいと思います。

マイクロソフト各製品の安全なサービス停止の手順については、公式情報が出ています。

パソコンやサーバーの停電対策、節電機能、その他、役立つマイクロソフト・サポート技術情報: http://support.microsoft.com/gp/jishin-taisaku/ja#tab0

マイクロソフト製品群のバックアップ、障害対応および節電に関する情報: http://technet.microsoft.com/ja-jp/gg703325

なぜそれ以外にここに書いてみるかといえば、これらは「個々のPC、サーバーレベル」であって、サービスとしての停止手順ではないからです。

皆さんのシステムで、単独のサーバーで動作しているものは少ないのではないでしょうか?

最近のシステムは、ほとんどがWebベースで、Webサーバー(HTML, Silverlight等のUIもWebサーバーから配信されます)とDBサーバーから成り立っています。ここで、DBサーバーを先に停止させるとどうなるでしょう?ユーザーにはエラー画面が表示されると思います。B2B系のシステムの組み方に設計上の漏れがあり、リクエストがSOAPなどの画面が無い形態のWebサーバーであった場合、Webサーバーが処理を受け取った段階で、処理完了にしている事も考えられます。

またそのシステムは他のシステムに依存している場合もあるのではないでしょうか?EAI/ESBシステムが停止すると何が発生するでしょう?

そして、システムは構築時点と現在とて置かれている状況が異なると思います。重要性、依存関係が複雑になっていないでしょうか?

ですので依存関係を把握し、その順番で停止させる必要があるのです。

以下が、その例になります

  • システム同士の依存関係ダイアグラム: ECシステムとCRM。EAIシステムと会計システム、など。場合によっては社外のシステムと連携している場合もあるでしょう
  • ネットワークダイアグラム: ネットワークの影響は甚大です。
  • システムアーキテクチャダイアグラム: 単一システムの論理的な構成になります。物理サーバーとは別で、システム自体を理解するためのものです。WebサーバーとDBサーバー。など
  • データフローダイアグラム: 上記に加えて、どのデータがどこで作成されて、どのサーバーにて加工されて、どこにてユーザーに提供されるのか。データのCRUDをシステムアーキテクチャダイアグラムにマップしたようなイメージでしょうか?これにより、不用意なデータのバックアップを最小化します。全部のサーバーの「データ」のバックアップが本当に必要かの判断になります
  • 物理サーバーダイアグラム: 1つのサーバーに複数のシステムが動いている場合も、最近のサーバー統合(サーバー仮想化を含む)で増えていると思います。

これらによって、該当サーバー、システム停止時の影響を把握します。結果、MTTRを考慮してのバックアップ・リストアの計画が立てられると思います。

皆さん運用におけるドキュメント整備すすめていらっしゃると思いますが、運用においては極力人依存を最小化する試みを考慮いただければと思います。人のフェイルオーバーですね。

改めて、Visio使っていますか?


ご参考:

Microsoft Operations Framework: Reliability Service Management Function: http://technet.microsoft.com/en-us/library/cc506069.aspx

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中