社内ITシステムを構築・運用するのに最重要な3つのポイント - たごもりすメモ
2については同意しないかな。社内システムは費用対効果で調整しやすいのでむしろダウンタイムに余りこだわらない方がいい。拡張性や柔軟性とのトレードオフも生じるので何を優先するかによる所だけど。予算次第かな
2015/01/22 16:55
よんだ。
書いてある事は実現できる事に越した事はないのだけれど、現実的には様々な条件との折り合いが必要になります。
当然、社内ITシステムの予算は責任者が予算案を作成し、承認をもって開発・運用するのですが、この辺りは経営陣の理解のレベルにより、どの程度の予算が割かれるか分かれる所です。
私はコメントで２については同意していないのですが、理由としてはダウンタイムをなくすという行為は基本的にコストに直結します。
凄く単純な事を言えば、例えば、バックアップ。
Windows系のバックアップで単純な構成ですと、シャドウコピーを用いた日中帯のバックアップ措置と、夜間帯に実行するLTO等へのバックアップの２段階が想定できます。
厳格に言えば、LTO等へのバックアップ後のボリューム管理やDRの運用等もはいりますので、もっとありますが。
単純に行うのであれば、シャドウコピーを全てのボリュームで有効にし、その上で夜間バックアップも行うべきですが、これは、必ずしも必要条件ではありません。
そもそも全ボリュームでシャドウコピーを行うという事はそれだけのリソースを必要とします。それは年間の運用コストでみれば、利用者の増減に関わらず一定の負担を継続的に負担し続ける事となります。
これは直接的なメンテナンスによるダウンタイムとは違う例ですが、このケースでも、結局は費用対効果をどうするかという事に尽きます。
もしも、データの保全性を優先するという方針であるならば、ロストする可能性をゼロにするべく、DRまで想定し設計・運用すべきでしょう。
もっとも、そもそも完全な保全性をもとめるなら、シャドウコピーではない手段、つまりデバイスレベルで実現する話なので、例としても少しおかしいですが…
しかし、もしも前日営業終了時点のバックアップが存在すれば良い、という判断が経営サイドを通して現場と合意がはかれるのであれば、迷わずシャドウコピーは少なくとも頻度を少なくすべきです。
このような判断はあらゆる部分で生じます。
私は、無停止にこだわるよりも、安全に計画停止が的確に行えるシステムを第一に構築する方が美しいと考えています。
リスクマネジメントにおいて、「安全に停止できる」という事は、「停止しない」という事よりも私は重要だと考えているからです。
「安全に停止する事ができる」というのは、単純な手順の整備だけでなく、緊急時の状況判断と、その情報をもとにしたタスクに対する優先順付けにはじまり、最終的には、業務を見渡した上でのシステムリスタートから業務再開までの優先順位の判断と計画立案及び実施とその事に関する調整までが着実に行える事を保証するというものです。
当然、「停止しない」というシステムや「サービスを低下（一部の機能に制限をつけても全体のシステムは稼働する）させても停止はさける」という事は非常に重要です。
しかし、その事が、もしも会社のビジネスにおいて最優先事項（例えば、コールセンタービジネスにおいて、お客様情報やそれに付帯する取引情報のようなもの）に属するデータを取り扱うシステムでない場合、それは必須条件ではないという事を理解し、その上で、何を優先するべきか、例えば、自然災害等により緊急対応が必要となった瞬間、データの保全性の観点ではどの手順で何をすべきか、この事を明らかにし、そしてシステム部門の決定は、経営の決定と同じであるという事を全社的に理解し、場合によってはシステム部門長の判断により、無計画な停止も実施する事を容認する事の方が、ビジネス的に考えると有機的に働く事もあると考えています。
当然ながら、「停止しない」という事が安易に実現可能なもの（スケジュールサービスやメールのリレーサーバ、定期実行されるログの解析処理等）であれば停止を安易に想定すべきではありませんが、それらであっても「費用対効果」という側面で、社内ITシステム部門の人員数や日常的なタスク負荷等も想定し、ダウンタイムの許容範囲は明らかにし、それを全社共通の認識とする事は非常に重要だと考えます。
止まらない事を目指す事と同じぐらい、いかなる場合も、安全に、完全な停止と、迅速な再開が保証されたシステムを常に提供するという事は等価の価値をもち、私が経営サイドであれば、後者、つまり、停止・再開が保証されたシステムや体制の方が価値あるものと感じます。
まぁ、どのようなものを社内システムとして考えるかという点にもよりますが。
