チームで取り組む障害対応 / 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. #srefukuoka チームで取り組む障害対応 Incident response as a team Katsuhisa Kitano /

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

    Teachme Biz というSaaSをつくっている 東京からきました(年内は福岡にいます!) Organizer of SRE Lounge / SRE NEXT
  3. #srefukuoka SRE Lounge とは • 東京都内で、平日夜に開催しているSREに関する勉強会 ◦ 先日、第11回目が終わった • 各企業のSRE有志で集まり、コミュニティとして運営

    • 特徴 ◦ 開始時に乾杯する ◦ 質疑応答あり ◦ 一度の勉強会に複数社が登壇 ◦ イベント申し込みを開始して、1時間以内に満席になる 3
  4. #srefukuoka SRE NEXT とは • 2020/1/25(土)に東京で開催される 日本初のSREのカンファレンス • SRE Loungeの運営メンバーが中心となり開催準備中

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

  6. #srefukuoka SREチームになる前の話 • サーバーサイドの開発をやる傍ら、Infraのこともやるマン ◦ 自分でつくったものを自分で運用していたという意味においては、 Full Cycle Developer (圧倒的コレジャナイ感)

    • 当時のOnCall対応 ◦ ずっとおれのターン!!! 6
  7. #srefukuoka いつしかチームになった • 「人は、どうやってOnCall対応できるようになるのだろう?」 • 「障害対応にチームでどう取り組むべきか?」 → どうアプローチしてきたか? 今後どうアプローチしようとしているか?を話します 7

  8. #srefukuoka 8 チームで取り組む障害対応

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

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

  11. #srefukuoka SRE Onboarding • チームに新しく入った人が、 業務に速やかに合流するためOnboarding期間を設けている ◦ チームでいっしょにはたらく前提理解・知識をそろえる • OnCall対応に合流するために

    必要な知識の補充に重点を置いている ◦ SREとしての開発業務も、 このあたりの周辺理解がある方が取り組みやすい 11
  12. #srefukuoka SRE Onboarding • アーキテクチャ詳細解説 • ドメイン理解(Teachme Bizの機能説明会に参加) ◦ どの機能がサービスにとってよりミッションクリティカルなのか?を

    肌感覚で知ってもらう • サービス構築 ◦ AWSアカウントだけ与え、既存システムをゼロからつくってもらう • Postmortem reading ◦ 新しいSREは、サービスに関する知識がほとんどないため、 過去の障害からシステムがどのように動作するかを知ってもらう 12
  13. #srefukuoka 13 https://landing.google.com/sre/sre-book/chapters/accelerating-sre-on-call/ A blueprint for bootstrapping an SRE to

    on-call and beyond
  14. #srefukuoka 標準化 14

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

    どのような障害なら「即対応」か?は、 言語化しないとチームで判断基準がブレる • スタディストの場合は、Level 1〜5までを策定し運用 ◦ Level 1 が優先度最高 ◦ 機能によって優先度は異なる 15
  16. #srefukuoka Severity Level • ドキュメント化されていることと、 ドキュメント内容に基づき判断することは別問題 • 例:主要機能に影響があったら優先度高 →主要機能とは?がすぐに分からなければ、  ドキュメントに基づいた迅速な行動に結びつかない

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

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

  19. #srefukuoka 障害対応中はタスク実行と観察のバランスをとる • 救急外来チームを対象とした シミュレーションプログラムでの パフォーマンスの高いチームの特徴 ◦ 「タスクの実行」「観察」「診断を提案」を高速にまわす ◦ タスク実行が長くてもいけないし、観察が長くてもいけない

    ◦ このサイクルが特にうまくいっているチームの特徴は、 「やっていることを、声に出して伝え合っている」こと • 我々の仕事でも同じことが言える 19
  20. #srefukuoka 障害と向き合う文化 20

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

    現状では、開発者へのフィードバックとして活用 ◦ パフォーマンス劣化していたら、要因を調べ対応 • 今後、完全に開発者に委譲したい ◦ “Operate What You Build” 21
  22. #srefukuoka 障害につながるリリースをいかに減らすか • 計画続行バイアスに立ち向かう ◦ 目的地に近ければ近いほど、 懸念があったとしても、計画遂行を優先してしまうこと ▪ 結果、大惨事につながる可能性が高まる ◦

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

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

    障害をゼロにすることだけを目指すのではなく、 成果の最大化と障害の極小化の両立を目指す ◦ この2つは、トレードオフではない • SREはサイトオペラビリティにも責務も持っている 25
  26. #srefukuoka 26 https://sre-next.dev/ 会場で お待ちしてます

  27. 27 “伝えることを、もっと簡単に。" https://studist.jp/ 27 #srefukuoka 27

  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