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

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

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

(前の記事はこちら)

では、これらの対策に何をしたかをお話しましょう。

f:id:canalroy:20190827205341p:plain
行動原則を規定

我々は、エンジニアリングの行動原則を設定・適用しました。
これらは全く誰にとって目新しいものではありませんが、先ほど紹介した問題と相関関係にあります。

我々は、テスト環境を追加しました。
また、そこではバージョンコントロールと本番環境への適用に対する承認行為を採用しました。

f:id:canalroy:20190827205346p:plain
Ansibleの環境について

環境について話しましょう。

2年半前に、我々はAnsibleTowerを導入しました。
そして、我々は開発/テスト、プリプロダクション、プロダクションの3つの環境を用意しました。 これら3つの環境にはそれぞれ特定の目的がありそれらの目的の達成が強制されています。

開発/テスト環境においては、過去の環境と同じものが構成されています。

環境へのフルな権限は与えていません。
テストラボの中の端末にしかアクセス・実行できず、それらは仮想環境でネットワークを再現しています。
もしも、ネットワーク全体を再現してテストしたいというリクエストでも、他の人たちを待たせることなくテスト実行するための環境を渡すことができます。

開発/テスト環境で素晴らしいところは、開発者とネットワークエンジニアはお互いに全てのコードにアクセスできることで、どちらのスキル保有者も『ネットワーク開発者(Network Developper)』へのコンバートへトライできることです。
プラットフォームへもログインできますし、テストでラボ全体を使ってテストをして環境を壊すようなコードを書くことができますし、誰かがそれを修正することもできますし、やろうと思えばどんな事にもトライできます。

プリプロダクション環境をみてみましょう。
私たちは完全なネットワークアクセスを持っていますが、開発とマスターのブランチアクセスのみに限定されています。
そして、作成したコードは開発(develop)ブランチに入るためにどのようにプロダクションへの移行を進めるかについて会話を始めたなら、完全なコードレビューを経る必要があり、レビューを経た時点でコードはプロダクション用途として完全なものと考えられます。

そして、プロダクション環境のクラスタです。
最高規模のクラスタで、最も多くのCPU数やメモリを持ち、ここですべてのプロダクションワークロードを実行し、高可用性を確実にするため監視もされているクラスタです。
そして、これらに対する更新作業の裏側ではほとんどがAnsibleTowerを用いて行われています。

f:id:canalroy:20190827205352p:plain Ansible Towerが可能にすることの一つに、バージョンコントロールがあります。

以前は、必ずCLIを用いてそれぞれの環境でコマンド実行の必要性がありました。

そして、他の誰かが知らないうちにログインし、コマンドのたった一つに私が知らない変更を加えて、結果私が実行した時に予期せぬ結果を生み出すようなことが多々ありました。

現在我々はGitHub Enterpriseを用いています。

MicrosoftがGitHubエンタープライズのヘビーユーザーだったのでGitHubを買ったという話がジョークだったと言いたいのですが、冗談ではなかったのでしょう。
実際に我々はGitHubエンタープライズを使い始めました。
私たちはコードをすべてのサーバーに配布し、そしてそれらがきちんと特定のブランチから配布されているかを検証し確認します。
これらを原則とし、ブランチルールなどの規則を適用することができるようになりました。

f:id:canalroy:20190827205403p:plain

最終的には、プロダクション環境へのワークフローを承認します。
コードは開発ブランチから分岐したFeatureブランチから始まって、エンジニアたちは本当に様々な面白いコードを多数作成して、それらの開発中コードを繰り返しデバイスに対して実行して、本当に動くかを確実にテストしています。
問題なく動作できた場合には、開発ブランチへのプルリクを実行します。
実際にコードがレビューされ、プロダクションレディかどうかを確認します。

こんな形なので、おそらく誰でも機能開発のコード開発にトライすることができると思っています。
現在では素晴らしいことに、2週に一度、変更があった全てのコードをマスターに適用するような変更を加えることができるようになりました。

すでに組織にいる誰もが自動化に対して取り組めるようになっているし、自動化のコードを書いた全ての人を褒め称えるような組織的なコミュニケーションもやっています。
そして、これが本当に組織文化の変革における始まりだったのです。

例えば、古いシステムで私が自動化のコードを何か新しいものを書いたとして、話したこともないような人がそのコードを信用してくれて、プロダクション環境で実行しようとしてくれるようなことがあると思いますか?それがどう動作するかもわからないのに?

今、Microsoftは文化を作り上げました。
そこでは自動化の新機能をリリースするために協力したとして皆が名前をクレジットしたいと考えるようになったので、新たなCoolな取り組みにどんどんと参加するようになっています。

そして、これを実現するためにMicrosoftはAnsible Towerを購入しインストールすることにしました。そして、自動化のプラットフォームを構築し、そのトップにAnsible Towerを置いたのです。

(次回へ続く)

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