Document

特集
特集
それでもシステムは止まる
それ
システム
「システムを絶対止めない」―。日本では “止まらない” ことが当たり前のような風潮
があり、これまで費用を掛けてシステムを強化してきた。しかし、それでもシステムは止まっ
てしまう。今、システムのサービス化やクラウドの発展といった状況の変化が、従来の考
えを覆しつつある。目指すべきは「システムが停止してもビジネスを継続すること」。経営
層や利用部門を説得し、業務、システム、運用を設計する方法を解説する。
（白井良）
24
NIKKEI SYSTEMS 2015.7
PART 1　ビジネスは止めない
36
PART 4　クラウドで安く冗長化設計
30
PART 2　無駄な高可用性をやめる
39
PART 5　復旧作業に迷わない運用設計
33
PART 3　代替システムや紙で業務継続
42
PART 6　障害発生時の謝り方
NIKKEI SYSTEMS 2015.7
それでもシステムは止まる
26
特集
でも
は止まる
25
1
PART
ビジネスは止めない
業務継続に四つの対策
富士フイルムグループの挑戦
システムはどれだけ対策をしても止まる。富士フイルムグループはそれを現実として受け入れ、
システムの停止がビジネスの停止に直結しないための対策を講じている。
狙うのはビジネスの可用性を高めることだ。システムではない。
「万全と考える防止策を徹底しても、
を冗長化するソフトウエアにバグがあ
務の代替手段の設計」
「ITインフラの
システムは止まる」
。富士フイルムコ
り、論理的なデータ書き込み箇所と物
シンプル化」
「復旧フローの作成」と
ンピューターシステムの柴田英樹氏
理的なデータ書き込み箇所に不整合が
いったものだ（図1）
。
特集
（システム事業部 ITインフラ部部長）
発生。該当するストレージ装置を使う
その後、代替手段が必要になる大規
は厳しい口調で言う。柴田氏自身、プ
プライベートクラウドで、データが読
模障害は発生していないが、現在でも
それでもシステムは止まる
ライベートクラウドの大規模障害とい
み込めなくなった。
システムの新規構築、更新時に必ず上
う苦い経験を持つ。
バックアップからデータをリカバ
記の対策を利用部門と共同で検討し、
同社は2008年からプライベートクラ
リーする作業に延べ3日を費やした。
システムの停止に備えている。
ウドを運用し、富士フイルムグループ
その間、停止したシステムを使う一部
各社にITインフラをサービスとして提
の業務が遂行できなくなるなど大きな
供している。2012年、プライベートク
影響があった。
富士フイルムコンピューターシステ
ラウドの一部でシステムが停止し、
この大規模障害の経験を経て、柴田
ムが実施している、システム停止への
データ消失まで起こる大規模障害が発
氏は「システム停止が起こり得る前提
備えを一段詳しく見てみよう。
生した。
で、ビジネスへの影響を小さくするた
一つ目、重要度の洗い出しについて
原因はストレージ装置のファームウ
めの対策を講じる方針に替えた」と語
は、要件定義の段階で利用部門と復旧
エアの不具合。ストレージ装置の内部
る。
具体的には
「重要度の洗い出し」
「業
時間や復旧ポイントについて合意を取
システム面
での対策は
万全だ！
システム停止が
起こり得る前提で
対策を打とう
どこまでやっても
システム停止は
起こるのか
システム管理者
重要度の洗い出し
プライベートクラウド
冗長化されたシステム
冗長化されたネットワーク
予備機の準備
適切なバックアップ
停止を想定した業務フローを用意
復旧の
優先順
❶
●
❷
●
❸
●
業務の代替手段の設計
停止
切り替え
2012年以降
ストレージ装置のファーム
ウエアのバグが原因で
大規模障害を経験
ITインフラのシンプル化
停止
ストレージ装置の
冗長化機構を
停止して切り離す
手順を作成
手作業
Excel
復旧フローの作成
●障害復旧を開始する判断基準を
明示
● 原因調査より復旧を優先する
ケースを明記
●利用部門との連絡方法を記載
1 富士フイルムコンピューターシステムは「システムが止まってもビジネスを継続」する対策を実施
図
2012年にストレージ装置のファームウエアのバグによる大規模障害を経験し、システム停止に関する考え方を大きく変えた
26
NIKKEI SYSTEMS 2015.7
富士フイルム
コンピューターシステムの
柴田英樹氏
る。この際、
「個別に利用部門にヒア
リングすると、本来必要な水準よりも
高い信頼性を求める傾向がある」と柴
田氏は言う。適正化を図るため、客観
的な視点として、災害対策で作成され
たBCP（事業継続計画）を利用する。
BCPは経営視点で業務の重要度を定
義している。これを参照しながら、現
実的な復旧時間と復旧ポイントに落と
し込んでいく。
二つ目、業務の代替手段の設計は、
特集
システム開発時に実施する「業務プロ
セス設計」の次工程で行う。業務プロ
それでもシステムは止まる
セス設計では、データの入出力に注目
し、人とシステムがどういうフローで
何をやるのかを設計する。
柴田氏は
「業
務プロセス設計書をベースにすると、
システムが止まったときに何のデータ
の入出力ができなくなるか一目で分か
る。これを基にシステム停止時の代替
手段を考える」と説明する。
ほとんどの代替手段は、電話で顧客
とやり取りする形を想定している。た
だ、電話でやり取りするにも、データ
がないと継続できない業務がある。例
1 富士フイルムコンピューターシステムが作成した復旧フロー図
写真
障害規模やシステムの重要度、発生時期、緊急復旧の要不要を判定するプロセスを明確化した
えば「出荷指図」は、顧客、商品、在
庫といったデータが必須になる。代替
ら強制的に切り離せるようにしたい」
た場合、原因調査が難しくなるのを承
手段に最低限必要なデータを利用部門
と考え、ITインフラをシンプルに運用
知の上で、復旧を優先させる。フロー
と洗い出して、CSV形式でバックアッ
できるように工夫した。例えば、スト
を明確にすることで、判断に迷う時間
プ用サーバーに保存している。システ
レージ装置については、冗長化機構を
をロスしないようにした」
（柴田氏）
。
ム停止時には、ExcelやAccessでデー
停止させる方法をストレージベンダー
タを読み込み、顧客の連絡先や在庫の
の協力を得て手順書に記載した。
情報などを閲覧してもらう形で業務を
四つ目は復旧フローの作成である。
富士フイルムコンピューターシステ
進める。
障害復旧を開始する判断基準を明示
ムの取り組みは、従来の「システムの
三つ目はITインフラのシンプル化
し、現場で実施すべき手順をフロー
可用性を高める」という考え方から、
だ。2012年の大規模障害では、
ストレー
チャート化した（写真1）
。
「運用担当者
「ビジネスの可用性を高める」という
ジ装置内部の冗長化機構が原因となっ
はエンジニアとして、障害の発生原因
考え方に踏み込んだもの。システムを
た。こうした経験から柴田氏は「複雑
を究明したいものだ。しかし、ビジネ
止めないのは手段に過ぎず、ビジネス
な冗長化の仕組みは、かえって復旧し
スへの影響が大きい障害の発生時は、
を止めないことが目的なのだ。
づらい状況を作り出す。いざとなった
そうも言っていられなくなる。そうし
ビジネスを止めないという考え方は
重要なのは「ビジネスの可用性」
NIKKEI SYSTEMS 2015.7
27

Download Report