日経コンピュータのレビュー一覧
-
Posted by ブクログ
私も一応管理者みたいなことをやってるので、「システムダウン」なんてあまり嬉しくない事態だが、それでも起こる、そして起きてほしくない時に限って起こる。 この本では、ダウンの原因を、ソフトウェアの不具合、性能・容量不足、設定操作ミス、不慮の事故、の４つに切り分けて、それぞれの事例を分析している。 もちろんこれらが複合して起こるケースもあり、対応を難しくしている。 基本的な姿勢としては、ダウンを100％防ぐのは不可能、ということを前提に、どうすればダウンをできるだけ減らせるか、起こってしまったときの被害をできるだけ減らせるか、ということを考察する。 解説もわかりやすく、得るところの多い内容だった。
-
Posted by ブクログ
ダウンしない完全なシステムはない、と繰り返し訴えつつ、様々な障害事例が紹介されています。保守エンジニアは共感できる部分が沢山ありそうですよ。
しかし、よくもまあここまで障害事例を集めたなあ、と関心します。素晴らしい。これまで自分が味わった障害はほとんど網羅されてるんじゃないかな、とさえ思う。
20分くらいで流し読みしましたが、予想外に楽しめ？ました。
1つ気になって、強く実感したこと。
『ソフトウェア障害に2重化は通用せず。』
2重化にも何通りかあるとはいえ、バージョンなど一緒にしていたら、同じ問題が起きるので確かにソフトウェアの2重化にはならないですね。
同一バージョンでのHA構成、ちょ -
Posted by ブクログ
【読者】 主に若手～中堅のITシステムの運用担当者および開発担当者だが、利用者にとっても有益
【目的】 ダウンの要因やメカニズムを理解し、ダウンの削減と迅速な復旧に資する
【一押】 システム設計から運用までをシステムダウンの観点から事例や図を使いわかりやすく解説している
【概要】 ダウンの原因は大きく分けて４つある。①ソフトウェア、OS、ミドルウェアの不具合、②ハード、ネットワークの性能・容量不足、③環境設定・運用操作ミス、④ハード故障、不慮の事故である。それらはダウン発生時の現象から切り分けて考えられる。現象としては、一部ダウンか全面ダウンか、発生が朝などの起動時か運転中かといったこと -
Posted by ブクログ
私みたいな素人でも読みやすいと感じたのは、
専門用語を簡単に説明してとっかかりやすくしてくれているから。
このシリーズ、他にも基礎的なものを説明してくれているものがあるようなので、
次はそっちを読んでみたいと思う！
「ダウン」の発生原因
・ダウンを防ぐための例外処理にバグがあった
・信頼性を高めるためにシステム構成を複雑にしたことが被害の拡大につながった
システムの「ダウン」＝システムが本来の役割を果たせていない状態を指す
結局は絶対ダウンしないシステムは作れない
→ダウンしてもすぐに復旧させる、ダウンした際の影響範囲を小さくする、同様のダウンが起きないように対策を講じるといったアプロ -
-
-
-
Posted by ブクログ
上層部と現場の間の連携が大事。
進捗報告、課題やゴールの共有など、上層部の意見を踏まえつつ現場からも意見を出して、協力して進めるべに。
システムは完成したら終わりではなく、稼働した瞬間から陳腐化する。
いつまで使えるのかを見極める。
時代の流れや業務内容の変遷に柔軟に対応して改修していく必要がある。
目先のリスクを見極める力が重要。
どんなトラブルが起こりうるかを予測し、トラブルを最短で打ち取るためのプランを検討しなければいけない。
トラブルをなくすことはできないので、リスク対策を念入りに行う。コンチプラン。
社名や登場人物が多くて理解するの大変。
1章、2章、3章と時間を遡るので、同じ -
-
-
-
-
Posted by ブクログ
2021年2月〜2022年2月までで合計11回のシステム障害。
冒頭から障害に関する記載の嵐。結局最後までずっと障害。
著者はITに詳しく、分かり易く伝えることをすごく意識しているのが伝わってくる。兎に角すごい取材力。
だだ、本書はITが分からない人は少し難しいと思う。
一方で、仕事でITに携わっている人であれば、アプリ、インフラ、運用のどの領域であっても、この本を読むことで、自身がこれまでのIT業務で経験した反省点を思い出させてくれる一冊。
内容の重複記載が多いのは難点。日経CPに掲載したものをコピペで纏めているからだろうか‥。
障害原因をしっかりと深掘りして、過剰なプロセスを増やす -
購入済み
周回遅れのシステムあるある集
第１章から第３章は同じ話の繰り返しで水増し感がある。後段は、以前の「苦闘の19年史」とさして変わらず、既読感が強い。半額でいいんじゃないだろうか。周回遅れの他人の不幸は面白いし、システム屋は読んでおく必要があるだろう。同じ轍を踏まないために。
-
-
-
-
Posted by ブクログ
"東京スカイツリー建設費650億円 7本分かかった
→4000億なかば
→35万人月
→ベンダー千社（日本のITベンダの1割）
一次委託先70-80社
■勘定系システムとは
→銀行における預金や融資、振込などの業務を支える情報システム
メガバンクの勘定系システムは
計1億ステップほど
→★絶句、、、
1人のエンジニアが1ヶ月で5-8行
→1000人のエンジニアが10年間開発を続けないといけない量
■合併や企業統合は100日勝負 と言われる
→統合を発表して100日以内に、統合の方針を固め、関係者一同がその方針に沿って進んでいくように、意思の統一を図る必要がある
→★ITプロ -
Posted by ブクログ
名実ともに日本最大となったIT開発プロジェクト「MINORI」について、その全容を記した一冊。
総開発費4,000億円超、1,000社以上が開発に携わった（少なくとも国内全IT開発ベンダーの10%以上が参画した）「IT業界のサグラダ・ファミリア」が、どのように推し進められたのかを知ることができる点で、とても貴重。
2021年現在もトラブルが頻発している現状を鑑みても、成功譚と呼ぶにはあまりにも複雑で、「苦闘の19年史」という副題が言い得て妙だと感じる。歳月をかけて肥大化したモンスターは簡単には御し難く、これから長い年月をかけて付き合っていかなければいけない問題として残り続けるんだろう。
こ -
Posted by ブクログ
省庁基幹系システムの失敗など、日本政府によるDXが進まない状況について、政府のIT発注能力と調達プロセスの貧弱さを指摘した本。過去の失敗事例や関係者のインタビューも含み、現況を理解するのには適している一方、ファクトベースに寄りすぎているためか記事のような印象も受けた。
政府の発注能力ついては、発注者側のIT人材不足によって大手ベンダーに調達仕様を依存していることがボトルネックとなっている。調達プロセスについても、業務分析から工程管理に至るまでのスキルやリソースが未成熟であることが指摘されている。ベンダー成果物を精査し、業務とシステムの双方に精通する職員の育成、ベンダーによる安値受注を防ぐ入札
