新入社員

一週間ほど前に新入社員が配属されたので、今日は 2 時間ほどアラーム対応のトレーニングを行った。

「まずアラームが出たら何する？」と聞いてみたら「アラームに紐づくマニュアルを確認します」という回答が来たので、これはまずいと思い、切り分けのトレーニングをすることにした。

内容は、80 件くらいのアラームのどさっと提示して、何が原因でアラームが出ているか切り分けをしてもらうというもの。前提として、一つの障害が原因でこれだけのアラームが出ているということだけは伝えて、トレーニングスタート。

一つ一つ指示を出すのではなく、どうやったら正解（被疑箇所）にたどり着くことが出来るか、大まかな方針を立ててもらいつつ進めてもらう事にした。すると彼らは、複数のサーバから同じ種類のアラーム（ネットワークインタフェースのダウン）が多数出ている事に目をつけ、切り分けを開始していった。根拠としては、「一つの障害が起因となってたくさんのアラームが出ているのであれば、たくさん出ているアラームは被疑箇所に近いのではないか？」「仮に被疑箇所ではなかったとしても、そこからたどる事で特定するための糸口がつかめるのではないか？」という事だった。ちなみに、それらが「（ネットワーク機器ではなくて）サーバ」であると判断した理由は「アラーム文字列の中に kernel という単語が含まれているから」だそうだ。

実際には複数のサーバは被疑ではなかった（正常性の確認をとると、異常は見られない）ものの、これでサーバについては異常がないという切り分けができた。

まだ被疑箇所は特定できていないので、次のアクションを考えてもらうと「サーバのネットワークインタフェースに繋がっている先のスイッチが被疑ではないか？」という仮説が出た。ではそれをどのように確認したらよいか聞くと「ネットワークの構成図を見れば良い」との回答。

ネットワーク構成図を見ると、確かに複数のサーバと、それが持つインタフェースカードの識別子、そして繋がっている先のレイヤ 2 スイッチのノード名が確認できる。そして、アラームとして出ているインタフェースカードの識別子の先は、全て同じレイヤ 2 スイッチであった。これで、被疑のスイッチが特定できたことになる。

次に何をするか聞いたところ「被疑のスイッチから何かアラームが出ていないか確認する」とのこと。確かに、アラームが出ていなければ被疑箇所としての論拠は薄い。実際にアラームを確認してみると、被疑箇所からきちんとアラームが出ている。2 件ほど。

しかし、今までの切り分けで、それら 2 件のアラームが本質であるという確信が新入社員の中には確かに出ていた。

ということで、新入社員には「やり方を教える」のではなく、「調べる事や考える事を習慣づけさせる」事を徹底した方が良いのではないかという結論に至った。だって考えればできちゃうんだもの。もちろん、調べ方や考え方について適切な助言は必要だと思う。

新入社員すごいなーと思ったけど、よくよく考えたらこれくらい普通に出来てもらわないと困るというか、普段から当たり前の事を普通に出来る人と接する機会が少ないというか、ちょっと複雑な気分である。