![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2025-10-30T22:14:59+09:00","default:irrp","irrp") #author("2025-10-31T23:54:51+09:00","default:irrp","irrp") ※開発の失敗と本稼働に入ってからの障害は本来分けるべきかもしれませんが、ここでは一緒に扱っています。 →システム運用 →テスト・品質管理 →ランサムウェア ←KADOKAWAニコニコ動画事例についてはこちら →マルウェア →個人情報の保護・漏洩 #contents *一般 [#qc30d76e] -[[韓国、政府のオンラインストレージが火災で焼失 8年分の業務資料858TBが消滅か バックアップなく「気が遠くなる」 現地報道 - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2510/07/news112.html]] 2025.10 -[[ヤマト運輸「基幹システム移管」による障害、2日かかって復旧 - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2505/15/news116.html]] 2025.5 -[[ヤマト運輸の障害、24時間経過も復旧せず 基幹システム移管の影響続く - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2505/13/news189.html]] 2025.5 -[[ETCシステム障害、復旧までに38時間かかった理由は“見込み違い” 作業完了後に障害拡大 - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2504/10/news117.html]] 2025.4 -[[東京科学大学病院、富士通→IBMに切り替えたシステムで大規模障害、なぜ？ | ビジネスジャーナル>https://biz-journal.jp/company/post_386760.html]] 2025.3 -[[NHKがシステム開発を委託した日本IBMを提訴→日本IBMの反論が生々しい「仕様書にない仕様が満載」「やはり議事録...議事録は全てを解決する」 - Togetter [トゥギャッター]>https://togetter.com/li/2512998]] 2025.2 -[[NHKに提訴された日本IBMの反論が生々しい…仕様書に記載ない仕様が満載 | ビジネスジャーナル>https://biz-journal.jp/company/post_386528.html]] 2025.2 -[[日本IBM、NHKシステムの開発中断について見解 「協議の継続を希望する」 - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2502/07/news182.html]] 2025.2 -[[「サッと助けてくれるエンジニア」は、試行錯誤の質が高い。 nrs氏に聞く「経験の積み方」 | レバテックラボ（レバテックLAB）>https://levtech.jp/media/article/interview/detail_592/]] 2025.1 -[[ITエンジニアが遭遇する「摩訶不思議」な現象とその真相 #Python - Qiita>https://qiita.com/Sakai_path/items/40550594b13a6328cd68]] 2025.1 -[[滋賀銀行が次世代勘定系システムの構築を中止、日立が和解金80億円を支払い | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/news/24/01984/]] 2024.12 -[[1600便以上が欠航して損害総額が190億円以上に及んだ航空システム障害は3文字略称「DVL」でバックアップごと破綻したのが原因 - GIGAZINE>https://gigazine.net/news/20241119-uk-air-traffic-system-failure/]] 2024.11 -[[国内の複数組織に影響が及んだSalesforceのシステム障害についてまとめてみた - piyolog>https://piyolog.hatenadiary.jp/entry/2024/11/18/040039]] 2024.11 -[[約5日間「資産状況が全く確認できない」状態に マネフォ、SBI証券の連携で不具合 原因は - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2410/30/news188.html]] 2024.10 --スクレイピングしていたページのデザインが変わった -[[先輩社員がどうやって不具合を解決しているのか #Java - Qiita>https://qiita.com/opengl-8080/items/56d31fe80b45773dc808]] 2024.10 -[[日本通運のシステム開発訴訟、指摘多数の原因は「特殊な検収」とアクセンチュアは反論 | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/column/18/00001/09780/]] 2024.9 -[[PCが急に落ちちゃうんです！って言われて調べてみたら利用者の持ち物が原因だったの情シスあるある？→「あれそんな仕組みだったのか…」 - Togetter [トゥギャッター]>https://togetter.com/li/2441142]] 2024.9 -[[エンジニアなら知っておきたい障害報告&再発防止策の考え方>http://qiita.com/hirokidaichi/items/f9f4549c88aaf8b38bda]] 2014.1.19 -[[安定稼動のシステムこそ危険>http://itpro.nikkeibp.co.jp/article/COLUMN/20080117/291336/]] 2008.4.7 --普段から障害ばかり起こすシステムと，数年にわたって1度の障害もなく安定稼働を続けているシステムでは，いざトラブルが起きると前者よりも後者のほうが大規模かつ悪質なケースが多い。 --システム部門は札付きシステムや札付きプログラムを，たびたび障害を引き起こす“犯人”としてマークする。しかし，最も恐ろしい障害は，マークしていたシステムやプログラムではなく，意外とノーマークのシステムやプログラムによってもたらされるものだ。 --すべての人間に強制的に検診を受けさせるのは難しいが，システムの場合は時間と体力をそれなりに費やす覚悟さえあれば，1年や2年に1度くらいの頻度でテストすることは可能だろう。札付きシステムはもちろん，優良システムであっても，定期的なチェックを欠かしてはならない。 *2038年問題 [#y6e167de] -[[COBOL技術者の減少と、技術の「時限爆弾」に我々はどう向き合うべきか 〜「昭和100年」を前に〜【フォーカス】 | レバテックラボ（レバテックLAB）>https://levtech.jp/media/article/focus/detail_583/]] 2024.12 -[[対応が難しい「2038年問題」、人気OSSでも対策はまだという不安な実態 | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/column/18/00989/121000165/]] 2024.12 -[[「2038年問題」が2000年問題と比べ桁違いにヤバい…社会インフラで障害も | ビジネスジャーナル>https://biz-journal.jp/company/post_383968.html]] 2024.10 -[[32bitを超えるtime_t型を持つ環境における2038年問題とその検出 |情報学広場：情報処理学会電子図書館>https://ipsj.ixsq.nii.ac.jp/ej/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=239377&item_no=1&page_id=13&block_id=8]] 2024.9 *AWS障害 [#u5af4359] -[[Amazon 人材流出 ついに AWS をダウンさせる | ScanNetSecurity>https://scan.netsecurity.ne.jp/article/2025/10/31/53937.html]] 2025.10 -[[【AWS】バージニア北部リージョンの障害レポートを読んだので図解してみた - APC 技術ブログ>https://techblog.ap-com.co.jp/entry/2025/10/30/203606]] 2025.10 -[[米国東部（バージニア北部、US-EAST-1）リージョンにおける Amazon DynamoDB サービス中断の概要>https://aws.amazon.com/jp/message/101925/]] 2025.10 -[[【Infostand海外ITトピックス】世界を止めたAWS障害 技術的問題の裏に「組織的知識の喪失」 - クラウド Watch>https://cloud.watch.impress.co.jp/docs/column/infostand/2058097.html]] 2025.10 -[[2025年10月発生の AWS us-east-1 障害を検証：STS リージョン分離が影響を緩和したか？ - サーバーワークスエンジニアブログ>https://blog.serverworks.co.jp/aws-us-east-1-outage-oct-2025-sts-regionalization-analysis]] 2025.10 -[[AWS大規模障害の教訓：単一クラウドが単一障害点になる時代、金融システムはどう備えるべきか #マルチクラウド - Qiita>https://qiita.com/yoshimitsu-k-i-a/items/5dedf016adab925eae2a]] 2025.10 -[[AWSが大規模障害の詳細な分析を発表：たった一つのDNSの不具合が世界を止めた理由 | XenoSpectrum>https://xenospectrum.com/aws-outage-post-mortem-dynamodb-dns-race-condition/]] 2025.10 -[[AWS、19日からの大規模障害について謝罪し、再発防止策を発表 - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2510/24/news078.html]] 2025.10 -[[AWSの大規模障害でウェブの半分がダウンし数十兆円規模の経済的損失が出たとの指摘、優秀なエンジニアがAWSを離れている証拠であるという指摘も - GIGAZINE>https://gigazine.net/news/20251022-aws-problem-knock-out-half-web-costing-billions/]] 2025.10 -[[AWS大規模障害、ついに解消--2000以上のサービスに影響した理由は？ - CNET Japan>https://japan.cnet.com/article/35239436/]] 2025.10 -[[AWS障害はなぜグローバルに拡大したか？ US-EAST-1の「単一障害点」構造を徹底分析>https://zenn.dev/gorn/articles/1ce5cc1b5278f4]] 2025.10 -[[バージニア北部リージョンで障害が発生するとヒヤヒヤする理由 | DevelopersIO>https://dev.classmethod.jp/articles/us-east-1-global/]] 2023 -[[AWS障害、原因特定も日本時間の21日午前6時時点では完全復旧に至らず - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2510/21/news059.html]] 2025.10 *CrowdStrikeブルースクリーン障害 [#gea35f51] -[[Microsoft、システム障害再発防止へ会合 9月10日に - 日本経済新聞>https://www.nikkei.com/article/DGXZQOGN2432F0U4A820C2000000/]] 2024.8 -[[Xユーザーのタマゴケさん: 「CrowdStrikeのBSODの経緯と原因 概要：入力パラメータ数を誤認して実装し、たまたま全てのテスト、ドッグフーディング、フィールドテストを通り抜けた境域外メモリ読み出し>https://x.com/s5ml/status/1823140252594372691]] 2024.8 -[[CrowdStrikeが訴訟の嵐に直面する可能性。ポイントは契約の細かな部分に | WIRED.jp>https://wired.jp/article/crowdstrike-outage-microsoft-delta-lawsuits-analysis/]] 2024.8 -[[ブルースクリーンオブデスで世界的な障害を引き起こしたCrowdStrikeが根本原因分析を発表 - GIGAZINE>https://gigazine.net/news/20240809-crowdstrike-root-cause-analysis/]] 2024.8 --[[CrowdStrike releases root cause analysis of the global Microsoft breakdown - ABC News>https://www.abc.net.au/news/2024-08-07/drt-crowdstrike-root-cause-analysis/104193866]] 2024.8 -[[Recover AWS resources affected by the CrowdStrike Falcon agent | AWS re:Post>https://repost.aws/knowledge-center/ec2-instance-crowdstrike-agent]] 2024.7 -[[デルタ航空、世界的システム障害で補償請求へ＝ＣＮＢＣ｜ニューズウィーク日本版 オフィシャルサイト>https://www.newsweekjapan.jp/stories/business/2024/07/post-105238.php]] 2024.7 -[[MicrosoftがCrowdStrike障害についての分析結果を報告、将来の改善点についても説明 - GIGAZINE>https://gigazine.net/news/20240729-windows-crowdstrike-explains/]] 2024.7. -[[大規模システム障害、原因は品質管理の不具合＝クラウドストライク | ロイター>https://jp.reuters.com/business/technology/H7GTQ52ESNO6DN2EXXXD33R3TE-2024-07-25/]] 2024.7 -[[CrowdStrikeのブルスク、Fortune 500の損失は総額54億ドル──米保険企業試算 - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2407/25/news099.html]] 2024.7 -[[CrowdStrikeのWindowsブルースクリーン問題を神回避した米航空会社、その理由が話題に【やじうまWatch】 - INTERNET Watch>https://internet.watch.impress.co.jp/docs/yajiuma/1610327.html]] 2024.7 -[[Microsoftが「CrowdStrikeの障害の原因は欧州委員会のクレーム」と当てこすり、なぜMacは無傷だったのかも浮き彫りに - GIGAZINE>https://gigazine.net/news/20240722-microsoft-crowdstrike-eu/]] 2024.7 -[[大規模システム障害で米国が大混乱、「クラウドストライクショック」いまだ収まらず | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/column/18/00001/09566/]] 2024.7 -[[2024年7月19日発生した障害に関する技術情報 | CrowdStrike>https://www.crowdstrike.jp/technical-details-on-todays-outage/]] 2024.7 -[[「Windows」大規模ブルースクリーン障害、原因はクラウドストライク製ソフトウェア - ZDNET Japan>https://japan.zdnet.com/article/35221731/]] 2024.7 -[[CrowdStrikeのブルスク問題の影響を受けたPCは世界で850万台──Microsoft推定 - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2407/21/news055.html]] 2024.7 -[[史上最悪のIT障害「CrowdStrike問題」に便乗したフィッシング詐欺が急増中 - GIGAZINE>https://gigazine.net/news/20240722-fake-crowdstrike-fixes/]] 2024.7 -[[Likely eCrime Actor Capitalizing on Falcon Sensor Issues | CrowdStrike>https://www.crowdstrike.com/blog/likely-ecrime-actor-capitalizing-on-falcon-sensor-issues/]] 2024.7 --便乗してマルウェアを仕込もうとする事例 -[[世界的システム障害「保険上の大惨事」、多額の請求予想＝専門家 | ロイター>https://jp.reuters.com/business/2SXX5LTUU5IOFJOUKW2H6MDIR4-2024-07-19/]] 2024.7 -[[クラウドストライクが「Windowsブルスク化」システム障害の解析結果を発表 - ケータイ Watch>https://k-tai.watch.impress.co.jp/docs/news/1609910.html]] 2024.7 -[[【2024年7月19日に発生したWindowsサーバー障害に関する記事】AWS ナレッジセンターに公開された手順でルートボリューム置き換えによる回復を実施しました。 - サーバーワークスエンジニアブログ>https://blog.serverworks.co.jp/2024/07/20/180000]] 2024.7 -[[【2024年7月19日に発生したWindowsサーバー障害に関する記事】レスキュー用Windows EC2インスタンスを作成し、復旧対象のWindows EC2インスタンスから不要なファイルを削除する方法 - サーバーワークスエンジニアブログ>https://blog.serverworks.co.jp/2024_7_19_windows_server_blue_screen_recovery]] 2024.7 -[[米クラウドストライク、カーツCEOが状況説明もユーザーは恨み節 「配布前にテストしたのか？」「なぜ金曜日に」 - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2407/19/news191.html]] 2024.7 -[[It’s not just CrowdStrike - the cyber sector is vulnerable>https://www.ft.com/content/d2f529fe-3050-4ef5-a8c7-6487d533e57a]] 2024.7 -[[CrowdStrike社のセキュリティソフトに起因するWindowsのシステム障害（BSOD）について - セキュリティ事業 - マクニカ>https://www.macnica.co.jp/business/security/manufacturers/crowdstrike/news20240719.html]] 2024.7 -[[同時多発ブルースクリーン障害、国内企業の影響まとめ USJ「1台1台手当てしているので時間がかかる」 - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2407/19/news189.html]] 2024.7 -[[Statement on Falcon Content Update for Windows Hosts - crowdstrike.com>https://www.crowdstrike.com/blog/statement-on-falcon-content-update-for-windows-hosts/]] 2024.7 *江崎グリコERP(SAP)システム移行失敗 [#v849b460] -[[「プッチンプリン」＆「カフェオーレ」ついに復活──8月6日に出荷再開 障害から約4カ月で - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2407/19/news173.html]] 2024.7 -[[ランサムウェアでシステム壊されてた→わかる。プロに委託してシステム更新しようとしたらプリンが出荷できなくなった→なぜ - Togetter [トゥギャッター]>https://togetter.com/li/2386546]] 2024.6 -[[日本のIT人材が｢平均年収1200万円｣に達するのはいつなのか…周回遅れの日本企業に迫る｢2025年の崖｣という危機 グリコ出荷停止騒動は他人事ではない | PRESIDENT Online（プレジデントオンライン）>https://president.jp/articles/-/82624]] 2024.6 -[[グリコ、ITの精鋭部隊を年収500万円で募集→「悲劇のトラブル招いた原因」 | ビジネスジャーナル>https://biz-journal.jp/company/post_381651.html]] 2024.6 -[[「プッチンプリン」未だ復活せず。システム障害の影響が長引く江崎グリコ、社内SE募集のまさかの“低待遇”に「だからコケたまま」と呆れる声が続出 | マネーボイス>https://www.mag2.com/p/money/1460256]] 2024.6 -[[グリコがSAP技術者募集中！グリコ製品を早く供給してほしいエンジニアは急げ！ - Togetter [トゥギャッター]>https://togetter.com/li/2382345]] 2024.6 -[[デロイト、グリコに加えユニ・チャームでもシステム障害…ベンダ能力に疑問も | ビジネスジャーナル>https://biz-journal.jp/company/post_381357.html]] 2024.5 -[[グリコ、障害で売上200億円の損失…ベンダのデロイトに損賠賠償請求の可能性 | ビジネスジャーナル>https://biz-journal.jp/company/post_380797.html]] 2024.5 -[[長期化するグリコ出荷停止 需要期前に不安の声 Ａコープは他社製品で代替 / 日本農業新聞>https://www.agrinews.co.jp/news/index/233018]] 2024.5 -[[「S/4HANA」への切り替えでトラブルの江崎グリコ、1カ月経過も商品の出荷停止続く | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/column/18/01157/050900110/]] 2024.5 -[[グリコ、チルド食品の出荷停止を延長 5月中旬→「未確定」に - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2405/01/news144.html]] 2024.4 -[[江崎グリコの基幹システム移行トラブルについてまとめてみた - piyolog>https://piyolog.hatenadiary.jp/entry/2024/04/26/013037]] 2024.4 -[[グリコ｢17品出荷停止｣巨大プロジェクトで大誤算 40年ぶり社長交代で"データ志向"を目指したが | 食品 | 東洋経済オンライン>https://toyokeizai.net/articles/-/750383]] 2024.4 *神奈川県立高校入試システム障害 [#h25c929c] →[[Gmail関連>https://www.sangyo-rock.com/tech/index.php?Gmail%B4%D8%CF%A2#qed98157]]を参照 *全銀システム障害 [#hc4453b1] -[[「全銀システム障害」とは何だったのか 解明まで時間がかかった理由と、待ち構える“茨の道”とは（1/5 ページ） - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2312/28/news104.html]] 2023.12 -[[すべてのフェーズでミスが重なった ―全銀ネットとNTTデータ、全銀システム通信障害の詳細を説明 | gihyo.jp>https://gihyo.jp/article/2023/12/zengin-nttdata]] 2023.12 -[[全銀システム障害とは何だったのか【鈴木淳也のPay Attention】-Impress Watch>https://www.watch.impress.co.jp/docs/series/suzukij/1551556.html]] 2023.12 -[[全銀ネット障害、原因は仕様の”見落とし“ 設計者がチェックしていれば防げた可能性も - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2312/01/news179.html]] 2023.12 -※仕様の見落としというより、OS変更で32bit→64bitへのアーキ変更によって必要な領域サイズが変わるということを問題として認識できなかった、あるいは4テーブル合計サイズで計算しなければならないことを認識できていなかった（仕様認識の漏れ）か？ -[[【LIVE】NTTデータと全銀ネットの両トップが会見 10月のシステム障害受けて（12月1日）| TBS NEWS DIG>https://www.youtube.com/live/1WvRPuNfbFs?si=iwQ5iyyq9umkP21P&t=634]] 2023.12 -[[全銀システム障害の真因はメモリーの確保領域不足、全銀ネットとNTTデータが発表 | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/news/18/16364/]] 2023.12 -[[全銀システムの大規模障害、「真の原因」明らかに--全銀ネットとNTTデータが発表 - CNET Japan>https://japan.cnet.com/article/35212251/]] 2023.12 -[[全銀システム障害に残る3つの謎を追う、生成AIには負けられない | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/column/18/00138/111401408/]] 2023.11 -[[全銀ネット障害、根底に“開発体制の不備”か NTTデータの見解 - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2311/07/news129.html]] 2023.11 -[[全銀システム障害、全銀ネットの対応で不足していたもの【鈴木淳也のPay Attention】-Impress Watch>https://www.watch.impress.co.jp/docs/series/suzukij/1542501.html]] 2023.10 -[[全銀ネット障害、いまだ根本原因特定できず メモリ不足の指摘には「分からない」 - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2310/18/news179.html]] 2023.10 -[[システム障害に係る対応状況について>https://www.zengin-net.jp/announcement/pdf/announcement_20231018_2_besshi.pdf]] 2023.10 -[[プログラムミスで容量不足 全銀システム障害|47NEWS（よんななニュース）>https://www.47news.jp/9999417.html]] 2023.10 -[[全銀システム障害の原因判明、メモリー不足でインデックステーブルが不正確な状態に | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/news/18/16109/]] 2023.10 -[[2029年まで続く『全銀システム』リスク。次回は2024年1月に計画（神田敏晶） - エキスパート - Yahoo!ニュース>https://news.yahoo.co.jp/expert/articles/07e605145d5fa1ca5ac95d9b741bdb53c91f623c]] 2023.10 -[[全銀システム障害と、同システムが目指す将来像【鈴木淳也のPay Attention】-Impress Watch>https://www.watch.impress.co.jp/docs/series/suzukij/1538720.html]] 2023.10 -[[「テストを当然実施してきた」、全銀ネットが10日に開催した説明会の一問一答 | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/column/18/00001/08495/]] 2023.10 -[[全銀システムの大規模障害、中継コンピューター2台ともに不具合で冗長構成が機能せず | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/news/18/16078/]] 2023.10 -[[全国銀行データ通信システムのシステム障害についてまとめてみた - piyolog>https://piyolog.hatenadiary.jp/entry/2023/10/11/131415]] 2023.10 -[[全銀システムで中継コンピューターのチェック機能に不具合、40万件が処理できず | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/news/18/16074/?i_cid=nbpnxt_sied_blogcard]] 2023.10 -[[50年間も動き続けていた全国銀行資金決済ネットワークがシステム障害で振込処理ができない状態になっている「これはヤバい」「給料が振り込まれない」 - Togetter>https://togetter.com/li/2239071]] 2023.10 * 特許庁情報システムの開発失敗 [#g2d65e18] -[[決して簡単ではない行政システム改革、特許庁での経験から行政デジタル化を案じる | IT Leaders>https://it.impress.co.jp/articles/-/20223]] 2020 -[[政府のソフトウェア調達の改善について>https://www.issj.net/teigen/1303_software_choutatsu.pdf]] 2013 -%%[[経産省による特許庁情報システムに関する調査報告書>http://www.meti.go.jp/press/20100820003/20100820003-2.pdf]]%% ←いつのまにか消されていた -[[経産省による特許庁情報システムに関する調査報告書@国会図書館アーカイブ>https://warp.da.ndl.go.jp/info:ndljp/pid/8658576/www.meti.go.jp/press/20100820003/20100820003-2.pdf]] -%%[[「特許庁業務・システム最適化計画」(改訂版)について@特許庁>http://www.jpo.go.jp/torikumi/system/system_optimize_re.htm]]%% ←同上 -[[特許庁のシステム開発が破綻した本当の理由>http://satoshi.blogs.com/life/2013/01/toshiba.html]] 2013.1.6 --破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。 -%%[[【ITブラック】特許庁システムにまつわる黒い話が色々ヤバイ>http://matome.naver.jp/odai/2135019355282582601]]%% 2012.10.14 -[[特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐>http://www.publickey1.jp/blog/12/gpmo.html]] 2012.1.31 -[[特許庁の55億かけて頓挫したプロジェクトの報告書が面白い>http://anond.hatelabo.jp/20120127061544]] 2012.1.27 -[[特許庁の情報システムについて>http://myatsumoto.hatenablog.com/entry/2012/01/26/082554]] 2012.1.26 -[[特許庁情報システムに関する技術検証委員会 | 経済産業省 特許庁>https://www.jpo.go.jp/resources/shingikai/kenkyukai/system/index.html]] 2012 *ファーストサーバ事故 [#a4a96c16] -[[データ消失！あのとき、ファーストサーバになにが起こったか？>http://ascii.jp/elem/000/000/913/913202/]] 2014.7.27 -[[大規模障害から1年余り、あの企業が「その後」を語った>http://itpro.nikkeibp.co.jp/article/Watcher/20140214/536882/?ST=security&P=1]] 2014.2.20 -[[「軽過失だが比較的重度の過失」とは？ 法律家が読み解く、ファーストサーバ事件報告書>http://jibun.atmarkit.co.jp/lskill01/rensai/law/02/01.html]] 2012.8.9 -[[ファーストサーバ、データ消失事故の再発防止策を発表>http://www.itmedia.co.jp/news/articles/1208/10/news051.html]] 2012.8.10 -[[6月20日から21日にかけて発生した一連の事故の再発防止策>http://support.fsv.jp/urgent/fs-report.html]] 2012.8.10 -[[ファーストサーバ最終報告書、ベテラン担当者のマニュアル無視を黙認 >http://itpro.nikkeibp.co.jp/article/NEWS/20120731/413084/?ST=cloud&P=1]] 2012.7.31 --[[「ファーストサーバ最終報告書、ベテラン担当者のマニュアル無視を黙認 」>http://d.hatena.ne.jp/JavaBlack/20120801/p1]] 2012.8.1 ---おそらく問題認識が間違ってる．まるでドライバー一人で長距離バスを24時間連続運転させておきながら，ひとたび事故が起きれば「ドライバーの運転ミス／居眠り運転が原因です(キリッ)」と言うような感じ．その場合の事故の責任はドライバー以上に経営者にある． ---対策においても「バックアップディスクへの変更について，明確に禁止した条項がないことから追加し，バックアップディスクの更新禁止を明確化する」とか書いてる時点でダメダメ．禁止を条項に書いたらコマンドの打ち間違いによる人的ミスが無くなるとでも？そういうのは全部ツールを作って，削除の禁止をツールの中に作り込んで，そのツールを使う限りどんなバカでもハッカーでも削除できないようにしておくんだよ．そもそもバックアップディスクが普通に物理的に触れるような場所に接続されてること自体が問題だろうし． -[[第三者調査委員会「 調査報告書 （ 最終報告書 ） ＜ 要約版 ＞ 」>http://support.fsv.jp/urgent/pdf/fs-report.pdf]] 2012.7.31 -[[緊急特集：ファーストサーバ社データ消失事故の教訓（２）クラウド技術は全体最適の視点がないと難しい −ITアーキテクト・鈴木雄介氏>http://wirelesswire.jp/Inside_Out/201207241630.html]] 2012.7.24 -[[ファーストサーバの事故から考えること >http://shunichi-arai.blogspot.jp/2012/06/blog-post_25.html]] 2012.6.25 --致命的ミスと言えるのは、待機系(スタンバイ)サーバと、バックアップを混同してしまっていたことだと考えられます。 --待機系サーバというのは、あるサーバが故障で動かなくなったさいに代わりに立ち上げるサーバであり、そのデータは常に本番環境と同じデータを保持している必要があります。そのため、本番環境で行われたオペミスなどは待機系サーバにも波及してしまいます。 --それに対し、バックアップというのは、基本的には「ある時点のデータ」を保存して、オペミスを含むデータ損失事故を防ぐというものです。 --これはIT技術者にとって基本的知識だと思われますが、その点の配慮が無かったことが最大の敗因でしょう。 -[[大規模障害の概要と原因について（中間報告）>http://support.fsv.jp/info/nw20120625_01.html]] 2012.6.25 --ファーストサーバ大規模障害の報告 -[[ソフトバンクグループのファーストサーバがバックアップ含めデータ全消失、復旧不可能確定。 >http://nosoftbankno.blog84.fc2.com/blog-entry-177.html]] 2012.6.15 *みずほ銀行 [#nc268b38] -[[みずほ銀行のトラブルに学ぶ５つの教訓 - Qiita>https://qiita.com/FumioYoshida/items/bbabe44307de0f71ad42]] 2022.10 -[[みずほ銀行システム障害に学ぶ | 川口耕介のブログ>https://ja.kohsuke.org/software/mizuho-outage/]] 2021 -[[データ移行で発生したみずほ銀行のシステム障害についてまとめてみた - piyolog>https://piyolog.hatenadiary.jp/entry/2021/03/01/055810]] 2021.3 -[[みずほ銀行のマルチベンダー化について解説する>http://d.hatena.ne.jp/NOV1975/20121120/p2]] 2012.11.20 -[[みずほの次期システムはマルチベンダー、4社に分割発注 >http://itpro.nikkeibp.co.jp/article/COLUMN/20121116/437901/]] 2012.11.20 --みずほ銀行が次期システムの開発をマルチベンダー体制で進めることが日経コンピュータの取材で判明した。富士通、日立製作所、日本IBM、NTTデータの4社に分割発注する
