ネットワーク自動化の話題は、たいてい「設定をどう作るか」に集中している。Pythonで生成する、テンプレートから展開する、パイプラインで流す。
ただ、実際の仕事を思い返すと、設定を作っている時間はそれほど長くない。長いのは確認しているほうだ。そして確認については、どこまで自動化が進んでも、各ポイントで人が目を通すことになるだろうと思っている。
この仕事は、確認でできている
ネットワークエンジニア（以下、NE）の作業を工程順に並べると、確認の多さが見えてくる。
作業前に現状を確認する。設定を投入したら、入ったかどうかを確認する。疎通するかを確認する。顧客に業務が回るかを確認してもらう。翌営業日に問題が出ていないかを確認する。
設定そのものを書いている時間は、この全体からすると一部でしかない。にもかかわらず、自動化の議論はその一部に集中している。
これは夜間作業について書いた記事で整理した話とも重なる。作業ウィンドウの中で短縮されるのは投入の部分だけで、前後の確認工程はそのまま残る。
なぜ確認は人が見ることになるのか
「正常」の基準が現場ごとに違う
機器のログを見ると、たいてい何かしらのメッセージが出ている。問題はそれが今回の作業によるものなのか、前から出ているものなのかだ。
この判別は、その現場を知っている人にしかできない。「このアラートは去年から出ていて、原因は分かっているが対応保留になっている」といった情報は、どこにも書かれていない。前任者から口頭で引き継がれるか、自分で気づくかのどちらかだ。
機械に判定させるなら、まずこの「正常」を定義してやる必要がある。ところが定義しようとすると、現場ごとに例外だらけになる。定義する作業自体が、人が目を通す作業と変わらない量になってしまう。
確認の先に判断がある
確認は、それ自体が目的ではない。続行するか、切り戻すかを決めるためにやっている。
そして現実の作業では、判断が微妙な場面のほうが多い。想定していた事象が起きなかった代わりに、想定していなかった事象が出ている。放置しても業務は回りそうだが、根拠がない。作業ウィンドウは残り40分。こういう状況で決めるのが仕事だ。
この判断を機械に委ねられるかというと、少なくともいまは無理だと思う。判断材料が揃っていないから難しいのであって、揃っていれば人間だって迷わない。
責任の所在が変わらない
そしてもう一つ。仮に機械が「問題なし」と判定したとして、それをそのまま顧客への報告にできるかという問題がある。
翌日に障害が出たとき、「ツールが正常と判定しました」という説明は通らない。結局、誰が確認したのかを問われる。この構造がある限り、最終的に人が目を通す工程はなくならない。
自動化できる確認と、できない確認
とはいえ、確認がまったく自動化できないという話ではない。分けて考えたほうがいい。
設定が想定どおり入ったか、pingが通るか、BGPピアが上がったか、閾値を超えていないか。この種の確認は、条件が明確なので機械のほうが速いし正確だ。数十台を目視で確認するくらいなら、スクリプトに任せたほうがいい。
一方で、右側の項目は条件を書き下せない。「想定していなかった事象」は、想定していないから書けない。書けたらそれはもう想定内だ。
つまり自動化が得意なのは、あらかじめ定義した正常と一致しているかの照合であって、定義の外側で何かが起きていることへの気づきではない。そして作業中に本当に怖いのは、後者のほうだ。
減るのは作業、残るのは判断
ここまでをまとめると、NEの仕事に起きる変化はこうなる。
手を動かす作業は減っていく。設定を書く、投入する、目視で数を数える。この種の仕事は機械に寄っていく。
残るのは、見て判断する仕事だ。出ているものが問題なのかを見分け、続行するかを決め、その判断に責任を持つ。configの管理について書いた記事でも触れたが、現場で本当に効いているのは仕組みそのものではなく、それを見ている人が持っている文脈のほうだったりする。
この変化を歓迎するかどうかは、人によると思う。手を動かすほうが性に合っている人にとっては、しんどい方向かもしれない。
まとめ
自動化の議論は設定を作る工程に集中しがちだが、実際の仕事の多くは確認でできている。
そして確認のうち機械に任せられるのは、あらかじめ定義した正常との照合までだ。現場ごとに違う「正常」の基準、判断材料が揃わない状況での続行判断、そして報告の責任。この3つがある限り、各ポイントで人が目を通す工程は残ると思っている。
設定を書けることより、出ているものを見分けられることのほうが、これから価値になるのかもしれない。
