凸
- ついでなのでちょっと考えたこと。時間があったらやっておきたい。
- 一応ネットワーク的なお仕事をしていて、たとえば本当にこの設定、この変更手順で問題なく意図したことが実現できるかどうかの検証作業、なんてことをやったりするのだけれども、単純に実行するだけならともかく、その動的な変化をひとりで観るというのは非常に困難だ。
- 要は何らかの作業をしながら、それぞれの機械がどのような情報を受け取って、どのような処理を加えて、どのような出力を出して、全体として通信がどのように流れているかというようなことを観るのだけど、自律デバイスの集合体であるネットワークともなると、単純に操作だけでも環境内のデバイス分は人手が必要になってしまう。
- モノによっては一人で2〜3台やれなくもないのだが。場合によっては同時性が必要になってくるし、対象とするデバイスのほかに観測用のデバイスの操作なんかもあったりするからちょっと環境内デバイスの数が増えるととたんに観測まで手が回らなくなる。
- 観測に手が回らなくなるとどうなるかというと、複数回実施して、やるたびに見る部分を変えながらデータを取るわけだ。で、これがまた時間がかかる。ログを観ながら、どのタイミングで何がおきているかをいちいちマッチングさせたりする。はっきり言ってこれは無理だ。
- 要するに何がやりたいかというと、操作の自動化ができないかということだ。あるいはデータの取得か。シナリオに沿って、複数のデバイスに指定されたタイミングで指定されたコマンドを送る。そしてそのログを取る。シナリオは同期でも非同期でも書けるようにする。取得したデータによって条件分岐ができると完璧。
- 試験の前段階は指定したシナリオとおりに機器が設定でき、データが取得できることを確認することだ。必要なのはシナリオのプログラミング。後は観測にだけ専念すればよい。作業の再現性が確保できるのでとても便利。取得すべきデータが足りない場合は、人手を気にせずに、単にプログラムにコマンドを付け足すだけでよい。タイムスタンプがずれていたり、タイムスタンプを付け忘れたり、コマンド打ち忘れたり、コマンド入力タイミングを間違えてデータを取りそこなったりして作業が無駄に終わるということもなくなる。(この辺愚痴)
- 考えないといけないのはコマンドの送信方法かな。たとえば障害試験なんかの場合、通常のトラフィックルートにコマンドを通していては当然コマンドが途切れてしまうので、試験対象とは独立したコマンド専用の経路(out-of-bandな経路)が必要になる。スイッチならポート開けとけばいいんだけど、そのほかのNW機器だとそれ用のポートを確保することができない場合もあるからなあ。やっぱりシリアルか…。あとはCLIがあれば expect か Perl::Telnet で何とかなるだろう。
- なんてことをどっかでやってそうなものなのだが。なんかないのかなあ。
