Red Hat Summit 事例翻訳:5.Analog transformation: Scaling network automation culture with Ansible Tower at Microsoft

この記事は、以下のシリーズの5つ目の記事です。

Red Hat Summit 事例翻訳:Analog transformation: Scaling network automation culture with Ansible Tower at Microsoft

(前の記事はこちら)

そして、最後にAutomation Communityについてお話しましょう。

f:id:canalroy:20190827205434p:plain
MS社内の自動化コミュニティについて

私たちはチームの中にコミュニティを作りました。
そしてこのコミュニティは私たちがすべての質問をリダイレクトするところでもあります。
ある時、気が付いたのですが、たくさんの人たちが私たちのオフィスにやって来て質問をしているということです。そしてそれらの質問の多くは素晴らしい質問でした。

私たちは、これらの質問をどのようにまとめるか?ということを考えました。
書き留めてから、後でこれらの質問を投稿する場所を作り、eメールで送信しました。
結果、我々がやり始めたことで、開発チームの多くの負荷を軽減しました。

自動化のコミュニティがあるのなら、参加するべきでしょう。
我々は、誰もこのコミュニティへ強制的な参加やメンバー追加をしていません。参加することは完全にオプションです。ですが、もし同じようなコミュニティがあるなら、参加することをおすすめしますし、そこで質問をするべきです。

我々がオートメーションコミュニティを開始するや否や、爆発的に広がりました。
誰もが質問をし始めました。そしてその大部分は私たち専属チームのメンバーが答えているのではなく、組織内の他のエンジニアが質問に対して回答をしていました。

エンジニアの特性について、一つお教えしましょう。 エンジニアに問題を与えた時に、彼らは質問に対して回答をする最初の人間になりたいという、誇りのような感覚を持っています。 なので、コミュニティになにがしかエンジニアへの質問を投稿した場合、それをきっかけに大量の人がGoogleでその答えを検索に行くか(冗談)、回答してくれようとします。 それは20人のエンジニアが何かを実装するための正しい方法について議論するために反応しているようなもので、どんどんと会話に拍車をかけていきます。

会場にいるみなさんがMicrosoft Teamsを使っているかどうかはわかりませんが、Teamsを使っている我々のようなケースでいうと、すべて異なるTeamsにメンバーとして追加されているはずです。 自動化コミュニティは?私たちの組織にある、私たちが持っている、1つのTeamsであり、そこへアクセスしたい全ての人が参加できる場所で、本当にうまくいっています。
誰もが参加してくれました。

コミュニティの質は、まさしく素晴らしいものです。

さて、この文化的な変革は何が正しく見えるようになったのでしょうか?

f:id:canalroy:20190827205440p:plain

冒頭で申し上げたように、我々の自動化はネットワークでシンプルなスクリプトを扱うところから始まりました。

interface,何とかかんとか、shutdown, no shutdown...それらのコマンドが羅列されるPlaybookを書き始めました。
そして、ロジックを埋め込んだPlaybook。
デバイスのタイプを決定するPlaybook。
端末上のメタデータを読み込むPlaybook。

変更を加える前に特定の設定を検索することではるかにスマートになったPlaybookでは、APがダウンしたときにAPの復旧指示まで自動化するような本当にクールなことを実行でき、スクリプト内で決定を下すことができます。

我々は、『ネットワークエンジニア』が『ネットワーク デベロッパー』に変わったところを見てきました。
そして今はネットワークエンジニアが、ネットワークデベロッパーに変わったことを本当に実感しています。
もはやCLIを用いて日常を浪費することはないので、なにがしかの問題を解決するためには今ではそれ以外の方法を用いることを考えています。

ネットワークデベロッパーは私たちのプラットフォーム上でソリューションを開発しました。
彼らは、彼らのネットワークスペースに問題があることを知っているので、そこにたくさんのブラウンフィールド(再利用されない)なコードを持っていました。
それらはスノーフレーク(密結合)な状態で、自動化することは容易ではありませんでした。
どのようにプロセスを構築することできたのか、我々はまだまだCLIコマンドを利用しています。

CLIコマンドを利用し、相互にレビュープロセスを必要としています。 標準的な変更なので実行できますが、一度そのプロセスが完了すると、その後はAnsibleがそれらのコマンドを実行し、そのおかげで実際に承認したユーザーや何が実行されたのかを確認して追跡できます。
これは、私たちが過去にしていたことよりも、もっと目が行き届いた、より良いプロセスになりました。

そしてスライドの下の方に書かれているのは、我々が使っているツールたちです。
GitHubエンタープライズを利用している100人以上のエンジニアがいます。
Gitはすべてのグループや組織で使用されています。
Ansibleは、至る所すべてのユーザーで、最も重要な流行語(Buzzword)です。

また、さまざまなチームがPythonの様々な利用方法を検討しています。
Pythonを使用して双方向的で、かつ迅速で新しいデータ変換をネットワークデバイスへ行えるようにする方法などを検討しようとしています。

MicrosoftはCosmoDB(Azureの大規模なデータベースサービス)を持っているので、様々なFact(Ansibleで収集できるデータセット)を収集しています。エンジニアがデータベースから様々なFact情報を読みにいけることで、より良いネットワーク構築を行うために彼らが何をすべきかなどの判断をその場で決定できるようにしようとしているのです。
そして、我々もたくさんのアジャイルサービスを利用するようになってきましたが、誰もがクラウドを利用しています。

最後に、これからの大きな賭けの話をしましょう。

(次回へ続く)

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。