大和田尚孝のレビュー一覧

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

前半はみずほこんなことやって頑張ったぜ！ドヤ！みたいな内容。生のコードを書けなくして属人化を防ぐ超高速開発ツールなど、なかなかおもろい仕組みを使っていたのが興味深かった。しかし、ツール名が「超高速開発ツール」というのがダサい。
コロナが流行る前からWeb会議を使っていたのは先進的だと思う。（とはいえ、私もIT企業に勤めていて、コロナ前からWeb会議使ってたから、IT企業的には普通なのかしら）

後半がめちゃくちゃ面白かった。2011年と2002年のシステム障害の発生の原因について細かく描写している。仕様書やデータフローがなかったり、合併時のシステム統合の際に役員の中に有識者がいないなどとにかくやばい。システムくらい勉強しろよ。
エンジニアが本当に気の毒。
社内政治とか読み物としては面白かったけど、当事者にはなりたくないと思った。
みずほのシステムの関係者の皆様お疲れ様です…

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

障害発生とその対応の話は学ぶべきことが非常に多い。規模も業界も違うが頷ける話が多かった。

大規模障害の原因を突き詰めると個々のプログラムの品質よりも組織の風土や統制、経営層の理解といった部分へ通じてくる。

システムは人が作って運用している以上、
どの企業でも本書のようなことが起こりうることは知っておかなければならないと感じた

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

どこかで読まねばと思いつつ、ようやく読んだ1冊。幸いというかエンジニアのキャリアの中でこのプロジェクトに関わることはなかったけれど、当時「ブラックホール（＝行ったら帰ってこれない）」と呼ばれていたプロジェクトを全体感に立って振り返っていて大いに横展開できる反省点は盗もうと思った1冊だった。やっぱりエラーハンドリングもそうだけど、初動とトップのITへの理解が大切。もし自分が関わることになっていたとしたら、どの辺を担当することになってそこで力を果たして発揮できただろうか、とか思いながら読んだ1冊でした。

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

システム開発・運用に関わった経験があれば、読み進めるごとにキリキリとした不安な気持ちを感じるリアリティに溢れる良書。

「経営の責任」が伏線となって障害の増幅要因としてヒットする様は出来のいい小説のようでもあり、類似の伏線が実は今の日本に多数転がっているという示唆はホラーのようでもあります。

プロジェクトに関わる方は、一度手に取られると良いと思います。

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

みずほフィナンシャルグループは、メガバンク史上初めてシステムを新たに再構築した。MINORIと呼ばれるシステムは、事務作業を大きく削減し、新しい機能を付加させるための開発費用を減らし、オープンイノベーションを促進する事が期待され、システムが寿命を迎える2025年の崖から転落しないよう各企業が見習うべき良いケースである。と思われていた。しかし結果は今の通りである笑

不具合続きの今から振り返ると、第1部の成功ケースよりも第2部・第3部の失敗学の方が遥かに有益であるように感じる。そもそも、失敗の原因として「システムのブラックボックス化」「風通しが悪く、責任者への報告が遅れ、対応が後手に回る」「経営陣のIT軽視」が述べられていたが、今回のシステム障害の再発防止報告書にも同様の内容が列挙されており、みずほ自体が過去の失敗から何も学んでいない事がよく分かる。トップが失敗を反省し、リーダーシップを持って再発防止に努めなければ、同様の問題が必ず再発するであろう。「再発防止チーム」みたいな組織をその場凌ぎで作り、放任しているようでは先は無い。

成功を収める企業から学べる事は多いが、再現性に乏しい事が多い。一方で失敗した企業から学べる事は、再現性が強いため、こうしたら失敗するという良い学びを得る事が出来る。多くのケースを吸収し、経営判断を迫られた際に失敗しない様にしたいと感じた。

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

みずほをこき下ろすだけではなく、システム統合の難しさと統合によって目指していた事も描かれており、公平なドキュメンタリー本だった。

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

銀行の既存の疎結合なシステムをどう新規開発していったかがメインな話
ニュースにもなったみずほのトラブルの裏側など読み応えがあった

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

ホラー小説より恐ろしい 。SE必読の快作！- 「みずほ銀行システム統合、苦闘の19年史」　★★★★☆

恐ろしい。心底おそろしい。私もシステム開発を仕事として行っているので、こんなプロジェクトに配属されたらダウンする自信がある。
大きく3章で構成されており、1章は新システム「MINORI」の機能と開発秘話になります。大して面白くないです。SOA開発なんて普通じゃんか。
2章は「MINORI」の開発を始めるきっかけとなった東日本大震災直後のシステムトラブルの原因になります。恐ろしい。
3章は2章を引き起こすことになった真因である2002年の3行合併のいざこざと、合併直後のトラブルについて。まぢ恐ろしい。
お笑い芸人の「こんなシステムは嫌だ」に使えそうなネタ満載でたまりません。・3社合併だと思ってたら4社だった。
・一番大きい会社のシステムが一番ゴミ
・ゴミだってわかっているけど、コンサルさんは引き分けって言うしかない
・偉い人の中では決まっているけどそれは部下に伝えない
・障害は手作業で復旧
・障害が障害を呼ぶ（マドハンド状態）
・振込できてないのに残高が減る
・他支店の口座にアクセスするには成り代わりが必要
・偉い人はシステムに無知

一番ダメなのは、「合併直前のみずほFGの経営会議のメンバー、旧三行の頭取、副社長6人、CFO、CSO、CRO、CCOであった。後ろ3つの役職は馴染みがない。最重要課題なのに、情報システム責任者のCIOがいない。」これよね。銀行なんてシステムがなきゃなんもできないんだから。
システム開発を行っている人は是非読んでください！統合を考えている経営者は必読でお願いします。

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

システムダウンとは、そのシステムにおいて期待されるサービスが利用不可となること。

本書では、様々なシステムダウンの事例にあたりながら、その原因と対応策について迫っていく。

「システムダウンを100％防ぐことはできない」「人はミスをする生き物である」といったメッセージを受け取った。

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

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

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

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

いい本ですね。

システム統合の「正攻法」（日経BP Next ICT選書）

三菱東京UFJ銀行のシステム統合を題材にした、大規模システム統合の実態および考慮事項などなど。
自分はなかなかこういう仕事（大規模システム開発の PM）に携わる部署ではないが、知っておくことは大事。その勉強としては良い本だと思い、この評価にしている。

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

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

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

就職しＩＴの現場に入り、
直接現場の仕事とは関係ない、
システム関係の本として一冊目に読んだ本。

なんでよりによってシステムダウンを選んだのかは
いまだに不明ですが、当時、恐怖を感じその後慎重に仕事を進める
心構えを作るには十分な内容になっていたと記憶しているのですが、肝心な内容はあんまり覚えていない。

読み返します・・・・。

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

私は社内SEを初めて1年ちょっとの新米SEですが、社内で使うシステムやプログラムを作るようになり、システムを作る際にダウンのことまで考える必要性を感じて読んでみました。

まだシステムのことやプログラミングの知識は少ない私ですが、非常に分かりやすく、楽しく最後まで読めました。
一口にダウンと言っても色々な原因があることが分かりました。

時々再度して、自分のシステムがダウンを起こさないようにしたいと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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