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