「システムを絶対止めない」――。日本では“止まらない”ことが当たり前のような風潮があり、これまで費用を掛けてシステムを強化してきた。しかし、それでもシステムは止まってしまう。今、システムのサービス化やクラウドの発展といった状況の変化が、従来の考えを覆しつつある。目指すべきは「システムが停止してもビジネスを継続すること」。経営層や利用部門を説得し、業務、システム、運用を設計する方法を解説する。
それでもシステムは止まる---目次
目次
-
ユーザー視点で情報を伝える 「怒られない」は目指さない
PART 6 障害発生時の謝り方
システムが停止してしまうと、ビジネスの現場への影響は避けられない。影響を最小限にするには、利用部門との適切なコミュニケーションが肝要となる。初期段階のコミュニケーションをどのように取るべきか、伝えるべき情報とその順番を解説しよう。
-
素早い復旧を設計で実現、リクルートは10分停止もゼロ
PART 5 復旧作業に迷わない運用設計
システム停止を前提に考えると、スムーズな復旧が鍵になる。復旧を担当する運用チームがスムーズに作業できるよう、運用担当者は基本設計、詳細設計の段階でフローや支援ツールを準備しておく必要がある。
-
AWS全停止に備え、最小のコストで待機系を作る
PART 4 クラウドで安く冗長化設計
基本設計の段階で、インフラ担当者は非機能要件を満たすようにインフラの構成を設計する。ポイントは仮想化基盤やパブリッククラウドといった、いまどきの基盤を活用すること。コストを抑えながら可用性を高める機能を使いこなそう。
-
「業務の手段」を冗長化、紙、Excel、クラウドを活用
PART 3 代替システムや紙で業務継続
アプリケーション担当者は基本設計の段階で業務フロー図を作成する。ここから一歩踏み込んで、「システム停止」という例外系の業務フローを設計しよう。システム停止時に利用する業務の代替手段を作るのだ。
-
適正レベルを利用部門と合意、東京海上は4ランクに分ける
PART 2 無駄な高可用性をやめる
システム停止を前提に業務/サービスを考えるならば、どの程度ならシステムを止めても業務に影響しないか、経営層や利用部門との合意が必須だ。それには、システム停止が業務に及ぼす影響を把握し、ランク付けするとよい。
-
業務継続に四つの対策、富士フイルムグループの挑戦
PART 1 ビジネスは止めない
システムはどれだけ対策をしても止まる。富士フイルムグループはそれを現実として受け入れ、システムの停止がビジネスの停止に直結しないための対策を講じている。狙うのはビジネスの可用性を高めることだ。システムではない。