2016-07-25

ウェブオペレーションエンジニアの id:y_uuki です。2016年度のウェブオペレーションエンジニアの新卒研修を紹介します。

今年はウェブオペレーションエンジニアとして2名(id:masayoshi id:taketo957)が新卒として入社しました。若手のインフラ系エンジニアが少ないと言われる昨今で、もともと7人のインフラチームに2人も新卒が加わることはなかなか珍しいのではないでしょうか。

今年の新卒エンジニアは 2016年度はてな新人エンジニア研修を行いました - Hatena Developer Blog のエントリで紹介した新人エンジニア研修の後に、チームに配属されました。通例であれば、チーム配属後はOJTという名目で即実戦投入されます。しかし、今回は、OJTの前段に2週間程度の研修期間を設けてみました。

研修の動機

ウェブオペレーションエンジニアは、一般的なコンピュータサイエンスやウェブシステムの知識に加えて、社内のインフラ基盤や各サービス固有の知識も広く求められます。前者については、書籍やウェブ上の資料で体系的に学ぶことが比較的容易です。しかし、後者については、まとまった資料がない、というのはよくある話です。したがって、具体的なタスクをこなして、ボトムアップに学んでいくことになります。

それはそれで悪くはないのですが、トップダウンに全体の構成をみる機会がないことが問題だと思っていました。具体的には、以下のようなものです。

部分しか知らないと、上位レイヤと下位レイヤの両方を睨んだ最適な解決方法を発見できない
部分しか知らないと、既存の解決方法があることにすら気づかない
やったことないタスクをやるときに、作業見積もりができない

これらをある程度解決するために、新卒向けに研修を導入することにしました。

研修の設計

問題を踏まえて、どのように研修を設計したらよいか考えました。チームの状況を鑑みて、丁寧に資料を作成し、講義をする暇は残念ながらありませんでした。

そこで、自律学習とフィードバックをベースにした研修内容を考えました。課題を与えて、課題に対してアウトプットしてもらい、アウトプットを先輩社員がこまめにフィードバックするというものです。これで、業務に必要な知識がすべて身につくわけではもちろんないので、ポインタを知っておくことが大事です。

課題は知識課題、設計課題、実践課題の3種類用意しました。

知識課題

知識課題は、はてなのインフラの現状を理解するための課題です。はてなのインフラを構成する各トピックについて、自力で調査し、その結果をまとめてもらいます。1日ごとにトピックを用意し、次の日にアウトプット内容をみて先輩社員がフィードバックします。各トピックについて、一般的な知識はある程度あるものとして、はてなではどのようにやっているのかを把握することに主眼を置いています。

調査を進めるにあたって、社内のwikiをみてもよいし、GHEにあるリポジトリも自由にみてもらってよいし、サーバにログインして非破壊的なコマンドを実行してもよいとしました。

あまり長々と研修期間を設けるわけにはいかなかったので、かなり詰め込んだ内容になっています。

1日目: サーバプロビジョニング
- オンプレミス環境におけるブートストラップの仕組み: KickstartやXen環境の作成の仕組み
- AWS環境におけるEC2インスタンス作成の仕組み
- Chef運用
- アプリケーションデプロイ (Capistrano)
2日目: 仮想化基盤の構成
- Xenの構成
- LVMの構成
2日目: ロードバランサの構成
- LVS/TUN
- LVSの台数やLVSとサブネットの関係など
3日目: 冗長化の仕組み
- Keepalived
- MHA & ENI
3日目: MySQL運用
- フェイルオーバの仕組み
- 参照用スレーブ
- バックアップ方法
4日目: サーバモニタリング
- Mackerelのステータス管理やロール管理
- Mackerelと各ツールの連携
4日目: 典型的なサービス構成
- オンプレミス: 人力検索はてなの構成
- AWS: はてなブログの構成
5日目: その他
- 各種サービス探訪
- 各リポジトリ探訪
- ネットワーク構成

設計課題

設計課題は、スケーラビリティのあるシステムをどのように設計するのかを理解するための課題です。3日ほどで課題に対する設計案を考えてもらって、発表形式で議論しました。

設計課題を設けた理由は、最近のシステムが昔に比べて要求が厳しくなっているため、気軽に任せられるようなシステムが減ってきたことです。そこで、既存のシステムをベースに大きな機能を追加するときや、アクセスが10倍になっても耐えられるようにするにはどう設計するかを考えてフィードバックする機会があればよいと考えました。

今回のお題は、「Mackerelにおいて現状の100倍の稼働エージェント数に耐えられるシステムを設計せよ」でした。他の既存サービスや架空サービスをテーマにすることも考えましたが、一番難しくておもしろいやつがよかろうということで、Mackerelにしました。

いきなり100倍と言われても、とっかかりがないと考えにくいため、以下の手順で考えてもらうようにしました。

1. 現状の構成
2. 現状構成の限界エージェント数
3. エージェント数 10倍にしたときの構成
4. エージェント数 100倍にしたときの構成

アウトプットとして以下の要求をだしました。

システムの構成図
それぞれのロールにどれくらいの規模のサーバが何台くらい必要なのか
現構成から新構成にするにあたってデータ移行をどのように行うか
必要に応じてアプリケーションをどのように変更するか

正解はもちろんないので、アウトプットとアウトプットに対するフィードバックを通じて、システム設計の勘所が分かれば目的達成です。

実践課題

実践課題は従来からやっていたOJTと同じものです。基本的なオペレーションを含むメンテナンスタスクと本番サービスのシステム構築が主な内容です。

研修のKPT

設計研修が終わった段階で、研修を受けたメンティー2人とメンターでKPT会をしました。

メンティー

Keep
- 研修を通じて横で一緒に作業してる時にそれどうやってるのみたいなのを共有できたりできたのは最高だった
- 設計研修は少し重かったけど実際のサービスについて調べまくるのでPWGとかに出ても話の流れについていけるのが良かった
- 研修で色々調べる事でどの情報が古いかとかを判断する機会になるのは良い事だと思った
- 二人で相談しながら出来たので良かった
- サービスの構成や、はてなインフラの構成の概要がわかった
- git grep, ag でリポジトリ内を検索や、Mackerlを使った検索などもわかった
- 役割分担をできてよかった
Problem/Try
- 調べることに熱中して、メモや、時間などを気にしなかった場面があった
- 調べる内容も本質ではないところを調べすぎたところがある
- 資料作りに向けての時間をもう少し作ったほうが良かった
- (設計研修では)他社の事例をもっと見ても良かった
- 定量的に見られるようになりたい
- もう少し質問をすべきだったのかも知れない
- もう少しコードを見たほうが良い
- 設計研修はもう少し時間が欲しかったかもしれない
- サービス影響を考えて踏みとどまる事が多かった

メンター

Keep
- 新卒同士で組んで課題に取り組んでもらうのは良かった。ペアで知識を補完しあってたのがよかった
- 知識 => 設計の課題の流れがよかった
- 設計課題が難しすぎるかと思ったけど、ちゃんとできてた
- メンターの負荷を最小にしつつ、今後必要となる要素(はてなのシステムの全体把握)をある程度伝えられた気がする
- 設計課題の成果を他のチーム(Mackerelチーム)のエンジニアにもみてもらえた
Problem
- 知識課題でも毎日メンターからのFBは設けたが、うまく機能していない気がする
- メンターから課題進捗が把握しづらくて、翌日の朝にレポートを見てその場でFBだったのでやりづらかった。仮にあまり芳しくない状況のときのリカバリが難しいかもしれない
- 急いで作ったこともあって、全体的に課題の出し方が雑だった
- 2人じゃないとしんどい課題もありそうだったので、次の入社が1人のときにどうするか
Try
- 知識課題は具体的なトピックを充実させたほうが良さそう
- 昼も雑談とかで軽く話したほうがいいかもしれない
- 知識課題は質問をいくつか並べてそれに答える形がよさそう
- 設計課題は成果物のイメージをちゃんと伝えられるように