$30 off During Our Annual Pro Sale. View Details »

成り立ちから押さえるSRE

iwamot
September 09, 2022

 成り立ちから押さえるSRE

2022-09-09
ENECHANGE Tech Talk (社内勉強会)

iwamot

September 09, 2022
Tweet

More Decks by iwamot

Other Decks in Technology

Transcript

  1. 成り立ちから押さえるSRE
    2022-09-09

    ENECHANGE Tech Talk (社内勉強会)
    CTO室 岩本隆史 (@iwamot)

    View Slide

  2. SRE略史
    2003: Ben Treynor (Benjamin Treynor Sloss) 氏がGoogleに入社
    Productionチームのマネジメントを担当
    DevとOpsの対立を解決する「エラーバジェット」を発案
    運用プラクティスを「Site Reliability Engineering (SRE)」と命名
    2014: SRECon14にて同氏が基調講演 (YouTube)
    2015: メルカリのインフラチームがSREチームに名称変更
    2016: 『Site Reliability Engineering』出版
    2018: 『The Site Reliability Workbook』出版

    View Slide

  3. DevとOpsの対立
    Dev: 好きなものを好きなときに邪魔なしにローンチしたい
    信頼性が軽視されすぎ
    Ops: いったん動いたシステムは一切変更したくない
    信頼性が重視されすぎ

    View Slide

  4. Ben Treynor氏の気づき
    100%を信頼性の目標とすることは誤り
    ユーザー~サービス間の可用性は99.999%よりもはるかに低い
    PC・Wi-Fi・ISP・電力網など多くの別システムが介在する
    岩本註:CloudFrontのSLAは月間稼働率99.9%

    View Slide

  5. エラーバジェットの発案
    信頼性の目標が99.9%なら、0.1%のエラーは許容できる
    この0.1%をエラーの予算とみなす
    予算を超えない限り、機能をローンチしてよい
    予算を超えたら、信頼性の回復にのみフォーカスする
    DevとOpsが同じ目標を共有できる

    View Slide

  6. SRECon14基調講演で示されたSRE (1)
    Hire only coders
    SREにはソフトウェアエンジニアリングのスキルが必要

    View Slide

  7. SRECon14基調講演で示されたSRE (2)
    Have an SLA for your service
    Measure and report performance against SLA
    Use Error Budgets and gate launches on them

    View Slide

  8. SRECon14基調講演で示されたSRE (3)
    Common staffing pool for SRE and DEV
    Excess Ops work overflows to DEV team
    Cap SRE operational load at 50%
    Share 5% of ops work with DEV team
    運用作業 (トイル) が勤務時間の50%を超えたらDevに差し戻す
    トイルの例:割り込み対応・オンコール・リリース
    残りの時間は主にトイル削減に費やす
    トイルはサービスの成長に比例する (採用では追いつかない)

    View Slide

  9. SRECon14基調講演で示されたSRE (4)
    Oncall teams at least 8 people, or 6x2
    Maximum of 2 events per on-call shift
    多ければ忙しすぎ、少なければ時間の無駄

    View Slide

  10. SRECon14基調講演で示されたSRE (5)
    Post mortem for every event
    Post mortems are blameless and focus on process and technology,
    not people
    学びがなければインシデントが繰り返される
    非難は問題を隠蔽する文化を醸成する

    View Slide

  11. Googleでの実例 (2011)
    ネットワーク運用チームの人的リソースが不足し始めた
    トイルが原因と気づき、自動化を進めた
    1年後、手動対応は例外となった
    システムの信頼性がはるかに向上した
    出典:ごく普通のエンジニアリング運用チームを強力な SRE チームに
    変える

    View Slide

  12. 各プラクティスの関係性 (岩本の理解)
    信頼性の目標 (SLO, Service Level Objective) 策定が最重要
    信頼性を維持・改善する施策
    トイルの削減 (50%ルール)
    非難のないポストモーテム
    適切な負荷のオンコール

    View Slide

  13. 参考記事
    e34fmの#3からSREについての概要を文字起こししてみた
    Introducing Google Customer Reliability Engineering (CRE)

    View Slide