Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

「責任ある開発」を!フルサービスオーナーシップが変えるエンジニアリング文化

 「責任ある開発」を!フルサービスオーナーシップが変えるエンジニアリング文化

Developer eXperience Day 2024で登壇した資料です

Kazuto Kusama

July 16, 2024
Tweet

More Decks by Kazuto Kusama

Other Decks in Technology

Transcript

  1. Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering

    Meetup 代表理事 @一般社団法人クラウドネイティブイノベーターズ協会 Organizer @CloudNative Days
  2. システムの安定稼働が至上命題に システム障害 = 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年に入り、大きなインシデントが立 て続けに発表されていますね
  3. システム化の拡大と、テクノロ ジーの高度化により、問題解 決に要する時間と対応コストが 大幅に増大 システム停止がビジネス収益 の低下と、顧客からの信頼失 墜に直結しかねない レガシーシステムや継ぎ足しで 拡大してきた巨大システムが 問題を複雑化

    システム運用を取り巻く現状 多くの組織が直面する運用課題:いかにシステム障害発生時のダウンタイムを削減するか (システム障害の件数を減らすことはできるが、ゼロにすることはできない)
  4. フルサービスオーナーシップとは 「コードを書いた者が、その責任を負う」 • 設計と実装の点から見て、テクノロジーに最も精通した人 が 製品開発ライフサイクル全体の責任を引き受ける 運用モデル • 本番環境において自分が書いたコードの責任を負うよう、 最もシンプルな形でエンジニアに権限を与える

    • “You build it, you run it.” Werner Vogels - VP & CTO of Amazon フルサービスオーナーシップ という言い回しは PagerDutyが好んで使っていますが、ほぼ同じ考 えの “You build it, you run it”は他の場所でもよく 聞きますね
  5. “コードに責任を持つ ” メリット • 自分のコードに責任を持つ開発者は、 エンドユーザーエクスペリエンスにより大きな影響を及ぼす • 開発者は自分の仕事が顧客だけでなく、 ビジネスにも与える影響をよりよく知ることができる •

    開発者にとってモチベーションを高めるだけでなく、修正やアップデートの スピードアップにもつながる。 • 二次情報やサポートチケットに頼るのではなく、自分自身で問題を確認できる
  6. “コードに責任を持つ ” メリット • MTTR(平均修復時間)削減につながる • 開発者は不具合の修正に最も適した人材 • 不具合の際には、開発者がラインの先頭に立つ •

    コードの責任者が明確なら、より少ないメンバーで問題のトラブルシューティングに対応でき る • 300人規模のオンライン会議で、コードを最後に修正したのは誰かをトラブルシューティング するような状況から決別できる
  7. そんな簡単にできるものじゃない • 『作った本人が全部やった方が早い』 • それはそう • これだけだと、単に分業を否定しているだけになる • 「専門分野」を活かすことにメリットがあるから、分業が存在する ここまでの話を単純に捉えると、分業はダメだから

    1人 で全部やろうぜって話に聞こえてしまうかも。でも、別に 分業がダメと言ってるわけじゃないんです。分業には明 確なメリットがある。 分業を唱えた18世紀のアダム・スミスに物申したい訳 ではない。
  8. よくあるアンチパターン https://web.devopstopologies.com/#anti-types より引用 Ops Embedded in Dev Team DevとOpsのサイロ化を防ごうとした結果、 Devチームの中

    にOpsを担う人材を抱えるようになる 多くの場合、幅広い知見を持つ、チームの中でもっとも価 値のあるエンジニアが シャドーオペレーションを行う形になる 結果として、チームの能力を最大限に発揮することができ なくなる
  9. Team Topologies Stream-aligned team 価値のある単一の仕事のストリームに沿って働くチーム ※ストリーム=ビジネスドメインや組織の能力に沿った仕事の 継続的な流れ “サービスチーム(内部での呼称)は職能横断型で、サービスの 管理、仕様決定、設計、開発、テスト、運用 (インフラストラク

    チャーのプロビジョニング、顧客サーポートを含む )を自分で 行える能力を持っていなければいけない 。必要な能力は個人 に割り当てられるわけではなく、チーム全体として必要な能力 を備えていればよい。それぞれのチームメンバーに専門分野 があるが、専門分野以外でもチームに貢献する。 ” チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 より引用 このStream-aligned teamは、 フルサービスオーナーシップ
  10. 抽象化した機能の提供 Platform Engineering https://tag-app-delivery.cncf.io/whitepapers/platforms/ より和訳 ストリームアラインドチーム プラットフォームチーム インターフェース 提供機能 ドキュメント

    GUI (ポータル) プロジェクトテンプレート APIとCLI 環境とリソースの提供 インフラリソース データ保管 メッセージング ID管理と認証 CI/CD サービス連携 成果物管理 セキュリティ 可観測性
  11. エスカレーションポリシー • 3-tierのエスカレーションポリシーが標準的 • 1st level サービスに責任を持つチームの誰か • 2nd level

    1st levelで受け取れなかった通知をキャッチ • 3rd level チームリーダー、EM、プロダクトオーナーなど
  12. 疑問: 開発者がオンコールに入ると 生産性が落ちるのでは ? • 少なからず影響はある • 大事なのは、個人としてではなくチームとしてサービスに責任を持つ こと •

    チームとして見たときに生産性が悪化しないオンコールの体制作りが大事 • 適切なローテーション • 燃え尽きを防ぐ体制作り • インシデントを減らす学びの体制作り
  13. 「開発者に運用もやらせる」ではなく 「ライフサイクルに責任を持たせる」 Build Test Ship Run スケールアウトがしやすい実装 (コンテナオーケストレーターの自 律復旧に委ねる) ビルドやパッケージングの自

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

    動化 素早いビルドの工夫 実行パラメータの外部注 入(環境依存の排除) トラブルシュートしやす いログの工夫 インフラのコード化 フィードバックループで改善を続け、呼び出しの頻度を減らす
  15. 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
  16. 9つのベストプラクティス • アジャイルはそのままに • アジャイル開発の手法はフルサービスオーナーシップ文化の導入に不可欠 • 細かくフィードバックループを回すことで開発・運用双方の改善を図れる • 最初は小規模に •

    組織全体の変革には相当な労力と上層部の支援が必要 • 支援を得るためには、価値を証明することからはじめる • 影響が重大にならないサイズと重要度のサービスからはじめる
  17. 9つのベストプラクティス • プロジェクトの選択 • Greenfield projectとBrownfield project。レガシーの制約を受けず設計をできる Greenfieldのほうが 一般的には簡単 •

    しかしGreenfieldで成功しても、価値の証明にならないことがある。 • 達成可能なBrownfield projectを選択して、トランスフォーメーションに着手することを検討 • 非難しない • 間違いは必ず起こる。個人が間違った選択をした場合に非難されたり報復を恐れたりすることな く、意思決定や実験を行う権限を与えられる必要がある
  18. 9つのベストプラクティス • モノリスに対する計画の立案 • モノリシックな巨大なアプリケーションがある場合は、オンコール担当の対応について検討 • モノリスを担当するチームには、その他のサービスを担当させない • 一般向けの平易なドキュメントを作成 •

    ドキュメントの作成は、コードベースに関わる各エンジニアで責任を共有する • コードを書いた人が、ドキュメントを作成する • 相手サービスの担当者が、当該サービスを理解できるようにする • チームAPI