Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[F.O.XMeetup#2]インフラ業務を開発エンジニアへ移譲して_2年間の軌跡_

533 views

Published on

F.O.X Meetup #2
https://forceoperationx.connpass.com/event/79666/

○ 概要
スタートアップのエンジニアは、少人数でなんでもこなせる必要があると思います。
ただ、実際はインフラを触れるのが特定の人だけ、ということはないでしょうか。。。
クラウド化によって運用はしやすくなったものの、全員が運用が出来る状態にすることは簡単なことではありません。

F.O.Xにはインフラ専任のエンジニアは居なくて、開発エンジニア全員がインフラ構築運用を担っています。
ただ、2年前までは完全に分業制でした。
元々インフラエンジニアの自分が、組織をこの状態に持っていくために行った、全エンジニアの育成計画についてお話します。

Published in: Technology
  • Be the first to comment

  • Be the first to like this

[F.O.XMeetup#2]インフラ業務を開発エンジニアへ移譲して_2年間の軌跡_

  1. 1. インフラ業務を開発エンジニアへ 移譲して ~2年間の軌跡~ 茂木 高宏 (@tkmoteki) F.O.X meetup #2
  2. 2. 自己紹介 CyberZ F.O.X エンジニア 茂木 高宏(もてき たかひろ) 得意技術: ビッグデータ, AWS, ops系, サーバHW, kernel... twitter: @tkmoteki / facebook: takahiro.moteki.31 [登壇]FaaSで簡単に実現する数十万RPS 負荷試験 https://goo.gl/ffYVbt [登壇]Infrastructure as Codeを活用した F.O.Xのクラウドビッグデータ環境の変化 https://goo.gl/5HTPzY
  3. 3. agenda 移譲前 移譲中 移譲後 今 2016年 5月 2018年 1月~ 2016年 9月 2017年 3月 時系列で説明
  4. 4. agenda 移譲前 移譲中 移譲後 今 2016年 5月 2018年 1月~ 2016年 9月 2017年 3月 時系列で説明
  5. 5. 背景 7割 3割 10割 完全 クラウド化 マイクロサー ビス化 オンプレ モノリシック フル フルスタックエ ンジニア
  6. 6. 状況分析 開発チーム(局) インフラチーム(局) アプリA アプリB 依頼(分業) 権限ない
  7. 7. 状況分析 開発チーム(局) インフラチーム(局) アプリA アプリB 開発開発スピード 低下 開発障害対応ロス 開発 インフラ意識し た設計 開発エンジニア不 足 開発障害対応ロス 開発 開発意識した 設計 依頼(分業) 権限ない
  8. 8. インフラ業務を開発エンジニアへ移 譲しよう
  9. 9. 課題 ● インフラ業務未経験 ● スキル/知識不足 ● 既存システムと連携あり 開発チーム
  10. 10. 社内プロジェクト始動: インフラ技術向上(育成)PJ 対象: 事業部内のエンジニア(全員)
  11. 11. 目的 インフラ業務に対して、  インフラエンジニアのノウハウ、   スキルを養い、    インフラ技術力を向上 開発チーム インフラチーム アプリA
  12. 12. 期待する開発エンジニア像 開発エンジニア インフラ業務に積極的に取組み自走できる状態 インフラ動向を追いキャッチアップしていける 経験/実績をつくりエンジニアの市場価値を高めて いってほしい
  13. 13. 準備した3つのこと
  14. 14. ①育成運営チームを用意した 育成担当者 (僕) (MGR) 第三者のレビュアー (インフラエンジニア)
  15. 15. ②育成カリキュラムを組んだ 現場ではデータセンターのクラウド移行をしていた↓ 実際にインフラ業務をTry インフラ実業務に勝る育成方法はない と思った
  16. 16. ②育成カリキュラムを組んだ 個人目標設計 ハンズオン/ レクチャー グループワーク やらせる 伝える/ 見せる 教える 立会 非同期学習& レビュー
  17. 17. ②育成カリキュラム 大項目(ライン) 仮想サーバとDNS/ネットワークの知識 EC2/route53/VPC LB,負荷分散の知識 ELB/ALB DBAの知識 RDS for Mysql/RDS for Aurora 認証/認可の知識 IAM OS/ミドルウェア Linux/基本ミドルウェア ストレージ S3/EBS [基盤]構成管理/自動化 Cloudformation/ansible [基盤]モニタリング/監視 CloudWatch/zabbix [基盤]ログ収集/加工/活用/管理 fluentd/ElasticSearch(AES)/kibana [基盤]障害対応/リカバリ AWSで開発/運用する上で必要になるものを対象
  18. 18. ③現行システムを再設計した ○○共通基盤系の再設計 敷居を下げる(学習コスト低い / 利用しやすい / 管理しやすい) 構成管理基盤 ↓ VPN基盤 →
  19. 19. 構成管理の再設計 プラットフォームレイヤ (クラウド / オンプレ) 構成管理 サーバレイヤ構成管理 オーケストレーション 再設計前再設計後 CloudFormation kickstart CloudFormation Cloudera Director
  20. 20. 構成管理の再設計/選定 プラットフォームレイヤ (クラウド / オンプレ) 構成管理 サーバレイヤ構成管理 オーケストレーション 再設計前再設計後 CloudFormation kickstart CloudFormation Cloudera Director
  21. 21. 構成管理(ansible) What? infractructure as code実践可能なツール 品質の向上 運用の標準化 再利用性/工数削減 DSLでインフラ 構築手順 運用オペレーション 自動化 (テンプレート化) ソフトウェア開発のプラク ティス適用 (開発エンジニアに馴染 みやすい)
  22. 22. 構成管理(ansible) Why? シンプル オープン/実績高 過去ナレッジ有 ● yml定義 ● 管理対象はSSH接続 ● OSS ● 様々企業で本番導入 ● オンプレ環境で本 番導入実績 学習コスト低 ググれば大量の 情報
  23. 23. 妥協した技術 コンテナ技術は妥協しました AWSはコンテナ技術が弱い(2016年) ● コンテナ本番運用でKubernetes必要性 / ECSのノード管理有 ○ Kubernetes on EC2の選択肢 -> インフラ高い管理スキルが必要 ○ 普段開発しつつ、開発エンジニアがインフラ業務を行うので負担大 ○ AWS EKS / Fargateのフルマネージドコンテナ環境(2018年)
  24. 24. agenda 移譲前 移譲中 移譲後 今 2016年 5月 2018年 1月~ 2016年 9月 2017年 3月 時系列で説明
  25. 25. 課題と解決
  26. 26. ① 言われた通りの事しかや れない 課 題 インフラオペレーション方法を見せる 写経しか出来ないインフラオペレーション(応用が効かない)
  27. 27. 逆ハンズオン 解 決 実際に様々なインフラ業務(お題)を出し開発エンジニアがデモストレー ション インフラエンジニアにその意図含めた説明をしてもらう
  28. 28. ② 何がインフラのスキル なのか? 課 題 スキル向上って具体的に何ができたらスキル向上なのか?
  29. 29. 希望者のみ基準表つくり個 人レベルで起票 解 決 Aさん(※ イメージ) Bさん(※ イメージ)
  30. 30. ③ 権限付与が目的になっ てしまった 課 題 期待してたのは、インフラ業務の積極性 / 明るくなってほしい / 自走出 来ること これらが欠けてきてしまった
  31. 31. その他サービス/構築 解 決 ● 自由な発想で問題解決案提示 ● マイクロシステム作成 ○ 見積もり(お金/性能/運用) , 設計 , 構築 ● 様々な視点から楽しさ的な事を伝える)最新技術を色々使ってみた り) ● 期間 1週間~
  32. 32. ③: 成果物 CloudWatchEvent + Lambdaで作る Dynamic DNS CloudFormation + Jmeterで 負荷環境CI
  33. 33. 事業内に数人がインフラ業務をトー タルで可能な状態
  34. 34. agenda 移譲前 移譲中 移譲後 今 2016年 5月 2018年 1月~ 2016年 9月 2017年 3月 時系列で説明
  35. 35. 移譲後: 方針 より理解を深めるため達成した人(開発エンジニア)へ”教 える事”を移譲 やらせる 伝える/ 見せる 教える
  36. 36. 課題と解決
  37. 37. ④ 開発プロジェクトに属人化 した(開発全体課題) 課 題 新しい技術のナレッジが 開発プロジェクトを横断して活かせない状態
  38. 38. チーム体制へのシフト 解 決 チームに開発プロジェクトが紐づくように
  39. 39. ⑤ インフラの事前な運用管 理保守設計/実装が弱い 課 題 事後対応は自走、事前対応が弱い(様々なプロジェクトの運用経験) 事後対応? -> 何か障害が起きた(やらかした)時の再発防止策をやれるか等 事前対応? -> 何か障害が起きる(やらかす)前に事前に策を講じれるか等 事後対応 < 事前対応
  40. 40. SREチーム 解 決 ● 事前な運用管理保守設計のフォローアップ ● ○○共通基盤のグロース
  41. 41. 3人チーム内に2人はインフラ業務 をトータルで可能な状態
  42. 42. agenda 移譲前 移譲中 移譲後 今 2016年 5月 2018年 1月~ 2016年 9月 2017年 3月 時系列で説明
  43. 43. 今: 方針 チーム内でレクチャーし合う文化へ https://goo.gl/SMCNpm
  44. 44. ⑥ チーム内の達成進捗/ 基準がバラけた 課 題 チームの開発プロジェクトを紐付けが強くなったためチームの状態で進捗変化 インフラスキル(達成基準)がチーム別で高低 <-どちらかというとこちら
  45. 45. Eラーニング検討中 (最終確認) (解 決) 今の課題なので検討段階...
  46. 46. ⑦ チーム横断するナレッジ共 有が弱い 課 題 新しい技術のナレッジがチームを横断して活かしきれてない状態
  47. 47. 試行錯誤中... (解 決) 今の課題なので検討段階...
  48. 48. まとめ ● インフラ業務の分業制撤廃し、開発エンジニアへ移譲 完了 ○ スタートアップエンジニア体制へ ● 移譲するために時系列で育成計画、取組みを紹介 ○ 技術的なTipsも紹介 ● 発生した2年間の軌跡を課題と解決セットで紹介

×