#srefukuoka チームで取り組む障害対応 Incident response as a team Katsuhisa Kitano / @katsuhisa__

#srefukuoka 2 北野 勝久 / @katsuhisa__ 株式会社スタディスト 開発部 SRE - Teachme Biz というSaaSをつくっている 東京からきました（年内は福岡にいます！） Organizer of SRE Lounge / SRE NEXT

#srefukuoka SRE Lounge とは ● 東京都内で、平日夜に開催しているSREに関する勉強会 ○ 先日、第11回目が終わった ● 各企業のSRE有志で集まり、コミュニティとして運営 ● 特徴 ○ 開始時に乾杯する ○ 質疑応答あり ○ 一度の勉強会に複数社が登壇 ○ イベント申し込みを開始して、1時間以内に満席になる 3

#srefukuoka SRE NEXT とは ● 2020/1/25（土）に東京で開催される 日本初のSREのカンファレンス ● SRE Loungeの運営メンバーが中心となり開催準備中 ● 素晴らしい登壇者に集まっていただいた ○ https://sre-next.dev/speakers/ ● チケット販売中 4

#srefukuoka はじめに 5

#srefukuoka SREチームになる前の話 ● サーバーサイドの開発をやる傍ら、Infraのこともやるマン ○ 自分でつくったものを自分で運用していたという意味においては、 Full Cycle Developer （圧倒的コレジャナイ感） ● 当時のOnCall対応 ○ ずっとおれのターン！！！ 6

#srefukuoka いつしかチームになった ● 「人は、どうやってOnCall対応できるようになるのだろう？」 ● 「障害対応にチームでどう取り組むべきか？」 → どうアプローチしてきたか？ 今後どうアプローチしようとしているか？を話します 7

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

#srefukuoka 話すこと ● 人材育成 ● 標準化 ● 障害と向き合う文化 話さないこと ● ポストモーテムの書き方 ● 障害を減らすために行った パフォーマンス改善 ● 障害検知のための モニタリング 9

#srefukuoka 人材育成 10

#srefukuoka SRE Onboarding ● チームに新しく入った人が、 業務に速やかに合流するためOnboarding期間を設けている ○ チームでいっしょにはたらく前提理解・知識をそろえる ● OnCall対応に合流するために 必要な知識の補充に重点を置いている ○ SREとしての開発業務も、 このあたりの周辺理解がある方が取り組みやすい 11

#srefukuoka SRE Onboarding ● アーキテクチャ詳細解説 ● ドメイン理解（Teachme Bizの機能説明会に参加） ○ どの機能がサービスにとってよりミッションクリティカルなのか？を 肌感覚で知ってもらう ● サービス構築 ○ AWSアカウントだけ与え、既存システムをゼロからつくってもらう ● Postmortem reading ○ 新しいSREは、サービスに関する知識がほとんどないため、 過去の障害からシステムがどのように動作するかを知ってもらう 12

#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

#srefukuoka 標準化 14

#srefukuoka Severity Level ● 障害発生時に影響判断を行うためのドキュメント ○ 影響の大きさをレベル別に言語化したもの ○ レベルごとに検知後の対応手順が異なる ● どのような障害なら「即対応」か？は、 言語化しないとチームで判断基準がブレる ● スタディストの場合は、Level 1〜5までを策定し運用 ○ Level 1 が優先度最高 ○ 機能によって優先度は異なる 15

#srefukuoka Severity Level ● ドキュメント化されていることと、 ドキュメント内容に基づき判断することは別問題 ● 例：主要機能に影響があったら優先度高 →主要機能とは？がすぐに分からなければ、 　ドキュメントに基づいた迅速な行動に結びつかない 16

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

#srefukuoka 余談 18

#srefukuoka 障害対応中はタスク実行と観察のバランスをとる ● 救急外来チームを対象とした シミュレーションプログラムでの パフォーマンスの高いチームの特徴 ○ 「タスクの実行」「観察」「診断を提案」を高速にまわす ○ タスク実行が長くてもいけないし、観察が長くてもいけない ○ このサイクルが特にうまくいっているチームの特徴は、 「やっていることを、声に出して伝え合っている」こと ● 我々の仕事でも同じことが言える 19

#srefukuoka 障害と向き合う文化 20

#srefukuoka SLI定点観測 ● SLOと実績値を比較 ○ 性能劣化は障害の要因になりやすいので、 性能の傾向を定期的に把握 ● キャパシティ不足による障害を撲滅できるわけではない ○ 現状では、開発者へのフィードバックとして活用 ○ パフォーマンス劣化していたら、要因を調べ対応 ● 今後、完全に開発者に委譲したい ○ “Operate What You Build” 21

#srefukuoka 障害につながるリリースをいかに減らすか ● 計画続行バイアスに立ち向かう ○ 目的地に近ければ近いほど、 懸念があったとしても、計画遂行を優先してしまうこと ■ 結果、大惨事につながる可能性が高まる ○ 航空機事故からの教訓 ○ 機能リリースの納期を守ることを最優先にしていないか？ ● 障害につながるリリースを減らす ≠ リリース回数を減らす ○ リリース回数は増やしたい ○ 単に障害をゼロにすることを目指すのではなく、 「成果の最大化」と「障害の極小化」を両立したい 22

#srefukuoka 今後のやっていき / まとめ 23

#srefukuoka まだまだやりたいことはある ● Failure Fridays ○ PagerDuty での障害投入演習の取り組み ● Playing time-bound simulation games ○ 『SRE Workbook』の「Incident Response」の章で推奨 ○ 「Keep Talking and Nobody Explodes」というゲームが紹介されてる ■ Switchでできるよ！！！ ○ インシデント対応のtime-boundである側面を演習する ● PagerDuty の導入 ○ #oncallselfie をやりたい人生だった 24

#srefukuoka まとめ ● 障害対応できる人を増やすことは難しい ○ 実地訓練の機会を平等に提供できない ○ ただし、障害対応に必要な知識を広く提供することや、 プロセスを標準化することはできる ● 障害をゼロにすることだけを目指すのではなく、 成果の最大化と障害の極小化の両立を目指す ○ この2つは、トレードオフではない ● SREはサイトオペラビリティにも責務も持っている 25

#srefukuoka 26 https://sre-next.dev/ 会場で お待ちしてます

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

#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