「なんだかよくわからない」をどう乗り越える？　インフラ業務を開発エンジニアに移譲するためにやったこと

インフラ業務を開発エンジニアに移譲するまでの軌跡

茂木高宏氏（以下、茂木）：みなさん、こんばんは。今日はお忙しい中お越しいただき、ありがとうございます。「インフラ業務を開発エンジニアに移譲して」というタイトルで始めます。

まず自己紹介です。CyberZ F.O.Xでエンジニアをやっている茂木高宏といいます。

インフラ技術はほぼ全般的なことをやっていたんですが、中でも得意なのがビッグデータ関連です。スライドの右側にあるのはCloudera World Tokyoという技術カンファレンスで、こちらに登壇してきました。

他にはAWS系の技術やops系の技術が得意です。スライドの右下、ServerlessConf Tokyo 2017というカンファレンスにも登壇してきました。Lambda等を使い、サーバーレスアーキテクチャを用いた知見を共有をするカンファレンスです。

他にも、オンプレでもけっこうやっていたので、サーバーのハードウェアや、そういったOSやカーネル部分を得意技術としてやっています。

さっそく本発表なんですが、「インフラ業務を開発エンジニアに移譲して」ということで、2年間の軌跡を発表していきます。時系列で説明していこうと思います。

主に4つ分かれていて、業務を移譲する前と、移譲してる時、移譲し終わった後、そして、今どうなったか。この順番で発表していこうと思います。

移譲の背景と、移譲前の状況

まず、移譲前に関してです。背景なんですが、F.O.Xは、過去、オンプレミス環境で7割ぐらい、AWS環境で3割ぐらいで動いていました。この時、オンプレミス環境を撤廃して、完全にフルAWSでやっていく完全クラウド化の方針が決まっていました。

この時の状況として、業界的にマイクロサービスアーキテクチャが浸透し始めていて、開発エンジニアがインフラから開発のレイヤーまで業務でやっていくようなフルスタックエンジニアが社内でも求められつつありました。

これは当時の状況なんですが、開発チーム（開発局）と、インフラチーム（インフラ局）が存在していて、開発チームはソフトウェアのことだけで、インフラチームはインフラのことだけというように、完全に分業していました。

当然開発チームがインフラのことをやろうとしても、権限もなかったので、やれないという状況でした。ここで挙がってきたのが、「柔軟な開発ができなくて、開発スピードが落ちているよ」という問題でした。

あとは、障害対応のロスです。なにか障害があってそれを解決させる時に、インフラチームと開発チーム、両方が連携し合って解決に導いていくかたちだったので、そこで発生するコミュニケーションロスや調整ロスがけっこうありました。また、インフラを意識した設計ができなかったというところです。

インフラチームとしてはエンジニアがかなり不足していまして、当時、私ともう1人くらいしかいませんでした。障害対応のロスや開発を意識した設計などもうまくできない状況でした。

そんな中「インフラ業務を状況的に開発エンジニアに移譲していこう」という方針に決まりつつありました。

ただ、そこで新たに発生した課題が、今までインフラチームがずっとやっていたので、開発チームからしたらインフラの業務が未経験であったことです。他にも、スキルや知識が不足していました。

新規でサービスをつくるのであればアリかもしれませんが、すでに何十ものプロジェクトが動いていて、既存システムと連携が発生するような箇所もありました。そういった中で「明日から全部よろしく」となっても厳しい。ということで、社内のプロジェクトが始動しました。

インフラ技術向上プロジェクトが始動

これは社内の育成プロジェクトです。「インフラ技術向上プロジェクト」ということで、基本的にF.O.Xの開発エンジニア全員を対象としています。

目的は、インフラ業務・インフラエンジニアのスキルを養い、インフラ技術力を向上することが目的です。

最終的にインフラチームを廃止し、インフラチームの人間が開発チームに合流する、といったところを目指すものでした。

当時期待していたエンジニア像なんですが、開発エンジニアからすると、インフラ業務というのは暗闇の中にまぎれていて「なんだかよくわからない」、といったところがあったので、「積極的に取り組んでもらって、欲を言うなら自走できるといいな」と思っていました。

他にも、インフラも市場がどんどん変化していくので、インフラ市場の動向を自らキャッチアップしていけるだったりとか。あとは、「インフラの経験や実績をつくって、フルスタックエンジニアとしての市場価値を高めてほしいな」と、そんなことを思いつつ始めました。

この育成プロジェクトを始めるにあたって、準備した3つのことがあります。

まず、1つ目として育成運営チームを用意しました。

スライドの向かって左側が私です。

3ステップの育成カリキュラム

2つ目として、育成カリキュラムを組みました。F.O.Xでは、ちょうどデータセンターのクラウド移行をプロジェクトとしてやっていたので、「それなら実際にインフラ業務をトライできるな」と思ってやってもらいました。これは僕が思っていることなんですが、「インフラの実業務に勝る育成方法はないんじゃないか」ということでチャレンジしてもらいました。

主に「伝える／見せる」「やらせる」「教える」の3ステップがあります。その「伝える／見せる」「やらせる」のところでは具体的に、個人的に目標をすり合わせたりしたりして、ハンズオンやレクチャーしました。「やらせる」では、非同期学習をしたりレビューし合ったり、グループワークをしたり、それを僕のほうで立ち会ったりとか、そんなことを準備しました。

内容についてですが、実際はAWSでプロジェクトを開発、運用する時に必要になる、基本的なものを対象としていました。

3つ目として、現行システムの再設計をしました。よくある〇〇共通基盤系とかの再設計をしました。統合監視共通基盤だったりとか、そういったものですね。

再設計するにあたって、敷居を下げるっていうところを目標に置いていました。敷居を下げるいうのは、学習コストが低い、利用しやすい、管理しやすいですね。

せっかくなので、1つ、構成管理基盤について簡単に、技術的な要素が多くなるんですが、紹介しようと思います。

構成管理の再設計ということで、構成管理にはいくつかのレイヤーがあります。プラットフォームレイヤー、サーバーレイヤー、オーケストレーションレイヤーがあって、再設計後と再設計前をスライドに書いています。

再設計前はいろいろな技術が入り乱れていたんですが、再設計後はある程度統一しました。

なぜAnsibleを使ったのか

この中で構成管理で使っているAnsibleについて、簡単に話します。Ansibleとは何かというと、Infrastructure as Codeを実現するためのツールです。

DSLでインフラの構築手順や運用オペレーションの手順を書いたりすることで、自動化したりするものです。ソフトウェア開発のプラクティスを適用できるので、GitHubにコードをコミットしてレビューし合うなど、普段から開発エンジニアに馴染みがあります。

このメリットは、品質の向上であったり、運用オペレーションをテンプレート化できるので運用の標準化、再利用性、工数削減などです。

「なぜAnsible？」ということなんですが、Ansibleって非常にシンプルです。オープンで、さまざまな企業で本番導入されて実績が高い。他にも、かつてCyberZ内で本番運用をしたことがあったので、過去のナレッジがありました。

つまり、学習コストが低かったということと、困ったらググれば大量に情報が出てくるというところです。これは大事で、インフラの技術は仕様がオープンではないものがけっこうあります。ベンダーに仕様を確認しないと分からなかったり、そういった部分が敷居が高いなと思っていて。Ansibleの場合はこういったところがないので、非常に良かったです。

妥協した技術なんですが、実はコンテナ技術は妥協しました。理由は、AWSだったんですが、2016年代のAWSは非常にコンテナ技術が弱かったです。

GCPであればわかるんですが、理由は、コンテナを本番運用すると、Kubernetesが必要になることがあり、当時はKubernetes on EC2の選択肢しかありませんでした。これは高いスキルが求められます。普段開発しつつ、片手間でKubernetesの面倒見てるのも大変だ、ということで見送りました。

ただ2018年からは、AWSでフルマネージドのコンテナサービスが出てるので、再度検討しようかなという段階です。

移譲中に生じた課題をどう解決したか？

そんな感じで育成プロジェクトを始動していきました。次に、業務移譲中のことについて話します。

移譲中にも、やはりいくつか課題が出てきました。その課題に対する解決を紹介します。

まず課題だったのが、言われたとおりのことしかやれないということ。もともと、「伝える／見せる」のところで、僕のオペレーション方法を見せていたんですね。

そういうこともあったからか、僕がやったことをそのままやるという、いわゆる写経オペレーションしかできない状況でした。写経オペレーションも大事といえば大事なんですが、応用が利きません。

この解決策なんですが、育成の取り組みとして、逆ハンズオンというものを用意しました。これは、僕がさまざまなお題を出して、開発エンジニアがそれをデモンストレーションして実際にやるというものです。

それをやるにあたって、「なぜこうしたのか？」「何の意図があって、このように進めていったのか？」、その意図を含めた説明をしてもらう。それで議論し合うというものをやりました。

2つ目に「そもそも何がインフラのスキルなのか？」という部分です。スキルが向上してほしいなと思っていましたが、「具体的に何ができたら、スキルが向上したことになるんだろう？」ということが課題が現場の意見として挙がってきました。

この時は単純で、希望者のみ基準表のようなものをつくって個人レベルで起票して、フィードバックし合うみたいなものです。

3つ目に、権限付与が目的になってしまったことがありました。最初は期待したのは、インフラ業務というのは何をやってるかわからないし、暗闇の中にまぎれてるような状況の中で、開発エンジニアもインフラ業務に明るくなってほしいし、積極的に取り組んでいってほしい、欲を言えば、自走できるようになっていってほしいな、と思っていました。しかし、権限付与が目的になって、若干これらが欠けてきてしまったという課題がありました。

これに対する解決策ですが、その他サービスを構築するラインを設けました。これは何かというと、既存のインフラ環境の問題点を見つけてもらいます。そこで議論しつつ、自由な発想で改善案を提示してもらう。それを実際にシステムとして表現してもらい、つくってもらう、といったものです。

つくるにあたって、見積り、性能、運用、設計、構築など、全部やってもらいました。期間は1週間ぐらい取っていました。

実際の成果物のイメージですが、上がCloudFormationとJmeterを使い、継続的な負荷CI環境です。

向かって下は、サーバーレスアーキテクチャを入れて、CloudWatchEventとAWSのLambdaでつくるDynamic DNSというシステムですね。これらがけっこう良くて、つくったのが1年半ぐらい前ですが、実はまだ本番で稼働しています。

こんなことをやって、事業部内の数人がインフラ業務をトータルで可能な状態がつくれました。

移譲後の課題と解決策

次に移譲後についてお話します。移譲後は2017年3月ぐらいですね。

移譲後は「教える」というフェーズにフォーカスしました。実際に、他の人に説明することで、さらなる理解が増すんじゃないか、と思いました。私も、常に「伝える／見せる」「やらせる」をやっていると、そこで属人化するので、教えることを移譲しました。

そんな移譲後に発生した、いくつかの課題とその解決策です。

まず1つ目に、開発プロジェクトにナレッジが属人化しました。F.O.Xの中では複数の開発プロジェクトがあるのですが、特定のプロジェクトで使ってる新しい技術系のナレッジが開発プロジェクトを横断して活かせないような状態でした。プロジェクトが1人のエンジニアに紐づいてしまう。そういった状況がありました。

この解決のために、チーム体制へシフトしました。これは開発プロジェクトが1エンジニアに紐づいているような状況を、チームに紐づける。そして、チームを少人数制の3人、4人でやっていくというものです。これはまた後ほど紹介します。

2つ目にインフラの事前の運用管理保守設計、実装が弱い、という課題です。これは何かというと、インフラの運用管理保守というのは、例えば監視系であったり、データをリカバリーするための設計など、そういったものです。

実際に事象が起きてからそれを対応する事は、この時開発エンジニアでやれていたんですが、事象が起こる前に対応するという事前の対応に弱い部分がありました。

理想は、なにか大きな障害が起こって、それの再発を防止するために対応する事後対応よりも、大きな障害が起きないように事前に策を施しせる事前対応の方がが良いのです。

ここは難しくて、さまざまな開発のプロジェクトの運用経験がないと厳しいところがありました。

この解決として、SREチームを用意しました。このSREチームの業務は、運用ナレッジが入るような、事前な運用管理保守設計のフォローアップをしていく、というものです。一方的にSREチームが手を動かしてなにか作業する、というものではありません。イメージ的には「一緒にやっていこう。一緒にやっていって、フォローするよ」程度のものです。

他にもSREチームは、〇〇共通基盤、のグロースをしていました。

こんなことをやり、3人チームの中に2人ぐらいは、インフラ業務をトータルでできるような状態がつくれました。