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
880
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
110
Self-Service Implementation of AWS IAM Identity Center Permissions
yhamano
1
99
TIPSTAR におけるデータ分析基盤信頼性向上の取り組み
yhamano
1
1.1k
複数プロダクトを管理する AWS Organizations における AWS IAM Identity Center を GitHub x Terraform でいい感じに運用したい
yhamano
1
1.2k
CI/CD環境のTerraform versionを最新に保つと幸せになれる
yhamano
9
2.1k
IAMの地味なUpdateをご紹介_掲載用.pdf
yhamano
0
850
lightning-talk-toyosu_hamano_20190925_open.pdf
yhamano
0
860
Other Decks in Programming
See All in Programming
PHP ステートレス VS ステートフル 状態管理と並行性 / php-stateless-stateful
ytake
0
110
『GO』アプリ データ基盤のログ収集システムコスト削減
mot_techtalk
0
130
パスキーのすべて ── 導入・UX設計・実装の紹介 / 20250213 パスキー開発者の集い
kuralab
3
850
データベースのオペレーターであるCloudNativePGがStatefulSetを使わない理由に迫る
nnaka2992
0
210
ファインディLT_ポケモン対戦の定量的分析
fufufukakaka
0
870
AWS Organizations で実現する、 マルチ AWS アカウントのルートユーザー管理からの脱却
atpons
0
160
『GO』アプリ バックエンドサーバのコスト削減
mot_techtalk
0
150
Multi Step Form, Decentralized Autonomous Organization
pumpkiinbell
1
810
GoとPHPのインターフェイスの違い
shimabox
2
200
Formの複雑さに立ち向かう
bmthd
1
890
プログラミング言語学習のススメ / why-do-i-learn-programming-language
yashi8484
0
140
一休.com のログイン体験を支える技術 〜Web Components x Vue.js 活用事例と最適化について〜
atsumim
0
700
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
The Pragmatic Product Professional
lauravandoore
32
6.4k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.3k
How to Ace a Technical Interview
jacobian
276
23k
Building Your Own Lightsaber
phodgson
104
6.2k
Producing Creativity
orderedlist
PRO
344
39k
We Have a Design System, Now What?
morganepeng
51
7.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
The Invisible Side of Design
smashingmag
299
50k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
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.