日経コンピュータによって出版された『システムはなぜダウンするのか』を読んだので内容と感想です。
『システムはなぜダウンするのか』の内容と感想
社会インフラとなっている大規模システムが過去にダウンした際の原因を、さまざまな切り口から分析しています。また、システムが正常稼働するようなしくみ(冗長構成など)やITベンダーや運用部隊の事情なども解説されています。
オススメする人
専門的な技術書というよりも読み物みたいな雰囲気なので、ITが専門外の人でも大規模システムやSIerの実情を知ることができます。
また、運用設計や運用保守時、障害対応時に起こる問題が多く書かれているため、システムを作る(お客さんに納品する)ことだけに目が行きがちな新人のSEや運用保守業務を行っている方に特におすすめです。
古い本ですが、今にも生きる知見が多くあると感じます。
- 社会インフラとなっている大規模システム(官公庁のシステム、金融のATM、証券のシステム、鉄道システムなど)がダウンしないための工夫や過去にどのような原因でダウンしたのかを知りたい人
- SEに興味がある人(転職を考えている人やIT業界を検討している就活生)
- SEとして仕事を始めた人
→システムを作ることだけに目が向けてしまうことが多いため。 - システムの運用保守・障害対応に関わる人
独断と偏見で選ぶ難易度とオススメ度
難易度：★☆☆☆☆【星1つ】
オススメ度：★★★★☆ 【星4つ】
難易度の基準
以下のイメージで主観で選んでいます。
- ★1：ITのことが分かっていない初学者も読める本
- ★2：一通りの基礎知識が付いた人が読める本
- (プログラミングであればProgate、IT分野であれば基本情報技術者試験の範囲に一通り目を通したことがあるくらいの想定)
- ★3：専門分野の話を覗いてみたい人が読む本
- ★4：専門分野の話がより詳しく書かれている本
- ★5：それ以上
オススメ度の基準
世間での評価と読んでみた自分の評価を合わせて、個人的なオススメ度合いを相対評価で付けています。
★5だと上位20％、★4だと上位21～40％、★3だと41～60％、★2だと61～80％、★1だと81～100％となることを想定していますが、最終的にこのように分布するかは分かりません。
内容
目次
- 第1章 システムが止まった…
―「ダウン」とは何か - 第2章 きちんとテストしたはずなのに…
―アプリケーション・ソフトの不具合 - 第3章 アプリケーションだけではない…
―OS、ミドルウエアの不具合 - 第4章 アクセス殺到に耐え切れず…
―性能・容量不足 - 第5章 気づかなかったは許されない…
―環境設定・変更ミス - 第6章 その「うっかり」が致命傷…
―運用・操作ミス - 第7章 まさか、こんなことが起こるとは…
―ハード故障、不慮の事故 - 第8章 障害対応は時間との闘い…
―ダウンに学ぶ
第1章 システムが止まった…
- 最新技術を使うこととダウンはトレードオフ。また、ダウン対策費用のコスト面との兼ね合いもある。
- 結局、100％ダウンしないシステムは作れない。むしろ今後は大規模化して増えていく。
- ダウンを100％なくそうとするのではなく、すぐに復旧させる、影響範囲を小さくする、同様のダウンが起きないように対策を講じる などが大切。
- 技術者は、ダウンの原因を素早く突き止めるスキルとダウンから再発防止策を学ぶ力の両方が求められる。
- ダウンは原因から以下の4つに大別できる。
- ソフトウェアの不具合
- 性能・容量不足
- 設定・操作ミス
- 不慮の事故
第2章 きちんとテストしたはずなのに…
- 条件次第では、数年間安定して稼働していても突然障害が発生する
- データ移行プログラムは原因の特定に時間がかかる
- 回帰テストは、機能の追加・変更の対象部分のテストと比べて甘くなりがち
- 日付問題
- デッドロック
第3章 アプリケーションだけではない…
- 製品化されているOSやミドルウェアは、利用者がプログラムの中身を見ることができずブラックボックス化してしまう
- 二重化、冗長性(正しい構成で冗長化しましょう)
- 組み合わせ問題
- パッチ適用やバージョンアップ、新しいものを使うにもリスクがある
第4章 アクセス殺到に耐え切れず…
- 想定量を超えるアクセスが押し寄せたときに、システムが異常動作を引き起こすことがある
- ハード資源がボトルネックになる場合と、ソフト資源がボトルネックになる場合がある
- ソフト資源についてはパラメータを適切に設定し、ハード増強時に見直す必要がある。
- 通信データの増加によってダウンすることも。L3スイッチの故障やファームウェアの不具合など。
- 扱うデータ量が増えると、データベースが満杯になる、バッチ処理が終わらないなどの不具合が生じる
第5章 気づかなかったは許されない…
- パラメータ設定ミスはテストで見つけることが難しいのでやっかい。
そもそも担当者がパラメータの存在を思い浮かばなければ、パラメータの確認やテストができない。 - パッチ・ファイルの適用漏れ
第6章 その「うっかり」が致命傷
- 運用操作の完全自動化は無理で、監視機能や自動運転機能を使っていても、想定外の動作が起きた時は運用担当者が主導コマンドでキーボードから入力する必要がある。
- チェックを何重にしても複数人で確認しても人間のミスは0にはできない。
- 混乱が二次災害を生むので、フェイルセーフ、フェイルソフト、フールプルーフ、フォールトトレラントなどの考え方が重要
- ダウンした場合を想定して対策する事業継続計画(BCP)を考えるべき
第7章 まさか、こんなことが起こるとは…
- 不運としか言いようがないダウンも時に起こる
- サーバの故障や、冗長化しても複数台同時故障が起こる
- 通信ネットワークの普通
- 電源の故障。UDPを導入している企業は多い。
- 震災
第8章 障害対応は時間との闘い…
- 原因究明よりも復旧が優先
- 絶対にダウンしたら困るシステムの場合、様々な信頼性向上策によって目標をクリアしたとしても、少しでも止まったら怒られる。
- ダウンを「悪」と捉えるのではなく、システムの信頼性を高める機会を得たと前向きにとらえて再発防止策の検討に力を注いだ方が良い。
感想
システムは作って終わりなのではなく、むしろ作り終えてからいかに安定稼働させるかが一番大切だと分かった本です。
(私は元々開発に興味があって入社したのもあり、)便利になるような新規機能を追加したくなったり話題の新技術を使ってシステムを構築したくなることが多いですが、それよりもまず安定的に稼働するような構成の設計・運用設計・テストを行うことを第一に考えるべきだということが分かりました。
本の中のコラムにも書かれたこと曰く、ダウンが減るような創意工夫を凝らすことによって経験が浅いまま陣頭指揮をとらないといけない人が出てきているようです。
一方でシステムは複雑化しており、原因究明や復旧のための難易度や必要とされる調整能力は上がっていきそうですね。
事例がたくさん載っており興味深かったし、障害の原因の分類(第1章の区分やそれぞれの章立て)が分かりやすくこの先も役立ちそうなため、入社1年目で読んで良かったなと思う本でした。
技術的な用語について詳しく解説はされていないため、知らない単語があったら別途調べるのが良いと思います。また、原因には言及されているものの目指すべき復旧対策や再発防止策には触れられていないです。
これらを書くとあと数冊になると思いますし、もちろんマイナスではないです。
(システム部の偉い人は手順書レビューをあまり聞かずに承認、その後その手順書が原因で障害が起きた際には運用担当者のみ怒られるといったことがコラムにも載っていました。障害は組織的な背景がかなり大きいと思いますし、私はこういう背景に興味がありますね。)
コメント