横断歩道の赤信号
「今年はスキー場の事故が多いですね」と言われて、「スキー場じゃなくて、近くの雪山ですね」とお返ししておいた。スキー場管理してる人がかわいそうだもの。
スキー場内でもバッキャンやボーダーは規制線を超えてリフト下など未整備の場所にどんどん入り込んできていて、安全が脅かされていると感じて不愉快です。どうして規制線外のエリアを安全だと思うのでしょうか？雪崩や接触、衝突などプロのスキーパトロールでも難しい危険予測なのに素人がどうして自己責任とかで判断するんでしょう。自己責任が「自分さえ安全なら」だったり「自分の安全は自分で守るから」だったりと、多くは誤解しています。自損事故の衝突は勝手にしろかもしれないですが、リフト搭乗者との接触だったり、雪崩の発生とかをどう予測するのでしょう。規制線はルールであって、ルールを破ることは自己責任とは言いません。ルールが破られて安全が確保できないと規制が強化されます。規制線を金網にしたり、装備不問で全面立ち入り禁止とか、ヘルメット義務化など息苦しいです。
ルールは
- ルールだから守る。
- ルールを守らなかった時に発生する影響に自分の責任範囲外のものがあるから、守る。
- ルールを守ることで自己責任活動範囲を確保でき、その不自由さが行動の自由を保証するから守る。
と言う風に考えます。
だから、だれも居なくても横断歩道の赤信号を愚直に守るという行動を続けます。赤信号を渡るというささいな行動が社会のルールとモラルと人々の安全の判断をゆっくりと崩壊させていくことに私は責任取れないので。
田舎に住みますか、都会に住みますか
都会に住みますか、田舎に住みますか
あるプロジェクトの意思決定において。「クラウドへの移行を費用視点で詳細に分析した結果、今までのサーバーと同じ性能容量を確保する場合、クラウドに移行するよりも中古機を買って運用した方が安いので、クラウドへの移行は致しません。」と言われ反論する気が無くなった。新しい取組みに反対する人はいつもコストでしか反論しない、本心はやりたくないから規定通り工夫もなくコストを積んでるだけなのに。新しいテクノロジーがもたらしてくれる価値の増分には目を向けず、これまでと同じことを安くできることしか考えないという姿勢を崩さない。進歩が止まる瞬間だ。
こういうのって移動の基本が公共交通機関の都会に住むか、一時間に数本のバスも運行できないような中古の軽自動車だらけの田舎に住むかの判断だ。都会に住むのは共有のサービスが充実していて、自分で持ってなくてもサービスを買うことで便利な生活をしたいからだ。単位距離あたりの移動コストの比較じゃない、ライフスタイルの問題だ。ダウンタウンに出かけて飲んで電車で帰りたいから都会に住むんだよ、田舎にしか住んだことの無い人にはわからないよ。ICカードでさっと電車に乗り、利便性のためにみんなでコストを負担して電車やバスをシェアする。それに大規模な工場の引き込み線でもない限り電車に乗りたいからって言って電車作る人も居ないでしょ。
もういい加減にコスト比較しかできない能力の人にIT投資判断させるのやめよう。
Service Level Agreementとか
可用性なんてサービスの品質を向上させる上であまり役に立たない。契約、約款におけるSLAはサービス提供時間に対する保証契約の時間割合を示していることを正しく理解したい。サービスの見える化やサイドレターの撲滅には役立つがシステムの信頼性設計は別の対処が必要だと思う。
単体のハードウェアの信頼性でサービスの可用性を論じちゃいけないけど、可用性が契約した時間に対するサービスされている時間の割合であってシステムが故障しない確率じゃないということを説明するために、単純な例を一つ。MTBF（平均故障間隔）35年の化け物みたいなマシンがあってMTTR（平均修理時間）を8時間としたら可用性は99.997％です。満足ですか？このマシンを５年運用したときに故障する故障率はどのくらいかというと、だいたい15％です（詳細は信頼性計算とかの基礎的な算数をググってみてね）もちろん0.003％なんかじゃありません。導入した翌日に15％の確率で８時間停止するマシンの可用性は99.997％です。SLAで99.99％を求めてもこけるときはこけるんです。 それよりサービスプロバイダーの情報公開に基づいてして即時に対応できるFailure Based Designを徹底するほうがいいと思うんです。「サービスプロバイダーなんだからSLA99.99%でやってよ」って言っていても落ちるときには落ちる。それより責任ある情報公開に基づいて、自ら自信の持てる運用を作るほうが「自分の責任で努力できて」いいんじゃないの？ それにどんなにシステムが障害起こしてもサービスが止まらないような運用設計してたらさ、SLA高くて単価の高いインスタンスなんてナンセンスなんだよね。止まったら即座に他で動かす様にしたらいい。
フロントエンドのアプリケーションとバックエンドの障害を切り分けて、動くところを探して運用できるステートレスなアプリケーションデザインを採用したり、ダッシュボードとモニタリングの絶え間ない改善とか、サービスプロバイダーのSLA交渉とかしてる前にやること一杯あるでしょ。
