Reach Over The Sky, Tear The Sky

■隅々まで理解するということ 会社では、テクニカルサポートみたいな仕事もやってます。 先日、ストレージのアレイコントローラーの機能を使ったスナップショットボリュームについてのお問い合わせがあり、うまく答えることができませんでした。 スナップショット機能は、仕様は違えどおそらくどのストレージベンダーの製品にもある機能だと思います。 しかし私は、共通的というか汎用的な概念、数学でいうと公式のような部分をしっかり理解していなかったため、サポートのリクエスト者に適切な回答を提供することができませんでした。 日々の仕事のなかでは、「必要な部分は理解できたから」という大義名分のもと、曖昧な理解度のままに仕事を進めることがあります。 たとえば今回のような場合は、「スナップショットというのがあるからどうやら過去の状態に戻れるらしい」という程度の、非常に概念的な話を関係者とやり取りするような。 プロっぽくないですよね。 いつどこでどんな質問がされるか分からないんだから、隅々まで理解しておいたほうが良いのではと最近よく感じます。 実際のインフラ機器がある現場へ赴く業務をやっている人、私もたまにありますが、そんな仕事をやっている間は、本当に重箱の隅をつつく感じで徹底的に調べあげるような気概で取り組みたいです。 理解している範囲が広がると、「想定外の質問を想定外に変える」ことができます。 そして想定内の質問や仕事が増え、想定外のものが減るにつれ、 無駄に長い残業が減り、帰る時間が早くなるのではないかなと思います。 「隅々まで理解する」を頭のなかにいつも置いておきたいと思います。 ディスクが一個でも故障してると、ホットスペアを用いたリビルドが完了していたとしても、ストレージによるリモートレプリケーションに失敗するなんて、思いもしませんでした…。 今回対応した機種独特の仕様だと思いますが、 要は「故障Aの影響で、思わぬ障害Bが発生する」ってことですよね。 つまり、「思わぬ」と思っている自分の頭の想定範囲が狭すぎるということですね。 これを「思ってた」に変えれるように、日々勉強していきたいです。

■ITインフラのメンテナンスについて  最近の仕事の一つにITインフラのメンテナンス計画の策定みたいなことがあります。 いろんな事を考えてあげなくちゃいけないから大変です。 まぁ大変じゃない仕事なんてないでしょうけれども。 0から考える際の切り口としては… 　・いつ 　・何を  　・誰が　　 　・どんな多重度で 　・どんなマイナス影響があって 　・どんな試験で確認して 　・どんな環境で 　・どんな期間で などを考慮しながら計画をドンドンBreakdownしていきます。 ITインフラについて、どこまでだれが面倒を見るのかという考えについては、 できるだけ早く明確にしておいた方が良いのではないでしょうか。 「責任分界点」という言葉が使えると思うんですが、 どうも正直に言葉を習ったときの使い方のまま、 「障害発生時の責任追及試験紙」 のようにしか使われていない気がします。それって勿体無いような気がします。 予防保守においても、予防保守実施の責任分界点をきっちり決めて、 ここはアウトソース先にメンテナンスさせるのか、 それとも自社のエンジニアがやるのか、とか、 この機器はどれくらいの頻度でメンテナンスしてパッチを適用するのか、 一年に一回でいいのか、 それとも毎日丁寧に見て挙げなくちゃいけない箱入り娘なのか、 それとも障害がおこるまでほっとけばいい手間のかからない子なのか、 とか、 そういうところの議論は少し時間を取って行っても損にはならないのでないでしょうか。 当たり前といえば当たり前ですが、 運用保守の各業務の責任分界点を決めたいですね。 要は仕事を事前にきちんと細部まで考慮して 担当者をアサインしてましょうということですね。 基本こそきっちり忠実にこなす、私は苦手です…。 ■Vimがんばります 会社でVimを使うようにしたいと思い、Vimを触り始めました。 iで挿入モードになったら普通のエディタとおんなじことできるとか、 その程度の知識しかない。なので勉強していかないと…。 教えてもらったのはざっとこんな感じ。 Ctrl + W + ?で画面（ウインドウ） をいろいろいじれる ・画面の分割 ・画面を分割して空のファイルを開く :edit ファイル