Tweet
Tweet

Slide 1

Slide 1 text

「責任ある開発」を！ フルサービスオーナーシップが 変えるエンジニアリング文化 PagerDuty - Product Evangelist Kazuto Kusama @jacopen

Slide 2

Slide 2 text

Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup 代表理事 @一般社団法人クラウドネイティブイノベーターズ協会 Organizer @CloudNative Days

Slide 3

Slide 3 text

システムの安定稼働が至上命題に システム障害 ＝ IT部門が対処すべき課題 から システム障害 ＝ 経営リスク へ 出典：日経クロステック（ 2024/5/13） https://xtech.nikkei.com/atcl/nxt/column/18/01157/050900110/ 出典：朝日新聞（ 2024/6/25） https://www.asahi.com/articles/ASS6T32FPS6TUCVL00TM.html 出典：ITmediaエンタープライズ（ 2024/4/8） https://www.itmedia.co.jp/enterprise/articles/2404/08/news046.html 社会的信頼の失 墜 利益の逸失 取引先への影響 2024年に入り、大きなインシデントが立 て続けに発表されていますね

Slide 4

Slide 4 text

1時間 時間 $100K $250K インシデントがもたらす財務的影響 一説によると1時間の計画外ダウンにより平 均1600万円〜4000万円の損害が発生すると 言われている

Slide 5

Slide 5 text

システム化の拡大と、テクノロ ジーの高度化により、問題解 決に要する時間と対応コストが 大幅に増大 システム停止がビジネス収益 の低下と、顧客からの信頼失 墜に直結しかねない レガシーシステムや継ぎ足しで 拡大してきた巨大システムが 問題を複雑化 システム運用を取り巻く現状 多くの組織が直面する運用課題：いかにシステム障害発生時のダウンタイムを削減するか （システム障害の件数を減らすことはできるが、ゼロにすることはできない）

Slide 6

Slide 6 text

フルサービスオーナーシップとは 「コードを書いた者が、その責任を負う」 • 設計と実装の点から見て、テクノロジーに最も精通した人 が 製品開発ライフサイクル全体の責任を引き受ける 運用モデル • 本番環境において自分が書いたコードの責任を負うよう、 最もシンプルな形でエンジニアに権限を与える • “You build it, you run it.” Werner Vogels - VP & CTO of Amazon フルサービスオーナーシップ という言い回しは PagerDutyが好んで使っていますが、ほぼ同じ考 えの “You build it, you run it”は他の場所でもよく 聞きますね

Slide 7

Slide 7 text

製品開発ライフサイクル Build Test Ship Run Dev Ops かつてはライフサイクルの中で Devと Opsに分かれていました

Slide 8

Slide 8 text

製品開発ライフサイクル Build Test Ship Run Dev Ops 2009年にDevOpsが提唱されて以降、その境 界は曖昧になっています。ですが、依然として Dev担当、Ops担当というチーム分けは残って いる組織が多いです。

Slide 9

Slide 9 text

障害のほとんどはデプロイによって引き起こされる “障害のほとんどはデプロイによって引き起こされる。した がって、デプロイが増えると障害も増え、結果としてインシデ ント管理、軽減策、ポストモーテムが必要となる ” エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうのか より引用 しかし、最近日本語版が出たこの本に は、こんな一説がありました。

Slide 10

Slide 10 text

製品開発ライフサイクル Build Test Ship Run Dev Ops デプロイによって問題が起きるのであれば、そ の原因はDev側にあることが多いです。でも、 問題を最初に検知するのは Ops側。つまり、左 側とコミュニケーションしながら対応にあたる必 要がある。

Slide 11

Slide 11 text

フルサービスオーナーシップ Build Test Ship Run でもコミュニケーションは時間がかか る。であれば、特定の人が開発からデ プロイまで全部コントロール出来るよう になれば話が早い

Slide 12

Slide 12 text

真のDevOpsをやっていこうという話 Dev Ops Configure Verify Package Plan Monitor Release Create Plan

Slide 13

Slide 13 text

“コードに責任を持つ ” メリット • 自分のコードに責任を持つ開発者は、 エンドユーザーエクスペリエンスにより大きな影響を及ぼす • 開発者は自分の仕事が顧客だけでなく、 ビジネスにも与える影響をよりよく知ることができる • 開発者にとってモチベーションを高めるだけでなく、修正やアップデートの スピードアップにもつながる。 • 二次情報やサポートチケットに頼るのではなく、自分自身で問題を確認できる

Slide 14

Slide 14 text

“コードに責任を持つ ” メリット • 品質管理のループが生まれる • 夜中3時に好んで叩き起こされたい人はいない • 本番環境での責任を果たすため、運用品質を向上させようという モチベーションに繋がる • 組織構造ではなく、提供するものに集中できる • 責任者が誰なのかが明確となる • 組織の変化に対応していく仕組みが出来る

Slide 15

Slide 15 text

“コードに責任を持つ ” メリット • MTTR（平均修復時間）削減につながる • 開発者は不具合の修正に最も適した人材 • 不具合の際には、開発者がラインの先頭に立つ • コードの責任者が明確なら、より少ないメンバーで問題のトラブルシューティングに対応でき る • 300人規模のオンライン会議で、コードを最後に修正したのは誰かをトラブルシューティング するような状況から決別できる

Slide 16

Slide 16 text

理想 現実 これまでは理想について語ってき ました

Slide 17

Slide 17 text

そんな簡単にできるものじゃない • 『作った本人が全部やった方が早い』 • それはそう • これだけだと、単に分業を否定しているだけになる • 「専門分野」を活かすことにメリットがあるから、分業が存在する ここまでの話を単純に捉えると、分業はダメだから 1人 で全部やろうぜって話に聞こえてしまうかも。でも、別に 分業がダメと言ってるわけじゃないんです。分業には明 確なメリットがある。 分業を唱えた18世紀のアダム・スミスに物申したい訳 ではない。

Slide 18

Slide 18 text

認知負荷 オンコール ここでフルサービスオーナーシップを実践する にあたって課題となりやすいこの二つについて 説明します。

Slide 19

Slide 19 text

真のDevOps 開発者が、アプリをエンドツーエンドでデプロイし、実行する ただし、多くの組織にとって現実的ではない Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub Actions React Next.js Security Node.js Terraform ArgoCD APM Compliance 認知負荷が 高すぎる これをやり切れ る人材は少ない

Slide 20

Slide 20 text

認知負荷の増大 https://www.infoq.com/articles/platform-engineering-primer/ より引用 2014年にクラウドネイティブ技術が登場 して以降、開発者の認知負荷は右肩上 がりです。

Slide 21

Slide 21 text

よくあるアンチパターン https://web.devopstopologies.com/#anti-types より引用 Ops Embedded in Dev Team DevとOpsのサイロ化を防ごうとした結果、 Devチームの中 にOpsを担う人材を抱えるようになる 多くの場合、幅広い知見を持つ、チームの中でもっとも価 値のあるエンジニアが シャドーオペレーションを行う形になる 結果として、チームの能力を最大限に発揮することができ なくなる

Slide 22

Slide 22 text

DevとOpsというチーム分け Build Test Ship Run Dev Ops そもそものDevとOpsというチーム分け自 体を考え直す必要がありそうです。

Slide 23

Slide 23 text

Team Topologies 価値のあるソフトウェアを素早く届けられるよ うにするための組織設計。 4タイプのチーム定義と、3つのインタラクショ ンモードが定義されている。 そこで是非読んで欲しいのが Team Topologies

Slide 24

Slide 24 text

Team Topologies Stream-aligned team 価値のある単一の仕事のストリームに沿って働くチーム ※ストリーム=ビジネスドメインや組織の能力に沿った仕事の 継続的な流れ “サービスチーム(内部での呼称)は職能横断型で、サービスの 管理、仕様決定、設計、開発、テスト、運用 (インフラストラク チャーのプロビジョニング、顧客サーポートを含む )を自分で 行える能力を持っていなければいけない 。必要な能力は個人 に割り当てられるわけではなく、チーム全体として必要な能力 を備えていればよい。それぞれのチームメンバーに専門分野 があるが、専門分野以外でもチームに貢献する。 ” チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計　より引用 このStream-aligned teamは、 フルサービスオーナーシップ

Slide 25

Slide 25 text

Team Topologies ストリームアラインドチームが自律的に仕事を届けられるように するチーム。プラットフォームチームが提供するゴールデンパ スに沿ってもらうことで、認知負荷を軽減し生産性を高める。 “ストリームアラインドチームは本番環境のアプリケーションの 開発、運用、修正を含む全体のオーナーシップを持つ。プラット フォームチームは、内部サービスを提供することで、ストリーム アラインドチームが下位のサービスを開発する必要性をなく し、認知負荷を下げる ” チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計　より引用 Platform Team

Slide 26

Slide 26 text

Internal Developer Platform プラットフォームチームによって構築される、開発者のセルフサービスによる利用を可能にする 基盤。 さまざまな技術やツールによって構成され、コンテキストや基礎となる技術を抽象化することな く、開発者の認知負荷を軽減していく Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub Actions Security Terraform ArgoCD APM Compliance IDP Developer Platform Team self service

Slide 27

Slide 27 text

認知負荷を低く、生産性を高めるプラットフォーム • クラウドネイティブな自動化基盤作りを、開発者自身が担うことによる 認知負荷の高まりが問題になりつつある • 仕組み作りを担うPlatform Teamと協力し、認知負荷を高めずにクラウドネイティブ技術 を取り込んでいく • Platform Engineeringという分野が発展中

Slide 28

Slide 28 text

抽象化した機能の提供 Platform Engineering https://tag-app-delivery.cncf.io/whitepapers/platforms/ より和訳 ストリームアラインドチーム プラットフォームチーム インターフェース 提供機能 ドキュメント GUI (ポータル) プロジェクトテンプレート APIとCLI 環境とリソースの提供 インフラリソース データ保管 メッセージング ID管理と認証 CI/CD サービス連携 成果物管理 セキュリティ 可観測性

Slide 29

Slide 29 text

Team TopologiesとPlatform Engineeringを知るなら 7/9に開催したPlatform Engineering Kaigiという カンファレンスで、Team Topologiesの著者であ るManuel Pais氏を招聘し、語ってもらいました。 YouTubeでアーカイブ視聴可能です。 “Platform Engineering Kaigi 2024” で検索して 探すか、@jacopen のXをチェック

Slide 30

Slide 30 text

オンコール

Slide 31

Slide 31 text

オンコール • 運用で緊急を要する事態が発生した際、すぐに対応ができるように待機する 勤務形態 • PagerDutyを導入している場合、PagerDutyによって呼び出される • フルサービスオーナーシップの場合、開発者もオンコールのローテーションに 入る 開発者が運用にも携わるとい うことは、オンコールにも関与 するということになる

Slide 32

Slide 32 text

オンコール 必要なアラートだけに絞り込み 電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知 一次対応者 (応答がなければ) 二次対応者 オンコールの ローテーション

Slide 33

Slide 33 text

エスカレーションポリシー • 3-tierのエスカレーションポリシーが標準的 • 1st level サービスに責任を持つチームの誰か • 2nd level 1st levelで受け取れなかった通知をキャッチ • 3rd level チームリーダー、EM、プロダクトオーナーなど

Slide 34

Slide 34 text

疑問: 開発者がオンコールに入ると 生産性が落ちるのでは ? • 少なからず影響はある • 大事なのは、個人としてではなくチームとしてサービスに責任を持つ こと • チームとして見たときに生産性が悪化しないオンコールの体制作りが大事 • 適切なローテーション • 燃え尽きを防ぐ体制作り • インシデントを減らす学びの体制作り

Slide 35

Slide 35 text

「開発者に運用もやらせる」ではなく 「ライフサイクルに責任を持たせる」 Build Test Ship Run これを回すこと自体に責任を持たせる

Slide 36

Slide 36 text

「開発者に運用もやらせる」ではなく 「ライフサイクルに責任を持たせる」 Build Test Ship Run オンコール ライフサイクルを回していく中 で、オンコール対応が必要に なることも当然ある

Slide 37

Slide 37 text

「開発者に運用もやらせる」ではなく 「ライフサイクルに責任を持たせる」 Build Test Ship Run スケールアウトがしやすい実装 (コンテナオーケストレーターの自 律復旧に委ねる) ビルドやパッケージングの自 動化 素早いビルドの工夫 実行パラメータの外部注 入(環境依存の排除) トラブルシュートしやす いログの工夫 インフラのコード化 ただ、自分でオーナーシップを 持っていれば、改善すべきポイン トはたくさん見つかるはず。オン コールで消耗するなら、消耗しな いように自分で変えていけば良 い。

Slide 38

Slide 38 text

「開発者に運用もやらせる」ではなく 「ライフサイクルに責任を持たせる」 Build Test Ship Run スケールアウトがしやすい実装 (コンテナオーケストレーターの自 律復旧に委ねる) ビルドやパッケージングの自 動化 素早いビルドの工夫 実行パラメータの外部注 入(環境依存の排除) トラブルシュートしやす いログの工夫 インフラのコード化 フィードバックループで改善を続け、呼び出しの頻度を減らす

Slide 39

Slide 39 text

+ Recent Changes 最近入った変更のサマライズ デプロイで障害が発生すると言いま したが、PagerDutyを使うとインシデ ント前にどういう変更があったのかを 示唆してくれます

Slide 40

Slide 40 text

+ Past Incidents 過去の類似インシデント一覧と、 発生時期・回数のヒートマップを表示。 Related Incidents 他サービスで現在発生している、 関連性の高いインシデントを表示。

Slide 41

Slide 41 text

GUI/CodeによるJob定義と管理 41 41 柔軟なJob起動⼿段 認証 120を超える インテグレーション PagerDuty GenAI によるJob作成⽀援 オンプレ環境にも セキュアにアクセス Enterprise Runner - Event-Driven - Human-in-the-Loop - スケジューリング Web GUI API CLI Webhook PagerDuty Runbook Automation

Slide 42

Slide 42 text

アラートに応じた自動化 アラートを受信 インシデントを起票 切り分けのための タスクを実行 自動修復 軽減策のタスクを 実行

Slide 43

Slide 43 text

ポストモーテム SREのプラクティスでおなじみ • インシデントのインパクト • 緩和や解消のために行われたアクション • 根本原因 • インシデントの再発を避けるためのフォローアップ きちんと纏めておくことで、組織としての成長に繋がる。

Slide 44

Slide 44 text

+ だと Postmortems ポストモーテムの作成を支援。受信したイベント、ステータスアップデート、インシデント ノート、Slackの会話などからタイムラインを作成

Slide 45

Slide 45 text

フルサービスオーナーシップを 実現するための 9つのベストプラクティス

Slide 46

Slide 46 text

9つのベストプラクティス • アジャイルはそのままに • アジャイル開発の手法はフルサービスオーナーシップ文化の導入に不可欠 • 細かくフィードバックループを回すことで開発・運用双方の改善を図れる • 最初は小規模に • 組織全体の変革には相当な労力と上層部の支援が必要 • 支援を得るためには、価値を証明することからはじめる • 影響が重大にならないサイズと重要度のサービスからはじめる

Slide 47

Slide 47 text

9つのベストプラクティス • プロジェクトの選択 • Greenfield projectとBrownfield project。レガシーの制約を受けず設計をできる Greenfieldのほうが 一般的には簡単 • しかしGreenfieldで成功しても、価値の証明にならないことがある。 • 達成可能なBrownfield projectを選択して、トランスフォーメーションに着手することを検討 • 非難しない • 間違いは必ず起こる。個人が間違った選択をした場合に非難されたり報復を恐れたりすることな く、意思決定や実験を行う権限を与えられる必要がある

Slide 48

Slide 48 text

9つのベストプラクティス • 練習と実践を重ねる • 実際の応用に必要な自信と信頼を生むためには、低リスク環境での繰り返し練習が必要 • 本番を想定したインシデント対応の訓練 • チームの規模を適切なものに • Two-pizza rule - 2枚のピザで満たされるくらいのチーム - 5〜8人 • コミュニケーションに費やす時間を削減して、実務に充てられる時間を増やす

Slide 49

Slide 49 text

9つのベストプラクティス • サービスの定義を明確に • 問題の原因特定を容易にするため、サービ スは詳細に設定する必要がある • 2つのマイクロサービスが強い依存関係にあ り、片方の問題を修正することが他方の修 正に繋がる場合は、 1つにまとめる • インシデントが見過ごされることがないよう に、依存関係を文書化する Service Graph機能で影響範囲の可視化

Slide 50

Slide 50 text

9つのベストプラクティス • モノリスに対する計画の立案 • モノリシックな巨大なアプリケーションがある場合は、オンコール担当の対応について検討 • モノリスを担当するチームには、その他のサービスを担当させない • 一般向けの平易なドキュメントを作成 • ドキュメントの作成は、コードベースに関わる各エンジニアで責任を共有する • コードを書いた人が、ドキュメントを作成する • 相手サービスの担当者が、当該サービスを理解できるようにする • チームAPI

Slide 51

Slide 51 text

フルサービスオーナーシップに関する資料 PagerDuty自身の経験を元にしたガイド、「 Ops Guides」の一環として、フルサービスオーナー シップのドキュメントも公開中 現在は英語のみですが将来的な日本語の計 画もあり https://ownership.pagerduty.com/

Slide 52

Slide 52 text

まとめ • インシデントを減らし、価値を生み続けるソフトウェアの開発には、ライフサイ クルすべてに責任をもつフルサービスオーナーシップが重要 • Team Topologiesの実践により、フルサービスオーナーシップを実現するチー ムが見えてくる • 敬遠されがちなオンコールも担うことで、開発から運用まで含めたライフサイ クルの改善に繋げることができる • この一連のサイクルを実現するために、PagerDutyも貢献します

Slide 53

Slide 53 text

No content