システムはなぜダウンするのか

投稿元：

レビューを見る

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

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

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

投稿元：

レビューを見る

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

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

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

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

投稿元：

レビューを見る

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

投稿元：

レビューを見る

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


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

投稿元：

レビューを見る

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

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

投稿元：

レビューを見る

■目次

第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 原因究明よりも復旧を優先

■レビュー

・

投稿元：

レビューを見る

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

投稿元：

レビューを見る

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

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

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

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

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

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

投稿元：

レビューを見る

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

投稿元：

レビューを見る

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


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

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

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

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

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

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

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

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

投稿元：

レビューを見る

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

投稿元：

レビューを見る

記述は基本レベルが丁寧に書かれている。これをベースにアンチパターンとか実装例とかで勉強会やったら新人教育に（自分にも）よい感じ。情報システムの品質保証とかテストをやっている人も読んでおいてほしいな

投稿元：

レビューを見る

基本的な内容だけど、様々なシステムトラブル事例・パターンが書かれているので、再確認できる。また、自分の知らないパターンにも気づかされる。たしかに、結果論では「なんで、そんな単純なミスをするんだ」とか「基本中の基本で、あり得ない」等と言えるけど、実際には様々な要因が重なってトラブルが発生するよね…。

投稿元：

レビューを見る

【読者】　主に若手～中堅のITシステムの運用担当者および開発担当者だが、利用者にとっても有益

【目的】　ダウンの要因やメカニズムを理解し、ダウンの削減と迅速な復旧に資する

【一押】　システム設計から運用までをシステムダウンの観点から事例や図を使いわかりやすく解説している

【概要】　ダウンの原因は大きく分けて４つある。①ソフトウェア、OS、ミドルウェアの不具合、②ハード、ネットワークの性能・容量不足、③環境設定・運用操作ミス、④ハード故障、不慮の事故である。それらはダウン発生時の現象から切り分けて考えられる。現象としては、一部ダウンか全面ダウンか、発生が朝などの起動時か運転中かといったことである。ダウンは、例えどれだけ冗長化構成をとっても、テストケースを100万件こなしたとしても完全になくせるものではない。ダウンを予防することと同様に大切なことは２つある。いかに発生時の影響を最小限に抑えるか、そして発生したダウンを今後のシステムに活かすことである。今後は信頼性向上のためにも企業間のダウン事例共有なども整備されていくべきである。

【感想】　障害が発生すると自分の本来の仕事が進まなくなり、客への対応もしなければならない憂鬱なものだと思う。ただ、本書にあるようにそこから技術者として学ぶことができるのは良い経験なので、今後はそれを意識していきたい。

投稿元：

レビューを見る

感想は以下。
http://masterka.seesaa.net/article/162209542.html