チームで取り組む障害対応 / Incident response as a team

C0479b152c326746e911be790617f75b?s=47 katsuhisa_
November 25, 2019

チームで取り組む障害対応 / Incident response as a team

SRE meetup at Fukuoka vol.3 ( https://sre-fukuoka.connpass.com/event/151108/ ) での発表資料です。OnCallについてのPracticalなTopicについて話しました。

C0479b152c326746e911be790617f75b?s=128

katsuhisa_

November 25, 2019
Tweet

Transcript

  1. 2.

    #srefukuoka 2 北野 勝久 / @katsuhisa__ 株式会社スタディスト 開発部 SRE -

    Teachme Biz というSaaSをつくっている 東京からきました(年内は福岡にいます!) Organizer of SRE Lounge / SRE NEXT
  2. 3.

    #srefukuoka SRE Lounge とは • 東京都内で、平日夜に開催しているSREに関する勉強会 ◦ 先日、第11回目が終わった • 各企業のSRE有志で集まり、コミュニティとして運営

    • 特徴 ◦ 開始時に乾杯する ◦ 質疑応答あり ◦ 一度の勉強会に複数社が登壇 ◦ イベント申し込みを開始して、1時間以内に満席になる 3
  3. 4.

    #srefukuoka SRE NEXT とは • 2020/1/25(土)に東京で開催される 日本初のSREのカンファレンス • SRE Loungeの運営メンバーが中心となり開催準備中

    • 素晴らしい登壇者に集まっていただいた ◦ https://sre-next.dev/speakers/ • チケット販売中 4
  4. 9.

    #srefukuoka 話すこと • 人材育成 • 標準化 • 障害と向き合う文化 話さないこと •

    ポストモーテムの書き方 • 障害を減らすために行った パフォーマンス改善 • 障害検知のための モニタリング 9
  5. 12.

    #srefukuoka SRE Onboarding • アーキテクチャ詳細解説 • ドメイン理解(Teachme Bizの機能説明会に参加) ◦ どの機能がサービスにとってよりミッションクリティカルなのか?を

    肌感覚で知ってもらう • サービス構築 ◦ AWSアカウントだけ与え、既存システムをゼロからつくってもらう • Postmortem reading ◦ 新しいSREは、サービスに関する知識がほとんどないため、 過去の障害からシステムがどのように動作するかを知ってもらう 12
  6. 15.

    #srefukuoka Severity Level • 障害発生時に影響判断を行うためのドキュメント ◦ 影響の大きさをレベル別に言語化したもの ◦ レベルごとに検知後の対応手順が異なる •

    どのような障害なら「即対応」か?は、 言語化しないとチームで判断基準がブレる • スタディストの場合は、Level 1〜5までを策定し運用 ◦ Level 1 が優先度最高 ◦ 機能によって優先度は異なる 15
  7. 17.

    #srefukuoka Incident Response Run Book • Severity Level 1, 2

    の対応プロセスを言語化したもの ◦ 「誰に連絡するか?」「チームでどのように役割分担して動くか?」 「まずはじめに何をするか?」 • Security Incident の場合は、さらに専用のRun Bookに分岐 ◦ Security Incident Response Run Book ◦ キャパシティ不足等によるシステム障害と、 セキュリティインシデントでは、取り組み方がまったく異なるため 17
  8. 21.

    #srefukuoka SLI定点観測 • SLOと実績値を比較 ◦ 性能劣化は障害の要因になりやすいので、 性能の傾向を定期的に把握 • キャパシティ不足による障害を撲滅できるわけではない ◦

    現状では、開発者へのフィードバックとして活用 ◦ パフォーマンス劣化していたら、要因を調べ対応 • 今後、完全に開発者に委譲したい ◦ “Operate What You Build” 21
  9. 22.

    #srefukuoka 障害につながるリリースをいかに減らすか • 計画続行バイアスに立ち向かう ◦ 目的地に近ければ近いほど、 懸念があったとしても、計画遂行を優先してしまうこと ▪ 結果、大惨事につながる可能性が高まる ◦

    航空機事故からの教訓 ◦ 機能リリースの納期を守ることを最優先にしていないか? • 障害につながるリリースを減らす ≠ リリース回数を減らす ◦ リリース回数は増やしたい ◦ 単に障害をゼロにすることを目指すのではなく、 「成果の最大化」と「障害の極小化」を両立したい 22
  10. 24.

    #srefukuoka まだまだやりたいことはある • Failure Fridays ◦ PagerDuty での障害投入演習の取り組み • Playing

    time-bound simulation games ◦ 『SRE Workbook』の「Incident Response」の章で推奨 ◦ 「Keep Talking and Nobody Explodes」というゲームが紹介されてる ▪ Switchでできるよ!!! ◦ インシデント対応のtime-boundである側面を演習する • PagerDuty の導入 ◦ #oncallselfie をやりたい人生だった 24
  11. 25.

    #srefukuoka まとめ • 障害対応できる人を増やすことは難しい ◦ 実地訓練の機会を平等に提供できない ◦ ただし、障害対応に必要な知識を広く提供することや、 プロセスを標準化することはできる •

    障害をゼロにすることだけを目指すのではなく、 成果の最大化と障害の極小化の両立を目指す ◦ この2つは、トレードオフではない • SREはサイトオペラビリティにも責務も持っている 25
  12. 28.

    #srefukuoka 参考文献 • 『巨大システム失敗の本質』 • 『The Site Reliability Workbook』 •

    『Site Reliability Engineering』 • 『ウェブオペレーション』 • PagerDuty Incident Response https://response.pagerduty.com/ • How Did Things Go Right? Learning More from Incidents https://www.infoq.com/presentations/incident-investigation-failure-prevention/ 28