全知全能をかけた障害対応

publickeyにこんな記事がありました。

Webサイトの利用者数が500から数百万、数千万に増えると、最初に考えていた設計は有効ではなくなる。ある規模で有効な策は、その規模でしか有効ではないことを学んだ。サイトの設計を何度も考え直さなければならなかった。私たちはいまでもそうして何度もやりなおしている。

『Twitterの大規模システム運用技術、あるいはクジラの腹の中（前編）～ログの科学的な分析と、Twitterの「ダークモード」 － Publickey』
http://www.publickey1.jp/blog/10/twittertwitter.html

システムの設計をしていると、自然との戦いだと思うことがあります。ある程度までは自分の予想通りに物事が進み、足し算や掛け算で対処することができます。

しかしある時から突然に複雑さが増し、それまでの考え方が通用しなくなるような局面があります。些細な障害をきっかけに次々と不具合が引き起こされて、全体的な障害に発展してしまったというケースに遭遇したことのある方もおられるのではないでしょうか。

そういった時、何が起きているのかわからなくなってしまいます。しかし普段はあまり重要視していなかった情報が急に意味を持ち、雲が晴れるように全体を見通すことの出来る瞬間があります。アプリケーションのログ、CPUやメモリの利用率、データベースの挙動、そういったものからコンピュータが何をしようとしているかを汲みとることができると大きな達成感があります。

もちろんシステムの制御を失うようなことがあってはなりません。しかし完全にシステム単独で自動運用をするならまだしも供給電源や温度などの環境要因から、利用者の思いつき、他システムからの干渉などもあり、あらゆる条件で動くようにすることはなかなか難しいものがあります。（ちょっとでも怪しくなったら安全に落とすというやり方もあると思いますが）

あらゆる条件を想定して十分な予算と期間をつぎこめる開発でなければどうしても「あるべき姿」と「想定する最悪な条件」の間で動くシステムにならざるを得ません。想定外が発生してしまった場合は、せめて回復が早くなるようにと準備しておいた診断機能やログ機能を活用し、全知全能をかけた障害対応が始まります。

もしこうならば、ログはこうなっているはずだ、そうならばCPU利用率は高い（低い）はずだ、と推論に推論を重ねて真相を突き止める。障害対応やバグ取りには独特の魅力があります。

以前小俣さんが「良いものを作るにはARM（CPU)ならARMの気持ちで書かないとだめだ」と豪語していらっしゃいました。さぞかし障害対応もお強いのではないかと思います。