Cloud Native On-boarding

by Kohei Ota

Slide 1

Slide 1 text

Cloud Native Onboarding ~実践で身につけるモダンインフラの基礎~ Presented by Kohei Ota and Takuya Mikami CloudNative Days Tokyo 2020

Slide 2

Slide 2 text

自己紹介

Slide 3

Slide 3 text

自己紹介(メンティー) 名前: 三神拓哉所属: ZOZOテクノロジーズ役職: エンジニアカタギの人普通の人オンプレミスを扱う部署から　　　　　　　　　　クラウドを扱う部署へ異動

Slide 4

Slide 4 text

自己紹介(メンター) 名前: 太田航平 (@inductor) 所属: HPE 役職: ソリューションアーキテクト Kubernetes SIG-Docs Japanese localization owner Cloud Native Ambassador Docker Meetup Tokyo、本カンファレンス運営

Slide 5

Slide 5 text

自己紹介(メンター) 名前: 太田航平 (@inductor) 所属: HPE 本セッションはZOZO時代の話をします役職: ソリューションアーキテクトエンジニア Kubernetes SIG-Docs Japanese localization owner Cloud Native Ambassador Docker Meetup Tokyo、本カンファレンス運営

Slide 6

Slide 6 text

アジェンダ

Slide 7

Slide 7 text

アジェンダ ● 本セッションの動機 ● 今日のゴール ● メンティー視点 ○ 基本的な業務の進め方 ○ Cloud Nativeな開発を始めて意識するようになったこと ○ 振り返り ● メンター視点 ○ オンボーディングの基本 ○ チーム結成後の動き方と実践に向けたアプローチ ○ 実践でうまくいったこと、いかなかったこと

Slide 8

Slide 8 text

本セッションの動機

Slide 9

Slide 9 text

本セッションの動機 (メンティー視点) ● オンプレだけでこのままやっていけるのかという漠然とした不安の解消 ○ クラウド未経験からクラウドネイティブなエンジニアに転身 ● 社外勉強会で他社エンジニアと交流したときに感じた外とのギャップ ○ 自身は3ヶ月のオンボーディングと実務経験で様々なことを学ぶことができた ○ 周りからは『どうやって勉強したのですか？』という声が多かった ○ 多くの人がクラウドネイティブに関する興味を持っていると感じた

Slide 10

Slide 10 text

本セッションの動機 (メンティー視点) ● オンプレだけでこのままやっていけるのかという漠然とした不安の解消 ○ クラウド未経験からクラウドネイティブなエンジニアに転身 ● 社外勉強会で他社エンジニアと交流したときに感じた外とのギャップ ○ 自分は3ヶ月のオンボーディングと実務経験で様々なことを学ぶことができた ○ 周りからは『どうやって勉強したのですか？』という声が多かった ○ 多くの人がクラウドネイティブ関する興味を持っていることを感じたクラウドネイティブな技術に興味はあるが、はじめ方がわからない人が多い？『仕事でクラウドを使う』ことに大きな壁を感じている人も多い！自身を例としてクラウドネイティブなエンジニアになるまでの知見を共有したい

Slide 11

Slide 11 text

本セッションの動機 (メンター視点) ● 前職のチームビルディングが自身のキャリアにとって1つの大きな資産 ○ チームの仕事に再現性のある一定のクオリティを与えられた ○ 技術力は当たり前として、チームとして何をどうすべきか考えながら動く文化 ● 自分がメンターをやった成果 ○ 1クオータ(3ヶ月)で2人のクラウドネイティブなエンジニアを育成した ○ 今回ZOZOテクノロジーズ関係で登壇している 4人はその時のチームメンバー全員（！） ■ リーダーが@sonots、サブが私

Slide 12

Slide 12 text

Slide 13

Slide 13 text

アジェンダ ● 本セッションの動機 ● 今日のゴール ← ● メンティー視点 ○ 基本的な業務の進め方 ○ Cloud Nativeな開発を始めて意識するようになったこと ○ 振り返り ● メンター視点 ○ オンボーディングの基本 ○ チーム結成後の動き方と実践に向けたアプローチ ○ 実践でうまくいったこと、いかなかったこと

Slide 14

Slide 14 text

今日のゴール

Slide 15

Slide 15 text

今日のゴール (Key takeaways) ● 今日からあなたもクラウドネイティブ！ ● 自主学習とオンボーディングの活用で、短期間でも実践できる学習法 ● メンターとメンティーの関わり方について考えるきっかけにしてほしい ● 仲間を増やすことの大切さについて知ってほしい

Slide 16

Slide 16 text

当時の背景 ● 時は2019年の終わり頃 ○ なんか認証基盤をリプレイスするみたいな話が出た ○ 深遠な理由で比較的ベンダーニュートラルな技術スタックで基盤を作りたいという要件 ○ ML基盤チームでKubernetesの利用が進んでいたので白羽の矢が立った ● ZOZOTOWNオンプレチームとの連携 ○ リプレイス案件なので、既存のシステムに理解のあるメンバーも必要だった ○ オンプレチームから 2人が名乗りを上げたため、合計 4人の新しいチームが結成された

Slide 17

Slide 17 text

メンバー構成 ● リーダー ○ @sonots - 圧倒的リーダー ● メンバー ○ @inductor - Kubernetes利用歴が一番長いので教える人になった ○ @god(三神) - 神 ○ @kame(亀井) - 亀 @sonots @kame のセッションも是非ご覧ください →

Slide 18

Slide 18 text

メンバー構成 ● リーダー ○ @sonots - 圧倒的リーダー ● メンバー ○ @inductor - Kubernetes利用歴が一番長いので教える人になった ○ @god - 神 ○ @kame - 亀当時兼務で忙しかったリーダーを除き 1人のメンターと2人のメンティーでクラウド技術の第一歩を歩み始めた (オンボーディング開始)

Slide 19

Slide 19 text

アジェンダ ● 本セッションの動機 ● 今日のゴール ● メンティー視点 ← ○ 基本的な業務の進め方 ○ Cloud Nativeな開発を始めて意識するようになったこと ○ 振り返り ● メンター視点 ○ オンボーディングの基本 ○ チーム結成後の動き方と実践に向けたアプローチ ○ 実践でうまくいったこと、いかなかったこと

Slide 20

Slide 20 text

メンティー的業務の進め方

Slide 21

Slide 21 text

メンティー的業務の区分と進め方 ● リアクティブな動き方 (チームのために動く) ○ タスクをもらったときに指摘を受けたことや意識したこと ○ タスクへの取り組み方とすり合わせ ○ ゴールの設定と振り返り ● プロアクティブな動き方 (自己学習のために動く) ○ 完全ガイドを用いた輪読会 ○ 帰り道の反省会 ○ 社外勉強会への参加

Slide 22

Slide 22 text

チームを意識した動き

Slide 23

Slide 23 text

メンターからの指摘点や改善点 ● 思考のドキュメント化 ○ 1年後の自分が見ても理解できるような文章を心がける ○ 自分がいつ辞めてもいいように仕事をする ● タスクをもらった時に最初に議論する ○ 認識が合わないままタスクが進んでも誰も幸せにならない ○ 不明点は明らかに ● クロスレビューの徹底 ○ 事前にメンバー同士でレビューを繰り返すことでリーダーの仕事を少しでも減らす ○ 物事を多面的に見るためには他人の目が必要なことも多い

Slide 24

Slide 24 text

タスクへの取り組み方 ● レビューを最優先タスクにする（自身を他人のボトルネックにしない） ○ レビューは質問や議論の格好の場。分からないことを理解できるのは大切なこと ● 不明点はすぐ質問 ○ 期間が短いので詰まることすらもったいない。集合知は正義。議論を徹底的に！ ● 成果物ができたらすぐ共有 ○ 共有が早ければレビューも早くできるし、仕事も早く終わる ● ペアプロ推奨 ○ 手の動かし方を学び、できる人の思考を理解できる

Slide 25

Slide 25 text

ゴールの設定と振り返り ● タスクの最初にゴールのすり合わせを行う ○ 不明点を洗い出しておくことでタスクを迅速に進めることができる ● 大きなタスクをサブタスク化して細かくゴールを定義する ○ 調査・改善・設計・実装などフェーズによって目指すべきゴールも変わる ● 隔週のKPTで振り返り ○ 日常的に業務改善するための仕組みづくり

Slide 26

Slide 26 text

(参考)いつかのKPT(抜粋) ● KEEP ○ Gitを使えるようになってきた ○ 学習のINPUT/OUTPUTの時間を強制的に設定した ● PROBLEM ○ 単純な知識が足らないので指摘してもらった点を理解するのに時間がかかる ● TRY ○ 単純な知識が足らないので指摘してもらった点を理解するのに時間がかかる → ホワイトボードで話して写真とってドキュメントに貼っておいてもらえるとよさそう (そのっつ）

Slide 27

Slide 27 text

当時のホワイトボード

Slide 28

Slide 28 text

自己学習のための動き

Slide 29

Slide 29 text

完全ガイドを用いた輪読会 ● メンティー２人で毎週1章ずつKubernetes完全ガイドの輪読会を実施 ● お互いの資料について質問 ○ 担当しているタスクに関する質問 /議論

Slide 30

Slide 30 text

帰り道の反省会 ● その日メンターから受けた指摘点を帰り道で振り返る ○ 人の振り見て我が振り直せ ● 技術で自分が知らなかった点、誤認している点を共有 ○ 他人も同じポイントでハマりがち ● 明日への活力 ○ 大事

Slide 31

Slide 31 text

社外勉強会/技術ブログへの参加 ● 人と議論することが理解を深めるための最短経路 ○ 同じレベルの人と会話する機会を増やすことが大事 ● ブログ等の明文化は自分の思考整理にとても有効 ○ 自分の中で理解していない部分が見つかる ● 学んだことのアウトプットは必ず誰かの為になる ○ 「こんなこと、みんな知ってるはず」という思考は不要

Slide 32

Slide 32 text

Cloud Nativeな開発を始めて意識するようになったこと

Slide 33

Slide 33 text

中長期運用を意識した変化に強い構成管理 ● 気軽に更新/改修ができる環境を用意する ○ dev / stg / prd の3環境を用意し、インフラのコード化によって構成を統一 ● 更新/改修フローを自動化し構成管理に再現性をもたす ○ インフラのCI/CDを作り込むことで環境に直接触れる必要がなくなった

Slide 34

Slide 34 text

中長期運用を意識した変化に強い構成管理 ● dev / stg / prd の3環境を用意し、インフラのコード化によって構成を統一 dev stg prd

Slide 35

Slide 35 text

中長期運用を意識した変化に強い構成管理 dev stg prd git push ● dev / stg / prd の3環境を用意し、インフラのコード化によって構成を統一加えて、インフラのCI/CDを作り込むことで環境に直接触れる必要がなくなった

Slide 36

Slide 36 text

中長期運用を意識した変化に強い構成管理 dev stg prd git push ● インフラのCI/CDを作り込むことで環境に直接触れる必要がなくなった・運用を踏まえた設計のシンプルさ(Simplicity) ・改修、追加のコストを抑えるための簡単さ(Easiness) のどちらも両立した基盤設計ができた

Slide 37

Slide 37 text

基盤を『作る』よりも『使う』

Slide 38

Slide 38 text

基盤を『作る』よりも『使う』『サービスが動くものを作る』から『マネージドサービスをうまく使う』へ考えがシフト

Slide 39

Slide 39 text

基盤を『作る』よりも『使う』 ● 物理レイヤーを意識しなくなり、基盤自体の最適な使い方を考える余裕ができた ○ マネージドサービスの利用における比較検討や検証などが日常的にできるようになった ○ インフラだけでなく、アプリケーションの CI/CDも開発チームと一緒にメンテナンス ● 検討、検証のサイクルが短くなった

Slide 40

Slide 40 text

守備範囲や働き方の変化 ● 複数人での開発をGitで進めるのが当たり前に ○ ソフトウェア開発との境界線が曖昧になってきた ○ 一人ひとりの守備範囲を広くとることで、誰かが欠けても回せるチーム作り ● 他人のタスクをレビューするのが当たり前に ○ タスクを作るときにゴールを明確にするための議論ができているからこそできること ○ 隔週の振り返りや、質問の文化が活かされる場面 ● 実現(How)はコードに、思想はドキュメントに記載するのが当たり前に ○ コードには何をしたか、どうしたかがある ○ コメントには経緯などが書かれている ○ ドキュメントには、なぜ他のアプローチを取らなかったかが書かれている

Slide 41

Slide 41 text

Slide 42

Slide 42 text

秘匿データの扱い方、考え方の変化 ● 公開するサービスは既存環境と変わらない対策が求められる ● コード管理を始めたことでパスワードの平文記載文化を見直す ○ External Secretsを用いてAppの秘匿情報をGitのKubernetesマニフェストに載せずに管理する手法の導入 ● SSHによるアクセスを行わない方針(EKS, GKEどちらでも実現可能)

Slide 43

Slide 43 text

秘匿データの扱い方、考え方の変化パスワード等の秘匿情報をより厳密に管理 ● 公開するサービスは既存環境と変わらない対策が求められる ● コード管理を始めたことでパスワードの平文記載文化を見直す ○ External Secretsを用いてAppの秘匿情報をGitのKubernetesマニフェストに載せずに管理する手法の導入 ● SSHによるアクセスを行わない方針(EKS, GKEどちらでも実現可能) オンプレミスでは実現が難しいセキュリティ要件でもマネージドサービスを利用することで対応できるかも？

Slide 44

Slide 44 text

コストに対する考え方 ● 物理サーバを購入した場合はダイレクトに維持費が変動することは無い運用の効率化に成功しても物理的な維持費は変わらない

Slide 45

Slide 45 text

コストに対する考え方 ● クラウドは利用分だけ課金されるため、コスト感をより意識する俺の効率化で前月より安くなってる！

Slide 46

Slide 46 text

スケジュールに対する考え方 ● 物理サーバの購入に1~2ヶ月程度かかるので準備期間がある ● 物理的作業や構築作業の分担があって余裕をもったスケジュールになるサーバ屋綿密な計画やスケジュール調整が大事

Slide 47

Slide 47 text

● 構築準備が不要なので、設計から構築までのリードタイムが無い！辛い ● 個人のスキル次第でこなせるタスク量に差が生まれる待ち時間が無いサーバ屋スケジュールに対する考え方個人のスキル次第でタスクを進められる

Slide 48

Slide 48 text

ここまでのまとめ ● 短期間で多くのことを学ぶには「個人」と「チーム」どちらの動きも重要 ● クラウドとオンプレは一直線上にあるものではなく、別の概念 ○ かといって、太刀打ちできないわけではない

Slide 49

Slide 49 text

メンティーとしての振り返り

Slide 50

Slide 50 text

クラウドネイティブ入門の心構え ● あなたは今、『新しいこと』に挑戦しようとしてます ● 初めはみんな、学ぶところから始めています ○ いま『インフラエンジニア』でも、知らないことがあるのは当たり前 ● オンボーディングはその勇気を踏み出すための第一歩

Slide 51

Slide 51 text

クラウドネイティブ入門の心構え ● あなたは今、『新しいこと』に挑戦しようとしてます ● 初めはみんな、学ぶところから始めています ○ いま『インフラエンジニア』でも、分からない事があるのは当たり前 ● オンボーディングはその勇気を踏み出すための第一歩『新しいものに挑戦する』と意識するべき新しいものに挑戦するからには分からないことが多くて当然半年後に成果が出てれば大成功 (だと思う)

Slide 52

Slide 52 text

自走の仕方を学ぶ ● 魚をもらうのではなく「釣り方」を教わる意識 ● 他人の実践方法を「盗む」 ○ 周囲のエンジニアはもちろんだが、インターネット上には情報がたくさん転がっているので都合のいいものだけ「いただく」 ● アウトプットにより指摘をもらいに行く ○ 本来なら自分がもっと積極的にアウトプットすべきだが、不足を感じており今後の課題

Slide 53

Slide 53 text

メンターとの接し方 ● メンターがいる最大のメリットは議論ができること ○ 悩んでいる時は積極的に悩みのポイントを伝える (タスクの頭出しフェーズなど ) ○ 結論を出したい時は自分が考えうるベストを尽くして結論に関する 5W1Hを伝える ■ ドキュメント整備の習慣がさらに活きてくる ● 自身の考えを整理したうえで積極的に議論を重ねるべき ○ 結果的に間違っていたとしてもきちんと振り返ることが大切

Slide 54

Slide 54 text

学ぶ仲間が一緒にいてよかった ● 最も気軽に相談できるのは、同じレベルの仲間 ○ 相談しながら一緒に思考を整理できることが強み ○ 自分の至らなさに挫折しそうな時に支えになってくれる ● お互いに質問し合ったり、教え合ったりすることは理解への最短経路 ○ 自身とは違う視点で疑問を持てる相手がいると、学びが深くなる ○ 「間違ったことを教えてはいけない」という意識が物事を正しく理解する習慣につながる

Slide 55

Slide 55 text

ここまでで、だいたい 30分ちょいの想定(フラグ)

Slide 56

Slide 56 text

メンターが最後の追い上げをします

Slide 57

Slide 57 text

アジェンダ ● 本セッションの動機 ● 今日のゴール ● メンティー視点 ○ 基本的な業務の進め方 ○ Cloud Nativeな開発を始めて意識するようになったこと ○ 振り返り ● メンター視点 ← ○ オンボーディングの基本 ○ チーム結成後の動き方と実践に向けたアプローチ ○ 実践でうまくいったこと、いかなかったこと

Slide 58

Slide 58 text

メンター的オンボーディングの基本

Slide 59

Slide 59 text

オンボーディングにおける原則 ● レビューは最優先タスク ● 不明点はすぐ質問 ● 成果物ができたらすぐ共有 ● ペアプロ推奨 ● 思考のドキュメント化 ● タスクをもらった時に最初に議論する ● クロスレビューの徹底メンティー視点と基本は同じ

Slide 60

Slide 60 text

オンボーディングにおける原則 ● レビューは最優先タスク ● 不明点はすぐ質問 ● 成果物ができたらすぐ共有 ● ペアプロ推奨 ● 思考のドキュメント化 ● タスクをもらった時に最初に議論する ● クロスレビューの徹底メンティー視点と基本は同じ最も重要なポイント: 1. メンター自身が実践できていること 2. できたことを認識してもらうこと！「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ」 by 山本五十六といいつつ、sonotsさんの受け売りです＞＜

Slide 61

Slide 61 text

チーム結成後のアプローチ

Slide 62

Slide 62 text

メンター自身が実践できること ● 基本的に自分ができないことは無理に教えようとしない ○ 自分の間違った理解を相手に伝えることはチーム全体にマイナス ○ リーダーに頼るべきところは頼る。その代わり普段はできるだけ負担をかけずに動く ● アウトプットは自分が一番積極的に ○ 会社に紐付いたQiita(アドベントカレンダーとか )やテックブログへの貢献 ○ チームで使っている OSSへの貢献 ○ その他コミュニティでの会社としての登壇 ● ちょっとしたペアプロやDiscordでの雑談の機会を逃さない ○ 教わるメンティーにとって「こいつ常に暇なのでは？」と思わせるくらいの錯覚を与える ○ 見えないところでがんばる「お前が言うなよ」と言わせない実行力

Slide 63

Slide 63 text

できたことを認識してもらう ● ゴールのすり合わせ ○ 相手が見えない世界をいきなりは無理に見せない ● KPTや朝会などを定期的に行うことで定期的にタスクを共有 ○ メンターとか関係なく一人の人間として進捗にばらつきがあるのは当たり前 ○ みんながスーパーマンではない。相談しながら改善を続けるための仕組みを用意 ○ タスクのKPTをシェアすることで達成感を持ちつつ、チーム自体の距離を縮める ● 1on1の実施 ○ 日々の業務とは別に、リーダーの sonotsさんに1on1をやってもらうように依頼 ○ リーダーは話を誘導せず傾聴に徹し、メンバーが話したいことを話せる環境づくり

Slide 64

Slide 64 text

Slide 65

Slide 65 text

文化の継承と成果

Slide 66

Slide 66 text

文化の継承仕組みによって伝えられることは仕組みで伝えるべきだが、限界はある例: やらないことの範囲を決める、まず最初にゴールを明確にする etc.

Slide 67

Slide 67 text

文化の継承 ● クラウドの考え方やSREという文化を伝えるために ○ SREの考え方に則り、ソフトウェア開発の手法を積極的に取り入れる ■ CI/CDは触れて当たり前だし、無いと困るくらい体験の良いパイプラインを作る ■ OSSにIssueを立てる、PRを投げるのは当たり前 ● git pushするだけでKubernetes YAML/ Terraform/CFnのCI/CDが反映されるパイプライン ● アプリケーションのデリバリーも自分たちで作る ● 「なぜ他の方法をとらなかったか」がドキュメント化されている ● 外部の人にも情報を一般化して伝えられる

Slide 68

Slide 68 text

文化の継承 ● クラウドの考え方やSREという文化を伝えるために ○ まだ実現できてないタスクもある程度道筋を示した上で渡す(相談できる安心感を与える ) ■ 例1: AWSで機密情報どうやって管理しますか？ ■ 例2: SSHのポートを開けずにどうやってトラシューしますか？など ■ 結果: オンプレとクラウドの違いを意識しつつ設計から考える機会ができた ● 検証、設計などをドキュメント化し、 IaCで実装、構築、運用までを体系的に行ってもらう ● 答えが大体分かっているものをお願いする ● よくわからんやつは(最初は)全部巻き取る

Slide 69

Slide 69 text

文化の継承による成果 ● クラウドの考え方やSREという文化を伝えた成果 ○ 既存のオンプレでは仕組みとして作れていなかった無停止 & 全自動のデプロイを作り込むことによって、 SREとして担当できる範囲を増やせた ○ 開発チームとの日常的なコミュニケーションは当たり前にできるようになった

Slide 70

Slide 70 text

文化の継承による成果 ● クラウドの考え方やSREという文化を伝えた成果 ○ 既存のオンプレでは仕組みとして作れていなかった無停止 & 全自動のデプロイを作り込むことによって、 SREとして担当できる範囲を増やせた ○ 開発チームとの日常的なコミュニケーションは当たり前にできるようになった ● メンターのおかげではなく、ここまで自分たちがこなしたタスクや養った経験の成果であると認識してもらう ○ ドキュメントやKPTとして全て成果が残っている ○ 給料や職位も爆上がり！！！！

Slide 71

Slide 71 text

Slide 72

Slide 72 text

うまくいかなかったこと

Slide 73

Slide 73 text

うまくいかなかったこと ● (SREなのに)コードを書いてもらう時間が全然とれなかった ○ 日々の業務をこなしながらの 3ヶ月ではA tour of Goをちょっとやってもらうのが精一杯 ○ そもそも自分もプログラミングはそこまで得意じゃない ● リーダーのサポートが十分にできなかった ○ (当時の自分もだったが、自分以上に )複数のポジションを兼務していて、できるだけタスクを取りたかったが、思った以上の成果は出せなかった ● プロダクション運用はやれなかった ○ 設計構築までの段階で自分は離れてしまったので、運用までメンターはできなかった ○ オンボーディングだけする引き継ぎのおじさんになってしまったことは否めない

Slide 74

Slide 74 text

メンターとしての振り返り

Slide 75

Slide 75 text

振り返り「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ」

Slide 76

Slide 76 text

振り返り「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ」このスライドは、僕にとってのバイブルです参考: “「ZOZO MLOps のチームリーディングとSRE(Engineering)」というタイトルで SRE Next 2020 に登壇しました”

Slide 77

Slide 77 text

まとめ(Key takeaways) ● 今日からあなたもクラウドネイティブ！ ○ 新しいことを学ぶためには仕組みと取り組みが重要 ● 自主学習とオンボーディングの活用で、短期間でも実践できる学習法 ○ 日々の業務でも、リアクティブ、プロアクティブを意識して動く ● メンターとメンティーの関わり方について考えるきっかけにしてほしい ○ メンター、メンティー共に上下はなくただの役割 ○ 対等に議論できる仕組みと文化づくりが重要 ● 仲間を増やすことの大切さについて知ってほしい ○ 気軽に相談できる仕組みと文化づくりが重要

Slide 78

Slide 78 text

ありがとうございました