障害訓練の取り組みについて.pdf

Transcript

1. 障害訓練の取り組みについて suzuki takafumi
2. Agenda • 自己紹介 • 障害訓練とは ◦ 企画の発端~運営チーム発足まで • なぜ障害訓練を実施するのか • どうやって障害訓練を実施するのか • 訓練を通しての学び • 終わりに
3. 自己紹介 • 鈴木孝史 (suzuki takafumi) ◦ 2020/04 アカツキ新卒入社 ▪ サーバーサイドエンジニア • 好きなもの ◦ VTuber ◦ 漫画 • 趣味 ◦ 旅行先とかで聖地巡礼をするのが好き ▪ → は京都/宇治のとある運動公園にいってた時です ◦ 散歩
4. 障害訓練とは 運営が意図的に障害を起こし、 訓練参加者がその障害を解決するまでの ロールプレイングです
5. 障害訓練とは 引用: SREサイトリライアビリティエンジニアリング 28.4.2 ディザスターロールプレイング 28.4.3 本物の破壊と修復 障害訓練と称していますが、 SRE本では ディザスターロールプレイングと表現されています。 ※以降この資料では障害訓練と記載します。 「新人はドキュメンテーションやポストモーテムを 読んだり、トレーニングを受けることによって SRE に関する多くのことを学べます。 ~中略~ とはい え、本物のプロダクションシステムを実際に壊し たり直したりすることで得られる経験はそれらに 勝ります。」 ※ポストモーテム...障害の事象と、それを解消するために行った事、原 因、再発防止策...等をまとめたドキュメントの事
6. 障害訓練とは SREサイトリライアビリティエンジニ アリング 28.4.3 本物の破壊と修復より 「新人はドキュメンテーションやポストモーテムを 読んだり、トレーニングを受けることによって SRE に関する多くのことを学べます。 ~中略~ とはい え、本物のプロダクションシステムを実際に壊し たり直したりすることで得られる経験はそれらに 勝ります。」
7. 障害訓練とは SREサイトリライアビリティエンジニ アリング 28.4.3 本物の破壊と修復より 「新人はドキュメンテーションやポストモーテムを 読んだり、トレーニングを受けることによって SRE に関する多くのことを学べます。 ~中略~ とはい え、本物のプロダクションシステムを実際に壊し たり直したりすることで得られる経験はそれらに 勝ります。」 ポストモーテムは、 • その障害自体の振り返りにも有効です。 • 将来のメンバーが過去の事象を知り、学ぶ材 料となります。 • 障害を再現するための資料 にもなります
8. 障害訓練とは 「新人はドキュメンテーションやポストモーテムを 読んだり、トレーニングを受けることによって SRE に関する多くのことを学べます。 ~中略~ とはい え、本物のプロダクションシステム を実際に壊し たり直したりすることで得られる経験はそれらに 勝ります。」 訓練用の開発環境 引用: SREサイトリライアビリティエンジニアリング 28.4.2 ディザスターロールプレイング 28.4.3 本物の破壊と修復
9. 障害訓練とは 「新人はドキュメンテーションやポストモーテムを 読んだり、トレーニングを受けることによって SRE に関する多くのことを学べます。 ~中略~ とはい え、本物のプロダクションシステム を実際に壊し たり直したりすることで得られる経験はそれらに 勝ります。」 訓練用の開発環境 引用: SREサイトリライアビリティエンジニアリング 28.4.2 ディザスターロールプレイング 28.4.3 本物の破壊と修復 運営が訓練用の開発環境に障害を起こし、 訓練参加者がその障害を解決するまでの ロールプレイングです
10. なぜ障害訓練を実施するのか
11. なぜ障害訓練を実施するのか 幾つかの不安 • サービスが安定稼働することで、稀に起きる"障害"への対応に不安があった • 障害が起きた時に一部のメンバーに頼ってしまうことがあった • 初めて本番障害にであったことで、うまく立ち回ることができなかった • 原因特定はできても咄嗟の対応/判断に自信がない ポジティブな目標 • チームとしてもっとトラブルへの対応練度を高めたい • OnCallメンバーで適切に対応ができるチームでありたい ※OnCall…日替わりで担当している1次調査担当メンバーの事 (各所からの調査依頼/対応などを行います)
12. なぜ障害訓練を実施するのか 幾つかの不安 • 稀に起きる"障害"への対応に不安 • 一部のメンバーに頼ってしまう • うまく立ち回ることができなかった • 咄嗟の対応/判断に自信がない ポジティブな目標 • トラブルへの対応練度を高めたい 漠然とした経験のなさからくる不安 より良い対応フローを求めて ...
13. なぜ障害訓練を実施するのか 幾つかの不安 • 稀に起きる"障害"への対応に不安 • 一部のメンバーに頼ってしまう • うまく立ち回ることができなかった • 咄嗟の対応/判断に自信がない ポジティブな目標 • トラブルへの対応練度を高めたい 開発環境で障害を再現させて、 訓練をし、対応練度をたかめよう！ 漠然とした経験のなさからくる不安 より良い対応フローを求めて ...
14. どうやって障害訓練を実施するのか
15. どうやって 障害訓練を 実施するのか • 事前 ◦ 運営チーム発足 ◦ 訓練の目的決め ◦ 訓練の内容決め ◦ 訓練のタイムライン作成 ◦ 障害の再現準備 • 当日 ◦ 当日の様子の記録 • 事後 ◦ 振り返り
16. どうやって障害訓練を実施するのか1/7~運営チーム~ • サーバーエンジニア (3人) ◦ 訓練全体の監修と古の不具合についての情報提供 (1人) ◦ 障害再現のための準備とか当日進行とか諸々やる (2人←鈴木含む) • PM (1人) ◦ 普段実際に行っている ”不具合対応取りまとめ ”を行ってもらう ▪ リアリティUP!
17. どうやって障害訓練を実施するのか2/7~目的決め~ 過去に実際に起きていた障害を再現することで • チームとしての対応練度を高めること • 障害が起きた時の対応の練習とすること • 障害時の咄嗟の判断になれること
18. どうやって障害訓練を実施するのか3/7~内容設定~ • 過去のポストモーテムから訓練の内容にするネタを決める (今回は2つ) ◦ 「e.g. ログインができない/高負荷状態を再現し特定のコンポーネントへ負荷をかける」 ◦ 「e.g. サーバー実装バグにより、見た目上だけの不具合となってしまう」 • 内容によってどこまでをゴールにするか考える ◦ ログイン障害 ▪ 1次対応によって適切にログインができるように復旧すること ▪ +α ソースコード修正による根本対応のアクションができること ◦ 見た目上だけの不具合 ▪ 「見た目上の問題であり、ユーザーデータへの影響がないこと」がわかること ▪ +α 原因のコードを見つけ、修正対応ができること
19. どうやって障害訓練を実施するのか4/7~タイムライン作成~ • 普段の障害対応フロー(簡易版) 1. 検知 2. 1次調査 3. 社内外向けの展開 4. 調査 5. 解決 対応フローを再現するように、 ”シナリオ”を作ります ※シナリオ... 運営の考える理想のシナリオ
20. どうやって障害訓練を実施するのか5/7~障害の再現準備~ • ポストモーテムを活用し、障害が起きるようにしておく ◦ ソースコードの改変やマスターデータの改変 ◦ 負荷をかけられるようなスクリプトを用意 ◦ 事前に適当なユーザーデータを用意 • 各種調査ができるようにAPM/CloudWatchなどの準備 ◦ ※APM/CloudWatch…いわゆる監視ツール • その他一部インフラの調整...etc ◦ ※障害の再現にあたり、開発環境の設定を一部変える必要がある ...等
21. どうやって障害訓練を実施するのか6/7~当日の記録~ • 当日は事前に作ったシナリオを元に障害を発生させます • 事前に用意したシナリオに沿って誘導したり、都度対応したりします。 ◦ 適宜、対応状況に応じてシナリオ分岐しつつ進行します • 想定のゴールにたどり着いたら終了 • ※ 当日の流れを後から振り返るために実際のタイムラインを記録しておきます。
22. どうやって障害訓練を実施するのか7/7~振り返り~ • 訓練中の対応の様子を振り返り ◦ 良かったところ(Keep), 減らしたい事 (Less of), 増やすもの/始めるもの(More of)を考えます ◦ なにか行動が必要なもの (ドキュメント作る) 等については担当者をきめたり • 訓練の実施内容の解説 ◦ 技術的な模範解答,理想的な調査フローを解説 ◦ 非技術的な全体の流れなどに振り返りの項目を見ながら一緒に考える ※Keep/Less of/More ofの考え方はsmart starfishという振り返り手法を用いたためです
23. 訓練を通しての学びの共有 (一部) Keep • ポストモーテムを活用した、過去の障害の追体験というものがよかった。 • 調査/対応において、方針を決めてからの行動が素早くできた。 Less/Stop • 役割を決めない状態で各々が調査を始めない → 2回目では、 誰が何をしているか、定期的にチーム内で同期できていた。
24. 訓練を通しての学びの共有 (一部) More of • PMや他チームメンバーへの共有は定期的に行い、情報の透明化をする • 調査を実施する際に、誰が何をするかを共有してから実施する • 調査には優先度をつけ、順次対応をしていくようにする。 → 闇雲に調査をしない • Slackの調査スレッドを活用し、 Zoomに参加していないメンバーでも様子がわかるようにする → もしかしたらZoom外のメンバーの方が詳しいかもしれない • 普段の自分がやっていないようなことを訓練時にやってみる → サーバーチーム内の取りまとめとか、普段やっていないメンバーもやってみる
25. 終わりに • 訓練を実施してみて ◦ 参加者 ▪ 対応フローの練習とすることができる ▪ 純粋に障害の追体験ができる ◦ 運営 ▪ 過去の障害がどうして起きていたんだっけ？といったところを改めて考えることができた ▪ 普段は参加者側にいる自分達を ”外から”見ることができ、俯瞰的にみることができた
26. 終わりに • 訓練を実施してみて ◦ 参加者 ▪ 対応フローの練習とすることができる ▪ 純粋に障害の追体験ができる ◦ 運営 ▪ 過去の障害がどうして起きていたんだっけ？といったところを改めて考えることができた ▪ 普段は参加者側にいる自分達を ”外から”見ることができ、俯瞰的にみることができた このような訓練を糧にし、今後もよりよいサービス運営を支えていきたいとおもっています
27. おわり。