はじめに

Ansible のような自動化ツールを扱っていると「自動化できるか、できないか」のような調査をすることがあります。

この手のものは、機能面だけは判断できないなと思うことがあるので、簡単ですが自分の考えをまとめます。当たり前のことばかりかもしれません。

パラメーターのべた書きが通用しない

Ansible であれば、たとえば「サンプル Playbook を書いて実行したら思った通りに動いた！」と結果が得られたとします。

検証時点では、モジュールに指定するパラメーターがべた書きだったり、変数化したとしても「こういう変数があったとします」という前提で書くことが多いです。いずれの場合もうまく動くように都合よくパラメーターを準備したりするものです。

実際業務で使うにあたっては、都合のいいパラメーターはどこからか降ってくるわけではありません。むしろパラメーターを準備する方が大変、という感覚すらあります。

だとすると「機能が簡単に作れる = 簡単に自動化できる」とは限らない話になります。

パラメーターはどこからやってくる？

自動化の文脈でパラメーターといえば、何かしらのフォーマットでパラメーターが書かれたものが依頼元からやってくる業務の流れです。Excel ファイルによる申請書が代表的でしょうか。

このパラメーターをもとに自動化することになるのですが、このタイミングだけでも少なくとも以下の点が考慮点になります。

このパラメーターはどのようにして求められたのだろう？どれだけ時間がかかるものなんだろう？
このパラメーターを自動化にどう適用すればいいだろう？

「自動化」をシステム面だけで考えると2の方が関心ごとになります。しかし、業務面も含めて考えると1の方も関心ごとになります。

もし「実際に適用するパラメーターが決まってからの作業は実は時間がかかってなくて、上記の1と2に時間がかかっていた」という場合は、自動化の機能だけ作りこんでも、なかなか効率化が見込みにくくなってしまいます。

そのため、自動化を考えるにあたっては「機能をどう作るか」だけでなく「パラメーターをどう準備するか」もセットで考える必要があると捉えています。

たとえば ACL 変更

ちょっと抽象的な話が続いたので、少し具体的な話をします。

例えば、ACL やファイアウォールポリシーの追加、変更、削除に利用するパラメーターです。

Ansible でいうと使えそうなモジュールは割とすぐ思いつくのですが、この手の作業はパラメーター準備がかなり難しい作業だと思っています。

というのも「この通信を通すように変更してください」という要件は、エンドツーエンドだったりします。ところが、実際のネットワーク構成は、そのエンドツーエンドの間に複数の機器が挟まっていることがよくあります。

となると、そもそも

どの機器が設定対象か

から調べ上げる必要があります。ほかにも、

どのような設定を入れるか
どういう順番の設定にするか

など考慮点は多いです。

この話はできればもう少し深堀りして別の記事にしたいと思います。

パラメーター準備のパターン

やってきたパラメーターをそのまま自動化に適用できるのが一番簡単なパターンですが、簡単な順に上げると以下の大きな括りになるかと思います。

パターン1: そのまま機能に適用
パターン2: パラメーター内のキーなどをもとに、自動的に導出して機能に適用
パターン3: パラメーター内のキーなどをもとに、人が導出して機能に適用

パターン3（人が導出）がなかなか悩ましいですね。ここにリードタイムがかかっている場合は、その後のプロセスタイムを自動化で短縮できたとしても、業務全体で見ると思うような効果が得られないことになります。対比するために極端な例を挙げるとすると、実は「パラメーターの準備を自動化すべきであって、その後の処理は今までのツールを使えばいい」というケースもあるのかもしれません。

また、本記事タイトルにある「難易度」の観点とはそれますが、仮にパターン1（そのまま）だとしても、業務の流れの中でコピペが多いとミスの原因になり得てしまいます。もし、自動化の目的がオペミスの低減なのであれば、コピペをなくすにはどうすればよいか、は外せない視点になります。そうでなくてもコピペは少ない方が楽ですね。

おわりに

あまりまとまりがないですが、パラメーターをどう準備するかという点に重要性を感じる場面が多々あったため、自分なりに書きとどめてみました。

何かが難しいと感じた場合、処理自体が難しいのか（狭義の自動化処理）、そもそも業務自体が難しいのかといったところも見極めポイントに感じています。

検証フェーズだと、つい機能面に終始してまいそうですが、業務の流れや運用を見据えたうえで検証したいものです。