この記事は、DevX, Core Software Group の Sr. Technical Leader, Engineering である Siming Yuan によるブログ「The pyATS DevNet Journey: Aspirations & Inspirations
」（2021/5/3）の抄訳です。
開発者として、日々の作業の中で、泥沼にはまり込むことはよくあることです。じっくり考え思い起こす時間はほとんどありません。そこで、pyATS を私たちのお客様向けに立ち上げるまでの過程を今ここで思い起こし、私たちの経験や学習を皆様と共有する機会を設けたいと思います。
光陰矢の如し
私たちが、pyATS を シスコ DevNet を通してデベロッパー向けに立ち上げてから 4 年にもなろうとしているとは信じられないことです。まだ昨日のことのように感じられます。
最初の 100 のダウンロードから、現在の毎月 20,000 以上のダウンロードまで – pyATS 開発チームには長い道のりでした。刻一刻と時間が過ぎる間に、私たちは新しい機能を提供し、ライブラリを拡張し、古いコンポーネントをリファクタリングし、機会が発生すればそれを利用し、許される限りリスクを取ってきました。チームは自分たちが行ってきたことに大きな誇りを感じています。当初は社内ツールとして立ち上げ、オープンソース NetDevOps コミュニティで大規模に展開、ユーザに力を付与し、ソリューションを使用可能にしました…
このチームの成功は、私たちが提供した品質と創意工夫に結びついています。
エンジニアとして
エンジニアとしての職務は、無限の可能性がある高品質な製品を構築することです。pyATS はフレームワークですから – 構築者としての私たちの願望は、他の開発者たちが使用し、拡張し、土台にすることができる最も強力なシステムを構築することです。
コアシステムの設計には慎重なステップを取りました – 道程のすべてのステップで、将来的な可能性を有効にすることに注力しました。私たちは、すべての人々のニーズに応えられるシステムを構築しようとしました。そして、私たちの設計の背景にある思考過程を開発者に知ってもらうための完全なドキュメンテーションを、そのシステムに組み合わせました。
「pyATS はすばらしい読み物です」– Raymond Hettinger [@raymondh、Python の中心的開発者]
私たちは、すべての準備が整ったと考えました。
pyATS が DevNet で発表された時点では、当初の評判は期待したほど高いものではありませんでした。NetDevOps のテストおよび検証ドメインを作り直すことで逆転を望みました。このインフラストラクチャを作るために多大な情熱が注がれました。パワフルであることは分かっています…そして、結果は?
2018 年始めの、まさに第１回の Cisco Live セッションを思い起こすと、発表全体でインフラストラクチャの抽象的性質に焦点を合わせ、解き放たれる可能性について話しました。フレームワークのパワーとフレキシビリティを注ぎ込んだ、何千ページにもわたるドキュメントに関しては堅苦しくならないように話しました。「可能性は無限大」などという言葉も使いました。しかし聴衆の間には、数多くの困惑した眼差しだけが見えました。私たちは言いました。
「pyATS のライブラリ、Genie は抽象化したライブラリ インフラストラクチャを備えています。例えば OS とリリースなどの事柄の間の相互の違いを抽象化し、API を構造的な方法で構築することを可能にし、API システムが現在スクリプトを実行中のデバイスをベースにしたライブラリの適切なセットを読み込む、シングル ソーススクリプトを書く、ということができるようになります。
スクリプトを構築するために、設定なしで使用可能な何千ものライブラリや API があります。
皆様はビジネスロジックを管理できます。可能性は無限大です。」
自分たちの設計に自信をもっていました。他の開発者たちが理解してくれることを望んでいました。フレームワーク自体の内部の仕組み (例えば拡張) に興味を持つだろうと思い込み、それを使用して実世界の問題を解決するという最も重要な側面を忘れていました。言い換えればユーザは、抽象性すべてを通した価値を見出し、要素と機能を当面の課題を解決するソリューションにマッピングすることを望んでいるものだということです。
例えるなら、数千ピースのレゴが入った箱を誰かに渡し、「これで何でも作れるよ」と言っているようなものでした。そう、理論上は可能です – しかし、たどり着くまでには長い時間がかかりそうです。
私たちには、そんな種をまく秘訣が欠けていました。
私たちには確かに事例もありました。しかし私たちの事例は、ロジックが相互のインターフェイスをどのようにブロックするかという、インフラストラクチャの機能を紹介するものでした。それが何故利益になるのか、または日々のネットワークの問題を解決するためにどのように応用できるかを理解するための役には立ちませんでした。
時とともに、そして先駆的ユーザのひらめきの下で、またシスコ DevNet、CX & SE のエキスパートにより、ソリューション ベースアプローチに向けて徐々に変わって行きました。
- 私のネットワークで何が変わったの?!! Genie に聞いてみよう– Hank Preston
- pyATS のデモ：ネットワークのプロファイリング – NetDevOps シリーズ第 15 部– Julio Gomez
旅をする – 単に説明するだけでなく
1 つの製品の成功とは、2 つの重要な要素の組み合わせです。強力なソリューションと、ユーザが目前の問題を解決するために役に立つユースケースが対になっています。
今なら何事にも全く異なるアプローチをするでしょう。前と違って次のように言うでしょう。
「pyATS は設定不要ですぐに使えます。最初は使用しているネットワークの運用状態を学習して比較するなど、簡単なことから始められます。
・使用しているネットワークが現在どのように動作しているか学習します (構成 + インターフェイスの状態、ルーティング、近隣などの運用データのためのさまざまな show コマンド)
・使用しているネットワークに変更を加えます (例えば、構成を変更する、何らかのネットワークイベントを待つ、など)
・新しいネットワークの状態を再度学習し、以前のスナップショットとの比較を行います
diff システムは、使用しているネットワークで何が変更されたかをすぐに知らせてくれます。エラーイベントのデバッグのため、そして構成の変更が目的とした効果をもたらしたかどうか、などを突き止めるために役に立ちます。」
システムがどのように実装されているか複雑な詳細に移動することなく、対象ユーザの注目を日々の作業に関連する使用シナリオに集中させます。この新しいアプローチは、すぐに、誰とでも調子を合わせます – そして、地平を広げる最初の種をまきます。
別の例を挙げます。pyATS のテストスクリプトの実行で、カスタム ループ ジェネレータに対応するために、ランタイムエンジンを明示的に設計しました。その設計は、以下に示すようなものです。
そして、その機能を以前だったら次のように話していたと思います。
「pyATS では、テストケースは通常、線形アプローチ、つまり、それらが定義された順番で実行されます。それに加えて、ループ化されたテストケースを作ることができます。例えば、同じテストケース/コードを反復し、再利用することができ、それぞれの反復 (独立した分離オブジェクトインスタンス) に入力変数値の独自のセットを取ることができます。
明示的にジェネレータに対応するために、それを構築しました。皆様は独自のテストケースジェネレータを作成し、それをループエンジンにフィードすることができます。そこで実行する対象、およびそれを実行する方法を全面的に制御できます。」
上記の議論では、この機能の価値はすぐには明白になりません。
今日、この機能に全く異なるアプローチをします。それはむしろ以下に近いものです。
「pyATSでは、一般的に、テストスクリプトは WYSIWYG アプローチに従います。使用するテストケースは、スクリプトで定義した順番で実行されます。例えば、
1.デバイスに接続
2.インターフェイスを構成
3. Ping を検証
そして、アクションを 1 つずつ順番に実行する線形スイートを構築し、ありふれたタスクは自動化できます。
さらに、システムは、テストケースが実行される方法を完全に制御することを可能にし、また、オンザフライでテストケースを「生成」することもできます。
例えば、使用するネットワークに変更 (カオス) を挿入する chaos-monkey/chaos-engineering モデルでは、最初に使用するネットワークの現在の状態を読み取るテストケースジェネレータを構築し、ネットワークがどのような障害をもたらす可能性があるかを判定することができます。その障害を起こし (テストケースを実行し)、テストケース結果の組み合わせに基づいて (例えば、カオスが正常に挿入されたか)、そしてシステムが適切に対応するかどうかによって、自動的に復元してレポートするか、または実行を続けるかを判定します。」
機能そのものは変わりません。変わったことは、ユーザの立場を経験し、ネットワークのエンジニアが私たちの機能をネットワークデバイスで実行したいことに関連付けるということです。
ソフトウェアピラミッド
ソフトウェア開発は、ピラミッドの建設に似ています。堅固な基礎から始めて、ライブラリを構築し、それにドキュメントを追加し、トップをユースケースで締めくくります。しかしながら、開発者がその製品を消費する場合、開発者はユースケースから始めます – そこが彼らに最も関連があるところです。ユーザは、ユースケースがその解決のために役立つことができる問題点に関して、迅速なフィードバックを得られます – それ自体は他の扉を開くための鍵となり、ドキュメントの参照に導き、より多くの API を活用し、そしてより多くの可能性を解き放ちます。
優れたユースケースは、採用決定過程を促進する触媒です。
フレームワークそのものがレゴのブロックのピースであるとすると、ドキュメントはブロック同士を繋ぎ合わせる方法を教えるガイドであり、そしてユースケースは最終目的を達成する方法を指導するパンフレットです。
ありがとう
4 年近くが経過し、私たちの抽象的で強力なシステムを構築するという根本的な理想論は変わっていません。変わったことは、私たちが自分たちのストーリーをもっとうまく語れるようになったことです。
Webex チームルームの 1000 人近いユーザと共に、皆様からたくさんのことを教えていただきました。pyATS はテストエンジニアリングとお客様との橋渡しになりました。それによりユースケース、お客様の解決困難な問題に立ち返り、シスコが自社製品をより適切にテストするために活用しております。これからの道程もまだ遥かに先ですが、真摯に取り組んで行きます。
可能性は無限大です。
関連リソース
Authors
