前回までのおさらい
➡️第4〜5回では、自動化のコストがなぜ高くなるのかを見てきました。機器ごとの違いは掛け算で増え、それを吸収しようとすると、その仕組みの導入や保守、変更結果の確認、実機とデータの整合に負担がかかる。製品を買っても自分たちで作っても作り込みは残る。今回は天秤の反対側、自動化の「効果」の話です。➡️第3回では、判断材料がデータになっていないことを見ました。今回は、それをデータやルールにする手間がなぜ投資として見合いにくく見えるのかを考えます。
図1: 連載マップ
この回の要点
- 「この通信はどこを通るか」のような判断は、人なら構成図を見て即答できますが、機械にやらせるにはたくさんのデータとロジックが要ります。
- その結果、いまの規模と作業時間で比べると手作業のほうが安く、その判断には十分な理由があります。
- ただし、規模が大きくなってから自動化しようとすると、難易度もコストも上がってしまいます。
困る場面
ファイアウォールのフィルタルールの管理・運用が煩雑なため、フィルタ設定の自動化を運用チームで始めたとします。変更依頼を受けてから設定を入れるまでの作業を洗い出すと、結構な時間は「指定の通信がどの機器のなんのフィルタを通るか」を調べることに使われていました。それならその部分を自動化しようか…という話になります。
ところが、実装方法を具体的に考え始めると話が止まります。FW ルールを入れる場所を決めるには、通常時と障害時に通信が通りうる機器を特定する必要があります。それを機械にやらせるには、トポロジのデータ、冗長構成の組み方、途中にある NAT の情報、そして「このNWでは通常はこう通り、障害時はこう切り替わる」という設計上の前提が必要です。そのどれもが、いま機械で使える形ではそろっていません。一方、実務経験のある運用担当者であれば構成図を見てすぐに答えてくれます。「それならいまのまま人がやったほうが早いのでは?」という結論に落ち着きます。
この回では、なぜそうなるのか、その判断がいつまで正しいのかを考えます。
人には簡単、機械には難しい
「どこを通るか」を機械にやらせる
冒頭の例をもう少し詳しく見てみます。
図2: 「どこを通るか」を判断するために必要なもの。人は構成図と知識で、機械はデータとロジックで判断します。
人がやる場合、構成図を見て送信元と宛先の位置を確認し、その間にある機器を目で追います。ファイアウォール設定の話をしているので、通るリンク一つひとつを追うようなNWの動作を完全にシミュレーションする必要はありません。「通常はこちらを通る」「障害時はあちらに切り替わる」という知識と経験で判断できます。
機械がやる場合、機械はそうした知識を持っていません。まずトポロジのデータが必要で、冗長構成があれば通常時と障害時にどちらを通るか、途中に NAT があれば変換の前後でアドレスがどう変わるかも与えなければなりません。人が「通常はこちら、障害時はあちら」と判断するときに使っている設計上の前提を、データやルールとして明示する必要があるわけです。ところが、その前提はプロトコルの知識・自分たちのNWの設計の知識・過去の経験が混ざりあったもので、書き出すのは困難です。
周囲を見て判断する作業
「どこを通るか」以外にも、人には簡単で機械には難しい作業はたくさんあります。
- 対向の状態を見て操作を変える: 接続先の機器の状態を確認し、それに応じて手順を変える。冗長構成の片系メンテナンスがその例です。
- 冗長ペアをいまどう見るかを決める: クラスタ化されたFWのように「1台として扱うか、2台として扱うか」を作業の目的に応じて切り替える。
- 複数の機器を順に操作する: ある機器の設定を変えてから、その機器+周辺の機器の状態が落ち着くのを待って別の機器の設定を変える。このような順序やタイミングに依存する作業は人なら経験で自然にこなせますが、自動化するには、待つ条件や失敗したときの戻し方まで機械が判定できる形で決めておく必要があります。
人は構成図を何枚も頭の中で重ね、例外も含めてこうした判断をこなしています。その能力に頼っている部分ほど自動化は難しくなります。
頭の中を書き出すコスト
自動化の実装で最も時間がかかるのは、コードを書く作業ではなく、人が頭の中でやっている判断を書き出す作業であることが少なくありません。
ベテランのエンジニアに「どうやって判断しているのか」を聞くと、多くの場合「構成図を見ればわかる」「この構成なら普通はこう」という答えが返ってきます。その「普通は」の中には、設計の意図、過去の障害の経験、機器の癖といった、明文化されていない知識が詰まっています。本人にとっては当たり前なのでうまく言語化できていません。これを書き出すには、判断の例をたくさん集めて「この場合はなぜこうするのか」をひとつずつ確かめていく必要があります。その過程で例外が次々に見つかります。「ただし、この拠点だけは古い構成なので別」「この機器の組み合わせのときは順番を変える」……そうした例外を含めて書き出すのは大仕事です。
一部だけの自動化では、全体の時間が縮まりにくい
もうひとつ効果を小さく見せているのが、プロセスの一部だけを自動化しても、依頼から完了までの時間はあまり縮まらないことです。
➡️第1回で見たように、NWの変更は計画・設計・検証・実施・テストのプロセスで進みます。このうち設定投入だけを自動化しても、その前後の計画・設計・テストに人の判断が残っていれば、依頼から完了までの時間はそれほど縮まりません。人の判断を待つ時間が支配的なことが多いからです。
かといって、判断の部分まで自動化しようとするとここまで見てきた難しさにぶつかります。部分的な自動化では効果が小さく、全体の自動化はコストが大きい。そのため「いまのままでいい」という判断に落ち着きやすくなります。
手作業のほうが合理的に見える
こうした作業を自動化するには大きなコストがかかります。一方で、人がやれば数分〜数十分で終わる作業です。自動化の効果は「自動化によって浮く人の時間」で測られることが多いでしょう。本来は、作業ミスの減少や、作業記録・再現性が残ることも効果に入るはずですが、こうした効果は数字にしにくく、判断の場では見落とされがちです。人がすぐにできてしまう作業は、1回あたりに浮く時間が小さいので効果が小さく見えます。NWの規模がそれほど大きくなく、変更の頻度も高くない環境であればなおさらです。
直近の作業時間と導入費用で比べれば、見送る判断には十分な理由があります。ただ、その物差しには、ミスの削減や再現性、将来の作業量が入っていないことが多い点には注意が必要です。NWの自動化が進まない理由のひとつは、この判断にあります。
それでも数が増えると詰まる
ただし、この判断がいつまでも正しいとは限りません。
ファイアウォールのフィルタの例に戻ります。1件1件の依頼は、人が経路を見て判断できる簡単な作業です。ところが、E2E の通信の組み合わせは端点(endpoint)の数の2乗のオーダーで増えていきます(➡️第2回)。そのため、サービスが拡大してNWに載るシステムが増えると変更依頼の数も増えていきます。
一つひとつは簡単でも、数が多くなると人の作業がプロセス全体のボトルネックになります。サーバの構築やアプリケーションのデプロイは自動化されていて数分で終わるのに、NWの設定変更だけ依頼から数日かかる……そんな状況は、多くの現場で見られるのではないでしょうか? そうなってから自動化しようとすると、今度は自動化の難易度が上がっています。規模が大きくなり、重要なサービスが増え、「怖くて消せないルール」(➡️第3回)も個別の例外事項もたまっています。小規模なうちに始めていれば扱えた範囲が、あとからだと手に負えない大きさになっているかもしれません。
図3: 手作業と自動化のコストの関係(模式図)。規模が小さいうちは手作業のほうが安く見えます。規模が大きくなると手作業のコストが上回りますが、そこから自動化しようとすると、最初から取り組んでいた場合よりもコストがかかります。
人も機器も、手作業向けにできている
もうひとつ、効果を見えにくくしている背景としては、NWの運用は人も機器も手作業に最適化されているという点がありそうです。
NWの運用者は、機器に直接ログインし、コマンドを打ち、出力を読んで判断することに習熟しています。これは、NWの運用がそういう形で行われてきたことに対する合理的な適応の結果です1。その分ソフトウェア開発や自動化の知識を身につける機会は多くありませんでした。機器の側も同様で、NW機器の操作体系はCLI を中心に人が使うことを前提に作られています(➡️第4回)。この組み合わせは手作業の効率を高めますが、裏を返せば自動化の効果を小さく見せる要因にもなっています。
投資判断の物差し
いまの規模と作業量で自動化の投資対効果を測ると、多くの場合割に合わないという結論になると思います。その判断自体はおそらく間違っていません。問題は、その判断を「いまの作業量」だけを基準に決めてしまってよいかどうかです。
NWの規模や、NWに求められる変更のスピードが増していくのであれば、どこかの時点で人(手作業)がボトルネックになります。そのときにあとから自動化しようとすると、難易度もコストも上がっています。投資の判断には、現時点の作業量に加えて「将来的に予想される規模」「それに対して手作業がボトルネックになるのはいつか」という観点も入れる必要があります。すべてをいますぐ自動化する必要はありませんが、将来に備えてデータの整備のような地ならし(➡️第3回)を先に進めておくことは可能でしょう。
次回は、天秤のもうひとつの要素であるリスクを取り上げます。自動化に踏み出すためには安全に試せる場所が必要です。しかし、NWではそれがなかなか作れません。
-
そもそもNWは「なにもつながらない」ところに人が配置して「つながるようにする」ためのものなので、人が直接触るための操作体系になるのは自然なことです。 ↩