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

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.