Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

[社内合同勉強会]インフラ業務を開発エンジニアへ移譲して 移譲前-移譲後-そして今-

3.546 Aufrufe

Veröffentlicht am

[社内合同勉強会]@20170222

Veröffentlicht in: Ingenieurwesen
  • Awesome lonely girl looking for fun on webcam with the you now - www.xslideshare.usa.cc
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

[社内合同勉強会]インフラ業務を開発エンジニアへ移譲して 移譲前-移譲後-そして今-

  1. 1. インフラ業務を開発エンジニアへ移譲して ~業務移譲前-業務移譲後-そして今~
  2. 2. 自己紹介 株式会社 CyberZ F.O.X事業 ビッグデータ、イ ンフラ全般、SRE(現場のエン ジニア) twitter: @tkmoteki facebook: takahiro.moteki.31 もてき たかひろ
  3. 3. agenda 移譲前 移譲中 移譲後 今 2016年5月 2017年2月 2016年6月 2016年9月 2016年10月 2016年12月 時系列で説明
  4. 4. 業務移譲前(背景) ~2016年5月~ ● アドテク事業部は完全なパブリッククラウド ネイティブな会社方 針 ● マイクロサービス、マイクロアーキテクチャが浸透 パブリッククラウド 例えば の流 れだと だけでなく、 が多 く開発側にも業務委譲した方が良い インフラエンジニア不足
  5. 5. 業務移譲前(状況分析) ~2016年5月~ 開発側は、 AWSインフラ構築/インフラオペレーションは“権限”がない、出来ない 業務レベルのインフラ権限を解放していない 例) • EC2作成/構築 • ELBのオペレーション • Lambdaの作成/構築 • ansibleでOS/ミドルウェア自動化 随時インフラ局へ依頼 開発スピードが出ない インフラ運用を意識した 設計が出来ない インフラがクローズド , 開発エンジニアとインフラエン ジニアの連携問題 障害対応にロス (開発エンジニアと インフラエンジニアが必要 )
  6. 6. 開発エンジニアへ インフラ業務を移譲しようか MGR
  7. 7. MGR僕 なるほど、 インフラ強い人とかで数 絞ってやりますか んあ、開発局のエンジニア全員 え? 育成コスト、運用コスト を考えると全員は現実的で はないですね、、、 んあ、無理。 理由はみんな出来るようになっ て欲しいから んあ、じゃあ後よろしく (トコトコ) え?(理由じゃない...)
  8. 8. 壁(現場分析) ~2016年5月~ 開発エンジニアはインフラ業務実績/経験がない(今 までインフラエンジニアがやっていたため) 世間一般的な中途インフラエンジニア並のスキル 知 識がない 既存のオンプレ のインフラ環境があり相互連携も発生する… 新規プロジェクトではないものが大半 それをいきなり開発エンジニアによろしく は…無茶だ
  9. 9. 社内プロジェクト始動: インフラ技術向上PJ
  10. 10. 目的 「実績ないインフラ実業務に対して、  インフラエンジニアの専門的なノウハウ、   スキルを養い、    インフラ技術力を向上すること」
  11. 11. 方針 期待したエンジニア像 ~2016年6月~ ○ 開発エンジニアがインフラ業務に明るくなりインフラ業務を積 極的にやって欲しい □ 肌感イメージ □ インフラ業務も行う 開発エンジニア □ わからない事 不安なこと 旧インフラエンジニアに相談する ○ 自主的にインフラ技術の最新動向を追い、キャッチアップし ていける ○ インフラ業務経験 実績をつくり、エンジニアとしての市場価 値を高めていってほしい
  12. 12. agenda 移譲前 移譲中 移譲後 今 2016年5月 2017年2月 2016年6月 2016年9月 2016年10月 2016年12月 時系列で説明 2016年7月
  13. 13. 準備したこと ~2016年6月~ ○ インフラ技術向上PJ運営チームを用意した ○ インフラの体制再考した ○ 育成カリキュラムを組んだ ○ 現状のインフラ環境/システムを再設計した
  14. 14. インフラ技術向上PJ運営チームを 用意した 育成 (僕 元インフラエンジニア) 報告者 (MGR) 第三者のレビュアー (インフラエンジニア) 僕は育成のプロではないです、現場で叩き上げでやってきた現場の一エンジニアで す
  15. 15. インフラ体制再考した ~2016年6月~ ~詳細説明は省略~ 関係組織モデル再考 業務役割モデル再考
  16. 16. インフラ体制再考した ~2016年6月~ ~詳細説明は省略~ 認証・認可構成 権限設計
  17. 17. 育成カリキュラムを組んだ(進め方)1. ~2016年6月~ ~インフラエンジニア(僕)が開発エンジニアへ実施~ ○ 個人レベルで目標すり合わせ、ヒアリング、スケジュール相談 ○ 非同期学習&レビュー -> 一般的な仕様やサービス知識 □ 読み物,構築など ○ ハンズオン -> 僕と2人で個別でハンズオン □ オペレーションなど ○ グループワーク -> グループ単位でハンズオン ○ ワークショップ -> 体制から文化、インフラの仕事的なところ
  18. 18. 育成カリキュラムを組んだ(進め方)2. ~2016年6月~ ちょうどオンプレミスからクラウド環境へ全面移行。 この移行しながら、移行先のインフラ環境やれるところでハンズオンを実施 ● 実現場のインフラ業務に勝る育成方法はないと思った ● 自身の開発したサービスが動かなくなるため、取り組む ”必要性”が出てくる 開発エンジニアは開発業務と調整つけ並行してやっていくので、長いプロジェクトになりそうだなぁ ...
  19. 19. 育成カリキュラムを組んだ(内容) ~2016年6月~ フェーズ 大項目 ライン 仮想サーバと の知識 ネットワークの知識 負荷分散の知識 の知識 認証・認可の知識 基盤 構成管理 統合自動化基盤 ミドルウェア 基盤 モニタリング、監視 基盤 インフラのログ収集 加工 活用 管理 必須ワークショップ フェーズ1 : AWS関連, フェーズ2 : AWS以外 社内基盤関連, ワークショップ : スタートアップ(インフラの業務についてなど )
  20. 20. 現状のインフラ環境/システムを再設計した ~2016年6月~ 開発プロダクト B(組織B) 開発プロダクト A(組織A) 開発プロダクト C(組織C) ○ AWSアカウント ○ 各種基盤 □ 自動化系、監視系など インフラエンジニアで構築 /運用してきた もの全てが、プロダクト (組織)で相乗り で使用 開発プロダクトA(組織A)の開発エンジ ニアが安全にインフラ業務を行えるよう に再設計 僕 インフラ業務を行う開 発エンジニア
  21. 21. “開発エンジニアへ周知/展開。 インフラ技術向上PJ フェーズ1(AWS)スタート
  22. 22. agenda 移譲前 移譲中 移譲後 今 2016年5月 2017年2月 2016年6月 2016年9月 2016年10月 2016年12月 時系列で説明 2016年7月
  23. 23. インフラ技術向上PJ 問題点 ~2016年7月~ 誰もやってくれなかった。。。
  24. 24. インフラ技術向上PJ 原因/対策 ~2016年7月~ ○ 原因 : 誰もやってくれないではなくて、育成側の時 間が抑えられない(いつでもいいよ、で案内してい た) ○ 対策 -> インフラ技術向上PJ専用日を作り、枠を設 けた
  25. 25. agenda 移譲前 移譲中 移譲後 今 2016年5月 2017年2月 2016年6月 2016年9月 2016年10月 2016年12月 時系列で説明 2016年7月
  26. 26. インフラ技術向上PJ ~2016年9月~ 大量の問題点、、、
  27. 27. インフラ技術向上PJ問題点 ~2016年9月~ ○ 言われた通りの事しかやれない、伝えた事しか答えられない ○ 具体的に何を理解すれば良いのか、項目含め基準が知りたい ○ 権限を付与するのが目的になってしまった
  28. 28. インフラ技術向上PJ 対策 ~2016年9月~ ○ 言われた通りの事しかやれない、答えられない ○ 対策 -> 逆ハンズオン 逆ハンズオン ・・・実際にインフラ業務(お題)を出す。開発エンジニアがデモンストレーション (実作業)しながらへインフラの説明してもらう(質疑応答) ~インフラエンジニア(僕)と第三者インフラエンジニアへ説明~
  29. 29. インフラ技術向上PJ 対策 ~2016年9月~ ○ 具体的に何を理解すれば良いのか、項目含め基準が知りたい ○ 対策 -> 希望があった人のみ基準表をつくり、個人レベルで起票 した Aさん Bさん
  30. 30. インフラ技術向上PJ 対策 ~2016年9月~ ○ 権限を付与するのが目的になってしまい、インフラ の理解力が低下した ○ 対策 -> ライン:その他サービス構築新設 既存運用しているインフラ環境の問題点を見つけて、自由な発想で考え、改善案を提示。 本番環境で運用できるシステムを作る (やってみた!はNG)。 インフラの業務システムを見積もりから、アーキ設計、構築までインフラフルスタックで行うもの。 成果物例) ● 「CloudWatch Events + Lambda」で構築するDynamic DNS ● 「CloudFormationを用いた負荷環境のインフラ動的生成と破棄、 immutable infrastructureの実践」
  31. 31. agenda 移譲前 移譲中 移譲後 今 2016年5月 2017年2月 2016年6月 2016年9月 2016年10月 2016年12月 時系列で説明 2016年7月
  32. 32. インフラ技術向上PJ ~2016年10月~ フェーズ2(AWS以外の社内基盤)がスタート
  33. 33. インフラ技術向上PJ 問題点 ~2016年10月~ フェーズ2取り組めない、、
  34. 34. インフラ技術向上PJ 対策 ~2016年10月~ ○ 原因 : 敷居が高い、作業時間がかかる ○ 対策 : 既存基盤を効率使える仕組みを用意し敷 居を下げた □ ワークフローを定義 □ スケルトンモデル(sample)を用意 (ワークフロー追加定義するくらいだったら、ワークフローを定義せざるをえなくなった、 基盤自体を根幹から見直す必要あったが、時間もなくバンソウコウ対応 )
  35. 35. agenda 移譲前 移譲中 移譲後 今 2016年5月 2017年2月 2016年6月 2016年9月 2016年10月 2016年12月 時系列で説明 2016年7月
  36. 36. インフラ技術向上PJ ~2016年12月~ フェーズ2(AWS以外の社内基盤)終了 フェーズ1のみ達成 半分/開発局エンジニア全員 フェーズ1 + 2達成 2割/開発局エンジニア全員 達成した人から順次業務移譲。茂木はファシリテータへ
  37. 37. agenda 移譲前 移譲中 移譲後 今 2016年5月 2017年2月 2016年6月 2016年9月 2016年10月 2016年12月 時系列で説明 2016年7月
  38. 38. インフラ技術向上PJ 今 より理解を深めるため達成した人(開発エン ジニア)へ”教える事”を移譲した やらせる 伝える/ 見せる 教える 達成したエンジニアがそれぞれメンターになって、達成していない人へレクチャー 教えてみることで、さらに理解を深める
  39. 39. インフラ技術向上PJ 今の問題点 ~2017年2月~ ○ チーム(プロジェクト)属人化問題 □ 現状プロダクトの中に開発チームが複数あり、新しい仕組みを入れてもプロジェクト横断した横 転ができない □ 以前はインフラエンジニアが複数の開発チームを見ていたためチーム (プロジェクト)属人化問 題は目立たなかった ○ インフラの運用管理保守の事前設計/実装が弱い □ 見積もり、構成、キャパシティ、様々な要素を見越して、考慮して行うインフラの運用管理保守 □ “何か事故”ってから対策を立てるのではなく、リリース前に事前に対策 /実装を行う □ 事故る前に事前策/実装が出来る -> プロ □ 事故った後で事後対策 /実装をする -> 素人 □ 簡単な例) S3は99.999999999%の高可用性でデータ入れればとりあえず安心 -> いや、オペミス したらデータ消える □ エンタープライズ領域のエコシステムや基幹システムほど超重要
  40. 40. インフラ技術向上PJ 今の問題点 ~2017年2月~ ○ ホウ・レン・ソウの認識違い □ 開発エンジニアとインフラエンジニアとではホウ・レン・ソウに違いがある □ そもそも育成側としても未考慮 □ 業務移譲する(任せる) = ホウ・レン・ソウしなくていいよ、は間違い。 ○ 複数インフラが絡むシステム、通信、データの関係性理解 低下 □ そもそも育成側としても未考慮 ○ インフラの小さなミスが全体として目立ち品質低下 □ 単純にインフラ業務を行う人が増えて目立った □ そもそも環境がレガシーだから
  41. 41. 最後に、、、 運営側として心がけたこと(学んだこと含) 時間がないのでエピソードは省略
  42. 42. 運営側として心がけたこと(学んだこと含) ○ 相手側への歩み寄り ○ 素直な技術コミュニケーション ○ 即日/翌日FBK ○ 当たり前の事を当たり前に行う事
  43. 43. 相手側への歩み寄り ● 個人 個人と向き合って、議論して、伝え方/やり方を変える事 ● 受ける側の”悩み”は一緒に解消する ● 受ける側が受け入れられないカリキュラム(やり方)はクソ ● 何も知らない事に対して、受ける側が理想すぎるものは、たいてい受ける側 のためにならない ● そのために、その分解点を個人個人で議論する ● 面倒くさがってたら、始まらない
  44. 44. 素直な技術コミュニケーション ● 納得させるんじゃなくて、お互い納得し合う事 ● 無理に納得させようとしても拒絶する ● 建設的に議論する ● なんとも言えない、微妙だったりする事を無理やり正論づけない ● エンジニアとしてウソは厳禁だが上記にも配慮しよう ● 結果エンジニアとして”信頼されない”から ● 「なんとも言えないです、調べます」って言えばいいと思う ● 知らない、わからないは、はっきり言う ● 知らないことを知らないと言える人ほど、知ってる事を教えてもらう場合に 信頼を得やすい (仕事で僕が一番意識していることでもあります)
  45. 45. 即日/翌日FBK ● 新しく学ぶ内容ほど、期間が開くと学びずらい(覚えにくい) ○ コンテキストスイッチを最小化させる ● FBKやレビューを放置すると、受ける相手に育成側は信頼されない ● githubレビュー、口頭、chat同様
  46. 46. 当たり前の事を当たり前に行う事 ● 今回の育成は工数の都合上長期プロジェクト ● 当たり前の事を当たり前に行うって案外難しい ● 長期プロジェクトになればなるほど、当たり前の事を当たり前に行えなくな る ● 例) 育成側としてのホウ・レン・ソウ ● どんなに技術やスキルや経験があっても、ホウ・レン・ソウ出来ないと仕事 として信頼されない。頑張ってたって仕事で信頼されない
  47. 47. 今後 ○ “今”の課題に向き合っていく ○ 業務移譲後の効率性を数値化して振り返り □ 実績調査やアンケートなど
  48. 48. インフラ技術向上PJ プロジェクトとしては終了 新しい体制でスタートをきって運用中 今後も”今”の課題に向き合っていく

×