Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Opsしかやってこなかった私が DevOpsが根付いたチームにJoinした話

Opsしかやってこなかった私が DevOpsが根付いたチームにJoinした話

C86708d49471e365b38de3f5322e1ac4?s=128

yhamano

June 21, 2022
Tweet

More Decks by yhamano

Other Decks in Programming

Transcript

  1. Opsしかやってこなかった私が
 DevOpsが根付いたチームにJoinした話
 
 Ops JAWS Meetup#21 2022年6月21日(火)


  2. おしながき
 • DevOpsとは
 • DevOpsが根付いたチームにJoinした話
 ◦ 苦労した所と対策
 ◦ バリューを出すために意識したこと
 •

    まとめ

  3. DevOpsってなあに?


  4. Dev(開発)とOps(運用)の分離/対立
 • DevとOpsが別の組織として仕事をする(サイロ化)
 ◦ 相手領域の作業が必要な場合は依頼ベースで行う
 • 各組織での潜在的な責務が違うことによる対立
 ◦ Devの責務:機能の追加/変更を行ってサービスの売上向上を 目指す

    → 変更を加えたい
 ◦ Opsの責務:システムを安定稼働させサービスの売上損失を避 ける → 変更を加えたくない

  5. Dev(開発)とOps(運用)の分離/対立
 • DevとOpsが別の組織として仕事をする(サイロ化)
 ◦ 相手領域の作業が必要な場合は依頼ベースで行う
 • 各組織での潜在的な責務が違うことによる対立
 ◦ Devの責務:機能の追加/変更を行ってサービスの売上向上を 目指す

    → 変更を加えたい
 ◦ Opsの責務:システムを安定稼働させサービスの売上損失を避 ける → 変更を加えたくない
 顧客への貢献&ビジネス成功という目的は同じ
 

  6. DevOps
 “DevOpsでは、従来型のソフトウェア開発と、インフラストラクチャ管理プロセスを 使用するよりも速いペースで製品の進歩と向上を達成し、企業がアプリケーショ ンやサービスを高速で配信できるように、
 文化的な基本方針、プラクティス、ツールが組み合わされています。”
 https://aws.amazon.com/jp/devops/what-is-devops/


  7. 文化的な基本方針
 • アプリケーションデリバリにおけるチーム間のインタラクション をスムーズにする
 ◦ DevとOpsがひとつのチームで仕事をする
 ◦ 別チームに対して機能(API,モジュール等)を提供する
 • 他チームのサポートを必要とせず、チームメンバのみ


    でアプリケーションのデプロイ、インフラストラクチャのプロビ ジョニングを可能にする
 • 手動で時間がかかっていた運用をソフトウェアで自動化する

  8. プラクティス/ツール
 プラクティス
 ツール
 継続的インテグレーション/デリバリー (CI/CD)
 CodePipeline, CodeBuild, CodeDeploy
 マイクロサービス
 ECS,

    EKS, Lambda
 Infrastructure as Code
 CloudFormation, CDK
 モニタリングとロギング(Observability)
 CloudWatch, X-Ray
 コミュニケーションと共同作業
 チャットアプリケーション, 課題管理, wiki 

  9. DevOpsの実現には3要素全てを
 取り入れることが重要💪


  10. Four Keys
 • DevOpsの成果と成熟度を測る4つの指標
 ◦ デプロイの頻度
 ▪ 組織による正常な本番環境へのリリースの頻度
 ◦ 変更のリードタイム


    ▪ commit から本番環境稼働までの所要時間
 ◦ 変更障害率
 ▪ デプロイが原因で本番環境で障害が発生する割合
 ◦ サービス復元時間
 ▪ 組織が本番環境での障害から回復するのにかかる時間
 https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance

  11. DevOpsなチームにJoinした話


  12. Opsだけやってた頃
 • インフラ(クラウド)エンジニア@SIer
 • DevとOpsがくっきり分かれていた
 ◦ DevがAWSマネジメントコンソールさえも見れない現場も、、
 • Excel,PowerPointを駆使して各種定義書/設計書/手順書をた くさん書いていた


    • 運用設計書/手順書は作成するが実運用者は別の人
 

  13. Opsだけやってた頃
 • インフラ(クラウド)エンジニア@SIer
 • DevとOpsがくっきり分かれていた
 ◦ DevがAWSマネジメントコンソールさえも見れない現場も、、
 • Excel,PowerPointを駆使して各種定義書/設計書/手順書をた くさん書いていた


    • 運用設計書/手順書は作成するが実運用者は別の人
 
 なんやかんや(転職) あって環境が
 ガラッと変わることに

  14. DevOpsなチームにJoin
 • とあるプロダクトのバックエンドチーム(約10名)にJoin
 • DevOpsの文化的な基本方針、プラクティス、ツールが
 全て取り入れられているチームだった
 ◦ チームメンバのみで機能開発/インフラのプロビジョニング/
 運用(オンコール含む)を対応する
 ◦

    CI/CDで自動化されたテスト/デプロイ
 ◦ kubernetes等で動作するマイクロサービス
 ◦ OpenAPI,gRPC等を用いたスキーマ駆動でのコミュニケーション

  15. DevOpsなチームにJoin
 • とあるプロダクトのバックエンドチーム(約10名)にJoin
 • DevOpsの文化的な基本方針、プラクティス、ツールが
 全て取り入れられているチームだった
 ◦ 1チーム内で機能開発/インフラのプロビジョニング/
 運用(オンコール含む)を対応する
 ◦

    CI/CDで自動化されたテスト/デプロイ
 ◦ kubernetes等で動作するマイクロサービス
 ◦ OpenAPI,gRPC等を用いたスキーマ駆動でのコミュニケーション
 何も分からん

  16. まずはやれる所からやっていく
 • 辛うじて事前知識があるOps周りのタスクからやっていった
 ◦ インフラのプロビジョニング
 ◦ Toil削減
 ▪ ex)CI/CD環境のTerraform versionを最新に保つと幸せになれる


    ◦ コスト最適化
 ▪ ex)開発環境へのスポットインスタンス導入
 ◦ セキュリティ
 ▪ ex)kubernetesのDockershim非推奨によるcontainerdへの移行

  17. 苦労した所
 • コードリーディング/ライティング😇
 ◦ Opsメインでもエンジニアであればコードの読み書きは必須
 ▪ 手作業の運用を自動化する運用ツールの作成/メンテナンス
 ▪ アプリケーション起因のオンコール対応
 •

    各APIやバッチの概要把握
 ◦ スキーマやドキュメントを読んではいたが、各々数が多いこともあり 全容をなかなか把握できなかった

  18. 実施した対策
 • アプリケーション機能開発タスクもやっていく
 ◦ コードを読み書きする機会が圧倒的に増える
 ◦ 他メンバが実装したコードもレビュできるようになり
 各種機能の仕様理解が進む
 • 負荷試験を担当する


    ◦ テストシナリオの作成/パフォーマンスチューニングを通して各種 機能の仕様理解が進む
 ◦ パフォーマンスチューニングに関するノウハウの学習はISUCON 本をおすすめしたい

  19. バリューを出すために意識したこと
 • 守備範囲を広げて顧客への安定かつ迅速な価値提供に貢献す る
 ◦ 自分の強みを持ちつつも他の領域も見れるようにすることで
 DevとOps両面から俯瞰してシステムを見ることが可能
 ◦ 強みの深堀も重要
 ◦

    認知負荷が上がるためバランスは大事
 

  20. バリューを出すために意識したこと
 • 守備範囲を広げて顧客への安定かつ迅速な価値提供に貢献す る
 ◦ 自分の強みを持ちつつも他の領域も見れるようにすることで
 DevとOps両面から俯瞰してシステムを見ることが可能
 ◦ 強みの深堀も重要
 ◦

    認知負荷が上がるためバランスは大事
 
 チーム/プロダクトの状況や規模によって
 バリューの出し方は変わってくる 

  21. バリューを出すために意識したこと
 • 守備範囲を広げて顧客への安定かつ迅速な価値提供に貢献す る
 ◦ 自分の強みを持ちつつも他の領域も見れるようにすることで
 DevとOps両面から俯瞰してシステムを見ることが可能
 ◦ 強みの深堀も重要
 ◦

    認知負荷が上がるためバランスは大事
 
 チーム/プロダクトの状況や規模によって
 バリューの出し方は変わってくる 
 チームとしてDevOpsを
 加速させるためにはどうすれば良いか?

  22. チームとしてのDevOps加速
 • Four Keysの継続的な計測と改善
 • チーム/プロダクトの規模が拡大してもデプロイ頻度や品質を高 く保つための仕組み作り
 ◦ ex)ガードレール的チェック機構の導入
 ◦

    ex)デファクトスタンダードが盛り込まれたテンプレートや
 モジュールの用意
 

  23. まとめ
 • DevOpsには文化的な基本方針、プラクティス、ツールの
 3要素が重要
 • 未知の分野が多くある場合でもやれる所からバリューを出して いって徐々に守備範囲を広げていくことで大きなバリューを出し ていくこともできる
 • チーム全体のDevOpsを加速させる場合は個人にフォーカスし

    た活動だけでなく、チームとして何が足りていないか、問題があ るのかを計測/判断し改善していく必要がある
 

  24. Thank you.