仕事でシステム保守をしているので、明日は我が身という気持ちで読みました。 設定ミスや操作ミスの話は肝が冷えました(笑) 企業名などは伏せられた状態でいろんな原因のシステムダウン事例が紹介されていて、不謹慎ですがこういうトラブル系の話を読むのが好きなので面白かったです。 どれだけ万全に対策をしていてもダウンは起きるので、発生したときに「見直す機会ができた」と前向きに捉えるという話は、なるほどなーと思いました。

主に銀行や証券取引所のDBダウンについて事例を用いて紹介している。 原因と対策が明確に書かれてあり、システム管理に従事しない自分としては大変参考になった。 面白すぎる。

システムダウンとは、そのシステムにおいて期待されるサービスが利用不可となること。 本書では、様々なシステムダウンの事例にあたりながら、その原因と対応策について迫っていく。 「システムダウンを100％防ぐことはできない」「人はミスをする生き物である」といったメッセージを受け取った。

ハード、ソフト、人的要因までシステムがダウンする理由を体系的にまとめている本。 平易な書き方だし、例示も多いので読みやすい。（ATMに関する話ばかりなのは著者の業界によるものか） システム屋さんだけでなく、パソコンをちょっとでも管理してる人は読んでおくと基礎固めとしてとても良い本です。

システムのダウンする経緯、原因を 企業名を伏せたままで現実の話をたくさん 載せている。 システム管理者が自分の経験を増やすのに最適！

2010/3/14　　借りて、読み始める。　4/15　途中までで一旦返却。 内容は専門的だが具体的でわかり安い。　必要になったら再読しよう。 内容と著者は 内容　： 実際に発生したシステムダウンの事例のなかから、雑誌や新聞などで原因が詳しく報じられたケースを取り上げ、 どのような原因がきっかけでどんな事象が起きたのかを技術的な観点で体系的にまとめる。 著者　： 第一種情報処理技術者、データベーススペシャリスト。 ＳＥ経験を経て日経ＢＰ社に転じ、日経コンピュータ記者としての大規模システム稼動事例やダウン事例などの取材・執筆を続ける。 目次　：　システムはなぜダウンするのか 第１章　システムが止まった…　　　――「ダウン」とは何か 1.1　停止＝ダウンは誤解 1.2　ダウンは原因から４種類に分けられる 第２章　きちんとテストしたはずなのに…　　　――アプリケーション・ソフトの不具合 2.1　突然に目を覚ます２０世紀のバグ 2.2　忘れたころにやってくる「日付問題」 2.3　データベースのデッドロックが連発 COLUMN　こちらシステム・ダウン相談所　　　　システム・ダウンが「３K」の一因？ 第３章　アプリケーションだけではない…　　――OS、ミドルウエアの不具合 3.1　停止を検知できない 3.2　組み合わせを変えたら動かない 3.3　メモリーをつかんだまま解放しない 第４章　アクセス殺到に耐え切れず…　　　――性能・容量不足 4.1　ハードウエアの性能を生かしきれない 4.2　メモリー、CPUが足りない 4.3　通信データの増加がダウンをまねく 4.4　データベースが満杯に 4.5　夜が明けてもバッチ処理が終わらない COLUMN　こちらシステム・ダウン相談所　　　　運用担当者は叱られ役？ 第５章　気づかなかったは許されない…　　　――環境設定・変更ミス 5.1　つい見逃すパラメータ変更 5.2　システム環境の変更ミス 5.3　パッチ・ファイルの適用忘れ 5.4　カレンダーの設定ミス 第６章　その「うっかり」が致命傷…　　　――運用・操作ミス 6.1　運用コマンドを間違える 6.2　データの移行・入力ミス 6.3　待機系への切り替えに失敗 6.4　混乱が「２次災害」を生み被害拡大 第７章　まさか、こんなことが起こるとは…　　　――ハード故障、不慮の事故 7.1　サーバーが壊れた 7.2　通信ネットワークが不通に 7.3　コンピュータ、電気なければただの箱 7.4　震災でデータセンターが破壊・焼失 COLUMN　こちらシステム・ダウン相談所　　　　ダウンが減りすぎて困る？ 第８章　障害対応は時間との闘い…　　　――ダウンに学ぶ 8.1　原因究明よりも復旧を優先

【読書感想】システムはなぜダウンするのか 大和田 尚孝 タイトル通り、システムがなぜダウンするのか具体的な事例をあげながら、ダウンの原因を探っていく内容の本です。 私が、想像力と妄想力豊かというのもあるかとは思いますが、 一応IT業界の端っこにおり、 さらにさらに、IT業界で働く夫を持つ身として、 なんていうか、読んでて心がヒリヒリします。 後半、つらくなりました（笑） メンタルが結構やられますが、エンジニアにとってはとても良い本です。 どの立場の人でも、読んでおいて損はないと思います。 具体的な企業名とかはボカしてるものの、 ニュースにもなってたような大きなシステムトラブルの根本の原因がわかりやすく書かれています。 ものすごい大きなトラブルの原因も、 突き詰めて行くと、開発したプログラムの小さなバグだったり、 アプリやOSの1個のパラメータ設定ミスだったり、 ハードの故障だったり、それらのコンボだったり。 突き詰めて行くと、自分らのような下々の立場の人間でも、大規模トラブルの一因になったりするわけです。 話が具体的な分、そういう立場に追い込まれた自分を余裕で想像できちゃって、恐怖だった。。。 エンジニアじゃない人は、解説があるものの専門用語も多いのでちょっと読むのが大変かもしれません。 エンジニアには超オススメです。

ＩＴ関係者ならば、必ず数度は体験するシステムダウンについて、考え方と原因分析、事例紹介を読みやすく描いた一冊。 最近ではセキュリティがフォーカスされている反面、機器同士の相性問題も減り、導入でも提案でも、ある程度過去の経験測を元に、機器選定をしてしまっている面がある。 しっかりと理論に基づいた危機管理、各種リスクプランニングを行い信頼を得るためには、土台として読むとよいと思います。 （若干、金融系のシステムが多く、知識の偏りから☆をひとつ落としています）

実際に発生した大規模システムの障害事例を元に、システムがダウンする原因を解析していく。 私的には、あまり縁のなかったホストの用語の意味が説明されていたのが勉強になった。

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

「システムは正常に動いて当たり前」だけど、その当たり前を阻害する要因は本当に様々である。 その要因や対処法が手堅くまとめられており、ネットワーク技術者、およびネットワークサービスを提供する立場にある人は必携。 基本書というだけあり、これから何回も読み直すことになると思う。

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

システムダウンの要因について，ソフトウェアのバグ，パラメータ設定ミス，人的操作ミスなどカテゴリー化してあり，それぞれのカテゴリーについて原因と対策について述べてある．具体例を交えながらの解説なので，実際にイメージをつかみやすい．また比較的平易な言葉で書かれており，新米SEにも読み進めやすいと思われる． システムダウンについては実際に目の当たりにして学ぶところが多いようだが，近年ではシステムダウンを目にする機会が減ってきているとのこと．その分システムダウンの基本的な要因については本書で押さえておきたい．

システム・ダウンの事例と原因が数多く紹介されている。 ありとあらゆる部分にダウンの危険が潜んでいて、読んでいるとだんだん落ち込んでくる。 今まで何の問題もなく動いていたとしても、1時間後も正常に動いているとは限らないというなんとも憂鬱な事実が繰り返し語られる。 二次災害とか…やってられるか！と言いたくなるレベルの話だ。 手をかければかけるほど良くなっていくわけではないと分かった時の失望を思い出した。 何か問題を指摘されても「いやぁ、そんなはずないんですけど…」と、弱気に返すしかないという事態。 「テストしなかったの？」というお決まりのセリフに怯える日々。 そしてこの本を読んで知る、さらに最悪な状況…。 もっと気を引き締めて仕事しないとなと改めて思った。 勉強になりました。

私は社内SEを初めて1年ちょっとの新米SEですが、社内で使うシステムやプログラムを作るようになり、システムを作る際にダウンのことまで考える必要性を感じて読んでみました。 まだシステムのことやプログラミングの知識は少ない私ですが、非常に分かりやすく、楽しく最後まで読めました。 一口にダウンと言っても色々な原因があることが分かりました。 時々再度して、自分のシステムがダウンを起こさないようにしたいと思います。

実際に現場で起こった障害を元に、原因や対応等について解説。 システムに詳しくない人でも分かるように平易な表現をしている。 主に銀行ATMなどの大規模な仕組み、メインフレームを取り上げている。 実際の業務に携わる上では「役には立たない」。 システムを開発・運用・保守していく上での基本はわかる。

システムダウンの原因が、実際に起きた障害に例をあげながら紹介されている。わかりやすくまとまっているので、システムダウンまでの一連の流れをテンポよく読み進められた。 頭の片隅において、いざという時の引き出しにしたい。

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

システム基盤の構築や運用に携わって、(今現在)8年になります。後輩や協力会社の育成が課題です。自分自身が作業自体になかなか関われないため、ほぼ未経験の担当者に手取り足取り指導できない状況にあります。そんな中、経験なり知識を少しでも身につけさせるための副読本を探しており、この本を見つけました。 内容は主に、システムダウンの原因を4つのジャンルに分け、その原因ごとの事例を元にしたケーススタディが中心です。事例は実際に発生したものが取り上げられております。実際のダウンを経験する代わりとして、実際のダウン事例を取り上げることで、ダウンからの復旧や、ダウン自体の削減に役立てたい、という筆者の意向のようです。 読んだ感想ですが、第一印象を一言で言えば「あー、わかる！」という感じです。システム運用を経験したことがある人ならば、自分が直面したことのある事例に近いものが、1つや2つはあるのではないかと思います。また、実際にシステム障害に直面したときの思考や挙動について、経験的で感覚的になりがちな部分をきちんと体系立てて記述されていると感じました。そのため、運用をある程度経験した人も、改めて障害に関する知識を整理することができると思いました。 私の場合は、経験不足なメンバの経験を補う目的で、この本を購入しました。手順書ベースでしか動くことができないメンバに対して、より応用力のある対応ができるようになることを期待しているためです。この書籍では、細かい技術に関することは扱っていません。従って、コマンドリファレンスなど、もっとオペレーション技術に特化した本と合わせて読ませる必要があるかと考えてます。しかし、コマンドリファレンスだけではわからない、根本的な知識を身につけるには、具体的な事例が丁寧に説明してあるこの本が最適ではないかと感じました。 完全な初心者が、この書籍だけでシステム基盤や運用のすべてを理解できる、というものではありません。ただし、少しでも経験がある人であれば、自分の経験と照らし合わせながら丁寧に読むことで、小手先の対応だけでなく、応用力を身につけるための根本的な知識を習得することができるのではないかと期待しています。運用に関する多少の勘所も必要だと思われます。おそらく、システム基盤や運用について全く知識がない状態だと、この書籍がいったい何を言いたいのか、理解することはできないと思います。基盤や運用について一歩ステップアップするための位置づけで、この書籍を読むことをお勧めします。 ちなみに、私がこっそり気に入ってたのは、間にある運用に関するコラムでした。「運用担当者は叱られ役？」って言葉は、なかなか胸に響きました。経験者にしかわからない言葉だと思います。

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

過去のシステム障害の事例を元に、 技術的なミス、人為的ミス等、 色々なパターンで障害が発生することを教えてくれます。 この本を読めば、 高度なシステムでも絶対と言う言葉は無く、 システム障害は、起こるべくして起こっていると言うことがわかると思います。 システムエンジニアを目指す人は、 これからどんな仕事をするかの一面を垣間見ることが出来るので、 一度読んでおくべきだと思います。

ダウンしない完全なシステムはない、と繰り返し訴えつつ、様々な障害事例が紹介されています。保守エンジニアは共感できる部分が沢山ありそうですよ。 しかし、よくもまあここまで障害事例を集めたなあ、と関心します。素晴らしい。これまで自分が味わった障害はほとんど網羅されてるんじゃないかな、とさえ思う。 20分くらいで流し読みしましたが、予想外に楽しめ？ました。 1つ気になって、強く実感したこと。 『ソフトウェア障害に2重化は通用せず。』 2重化にも何通りかあるとはいえ、バージョンなど一緒にしていたら、同じ問題が起きるので確かにソフトウェアの2重化にはならないですね。 同一バージョンでのHA構成、ちょっと考え直したほうがよくない？メリデメリは色々あれど、検討と改善要望の余地はあるはず。

【読者】　主に若手～中堅のITシステムの運用担当者および開発担当者だが、利用者にとっても有益 【目的】　ダウンの要因やメカニズムを理解し、ダウンの削減と迅速な復旧に資する 【一押】　システム設計から運用までをシステムダウンの観点から事例や図を使いわかりやすく解説している 【概要】　ダウンの原因は大きく分けて４つある。①ソフトウェア、OS、ミドルウェアの不具合、②ハード、ネットワークの性能・容量不足、③環境設定・運用操作ミス、④ハード故障、不慮の事故である。それらはダウン発生時の現象から切り分けて考えられる。現象としては、一部ダウンか全面ダウンか、発生が朝などの起動時か運転中かといったことである。ダウンは、例えどれだけ冗長化構成をとっても、テストケースを100万件こなしたとしても完全になくせるものではない。ダウンを予防することと同様に大切なことは２つある。いかに発生時の影響を最小限に抑えるか、そして発生したダウンを今後のシステムに活かすことである。今後は信頼性向上のためにも企業間のダウン事例共有なども整備されていくべきである。 【感想】　障害が発生すると自分の本来の仕事が進まなくなり、客への対応もしなければならない憂鬱なものだと思う。ただ、本書にあるようにそこから技術者として学ぶことができるのは良い経験なので、今後はそれを意識していきたい。

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

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

私みたいな素人でも読みやすいと感じたのは、 専門用語を簡単に説明してとっかかりやすくしてくれているから。 このシリーズ、他にも基礎的なものを説明してくれているものがあるようなので、 次はそっちを読んでみたいと思う！ 「ダウン」の発生原因 ・ダウンを防ぐための例外処理にバグがあった ・信頼性を高めるためにシステム構成を複雑にしたことが被害の拡大につながった システムの「ダウン」＝システムが本来の役割を果たせていない状態を指す 結局は絶対ダウンしないシステムは作れない →ダウンしてもすぐに復旧させる、ダウンした際の影響範囲を小さくする、同様のダウンが起きないように対策を講じるといったアプローチが必要。 デッドロック防止 → ルールを策定しロック順序をそろえる、すべてのプログラムがルールを守っているか総点検する、負荷テストを実施する 64ビット OS＝CPUに対して一度に64ビットの命令を受け渡せるソフトウェアのこと ソフト資源＝ソフトウェアの処理性能のこと バッチ処理は短いものでも数秒から数分、長いと数時間に及ぶ。(オンライン処理は3秒以内に応答を返すのが基本) リラン＝エラーとなったバッチ処理を最初から再実行する リスタート＝エラーとなったバッチ処理を途中から続行する ジョブ管理ソフトの役割 →(1)システムの監視機能 複数のハードウェア、ハードウェア上のAPの稼働状況を一括して把握できる。 この機能を使うためには運用、監視ソフトを搭載した監視サーバを用意し、コンソールで表示し、監視する 監視対象のサーバに「エージェント」と呼ぶソフトウェアを導入する。 (2)自動運転機能 ＝ジョブスケジューラ。運用管理サーバを用意する。 フェイルセーフ＝ダウンしたときに影響範囲がシステム全体に広がらないようにする フェイルソフト＝システムのある部分がダウンしたとき、それ以外の機能は稼動を続けられるようにする フールプルーフ＝利用者が意図しないような使い方をしてもシステムがダウンしないようにする フォールトトレラント＝システム構成要素の一部が故障してもシステム全体には影響がないように冗長構成をとる JCL(ジョブ制御言語)＝メインフレームを使ったシステムで用いるバッチ処理の起動ファイル (1)入出力ファイルに関する指定(2)実行制御に関する指定 ダウンは「悪」ではない…システムの信頼性を向上させる機会ととらえる

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

全体を通して読みやすく図解が多いので、技術職以外でも読みやすい。 某大手銀行の統合時のシステムダウンなど、内部の人間しか知らない様な内容を、システム概要からしっかり解説しているので、システム事故撲滅のための失敗事例共有としては非常にためになった。 銀行系システムばかりなので、汎用機での事例がほとんどだが、 DBのデッドロックの解説は、とても分かり易くどんなシステムでも十分役に立つ。 またシステムダウンの意味を定義して分類しているのは、 本書ならではの解説で、現場で使える。 システム管理者なら必ず一度呼んだ方が良い。 失敗事例の共有は下記の様なサイトもある。 http://shippai.jst.go.jp/fkd/Search

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

■目次 第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 原因究明よりも復旧を優先 ■レビュー ・

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

システムにとってのリスクを事例ベースで教えてくれる。 事例とからめてあるので頭に入りやすかった。 こういった先人の失敗を知っておくこと、同じことを繰り返さないことを意識するとセンスが磨かれていくのかもしれない。

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

日経コンピュータというシステム障害の豊富な取材データがあるところが監修しているにしては、ちょっと期待はずれ。 読んですぐに感じる違和感は、対象読者はいったい誰なのかということ。題名からは専門技術者向けのように期待されるが、中の書き方は一般読者向けのような冗長さが目立ちます。中にはSQLとはという説明があったり(p233)、反面、待機系や勘定系とかは説明もなく使われたり、やさしく書こうとしているところと専門的な内容がうまくかみあっていない印象です。そのために、読んでいて読みづらく、内容ももっと突っ込んだものができたはずだろうに残念です。 取材メモからルポ的に文章を起こしたり、より専門的な内容にしておけばもっと価値のある本になっただろうと思いますな。 図書館や知人から借りられれば読んでみるのもいいけど、わざわざ買うほどでもない。

動かないコンピュータの教科書化。従って完全なバッドノウハウ集。 本書ではシステムダウンの原因をアプリケーション/ソフトの不具合、OS・ミドルウェアの不具合、性能・容量不足、環境設定・変更ミス、運用・操作ミス、ハード故障・不慮の事故に分けて説明している。 如何にシステムトラブルの原因が様々で、かつその原因特定が難しいかがわかると思う。