入門オンコール対応

Transcript

1. 1 ⼊⾨ オンコール対応 ~ 深夜対応後のラーメンが最⾼編 ~ 渡部 ⿓⼀ TechRAMEN 2024

   Conference

2. 2 アジェンダ 1. 自己紹介 2. イントロダクション 3. オンコール対応とは 4. オンコール対応の具体的な事例紹介

   5. まとめ

3. 3 ⾃⼰紹介

4. 技術部プラットフォームグループ 2021年 中途入社 4 自己紹介 渡部 龍一 Watanabe Ryuichi •

   ロール: SRE • 仙台から来ました。北海道は2ヶ月ぶり2回目 • SNS: @ryuichi_1208 • 好きなこと: 障害対応、EOL対応 • 好きなラーメン: 仙台っ子ラーメン(豚骨醤油)

5. 5

6. 6 イントロダクション

7. 7 イントロダクション “オンコール対応やってますか？”

8. 8 イントロダクション “⼤変じゃないですか？”

9. 9 日中帯の割り込み 休日・夜間対応

10. 10 どうにかしたい！

11. 11 https://atmarkit.itmedia.co.jp/ait/articles/2207/26/news017.html

12. 12 あれから2年後...

13. 13 話すこと • オンコール対応の基本 • オンコール対応を円滑に進めるための具体的な手法 セッション対象 • システム運用をやってる方、その働き方に興味がある方 •

    オンコール対応に初めて携わる方 • オンコール対応を効率化したいと考えている人

14. 14 オンコールの世界へDive!

15. 15 オンコール対応とは

16. 16 • システム運⽤やITサポートにおいて、緊急のインシデントや問題が発⽣した際に即座 に対応するために、特定の時間帯やシフトで待機している体制のことを指す • 元々医療分野からきている⾔葉で医師や看護師が24時間体制で患者の緊急事態に対応 するために待機している状態を意味する オンコールとは

17. 17 • アラートの受信と確認 ◦ Webページに繋がらない、閾値以上の時間がかかっている • インシデントの分類と優先順位付け • 初期(⼀次)対応 ◦

    重⼤なインシデントの場合は即エスカレーションするケースも • 詳細なトラブルシューティング • 対応できない場合は開発の担当者などへエスカレーション ◦ エンジニア以外にも告知を出す担当者や事業の責任者などへも共有 オンコール対応では何をやるのか？

18. 18 なぜオンコールは必要なのか？

19. 19 オンコールがないシステム

20. 20 サーバダウン！！

21. 21 • 平⽇⽇中にサーバが落ちたら ◦ そのタイミングで対応する • 平⽇夜間にサーバが落ちたら ◦ 翌⽇の営業⽇に対応する •

    連休中にサーバが落ちたら ◦ 翌営業⽇に対応する サーバが落ちてサービスが繋がらない状態

22. 22 ⻑期休暇中だったらどうなる？

23. 23 1週間サービス使えません！

24. 24 • クレームの電話がなり続ける • サービスから離れていってしまう • SLAがある場合は利⽤料の返⾦対応などが必要となる場合も サーバが落ちてサービスが繋がらない状態

25. 25 SLA99%以上なら即対応が必須

26. 26 • システムの安定稼働 ◦ システムのダウンタイムを最⼩限に抑えるために、迅速な対応が求められる ◦ オンコール体制は、システムの安定稼働を維持するための重要な⼿段 • 顧客満⾜度の向上 ◦

    問題が発⽣した際に迅速に対応することで、顧客の信頼を維持し、サービス品質を向上させ ることができる • ビジネス継続性の確保 ◦ 重要なシステムやサービスの中断を最⼩限に抑えることで、ビジネスの継続性を確保できる オンコールの⽬的

27. 27 オンコール体制を整備！

28. 28 絶対必要？

29. 29 • 個⼈開発であればそこまで⾼い可⽤性は求めない • サービスの特性上⽇中帯以外は全く使われない ◦ 利⽤者から年中無休の可⽤性が期待されるサービスじゃないケースがある • ⼈員がいないためサービスが落ちているのを許容する オンコールをするかはサービスの特性による

30. 30 具体的な事例紹介

31. 31 • オンコールに関するシステム構成 • オンコール体制の話 • オンコール当番になった際にやっていること • オンコールトレーニング 具体的な事例で話すこと

32. 32 オンコールに関するシステム構成

33. 33 システム構成

34. 34 オンコール体制の話

35. 35 24時間戦えますか？

36. 36 ほぼNo(⼀部例外あり)

37. 37 • サービスに詳しい⼈が24時間365⽇対応できれば気にすることは特にない • それは現実的ではないので複数のメンバーで当番制にする必要がある ◦ 平⽇は始業時間〜翌⽇の始業時間 • 全メンバーが同⼀の技術スタックに精通していれば誰がいつやっても良い •

    それも現実的ではないので⼯夫してシフトを組む必要がある オンコール体制

38. 38 • オンコールは⼀般的にメインで担当するメンバー + それ以外のメンバーというシフト • PagerDutyにもエスカレーションポリシーという機能がある • サービスに詳しいメンバーと新メンバーで交互にエスカレーションをする オンコール体制の⼯夫:

    エスカレーションポリシー

39. 39 • スキルマップシート ◦ 誰がどの分野に詳しいかをスキルマップとして運⽤をしてみた ◦ 有効活⽤したいが... ▪ アップデートされなかったりして活⽤はできていない ▪

    興味がある分野を知るきっかけにはなった オンコール体制の⼯夫: エスカレーションポリシー

40. 40 オンコール当番になった際に やっていること

41. 41 • オンコール当番でも1⽇中すぐに対応できるようにしておくということはない • 出かける際にPCを持っていくやスマートフォンの通知を切らない • ⼤きめのリリース当⽇とかで待機を会社から指⽰されることは過去にはあった ◦ この場合は待機⼿当をもらった ◦

    法律的にはオンコール待機は業務時間にはならないので普段のオンコールでは該当しない オンコール当番になった際にやっていること① 待機

42. 42 • アラートの⼀次受け、⾃分で解決できる場合 ◦ ⼿動オペレーションで正常な状態へ戻す ◦ 根本対応まで実装 ▪ 設計/実装不備、チューニング不⾜はPull Requestの作成までやって翌営業⽇でリリース

    • ⼀次受けした後に⾃分で解決できない場合は詳しい⼈にエスカレーション ◦ どのくらいの時間調べてわからなければエスカレーションするかを事前に決めておく ▪ サービスの信頼性に直結する部分なので重要！ オンコール当番になった際にやっていること② 対応

43. 43 オンコールトレーニング

44. 44 • 配属や⼊社して即オンコールシフトは技術的にもメンタル的にも難しい • 誤った対応による⼆次障害、調査に時間がかかりすぎることによるMTTRの悪化 • オンコールで対応すべき内容は通常業務だけだと⾝につきづらい内容も多くある ◦ 「サービスが⾼負荷になった」、「データベースが落ちた」際の対応は通常業務では取り扱 うことあまりない

    オンコールトレーニング① 課題

45. 45 • シナリオベースの訓練の実施 ◦ 過去のオンコールで発⽣した対応をモブオペ形式で再現して対応を確認する ◦ さまざまなシナリオを想定して対応を練習することで、実際のインシデントに対する対応⼒ を強化する のが狙い •

    Playbook(Runbook)の整備 ◦ システム運⽤や管理において発⽣する作業や⼿順を⽂書化したもの ◦ 特定のインシデントやタスクを迅速かつ効率的に処理するためのガイドライン ◦ アラート -> 対応を⾃動化しにくいものはドキュメントとして⽤意している オンコールトレーニング②

46. 46 Playbookの例

47. 47 アラート整備

48. 48 アラートの数が多いと結局⼤変

49. 49 ⼈を増やして1⼈あたりの負担を減らせばいいじゃない

50. 50 アラートが多いならアラートを 減らす取り組みをすればいいじゃない

51. 51 • ノイズの削減 ◦ 緊急ではないアラートや冗⻑なアラートを除去し、重要なものだけが通知されるように設定 • アラートの閾値の調整 ◦ 過度なアラートを避けるために、適切なしきい値を設定 •

    対応の⾃動化 ◦ ⼿動対応の負担を軽減 ▪ ⽌⾎対応ばっかりやってるとアラートは減らない ▪ 理想は⽌⾎対応とかせずに根本対応までをアラートが出た時点でやれると良い ▪ 根本原因を把握して今後発⽣しないor発⽣しても⾃動対応の状態まで持っていく アラートを減らす取り組み

52. 52 https://speakerdeck.com/ryuichi1208/ru-men-zhang-hai-dui-ying

53. 53 まとめ

54. 54 • システムのダウンタイムを最⼩限に抑えるために、迅速な対応が求められる • オンコール体制は、システムの安定稼働を維持するための重要な⼿段 • 問題が発⽣した際に迅速に対応することで、顧客の信頼を維持し、サービス品質を向上させる • 重要なシステムやサービスの中断を最⼩限に抑えることで、ビジネスの継続性を確保できる まとめ

55. 55 ご静聴ありがとうございました

56. 56 • SRE サイトリライアビリティエンジニアリング / オライリージャパン • サイトリライアビリティワークブック / オライリージャパン

    • SREの探求 / オライリージャパン • システム運⽤アンチパターン / オライリージャパン • ⼊⾨ 監視 / オライリージャパン • 運⽤設計の教科書 / 技術評論社 • システム障害対応の教科書 / 技術評論社 • システム障害対応 実践ガイド / 翔泳社 • PagerDuty FANBOOK Vol.1 参考書籍など