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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

DevOpsってなあに？ 

Slide 4

Slide 4 text

Dev(開発)とOps(運用)の分離/対立  ● DevとOpsが別の組織として仕事をする(サイロ化)  ○ 相手領域の作業が必要な場合は依頼ベースで行う  ● 各組織での潜在的な責務が違うことによる対立  ○ Devの責務：機能の追加/変更を行ってサービスの売上向上を目指す → 変更を加えたい  ○ Opsの責務：システムを安定稼働させサービスの売上損失を避ける → 変更を加えたくない 

Slide 5

Slide 5 text

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

文化的な基本方針  ● アプリケーションデリバリにおけるチーム間のインタラクションをスムーズにする  ○ DevとOpsがひとつのチームで仕事をする  ○ 別チームに対して機能(API,モジュール等)を提供する  ● 他チームのサポートを必要とせず、チームメンバのみ  でアプリケーションのデプロイ、インフラストラクチャのプロビジョニングを可能にする  ● 手動で時間がかかっていた運用をソフトウェアで自動化する 

Slide 8

Slide 8 text

プラクティス/ツール  プラクティス  ツール  継続的インテグレーション/デリバリー (CI/CD)  CodePipeline, CodeBuild, CodeDeploy  マイクロサービス  ECS, EKS, Lambda  Infrastructure as Code  CloudFormation, CDK  モニタリングとロギング(Observability)  CloudWatch, X-Ray  コミュニケーションと共同作業  チャットアプリケーション, 課題管理, wiki  

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Four Keys  ● DevOpsの成果と成熟度を測る4つの指標  ○ デプロイの頻度  ■ 組織による正常な本番環境へのリリースの頻度  ○ 変更のリードタイム  ■ commit から本番環境稼働までの所要時間  ○ 変更障害率  ■ デプロイが原因で本番環境で障害が発生する割合  ○ サービス復元時間  ■ 組織が本番環境での障害から回復するのにかかる時間  https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance 

Slide 11

Slide 11 text

DevOpsなチームにJoinした話 

Slide 12

Slide 12 text

Opsだけやってた頃  ● インフラ(クラウド)エンジニア@SIer  ● DevとOpsがくっきり分かれていた  ○ DevがAWSマネジメントコンソールさえも見れない現場も、、  ● Excel,PowerPointを駆使して各種定義書/設計書/手順書をたくさん書いていた  ● 運用設計書/手順書は作成するが実運用者は別の人   

Slide 13

Slide 13 text

Slide 14

Slide 14 text

DevOpsなチームにJoin  ● とあるプロダクトのバックエンドチーム(約10名)にJoin  ● DevOpsの文化的な基本方針、プラクティス、ツールが  全て取り入れられているチームだった  ○ チームメンバのみで機能開発/インフラのプロビジョニング/  運用(オンコール含む)を対応する  ○ CI/CDで自動化されたテスト/デプロイ  ○ kubernetes等で動作するマイクロサービス  ○ OpenAPI,gRPC等を用いたスキーマ駆動でのコミュニケーション 

Slide 15

Slide 15 text

DevOpsなチームにJoin  ● とあるプロダクトのバックエンドチーム(約10名)にJoin  ● DevOpsの文化的な基本方針、プラクティス、ツールが  全て取り入れられているチームだった  ○ 1チーム内で機能開発/インフラのプロビジョニング/  運用(オンコール含む)を対応する  ○ CI/CDで自動化されたテスト/デプロイ  ○ kubernetes等で動作するマイクロサービス  ○ OpenAPI,gRPC等を用いたスキーマ駆動でのコミュニケーション  何も分からん 

Slide 16

Slide 16 text

まずはやれる所からやっていく  ● 辛うじて事前知識があるOps周りのタスクからやっていった  ○ インフラのプロビジョニング  ○ Toil削減  ■ ex）CI/CD環境のTerraform versionを最新に保つと幸せになれる  ○ コスト最適化  ■ ex）開発環境へのスポットインスタンス導入  ○ セキュリティ  ■ ex）kubernetesのDockershim非推奨によるcontainerdへの移行 

Slide 17

Slide 17 text

苦労した所  ● コードリーディング/ライティング😇  ○ Opsメインでもエンジニアであればコードの読み書きは必須  ■ 手作業の運用を自動化する運用ツールの作成/メンテナンス  ■ アプリケーション起因のオンコール対応  ● 各APIやバッチの概要把握  ○ スキーマやドキュメントを読んではいたが、各々数が多いこともあり全容をなかなか把握できなかった 

Slide 18

Slide 18 text

実施した対策  ● アプリケーション機能開発タスクもやっていく  ○ コードを読み書きする機会が圧倒的に増える  ○ 他メンバが実装したコードもレビュできるようになり  各種機能の仕様理解が進む  ● 負荷試験を担当する  ○ テストシナリオの作成/パフォーマンスチューニングを通して各種機能の仕様理解が進む  ○ パフォーマンスチューニングに関するノウハウの学習はISUCON 本をおすすめしたい 

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

バリューを出すために意識したこと  ● 守備範囲を広げて顧客への安定かつ迅速な価値提供に貢献する  ○ 自分の強みを持ちつつも他の領域も見れるようにすることで  DevとOps両面から俯瞰してシステムを見ることが可能  ○ 強みの深堀も重要  ○ 認知負荷が上がるためバランスは大事    チーム/プロダクトの状況や規模によって  バリューの出し方は変わってくる  

Slide 21

Slide 21 text

Slide 22

Slide 22 text

チームとしてのDevOps加速  ● Four Keysの継続的な計測と改善  ● チーム/プロダクトの規模が拡大してもデプロイ頻度や品質を高く保つための仕組み作り  ○ ex）ガードレール的チェック機構の導入  ○ ex）デファクトスタンダードが盛り込まれたテンプレートや  モジュールの用意   

Slide 23

Slide 23 text

まとめ  ● DevOpsには文化的な基本方針、プラクティス、ツールの  3要素が重要  ● 未知の分野が多くある場合でもやれる所からバリューを出していって徐々に守備範囲を広げていくことで大きなバリューを出していくこともできる  ● チーム全体のDevOpsを加速させる場合は個人にフォーカスした活動だけでなく、チームとして何が足りていないか、問題があるのかを計測/判断し改善していく必要がある   

Slide 24

Slide 24 text

Thank you. 