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

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両面から俯瞰してシステムを見ることが可能  ◦ 強みの深堀も重要  ◦
認知負荷が上がるためバランスは大事   

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

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

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

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

Thank you. 

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

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

yhamano

More Decks by yhamano

Other Decks in Programming

Featured

Transcript