Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Opsしかやってこなかった私が DevOpsが根付いたチームにJoinした話
Search
yhamano
June 21, 2022
Programming
2
1.3k
Opsしかやってこなかった私が DevOpsが根付いたチームにJoinした話
yhamano
June 21, 2022
Tweet
Share
More Decks by yhamano
See All by yhamano
MIXI での HCP Terraform 活用事例 / Use Case of HCP Terraform at MIXI
yhamano
2
470
Self-Service Implementation of AWS IAM Identity Center Permissions
yhamano
1
430
TIPSTAR におけるデータ分析基盤信頼性向上の取り組み
yhamano
1
1.6k
複数プロダクトを管理する AWS Organizations における AWS IAM Identity Center を GitHub x Terraform でいい感じに運用したい
yhamano
1
1.7k
CI/CD環境のTerraform versionを最新に保つと幸せになれる
yhamano
9
2.1k
IAMの地味なUpdateをご紹介_掲載用.pdf
yhamano
0
850
lightning-talk-toyosu_hamano_20190925_open.pdf
yhamano
0
870
Other Decks in Programming
See All in Programming
Goで作る、開発・CI環境
sin392
0
240
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
520
git worktree × Claude Code × MCP ~生成AI時代の並列開発フロー~
hisuzuya
1
580
Railsアプリケーションと パフォーマンスチューニング ー 秒間5万リクエストの モバイルオーダーシステムを支える事例 ー Rubyセミナー 大阪
falcon8823
5
1.1k
Flutterで備える!Accessibility Nutrition Labels完全ガイド
yuukiw00w
0
160
MDN Web Docs に日本語翻訳でコントリビュートしたくなる
ohmori_yusuke
1
130
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
830
プロダクト志向ってなんなんだろうね
righttouch
PRO
0
190
AIと”コードの評価関数”を共有する / Share the "code evaluation function" with AI
euglena1215
1
170
すべてのコンテキストを、 ユーザー価値に変える
applism118
3
1.3k
PipeCDのプラグイン化で目指すところ
warashi
1
280
Rails Frontend Evolution: It Was a Setup All Along
skryukov
0
160
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
How to Think Like a Performance Engineer
csswizardry
25
1.7k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
The World Runs on Bad Software
bkeepers
PRO
69
11k
Six Lessons from altMBA
skipperchong
28
3.9k
How to Ace a Technical Interview
jacobian
278
23k
A designer walks into a library…
pauljervisheath
207
24k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Transcript
Opsしかやってこなかった私が DevOpsが根付いたチームにJoinした話 Ops JAWS Meetup#21 2022年6月21日(火)
おしながき • DevOpsとは • DevOpsが根付いたチームにJoinした話 ◦ 苦労した所と対策 ◦ バリューを出すために意識したこと •
まとめ
DevOpsってなあに?
Dev(開発)とOps(運用)の分離/対立 • DevとOpsが別の組織として仕事をする(サイロ化) ◦ 相手領域の作業が必要な場合は依頼ベースで行う • 各組織での潜在的な責務が違うことによる対立 ◦ Devの責務:機能の追加/変更を行ってサービスの売上向上を 目指す
→ 変更を加えたい ◦ Opsの責務:システムを安定稼働させサービスの売上損失を避 ける → 変更を加えたくない
Dev(開発)とOps(運用)の分離/対立 • DevとOpsが別の組織として仕事をする(サイロ化) ◦ 相手領域の作業が必要な場合は依頼ベースで行う • 各組織での潜在的な責務が違うことによる対立 ◦ Devの責務:機能の追加/変更を行ってサービスの売上向上を 目指す
→ 変更を加えたい ◦ Opsの責務:システムを安定稼働させサービスの売上損失を避 ける → 変更を加えたくない 顧客への貢献&ビジネス成功という目的は同じ
DevOps “DevOpsでは、従来型のソフトウェア開発と、インフラストラクチャ管理プロセスを 使用するよりも速いペースで製品の進歩と向上を達成し、企業がアプリケーショ ンやサービスを高速で配信できるように、 文化的な基本方針、プラクティス、ツールが組み合わされています。” https://aws.amazon.com/jp/devops/what-is-devops/
文化的な基本方針 • アプリケーションデリバリにおけるチーム間のインタラクション をスムーズにする ◦ DevとOpsがひとつのチームで仕事をする ◦ 別チームに対して機能(API,モジュール等)を提供する • 他チームのサポートを必要とせず、チームメンバのみ
でアプリケーションのデプロイ、インフラストラクチャのプロビ ジョニングを可能にする • 手動で時間がかかっていた運用をソフトウェアで自動化する
プラクティス/ツール プラクティス ツール 継続的インテグレーション/デリバリー (CI/CD) CodePipeline, CodeBuild, CodeDeploy マイクロサービス ECS,
EKS, Lambda Infrastructure as Code CloudFormation, CDK モニタリングとロギング(Observability) CloudWatch, X-Ray コミュニケーションと共同作業 チャットアプリケーション, 課題管理, wiki
DevOpsの実現には3要素全てを 取り入れることが重要💪
Four Keys • DevOpsの成果と成熟度を測る4つの指標 ◦ デプロイの頻度 ▪ 組織による正常な本番環境へのリリースの頻度 ◦ 変更のリードタイム
▪ commit から本番環境稼働までの所要時間 ◦ 変更障害率 ▪ デプロイが原因で本番環境で障害が発生する割合 ◦ サービス復元時間 ▪ 組織が本番環境での障害から回復するのにかかる時間 https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
DevOpsなチームにJoinした話
Opsだけやってた頃 • インフラ(クラウド)エンジニア@SIer • DevとOpsがくっきり分かれていた ◦ DevがAWSマネジメントコンソールさえも見れない現場も、、 • Excel,PowerPointを駆使して各種定義書/設計書/手順書をた くさん書いていた
• 運用設計書/手順書は作成するが実運用者は別の人
Opsだけやってた頃 • インフラ(クラウド)エンジニア@SIer • DevとOpsがくっきり分かれていた ◦ DevがAWSマネジメントコンソールさえも見れない現場も、、 • Excel,PowerPointを駆使して各種定義書/設計書/手順書をた くさん書いていた
• 運用設計書/手順書は作成するが実運用者は別の人 なんやかんや(転職) あって環境が ガラッと変わることに
DevOpsなチームにJoin • とあるプロダクトのバックエンドチーム(約10名)にJoin • DevOpsの文化的な基本方針、プラクティス、ツールが 全て取り入れられているチームだった ◦ チームメンバのみで機能開発/インフラのプロビジョニング/ 運用(オンコール含む)を対応する ◦
CI/CDで自動化されたテスト/デプロイ ◦ kubernetes等で動作するマイクロサービス ◦ OpenAPI,gRPC等を用いたスキーマ駆動でのコミュニケーション
DevOpsなチームにJoin • とあるプロダクトのバックエンドチーム(約10名)にJoin • DevOpsの文化的な基本方針、プラクティス、ツールが 全て取り入れられているチームだった ◦ 1チーム内で機能開発/インフラのプロビジョニング/ 運用(オンコール含む)を対応する ◦
CI/CDで自動化されたテスト/デプロイ ◦ kubernetes等で動作するマイクロサービス ◦ OpenAPI,gRPC等を用いたスキーマ駆動でのコミュニケーション 何も分からん
まずはやれる所からやっていく • 辛うじて事前知識があるOps周りのタスクからやっていった ◦ インフラのプロビジョニング ◦ Toil削減 ▪ ex)CI/CD環境のTerraform versionを最新に保つと幸せになれる
◦ コスト最適化 ▪ ex)開発環境へのスポットインスタンス導入 ◦ セキュリティ ▪ ex)kubernetesのDockershim非推奨によるcontainerdへの移行
苦労した所 • コードリーディング/ライティング😇 ◦ Opsメインでもエンジニアであればコードの読み書きは必須 ▪ 手作業の運用を自動化する運用ツールの作成/メンテナンス ▪ アプリケーション起因のオンコール対応 •
各APIやバッチの概要把握 ◦ スキーマやドキュメントを読んではいたが、各々数が多いこともあり 全容をなかなか把握できなかった
実施した対策 • アプリケーション機能開発タスクもやっていく ◦ コードを読み書きする機会が圧倒的に増える ◦ 他メンバが実装したコードもレビュできるようになり 各種機能の仕様理解が進む • 負荷試験を担当する
◦ テストシナリオの作成/パフォーマンスチューニングを通して各種 機能の仕様理解が進む ◦ パフォーマンスチューニングに関するノウハウの学習はISUCON 本をおすすめしたい
バリューを出すために意識したこと • 守備範囲を広げて顧客への安定かつ迅速な価値提供に貢献す る ◦ 自分の強みを持ちつつも他の領域も見れるようにすることで DevとOps両面から俯瞰してシステムを見ることが可能 ◦ 強みの深堀も重要 ◦
認知負荷が上がるためバランスは大事
バリューを出すために意識したこと • 守備範囲を広げて顧客への安定かつ迅速な価値提供に貢献す る ◦ 自分の強みを持ちつつも他の領域も見れるようにすることで DevとOps両面から俯瞰してシステムを見ることが可能 ◦ 強みの深堀も重要 ◦
認知負荷が上がるためバランスは大事 チーム/プロダクトの状況や規模によって バリューの出し方は変わってくる
バリューを出すために意識したこと • 守備範囲を広げて顧客への安定かつ迅速な価値提供に貢献す る ◦ 自分の強みを持ちつつも他の領域も見れるようにすることで DevとOps両面から俯瞰してシステムを見ることが可能 ◦ 強みの深堀も重要 ◦
認知負荷が上がるためバランスは大事 チーム/プロダクトの状況や規模によって バリューの出し方は変わってくる チームとしてDevOpsを 加速させるためにはどうすれば良いか?
チームとしてのDevOps加速 • Four Keysの継続的な計測と改善 • チーム/プロダクトの規模が拡大してもデプロイ頻度や品質を高 く保つための仕組み作り ◦ ex)ガードレール的チェック機構の導入 ◦
ex)デファクトスタンダードが盛り込まれたテンプレートや モジュールの用意
まとめ • DevOpsには文化的な基本方針、プラクティス、ツールの 3要素が重要 • 未知の分野が多くある場合でもやれる所からバリューを出して いって徐々に守備範囲を広げていくことで大きなバリューを出し ていくこともできる • チーム全体のDevOpsを加速させる場合は個人にフォーカスし
た活動だけでなく、チームとして何が足りていないか、問題があ るのかを計測/判断し改善していく必要がある
Thank you.