※開発の失敗と本稼働に入ってからの障害は本来分けるべきかもしれませんが、ここでは一緒に扱っています。
→システム運用
→テスト・品質管理
→ランサムウェア ←KADOKAWAニコニコ動画事例についてはこちら
→マルウェア
→個人情報の保護・漏洩
- 安定稼動のシステムこそ危険 2008.4.7
- 普段から障害ばかり起こすシステムと，数年にわたって1度の障害もなく安定稼働を続けているシステムでは，いざトラブルが起きると前者よりも後者のほうが大規模かつ悪質なケースが多い。
- システム部門は札付きシステムや札付きプログラムを，たびたび障害を引き起こす“犯人”としてマークする。しかし，最も恐ろしい障害は，マークしていたシステムやプログラムではなく，意外とノーマークのシステムやプログラムによってもたらされるものだ。
- すべての人間に強制的に検診を受けさせるのは難しいが，システムの場合は時間と体力をそれなりに費やす覚悟さえあれば，1年や2年に1度くらいの頻度でテストすることは可能だろう。札付きシステムはもちろん，優良システムであっても，定期的なチェックを欠かしてはならない。
CloudFlare障害†
2038年問題†
AWS障害†
CrowdStrikeブルースクリーン障害†
江崎グリコERP(SAP)システム移行失敗†
→Gmail関連を参照
- ※仕様の見落としというより、OS変更で32bit→64bitへのアーキ変更によって必要な領域サイズが変わるということを問題として認識できなかった、あるいは4テーブル合計サイズで計算しなければならないことを認識できていなかった（仕様認識の漏れ）か？
特許庁情報システムの開発失敗†
ファーストサーバ事故†
- ファーストサーバ最終報告書、ベテラン担当者のマニュアル無視を黙認 2012.7.31
- 「ファーストサーバ最終報告書、ベテラン担当者のマニュアル無視を黙認 」 2012.8.1
- おそらく問題認識が間違ってる．まるでドライバー一人で長距離バスを24時間連続運転させておきながら，ひとたび事故が起きれば「ドライバーの運転ミス／居眠り運転が原因です(キリッ)」と言うような感じ．その場合の事故の責任はドライバー以上に経営者にある．
- 対策においても「バックアップディスクへの変更について，明確に禁止した条項がないことから追加し，バックアップディスクの更新禁止を明確化する」とか書いてる時点でダメダメ．禁止を条項に書いたらコマンドの打ち間違いによる人的ミスが無くなるとでも？そういうのは全部ツールを作って，削除の禁止をツールの中に作り込んで，そのツールを使う限りどんなバカでもハッカーでも削除できないようにしておくんだよ．そもそもバックアップディスクが普通に物理的に触れるような場所に接続されてること自体が問題だろうし．
- ファーストサーバの事故から考えること 2012.6.25
- 致命的ミスと言えるのは、待機系(スタンバイ)サーバと、バックアップを混同してしまっていたことだと考えられます。
- 待機系サーバというのは、あるサーバが故障で動かなくなったさいに代わりに立ち上げるサーバであり、そのデータは常に本番環境と同じデータを保持している必要があります。そのため、本番環境で行われたオペミスなどは待機系サーバにも波及してしまいます。
- それに対し、バックアップというのは、基本的には「ある時点のデータ」を保存して、オペミスを含むデータ損失事故を防ぐというものです。
- これはIT技術者にとって基本的知識だと思われますが、その点の配慮が無かったことが最大の敗因でしょう。
みずほ銀行†
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
