プライオリティという泥縄
仕事では優先順位が大事だそうだ。重要な課題には高い優先順位をつけて、大事な事から片付けていく。当たり前といえば当たり前。状況が変われば優先順位も変わる。これも当然のこと。それはわかる。でも、それって本当に状況が変わったの?
システムに不具合が発生して、サービスに影響が及んだ。不具合を防止する仕組みもなければ、サービスの監視も怠っていたから。その不具合を直して、再発防止策を取る。最優先で。でも、その不具合以外にもシステム障害の可能性はあって、それはテストや監視をきちんとしないかぎり消えない。でも、目先の障害は直ったので、根本的な解決の優先順位は低いまま。状況は変わっていないのに、障害が起きたら「最優先で!」になる不思議。
バックアップからリストアしてみたらリストアできませんでした。これもよくある話。必要なものをバックアップできていなかった、互換性のない形式でバックアップしていた、リストアの手順が文書化されていなかった、そもそもバックアップしたデータが壊れていた、リストアしてみたら死ぬほど時間がかかります。いろんな理由で。「最優先で」なんとかかんとか復旧させる。各方面にごめんなさいしながら。これも「バックアップしたらリストアする」という基本を怠っていたのが原因。けれど、喉元過ぎれば「これ、優先度高いんでこっちやって」。バックアップ対象、リストア手順の見直しや定期的なリストアといった再発防止策の優先順位は?状況は変わってないですよ?
こういうのは「状況が変わった」とは言わない。「自分が今やってほしいことが変わった」という言うべきだ。これがかの「バータリー」と並び有名な「ドロナーワ」である。
しかし、こうした「自分がやってほしいこと」を無視するわけにもいかない。なぜなら優先順位を律儀に守って彼らのやってほしいことをおざなりにしておくと、「あいつは頼んだことをやってくれない」「大した実績も上げずに好きなことばかりしている」という評価につながり、本来の優先順位を守ることもできなくなる。そして、そっちに関わり過ぎると想定されていた次の障害が発生し、その責はシステム管理者が負う。かくて、わかりやすい実績を上げつつcatastropheが起きる前に対策を打つという綱渡りを強いられる。
ということで、システム管理者には「しっかりした設計を行う能力」「日頃から改善を積み上げる習慣」や「先を見越して対策を打つ能力」などに加えて「わかりやすい結果を短期間で出す」ことも必要。残念ながら、「障害が起きないこと」よりも「やってほしいことをしてくれた」方が評価されるのだから。




February 2nd, 2009 at 7:21 am
まーバランスってことで。