この記事は、以下のシリーズの1つ目の記事です。
(前の記事はこちら)
MicrosoftのソフトウェアエンジニアリングチームのマネージャのBart Dworakです。
今日は、Microsoftが文化をどのように変えたのか？
そしてその変化のためにRed Hatと協力しAnsible Towerをどのように使用しているのかをこのセッションではお話ししようと思います。
では、これまでのMicrosoftとは？を話しましょう。
我々は、Microsoftの内部ネットワークを管理するチームです。
400+のインフラエンジニアがおり、全世界で600+のオフィスなどの管理をしています。
例えば、WirelessやVPNの整備をし、Microsoftの全ての従業員へ使わせるような業務というとわかりやすいと思います。
2015年では13,000ほどの設備を管理していましたが、2019年には17,000台以上の設備管理が必要になっていました。
現在では、ネットワーク設備の管理だけではなくAzure上で利用しているさまざまな資産の管理も開始しています。
それまで、自動化は手がけていなかったのでしょうか？
いいえ。手がけていましたが、Ansible Towerを導入するよりも前は単純なスクリプトが中心でした。
そういったスクリプトによる自動化のようなものでも、単純にコマンド実行はできていました。
ですが、レスポンスを見ながら何かをするような作業を自動化することは難しかったです。
そんなかつてのMicrosoftのネットワークエンジニアのスキルセットは、CLIが中心で、みんなPutty(日本でいうTeraterm)が大好きで、どんな変更をするにもログインをする必要がありました。
このやり方は、10-20か30-50程度のネットワークを管理するにはとても合っています。
ですが、今日話をするのは17,000以上を管理するための話です。
同じやり方を続けての管理は不可能です。
こちらが、本日お話をしたいアジェンダです。
まず、我々がこれまでエンジニアリングにおいてどのような問題・課題と対峙していたかをお話ししたいと思っています。
次に、我々が打ち立てたエンジニアとしての行動原則や、今どのあたりまで達成したのかを。
文化を変革するために何をやってきたのか。
実際に変革の過程のなかでどのような問題と対峙したのか。
打ち立てたエンジニアの行動原則(Engineering Principles)がどのようにMicrosoftの組織としての文化を変えたのか。
それらはどう我々の将来の価値になるのか？ネットワークの何を自動化しているのか？などです。
では、まずエンジニアリングの何に問題があったのか？
結論から入ると、バージョン管理がされていない状態で、本番環境の設定を実行していました。
何が正しいのかの確証は環境内部にしかありませんでした。
エンジニアリング組織として、2つの環境を我々は持っていました。
プリプロダクション環境とプロダクション環境です。
どちらのネットワークにも完全なアクセス権限があり、それを良しとしてきました。
あなたが、スクリプトを書いてどんな驚くような変更だろうと実行できてしまうプリプロダクション環境を持っています。
一方で、プロダクション環境での操作はとてもハードですよね。
エンジニアとしては、全ての作業をプリプロダクション環境で実行しようと選択するようになるでしょう。
皆さんも同じような経験をされましたか？
プリプロダクションの環境では承認などもいらないので簡単になんでもできて、プロダクション環境では絶対に何もできなくなるんです。
これまでのツールでは、バージョン管理に対応できていませんでした。
ツールにログインして、全ての実行する必要があるスクリプトをマニュアル実行する必要がありました。
このやり方を、色々な設備で同じように実行する必要があったんです。
同じようなスクリプトをなんども手動で実行させるというのは、エンジニア達に色々なところで様々な問題を引き起こさせるにはとてもいいやり方です。
スクリプトがプリプロダクション環境ではゴロゴロと転がっていて、その辺でイノベーション(皮肉)が生まれています。
それらのスクリプトをあなたが書いている訳ではなかった場合、途端に本番環境で実行するには信頼するに足りないコードの塊を所持していることと同義になってしまいます。
なので、すでに言ったように、これらはプリプロダクションからプロダクション環境へコードや設定を移す際に発生する、もっとも大きな問題の一つになります。
どこにも何も問題がないということを調査するために、メールをし、たくさんのエンジニアたちと話して確認する必要があり、精査をしていく必要があるのです。
これには膨大な時間がかかります。
もし、自分の仕事を終わらせたいということが第一目標になった場合、同じような確認作業を確実にやろうと思うでしょうか？
良いコードというのは、プリプロダクション環境で一度でも問題なく実行できれば良いコードと見られます。
そしてこれらの両方の環境への完全なネットワークアクセスを持っています。
私やエンジニアに取って、もっとも抵抗が少ないやり方は、プリプロダクション環境で問題無ければ良しとすることです。
結果として何が起きるのかは想像にお任せします。
では、これらの対策に何をしたかをお話しましょう。
(次回へ続く)
