摆贵.翱.齿惭别别迟耻辫#2闭インフラ业务を开発エンジニアへ移譲して冲2年间の轨跡冲
?
0 likes?1,206 views
F.O.X Meetup #2 https://forceoperationx.connpass.com/event/79666/ ○ 概要 スタートアップのエンジニアは、少人数でなんでもこなせる必要があると思います。 ただ、実際はインフラを触れるのが特定の人だけ、ということはないでしょうか。。。 クラウド化によって運用はしやすくなったものの、全員が運用が出来る状態にすることは簡単なことではありません。 F.O.Xにはインフラ専任のエンジニアは居なくて、開発エンジニア全員がインフラ構築運用を担っています。 ただ、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](https://image.slidesharecdn.com/tittle-180330034333/85/F-O-XMeetup-2-_2-_-2-320.jpg)
![②育成カリキュラム
大項目(ライン)
仮想サーバと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で開発/運用する上で必要になるものを対象](https://image.slidesharecdn.com/tittle-180330034333/85/F-O-XMeetup-2-_2-_-17-320.jpg)
摆贵.翱.齿惭别别迟耻辫#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. agenda 移譲前 移譲中 移譲後 今 2016年 5月 2018年 1月~ 2016年 9月 2017年 3月 時系列で説明
- 4. agenda 移譲前 移譲中 移譲後 今 2016年 5月 2018年 1月~ 2016年 9月 2017年 3月 時系列で説明
- 9. 課題 ● インフラ業務未経験 ● スキル/知識不足 ● 既存システムと連携あり 開発チーム
- 13. 準备した3つのこと
- 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. ③現行システムを再設計した ○○共通基盤系の再設計 敷居を下げる(学習コスト低い / 利用しやすい / 管理しやすい) 構成管理基盤 ↓ VPN基盤 →
- 21. 構成管理(ansible) What? infractructure as code実践可能なツール 品質の向上 運用の標準化 再利用性/工数削減 DSLでインフラ 構築手順 運用オペレーション 自動化 (テンプレート化) ソフトウェア開発のプラク ティス適用 (開発エンジニアに馴染 みやすい)
- 22. 構成管理(ansible) Why? シンプル オープン/実績高 過去ナレッジ有 ● yml定義 ● 管理対象はSSH接続 ● OSS ● 様々企業で本番導入 ● オンプレ環境で本 番導入実績 学習コスト低 ググれば大量の 情報
- 23. 妥協した技術 コンテナ技術は妥協しました AWSはコンテナ技術が弱い(2016年) ● コンテナ本番運用でKubernetes必要性 / ECSのノード管理有 ○ Kubernetes on EC2の選択肢 -> インフラ高い管理スキルが必要 ○ 普段開発しつつ、開発エンジニアがインフラ業務を行うので負担大 ○ AWS EKS / Fargateのフルマネージドコンテナ環境(2018年)
- 24. agenda 移譲前 移譲中 移譲後 今 2016年 5月 2018年 1月~ 2016年 9月 2017年 3月 時系列で説明
- 25. 课题と解决
- 30. ③ 権限付与が目的になっ てしまった 課 題 期待してたのは、インフラ業務の積極性 / 明るくなってほしい / 自走出 来ること これらが欠けてきてしまった
- 31. その他サービス/構築 解 決 ● 自由な発想で問題解決案提示 ● マイクロシステム作成 ○ 見積もり(お金/性能/運用) , 設計 , 構築 ● 様々な視点から楽しさ的な事を伝える)最新技術を色々使ってみた り) ● 期間 1週間~
- 32. ③: 成果物 CloudWatchEvent + Lambdaで作る Dynamic DNS CloudFormation + Jmeterで 負荷環境CI
- 34. agenda 移譲前 移譲中 移譲後 今 2016年 5月 2018年 1月~ 2016年 9月 2017年 3月 時系列で説明
- 36. 课题と解决
- 39. ⑤ インフラの事前な運用管 理保守設計/実装が弱い 課 題 事後対応は自走、事前対応が弱い(様々なプロジェクトの運用経験) 事後対応? -> 何か障害が起きた(やらかした)時の再発防止策をやれるか等 事前対応? -> 何か障害が起きる(やらかす)前に事前に策を講じれるか等 事後対応 < 事前対応
- 42. agenda 移譲前 移譲中 移譲後 今 2016年 5月 2018年 1月~ 2016年 9月 2017年 3月 時系列で説明
- 44. ⑥ チーム内の達成進捗/ 基準がバラけた 課 題 チームの開発プロジェクトを紐付けが強くなったためチームの状態で進捗変化 インフラスキル(達成基準)がチーム別で高低 <-どちらかというとこちら
- 48. まとめ ● インフラ業務の分業制撤廃し、開発エンジニアへ移譲 完了 ○ スタートアップエンジニア体制へ ● 移譲するために時系列で育成計画、取組みを紹介 ○ 技術的なTipsも紹介 ● 発生した2年間の軌跡を课题と解决セットで紹介