システムはなぜダウンするのか 知っておきたいシステム障害、信頼性の基礎知識

投稿元：

レビューを見る

動かないコンピュータの教科書化。従って完全なバッドノウハウ集。

本書ではシステムダウンの原因をアプリケーション/ソフトの不具合、OS・ミドルウェアの不具合、性能・容量不足、環境設定・変更ミス、運用・操作ミス、ハード故障・不慮の事故に分けて説明している。

如何にシステムトラブルの原因が様々で、かつその原因特定が難しいかがわかると思う。

投稿元：

レビューを見る

日経コンピュータというシステム障害の豊富な取材データがあるところが監修しているにしては、ちょっと期待はずれ。

読んですぐに感じる違和感は、対象読者はいったい誰なのかということ。題名からは専門技術者向けのように期待されるが、中の書き方は一般読者向けのような冗長さが目立ちます。中にはSQLとはという説明があったり(p233)、反面、待機系や勘定系とかは説明もなく使われたり、やさしく書こうとしているところと専門的な内容がうまくかみあっていない印象です。そのために、読んでいて読みづらく、内容ももっと突っ込んだものができたはずだろうに残念です。

取材メモからルポ的に文章を起こしたり、より専門的な内容にしておけばもっと価値のある本になっただろうと思いますな。

図書館や知人から借りられれば読んでみるのもいいけど、わざわざ買うほどでもない。

投稿元：

レビューを見る

■目次

第1章 システムが止まった…
――「ダウン」とは何か
1.1 停止=ダウンは誤解
1.2 ダウンは原因から4種類に分けられる

第2章 きちんとテストしたはずなのに…
――アプリケーション・ソフトの不具合
2.1 突然に目を覚ます20世紀のバグ
2.2 忘れたころにやってくる「日付問題」
2.3 データベースのデッドロックが連発

COLUMN こちらシステム・ダウン相談所
システム・ダウンが「3K」の一因?

第3章 アプリケーションだけではない…
――OS、ミドルウエアの不具合
3.1 停止を検知できない
3.2 組み合わせを変えたら動かない
3.3 メモリーをつかんだまま解放しない

第4章 アクセス殺到に耐え切れず…
――性能・容量不足
4.1 ハードウエアの性能を生かしきれない
4.2 メモリー、CPUが足りない
4.3 通信データの増加がダウンをまねく
4.4 データベースが満杯に
4.5 夜が明けてもバッチ処理が終わらない

COLUMN こちらシステム・ダウン相談所
運用担当者は叱られ役?

第5章 気づかなかったは許されない…
――環境設定・変更ミス
5.1 つい見逃すパラメータ変更
5.2 システム環境の変更ミス
5.3 パッチ・ファイルの適用忘れ
5.4 カレンダーの設定ミス

第6章 その「うっかり」が致命傷…
――運用・操作ミス
6.1 運用コマンドを間違える
6.2 データの移行・入力ミス
6.3 待機系への切り替えに失敗
6.4 混乱が「2次災害」を生み被害拡大

第7章 まさか、こんなことが起こるとは…
――ハード故障、不慮の事故
7.1 サーバーが壊れた
7.2 通信ネットワークが不通に
7.3 コンピュータ、電気なければただの箱
7.4 震災でデータセンターが破壊・焼失

COLUMN こちらシステム・ダウン相談所
ダウンが減りすぎて困る?

第8章 障害対応は時間との闘い…
――ダウンに学ぶ
8.1 原因究明よりも復旧を優先

■レビュー

・

投稿元：

レビューを見る

耳が痛い。ここに出てきているクラスの障害が発生した現場を想像すると吐き気を催す… 辛かっただろうな、ここの方たち。
今のお客さんの状況と照らし合わせるに、安易なWinやパッケージソフトの採用がシステムを複雑にし、切り分けを困難にしているのは自明。
しかし、この状況に対する対策や提言がないのは少しさみしいね。解無しなんだろうけど。

いい本ですね。

投稿元：

レビューを見る

システムにとってのリスクを事例ベースで教えてくれる。
事例とからめてあるので頭に入りやすかった。


こういった先人の失敗を知っておくこと、同じことを繰り返さないことを意識するとセンスが磨かれていくのかもしれない。

投稿元：

レビューを見る

情報システムの不具合の事例を見ながら、システム運用現場に関して学ぶ。
来年からＩＴ企業に就職する自分にとって、とても勉強になった。
また、「保守・運用部門ってのもいいかもしれないなぁ…。」と思っていた幻想が吹っ飛んだ。

投稿元：

レビューを見る

全体を通して読みやすく図解が多いので、技術職以外でも読みやすい。

某大手銀行の統合時のシステムダウンなど、内部の人間しか知らない様な内容を、システム概要からしっかり解説しているので、システム事故撲滅のための失敗事例共有としては非常にためになった。

銀行系システムばかりなので、汎用機での事例がほとんどだが、
DBのデッドロックの解説は、とても分かり易くどんなシステムでも十分役に立つ。

またシステムダウンの意味を定義して分類しているのは、
本書ならではの解説で、現場で使える。

システム管理者なら必ず一度呼んだ方が良い。

失敗事例の共有は下記の様なサイトもある。
http://shippai.jst.go.jp/fkd/Search

投稿元：

レビューを見る

私みたいな素人でも読みやすいと感じたのは、
専門用語を簡単に説明してとっかかりやすくしてくれているから。
このシリーズ、他にも基礎的なものを説明してくれているものがあるようなので、
次はそっちを読んでみたいと思う！


「ダウン」の発生原因
・ダウンを防ぐための例外処理にバグがあった
・信頼性を高めるためにシステム構成を複雑にしたことが被害の拡大につながった

システムの「ダウン」＝システムが本来の役割を果たせていない状態を指す
結局は絶対ダウンしないシステムは作れない
→ダウンしてもすぐに復旧させる、ダウンした際の影響範囲を小さくする、同様のダウンが起きないように対策を講じるといったアプローチが必要。

デッドロック防止
→ ルールを策定しロック順序をそろえる、すべてのプログラムがルールを守っているか総点検する、負荷テストを実施する
64ビット OS＝CPUに対して一度に64ビットの命令を受け渡せるソフトウェアのこと
ソフト資源＝ソフトウェアの処理性能のこと

バッチ処理は短いものでも数秒から数分、長いと数時間に及ぶ。(オンライン処理は3秒以内に応答を返すのが基本)
リラン＝エラーとなったバッチ処理を最初から再実行する
リスタート＝エラーとなったバッチ処理を途中から続行する

ジョブ管理ソフトの役割
→(1)システムの監視機能
複数のハードウェア、ハードウェア上のAPの稼働状況を一括して把握できる。
この機能を使うためには運用、監視ソフトを搭載した監視サーバを用意し、コンソールで表示し、監視する
監視対象のサーバに「エージェント」と呼ぶソフトウェアを導入する。
(2)自動運転機能
＝ジョブスケジューラ。運用管理サーバを用意する。

フェイルセーフ＝ダウンしたときに影響範囲がシステム全体に広がらないようにする
フェイルソフト＝システムのある部分がダウンしたとき、それ以外の機能は稼動を続けられるようにする
フールプルーフ＝利用者が意図しないような使い方をしてもシステムがダウンしないようにする
フォールトトレラント＝システム構成要素の一部が故障してもシステム全体には影響がないように冗長構成をとる

JCL(ジョブ制御言語)＝メインフレームを使ったシステムで用いるバッチ処理の起動ファイル
(1)入出力ファイルに関する指定(2)実行制御に関する指定

ダウンは「悪」ではない…システムの信頼性を向上させる機会ととらえる

投稿元：

レビューを見る

【狙い】：仕事用途
・ITの「失敗学」のフレームとして使いたい。

【コメント】
・ITの「失敗学」としては、ユーザ要件に関する失敗、プロジェクト運営の失敗は先例が多くあるが、当該書のように、いわゆる非機能要件を中心にまとめたものは、類書がないと思われる。

投稿元：

レビューを見る

私も一応管理者みたいなことをやってるので、「システムダウン」なんてあまり嬉しくない事態だが、それでも起こる、そして起きてほしくない時に限って起こる。 この本では、ダウンの原因を、ソフトウェアの不具合、性能・容量不足、設定操作ミス、不慮の事故、の４つに切り分けて、それぞれの事例を分析している。 もちろんこれらが複合して起こるケースもあり、対応を難しくしている。 基本的な姿勢としては、ダウンを100％防ぐのは不可能、ということを前提に、どうすればダウンをできるだけ減らせるか、起こってしまったときの被害をできるだけ減らせるか、ということを考察する。 解説もわかりやすく、得るところの多い内容だった。

投稿元：

レビューを見る

システムダウンの原因を数多くの事例をもとに紹介。
タイトルにあった内容なので、特に問題ないけど、ATMや証券などの事例に偏りすぎていたのが気になった。もっと、中小規模の事例も欲しかった。

投稿元：

レビューを見る

ダウンしない完全なシステムはない、と繰り返し訴えつつ、様々な障害事例が紹介されています。保守エンジニアは共感できる部分が沢山ありそうですよ。

しかし、よくもまあここまで障害事例を集めたなあ、と関心します。素晴らしい。これまで自分が味わった障害はほとんど網羅されてるんじゃないかな、とさえ思う。
20分くらいで流し読みしましたが、予想外に楽しめ？ました。

1つ気になって、強く実感したこと。
『ソフトウェア障害に2重化は通用せず。』
2重化にも何通りかあるとはいえ、バージョンなど一緒にしていたら、同じ問題が起きるので確かにソフトウェアの2重化にはならないですね。
同一バージョンでのHA構成、ちょっと考え直したほうがよくない？メリデメリは色々あれど、検討と改善要望の余地はあるはず。

投稿元：

レビューを見る

会社でまさにシステム障害の原因分類を整理するのに、参考のために購入。非常に役にたった。また、読みやすい文章だし、事例も新鮮で良い本だと思う。

投稿元：

レビューを見る

システムがダウンする理由: ソフトウェアバグ、データベースデッドロック、OS・ミドルウェアの不具合、ハードウェアの故障、パラメータ設定ミス、人的な操作ミス、などなど。

投稿元：

レビューを見る

システムがいわゆるダウンと呼ばれる状態について、アプリケーションの作りやヒューマンエラーなどの原因別にわかりやすく解説。