Aimless

ネットワーク運用でも継続的デリバリしたい。

network

昔ながらの変更作業

 SIerの中で、ネットワーク機器の運用受託業務をやっておりまして、毎日毎日、色々なお客様のスイッチやルータ、ファイアウォールの設定変更をしています。

 設定変更のプロセスはルール化されており、現在の以下の流れで設定変更が行われます。

  1. 作業者が手順書を作成する
  2. 確認者が手順書をレビューする。
  3. 承認者が手順書を確認し、作業を承認する
  4. 作業者と確認者が二重チェックで本番作業を実施する。
  5. 作業者が事後作業を実施する。(管理資料更新等)
  6. 確認者が事後作業をレビューする
  7. 承認者が結果を確認し、結果を承認する。

 それなりの人と時間をかけて対応している中で、上からは「コストを圧縮しろ!ただし、品質は下げるな!」という無茶を言われています。現時点では「二重チェックをやめて作業員を減らしましょうー。コストは下がりますよえへへ」という対応しか思いつかず、こんなことを言えば上長に殺されるわけです。

継続的デリバリーへの憧れ

 このような状況で、サーバやアプリケーションの世界で行われている「継続的デリバリ」の話を聞くと、素直にうらやましいわけです。テストが自動!?デプロイも自動!?

 作業手順のテストですか?頻度の多いファイアウォールの設定作業のたびに、ユーザと全く同じネットワーク環境を自前で用意するのは現実的ではないので、現在の設定をベースに頭の中で手順をトレースして、ユーザの要望を満たす設定になるかをテストしてますよ?

 作業結果のテストですか?作業後にトラフィックが流れてみないと分かりませんねー。もしかしたら考慮漏れにより作業とは関係のない通信が破棄されるかもしれませんー。または、作業時にミスってしまい、関係のない通信が破棄されるかもしれませんー。でも変更してみないと分かりません。

 デプロイですか?GUIで操作する機器なので、毎回指さし声出し確認しながらマウスをポチポチ頑張っています!

 このような設定変更作業を続けた結果、考慮漏れによる通信障害や作業ミスによる通信障害が発生し、ごめんなさいする羽目になります。深夜まで報告書を書いたのが懐かしい。

希望

 コストを下げて品質を維持するために、頻度の多いファイアウォールの設定変更作業で、継続的デリバリな仕組みができるといいなと思うわけです。ちゃんとテストしよう。手作業は止めよう。

 理想は以下の流れです。夢のようです。

  1. 作業者は設定変更の手順となるコードを作成する。
  2. 確認者は手順(コード)をレビューする。
  3. レビューが完了次第、CIツールがテストを実施する。
    • CIツールは、変更対象機器のコンフィグを元に、テスト環境をとなるネットワークおよびファイアウォールをデプロイする
    • CIツールが、テスト環境を利用して、ファイアウォールに対して変更手順を実施する。(手順の正しさをテストする)
    • CIツールが、テスト環境を利用して、ファイアウォールのすべてのポリシーを網羅するトラフィックを動的に生成してファイアウォールに順次流す。(作業結果のテストする)
  4. 手順と結果という2つのテストをパス次第、CIツールが本番のファイアウォールの変更作業を実施する。

 運用担当者がやることは手順となるコードの作成とレビューだけです。なんて素晴らしい!お客様!業後作業を希望ですか?いいですよ!CIツールがやりますんで!

課題

 実現に向けた課題は以下の通りです。Programmableな仮想ファイアウォールさえあれば、あとは仮想環境とオーケストレーションツール、CIツールを組み合わて作りこみでできそうな気がする。気がする。

1. Programmableなファイアウォール

 CIツールに自動テスト、自動デプロイさせるためには、ファイアウォールがprogrammableである必要があります。GUIと同様の機能をAPIで提供するファイアウォールはあるのでしょうか。Expectでやる?

2. 顧客ごとに異なるテスト環境を自動デプロイする必要がある

 顧客ごとにネットワーク環境が違うので、当然必要となるテスト環境も顧客ごとに異なります。そのため、CIツールが、全く違うテスト環境を気軽に作っては壊し作っては壊してできる仕組みが必要です。

 これは初回に手作業で仮想マシンと仮想ネットワークを作り、顧客ごとにテンプレート化しておけばいけそう。2回目からは、オーケストレーションツールにテスト環境を用意してもらいましょう。

3. ポリシーに沿って動的にトラフィックを生成する必要がある。

 複数の顧客を運用しているので、流れるトラフィックは送信元宛先プロトコルの組み合わせで千差万別になります。そのため、事前にテスト用のトラフィックを準備するのではなく、テストの度にファイアウォールのポリシーから動的にトラフィックを生成する必要があります。

 テストパターンは、ファイアウォールのポリシーをパースして作る。そのテストパターンを舐めるために疎通確認サーバを沢山立てるのは非現実的なので、疎通確認サーバのIPアドレスとデフォルトゲートウェイ、NICの接続先を、テストするトラフィックにあわせてオートメーションツールで切り替えれば行けそうな気がする。

 こういうことを考えて実現する仕事がしたい。。。

4 Apr 2014