[レポート]Amazon流にDevOpsに移行する #reinvent #DEV210

本記事はre:Invent 2018のセッション「DEV210 - Moving to DevOps the Amazon Way」のレポートです。

日本語のリソースとしては「DevOpsとは？ - DevOpsとAWS」を一読しておくと良いと思います。

概要

DevOps is currently one of the most sought after engineering models. One reason is that it helps enterprise transformations. The Amazon transformation to DevOps was born out of the desire to be even more customer obsessed, more agile, and more innovative. Come and learn from our journey as we share the playbook that helped us successfully implement and adopt DevOps as well as the lessons we learned the hard way.

スピーカー

• Ajit Zadgaonkar - Head - Global DevOps Specialty Practice, AWS Professional Services

レポート

アジェンダ

• DevOpsの必要性
• AmazonがどうDevOpsに取り組んだか
• 学んだ教訓
• DevOpsへの道のりをどこから始めるべきか

DevOpsの必要性

• エンタープライズではスピードとアジリティを求めている
• 今日のITのゴール
  • コストの削減
  • イノベーションのリードとビジネスの変革

DevOpsの効果

AWSのイノベーションペース

新たな機能/サービスのローンチ件数

• 2010年には61
• 2012年には159
• 2014年には516
• 2017年には1430

100万デプロイ/年 = 数千のチーム × マイクロサービスアーキテクチャ × 継続的デリバリ × マルチ環境 × 複数タイプのデプロイメント

どうやって「イノベーション」「アジリティ」「スピード」「クオリティ」を改善し、「コスト」を低下させるのか？

AmazonがどうDevOpsに取り組んだか

”文化的な基本方針 + プラクティスとパターン + ツール”を組み合わせる

Amazonの開発

2001年はモノリスだった...、そこから適度な単位にプロセスを分割していき、その単位毎に小さなチームをアサインした(2-Pizzaルール)。

現在はそれぞれのチームがスタートアップのように取り組んでいる。

チームのプロセス

機能横断の各チームがチーム毎のバックログのストーリーに一つずつ着手していく、シングルスレッドモデル。

スクラムの手法に則ったチーム体制(プロダクトオーナー、開発チーム、スクラムマスター)とタスクマネジメント。

開発と運用をサイロ化してしまうと、チーム間でブロック状態が発生するため、クロスファンクショナルな2-Pizzaチームで構成している。

学んだ教訓

• 企業規模の包括性
• ベルトとサスペンダーの仕様
• 効率化のパターン
• レジリエンス・テストの実装
• 可観測性の実装

DevOpsへの道のりをどこから始めるべきか

高度なところからではなく、Well Architectedから。
そして、DevOpsは目的地じゃなく、途上の旅。

(横軸が時間の経過を指している)

DevOpsを始めるための3ステップ

• 小さく始めて、学び、繰り返す
• スケールするフレームワークを設定する
• 教える

さいごに

DevOpsの背景と必要性、DevOpsとは何なのか紹介し、AmazonがどうDevOpsに取り組んできたのかを技術面、体制面でもアドバイスする内容でした。
組織によって導入のハードルの高低はあると思いますが参考にしてはいかがでしょうか。