「障害」というものについて、一度も書いてなかったような気がする。
障害・・（つまりは「システム障害」のことね）について語りたいことは、たくさんある。IT土方は皆、同じような思いを持っていることだろう。
インフラのレイヤにいれば、ゼッタイに障害と向き合わなければならない。そして、上流にいようが下流だろうが、障害はつきまとう。
なぜなら、（たかが）機械を相手にしているからだよ。
要件定義や設計では「耐障害性」にすぐれたシステムをつくりましょう、と合意される。そんなの当たり前だ。すぐ壊れるシステムなんざ、ポンコツ扱いで誰も使ってくれないからだ。
そこでとられる手法は、要は「冗長化」「二重化」「クラスタ」とか呼ばれる手法。片方が壊れても片系で動くから「サービス影響」はありませんよ、という理屈ね。
（同業者にはあまりにあたりまえのことを書いているな。。）
クリティカルなシステムであればネットワーク上のどの経路も冗長化されている。ＳＰ（シングルポイント）は許されない。たとえつくるためのお金がなくとも、絶対に許されない。（本来は）
ＳＰを許容しておくと、それがたとえユーザ合意の上であったとしても、ユーザのゴリ押しであったとしても、もしそこが原因で重大障害になってしまったら、ユーザは知らんぷりで、作った側に責任をおっかぶせられちまうからだ。
「あのとき、（オマエらが）もうちょっと強く冗長化の提案をしてくれればこんなことにはならなかったんだ！」ぐらいのことは、客にいわれる。テメーらがインフラにカネをケチったからだろ？ ボケが。
最近は、ネットワークシステム自体が激甚災害でぶっ壊れちまったときのために、遠隔地にＤＳ（ディザスタサイト）を構築したりする。バカみたいに金がかかる。けど、これだけＩＴインフラが企業にとって重要性が高まってくると、やらざるを得ない。
一旦構築して、追加構築追加構築を繰り返してスパゲティ状態になっているインフラは、災害でぶっこわれたら金輪際もとには戻らない。
バックアップをとっていようがいまいが、関係ない。戻らないものは戻らんのだ。
そうなってしまったら。もうたぶんその会社はつぶれちゃう。忠誠心のある会社員が生き残ったって、自社ビルが残ったって、会社を継続することはできない。ＩＴインフラは、企業にとってそれぐらいのインパクトがあるんだ。
ところで。。
エンドユーザにしてみれば、サービスが提供されていれば別に構わないんだろうけど（片系で動いている状況では、ちょっとレスポンスが遅くなったりすることもあるが）、オイラたちにしてみれば、ちょっと片側が動かなくなっても、障害は障害。
障害票切ったり、同報メールで状況流したり、客に説明したり、切り分けしたり、ハード障害だったらベンダ呼んで交換させたり、ソフトだったらアプリ側のＳＥにエスカレーションしたり。。
とにかく、軽度の障害であっても、いろいろ超めんどくさい。
これがもう、エンドユーザに影響が出ているとなったらもう、祭りだよね。客（この場合の「客」とは、そのシステムを保有している会社のこと）の情シス部長クラスが出てきて「早く直せ」と大騒ぎ。
昔のホストで「オレたちも昔はよく徹夜したなあ」みたいなおっさんども（今はちょっとは出世してんのか？）がわらわらとあらわれて、都度状況説明させられて、ハッキリいってあんたらジャマ。ふだん窓際のくせに。。とか思いつつ（これは、冗談だけどね）
「祭り」になったらもうハイだから、なりふり構わないけど、軽度障害のときは、もう手続きがアホらしくてな。。
バックアップが失敗しただの、サーバに赤いランプがついているだの、ノード監視が失敗しているだの。。 そういう障害って、ホント多い。
それに、障害ってさ、何歳になっても、緊張するし。
軽度障害でも、プレッシャーはかかるんだよ、ものすごく。
で、そういうのに迅速に対処する「縁の下の力持ち」が、オイラたちIT土方なわけだ。
前に「定義」の話を書いたはずだけど、リアルドカちんは作った建築物の運用はしないけど、オイラたちはやる。「セコム」みたいなもんだ。
ふだん「つかえねーやつら」「カネ食い虫」とか思われている（であろう）運用部隊も、きびきびと障害対応して、適切なタイミングで報告を入れ、アプリ側と連携し、無事、短時間で収束させたりすると、見直される。
同業者の皆さんは、お客が注目する障害対応時はそれなりに「演技」して、誠意をみせといたほうがいいよ。
でもさー、障害って、取り巻きで見てるやつらはのんきなもんだけど、当事者にはもうなりたくないんだよね。。 正直なところ。
発生した障害に対する対応者になりたくないし、もちろん引き起こす側にもなりたくない。オペミスで障害になったりしたもんなあ。。昔。
本番ルータのコンフィグ間違ってセーブしたら疎通できなくなったとか。。
しかも、ダマで作業してるときに。
そういうときに限ってエンドユーザが先に気付くんだよ。。 そして大問題になる。
あー、思い出したくもない。
本番作業ってホント、やりたくないよね。しかも他人が作った手順書とか。
運用の現場って手順書レビューなんて、ザルだからな。
東証だっけ？ 手順書レビューがなってなくて、マスコミに出るぐらいの大規模障害になったのって。
でも、レビューやったところで、結局何か起こって非難の矢面に立たされるのは、作業の当事者だからな。それってオペミスというより交通事故だよな。
だから、運用って敬遠されんだよ。カネも安いし。。
仕事の性質上、運用にモチベーション持たせんのはどうあがいたってムリなんだよ。しかも運用コストを減らそうとかいうときに真っ先に槍玉に上がるのはエンジニア費だからな。
アンタら（客）はオペレータとか運用エンジニアに会社の命運を託しているのだという自覚がない。どうせフルアウトソーシングして放置プレイでしょ。
それは単なる責任転嫁だよ。
日ごろから運用エンジニアを厚遇していないと（カネの面だけでなく、いろいろと）、いざ障害が発生したときに障害復旧時間が遅くなって大損害になるぞ。
とはいっておく。
客が率先して運用エンジニアを厚遇しなければ。文句いったりムリな作業依頼ばっかするんじゃなくて。
障害・・（つまりは「システム障害」のことね）について語りたいことは、たくさんある。IT土方は皆、同じような思いを持っていることだろう。
インフラのレイヤにいれば、ゼッタイに障害と向き合わなければならない。そして、上流にいようが下流だろうが、障害はつきまとう。
なぜなら、（たかが）機械を相手にしているからだよ。
要件定義や設計では「耐障害性」にすぐれたシステムをつくりましょう、と合意される。そんなの当たり前だ。すぐ壊れるシステムなんざ、ポンコツ扱いで誰も使ってくれないからだ。
そこでとられる手法は、要は「冗長化」「二重化」「クラスタ」とか呼ばれる手法。片方が壊れても片系で動くから「サービス影響」はありませんよ、という理屈ね。
（同業者にはあまりにあたりまえのことを書いているな。。）
クリティカルなシステムであればネットワーク上のどの経路も冗長化されている。ＳＰ（シングルポイント）は許されない。たとえつくるためのお金がなくとも、絶対に許されない。（本来は）
ＳＰを許容しておくと、それがたとえユーザ合意の上であったとしても、ユーザのゴリ押しであったとしても、もしそこが原因で重大障害になってしまったら、ユーザは知らんぷりで、作った側に責任をおっかぶせられちまうからだ。
「あのとき、（オマエらが）もうちょっと強く冗長化の提案をしてくれればこんなことにはならなかったんだ！」ぐらいのことは、客にいわれる。テメーらがインフラにカネをケチったからだろ？ ボケが。
最近は、ネットワークシステム自体が激甚災害でぶっ壊れちまったときのために、遠隔地にＤＳ（ディザスタサイト）を構築したりする。バカみたいに金がかかる。けど、これだけＩＴインフラが企業にとって重要性が高まってくると、やらざるを得ない。
一旦構築して、追加構築追加構築を繰り返してスパゲティ状態になっているインフラは、災害でぶっこわれたら金輪際もとには戻らない。
バックアップをとっていようがいまいが、関係ない。戻らないものは戻らんのだ。
そうなってしまったら。もうたぶんその会社はつぶれちゃう。忠誠心のある会社員が生き残ったって、自社ビルが残ったって、会社を継続することはできない。ＩＴインフラは、企業にとってそれぐらいのインパクトがあるんだ。
ところで。。
エンドユーザにしてみれば、サービスが提供されていれば別に構わないんだろうけど（片系で動いている状況では、ちょっとレスポンスが遅くなったりすることもあるが）、オイラたちにしてみれば、ちょっと片側が動かなくなっても、障害は障害。
障害票切ったり、同報メールで状況流したり、客に説明したり、切り分けしたり、ハード障害だったらベンダ呼んで交換させたり、ソフトだったらアプリ側のＳＥにエスカレーションしたり。。
とにかく、軽度の障害であっても、いろいろ超めんどくさい。
これがもう、エンドユーザに影響が出ているとなったらもう、祭りだよね。客（この場合の「客」とは、そのシステムを保有している会社のこと）の情シス部長クラスが出てきて「早く直せ」と大騒ぎ。
昔のホストで「オレたちも昔はよく徹夜したなあ」みたいなおっさんども（今はちょっとは出世してんのか？）がわらわらとあらわれて、都度状況説明させられて、ハッキリいってあんたらジャマ。ふだん窓際のくせに。。とか思いつつ（これは、冗談だけどね）
「祭り」になったらもうハイだから、なりふり構わないけど、軽度障害のときは、もう手続きがアホらしくてな。。
バックアップが失敗しただの、サーバに赤いランプがついているだの、ノード監視が失敗しているだの。。 そういう障害って、ホント多い。
それに、障害ってさ、何歳になっても、緊張するし。
軽度障害でも、プレッシャーはかかるんだよ、ものすごく。
で、そういうのに迅速に対処する「縁の下の力持ち」が、オイラたちIT土方なわけだ。
前に「定義」の話を書いたはずだけど、リアルドカちんは作った建築物の運用はしないけど、オイラたちはやる。「セコム」みたいなもんだ。
ふだん「つかえねーやつら」「カネ食い虫」とか思われている（であろう）運用部隊も、きびきびと障害対応して、適切なタイミングで報告を入れ、アプリ側と連携し、無事、短時間で収束させたりすると、見直される。
同業者の皆さんは、お客が注目する障害対応時はそれなりに「演技」して、誠意をみせといたほうがいいよ。
でもさー、障害って、取り巻きで見てるやつらはのんきなもんだけど、当事者にはもうなりたくないんだよね。。 正直なところ。
発生した障害に対する対応者になりたくないし、もちろん引き起こす側にもなりたくない。オペミスで障害になったりしたもんなあ。。昔。
本番ルータのコンフィグ間違ってセーブしたら疎通できなくなったとか。。
しかも、ダマで作業してるときに。
そういうときに限ってエンドユーザが先に気付くんだよ。。 そして大問題になる。
あー、思い出したくもない。
本番作業ってホント、やりたくないよね。しかも他人が作った手順書とか。
運用の現場って手順書レビューなんて、ザルだからな。
東証だっけ？ 手順書レビューがなってなくて、マスコミに出るぐらいの大規模障害になったのって。
でも、レビューやったところで、結局何か起こって非難の矢面に立たされるのは、作業の当事者だからな。それってオペミスというより交通事故だよな。
だから、運用って敬遠されんだよ。カネも安いし。。
仕事の性質上、運用にモチベーション持たせんのはどうあがいたってムリなんだよ。しかも運用コストを減らそうとかいうときに真っ先に槍玉に上がるのはエンジニア費だからな。
アンタら（客）はオペレータとか運用エンジニアに会社の命運を託しているのだという自覚がない。どうせフルアウトソーシングして放置プレイでしょ。
それは単なる責任転嫁だよ。
日ごろから運用エンジニアを厚遇していないと（カネの面だけでなく、いろいろと）、いざ障害が発生したときに障害復旧時間が遅くなって大損害になるぞ。
とはいっておく。
客が率先して運用エンジニアを厚遇しなければ。文句いったりムリな作業依頼ばっかするんじゃなくて。