ITプロジェクトの黄金律：無視すれば危険 - TechRepublic

シンガポールで執筆され、ロンドン ヒースロー空港の Wi-Fi 経由で 3 Mbps で TechRepublic に送信されました。

いかなるミッションクリティカルな状況でも、ルール、手順、チェックリスト、クロスチェックが不可欠であり、試行錯誤された方法が革新、推測、気楽な意思決定に優先しなければなりません。

同じことを何度経験していても、どれだけ自信があっても、必ず手順に従います。何度も確認し、手順を省略したり、行き当たりばったりで作業したりすることはありません。

この徹底した管理は、航空機の飛行と同様に、ソフトウェアやハードウェアの変更やアップグレードにも当てはまります。手順とチェックは、人為的なミスの可能性を減らすために存在します。なぜなら、何か問題が起きれば、それは深刻な事態を招くからです。

ですから、業界のマニュアルに「RBSの実践」という新しいフレーズが加わったとしても驚きません。英国のロイヤル・バンク・オブ・スコットランド（RBS）の顧客数百万人が数日間、現金と銀行サービスを失ったIT大失態について、無人島に住んでいる人でも知らない人はいないでしょう。同行は、この破綻による損失を補填するために1億2500万ポンド（2億ドル）を積み立てています。

英国金融サービス機構（FSA）は、RBSに対し、昨年6月に発生した一連の悲惨な出来事を調査するため、独立専門家を任命するよう命じた。調査結果がどうであれ、この出来事は明らかに自業自得であり、ITリヒタースケールで8に相当する。もし銀行が顧客データを損失していたら、9、あるいは大量絶滅に相当する事態になっていただろう。

何が問題だったのかを突き止めるのは不可能に思える。RBSのスティーブン・ヘスターCEOは、コスト削減が失敗の原因ではないと否定している。彼はエディンバラで管理されていたソフトウェアのアップグレードを挙げたが、真の原因が何であれ、誰かが見落とし、合意された手順から大幅に逸脱したアップグレードが実施されてしまったようだ。

業界のベストプラクティスと、何をすべきかを考えると、黄金律はシンプルです。

1. すべてのデータの少なくとも 3 つのバックアップ コピーを異なる物理的な場所に用意して、即時、高速、低速の回復機能を実現します。
2. オペレーティング システムとアプリケーションのすべてのバージョンのコピーを保持します。
3. 強力なバージョン追跡と制御を適用します。
4. すべてのアップグレードを記録して保存します。
5. 3 つの並列システムをオンライン、オン、オフ、コールド リザーブで実行します。
6. 新しいものをロードするときは、徹底的にテストしてください。
7. テストされていない、認証されていない、または監視されていないものをロードしないでください。
8. 当日までに、すべてをホットスタンバイにロードし、少なくとも 24 時間、可能な限りのテストを実施します。
9. すべてが正常であることを確認したら、ホット スタンバイを最前線のサービスに切り替え、古いオンライン システムをスタンバイ コールド モードに降格します。
10. コールド システムを起動し、ホット スタンバイ ステータスに昇格します。
11. 運用システムが安定していることが証明されたら、ホットスタンバイシステムとコールドスタンバイシステムのソフトウェアをアップグレードします。

言うまでもなく、これらの対策はすべて、十分な訓練を受けた経験豊富な人材によって管理される必要があります。これらのステップを、経験の浅いチームに委任することは絶対に避けてください。

RBS破綻の真の詳細が公表される可能性は低いが、多くの銀行、金融機関、企業が今後、特別な注意を払い、手続きを確認するだろうことは間違いないだろう。

RBS を行うことで生じる損害、悪評、恥辱は誰も望んでいません。

RBS が被った継続的なコスト削減と人員削減が、テクノロジー、システム、運用について何も知らない人々によって実行されたとしても、私はまったく驚かないだろう。

そして、他の銀行や企業も、同じ理由、同じメカニズムによって、同様の一連の出来事を経験しようとしていると推測できると思います。