SRE bridge the gap: Feature development to Core API / 機能開発チームとコアAPIチームの架け橋としてのSRE

Shopify の SRE の記事を見てから気になっていたキーノートでした.Shopify の中での SRE の実践でやっていった内容も興味深かったのですが,Shopify の中での信頼性に関する考えやキャリアの多様な在り方を認める文化って素敵だと感じました.

sre-next.dev

メモ

どういったタイミングで Production Engineering モデルが導入され,SRE チームが何を担っているか
- Production Engineeringの独立組織を作ってえた効果(2016~2017頃)
  - 機能開発チームで自分たちの環境を自律的に運用するためのツール開発
  - スケーラビリティやレジリエンシーへの投資
    - 結果として3倍のデプロイ頻度が増えた
- Production Engineeringのチームも大きくなってきた(2020年ころ)
  - Incident Manager On Call(IMOC)を担い始めた
    - SLO 違反になりそうなインシデント
- 信頼性について
  - Shopifyの考え：信頼性を脅かすことを享受すること(必要なこと)でしなやかなシステムにできる
    - 未来のRPMにするために学ぶ
  - Shopifyの複雑さ
    - フラッシュセール:トラフィックがスパイキー
    - ショップごとに機能要件が異なる
  - 対応
    - Semian
      - 外部サービスへの通信して遅くなったら失敗したときにサーキットが落とす関連記事
    - Load Shedder
      - DDoS を受けた時に同じようなトラフィックをEdgeでブロックする
    - Toxiproxy
      - 外部サービスの失敗したのシミュレーションできる
        
        Game Dayで失敗をして学ぶ
    - 文化やプロセス
      - 燃え尽き症候群が少ない
      - タイムゾーン別シフトを組んで、引き継ぎを行っていく
キャリアの話
- キャリアの3つの観点
  - 機能開発
  - CoreAPI
  - SRE
- 機能開発
  - 剣を使う人
    - どれだけ早くエンドユーザーにリリースできるかが関心事
- Core API
  - 剣を作る人
    - ドメインエキスパート
- SRE
  - 剣を研ぐ人
    - 分散型システムの失敗パターンに対するエキスパート
- それぞれのキャリア分野を掛け算ができる
  - 1つのチームの中で計画をする際に,違った視点を入れていく

Who owns the Service Level?

二年前の SLO Review の発表からの振り返りを共有いただいたセッションでした.なにかアクションを取る時に自己完結化できるようにすることは重要だと自分の経験上感じていたり,そのための権限や調整も必要だと思っていました.その中で組織内の技術戦略にまで踏み込んでいったお話は自分にとってなかった考えで,いろんな人々を巻き込んで進めることを体現されているなと感じました.

sre-next.dev

資料

メモ

SRE を実現するために必要な要素
- 指標をもとに完全し続ける文化
- 自己完結化を支えるプラットフォーム
- 優先順位を変更するための技術戦略
SRE でやること
- ユーザーが期待する信頼性を保っていること
  - やりすぎなくていい
- SLI/SLO を設定して非機能、機能の優先度決定するのに活用している
- 目標値のモニタリングとポリシーがチームで同意されている
- 定期的に見直されている
チムトポ
- SRE と開発チームの関係性
  - SRE : Platform(APIを使って提供),Enabling(専門家として他のチームが自律的に運用できるようにする)
  - 開発チーム : Stream Aligned (自分たちで必要なものを自分たちで用意できる/自己完結化)
MVVの話
- Mission
  - 自己完結化の重要な理由：他チームに必要なものを用意するために時間がかかってもったいない
    - 自己完結化が進むと,Dev vs Opsのような関係から And の関係になる
SLO Review の発表振り返り
- 良かったこと
  - 開発チームの認知不可を徹底的に下げることに拘った
- うまくいかなかった
  - エラーバジェットができなかった
    - SLI / SLO に従って行動できなかった
      - 非機能要求に対する権限・予算不足
  - SLO 違反したら全ての開発を止めてその修正を行うのは現実的ではないが、目標値を下回ったときのアクションを決める
    - 全員で負担する
技術戦略
- ビジネスの速度に追随するため、技術戦略が必要
  - 変更をしやすいシステム・コード・組織にする
    - 変更速度を妨げる要因を排除
- 技術的課題・負債をコントロール下におく
  - 特定の人に依存しないようにする

SLO決定のためのArt of SLO

転職先でも SLO の策定の話が出てきたので改めて決定に至るプロセスを確認したくて参加しました.CUJ -> SLI -> SLO -> エラーバジェットを策定するのが良さそう,加えてワークショップの紹介や質疑応答で SLO で追う目標値の数は 3~5 個で良いや SLO が顧客の期待に応えているかを見るのは難しいものの山口さんより参考情報をいただけたのは参考になりました.

sre-next.dev

メモ

CUJ
- Critical User Journey
- シーケンス図を書く
  - コンポーネント間のリクエストの様子を明らかにする -> SLI を決める
CUJからSLIを導き出すプロセス => 3~5くらいにするといい(振り返りで有効なものを選ぶ)
- SLIを導き出すメニューが有る
- SLI を導くイベントをもとに見るべき数値やメトリクスが決まってくる
SLO決定のためのプロセス
- 目標値と測定期間が必要
  - 過去データを参考にどれくらいのユーザーをカバーできているかを確認する
  - リクエストをカバーしないと収益に問題ないか
The Art of SLO ワークショップ
- グループワークで進めるコンテンツのためチームで SLO 策定の際にやってみると良さそう
- 下記のブログでも CUJ から SLI/SLO/エラーバジェットを定めるプロセスをさらえる