Slide 1
Slide 1 text
1
⼊⾨ オンコール対応
~ 深夜対応後のラーメンが最⾼編 ~
渡部 ⿓⼀
TechRAMEN 2024 Conference
Slide 2
Slide 2 text
2
アジェンダ
1. 自己紹介
2. イントロダクション
3. オンコール対応とは
4. オンコール対応の具体的な事例紹介
5. まとめ
Slide 3
Slide 3 text
3
⾃⼰紹介
Slide 4
Slide 4 text
技術部プラットフォームグループ
2021年 中途入社
4
自己紹介
渡部 龍一 Watanabe Ryuichi
● ロール: SRE
● 仙台から来ました。北海道は2ヶ月ぶり2回目
● SNS: @ryuichi_1208
● 好きなこと: 障害対応、EOL対応
● 好きなラーメン: 仙台っ子ラーメン(豚骨醤油)
Slide 5
Slide 5 text
5
Slide 6
Slide 6 text
6
イントロダクション
Slide 7
Slide 7 text
7
イントロダクション
“オンコール対応やってますか？”
Slide 8
Slide 8 text
8
イントロダクション
“⼤変じゃないですか？”
Slide 9
Slide 9 text
9
日中帯の割り込み 休日・夜間対応
Slide 10
Slide 10 text
10
どうにかしたい！
Slide 11
Slide 11 text
11
https://atmarkit.itmedia.co.jp/ait/articles/2207/26/news017.html
Slide 12
Slide 12 text
12
あれから2年後...
Slide 13
Slide 13 text
13
話すこと
● オンコール対応の基本
● オンコール対応を円滑に進めるための具体的な手法
セッション対象
● システム運用をやってる方、その働き方に興味がある方
● オンコール対応に初めて携わる方
● オンコール対応を効率化したいと考えている人
Slide 14
Slide 14 text
14
オンコールの世界へDive!
Slide 15
Slide 15 text
15
オンコール対応とは
Slide 16
Slide 16 text
16
● システム運⽤やITサポートにおいて、緊急のインシデントや問題が発⽣した際に即座
に対応するために、特定の時間帯やシフトで待機している体制のことを指す
● 元々医療分野からきている⾔葉で医師や看護師が24時間体制で患者の緊急事態に対応
するために待機している状態を意味する
オンコールとは
Slide 17
Slide 17 text
17
● アラートの受信と確認
○ Webページに繋がらない、閾値以上の時間がかかっている
● インシデントの分類と優先順位付け
● 初期(⼀次)対応
○ 重⼤なインシデントの場合は即エスカレーションするケースも
● 詳細なトラブルシューティング
● 対応できない場合は開発の担当者などへエスカレーション
○ エンジニア以外にも告知を出す担当者や事業の責任者などへも共有
オンコール対応では何をやるのか？
Slide 18
Slide 18 text
18
なぜオンコールは必要なのか？
Slide 19
Slide 19 text
19
オンコールがないシステム
Slide 20
Slide 20 text
20
サーバダウン！！
Slide 21
Slide 21 text
21
● 平⽇⽇中にサーバが落ちたら
○ そのタイミングで対応する
● 平⽇夜間にサーバが落ちたら
○ 翌⽇の営業⽇に対応する
● 連休中にサーバが落ちたら
○ 翌営業⽇に対応する
サーバが落ちてサービスが繋がらない状態
Slide 22
Slide 22 text
22
⻑期休暇中だったらどうなる？
Slide 23
Slide 23 text
23
1週間サービス使えません！
Slide 24
Slide 24 text
24
● クレームの電話がなり続ける
● サービスから離れていってしまう
● SLAがある場合は利⽤料の返⾦対応などが必要となる場合も
サーバが落ちてサービスが繋がらない状態
Slide 25
Slide 25 text
25
SLA99%以上なら即対応が必須
Slide 26
Slide 26 text
26
● システムの安定稼働
○ システムのダウンタイムを最⼩限に抑えるために、迅速な対応が求められる
○ オンコール体制は、システムの安定稼働を維持するための重要な⼿段
● 顧客満⾜度の向上
○ 問題が発⽣した際に迅速に対応することで、顧客の信頼を維持し、サービス品質を向上させ
ることができる
● ビジネス継続性の確保
○ 重要なシステムやサービスの中断を最⼩限に抑えることで、ビジネスの継続性を確保できる
オンコールの⽬的
Slide 27
Slide 27 text
27
オンコール体制を整備！
Slide 28
Slide 28 text
28
絶対必要？
Slide 29
Slide 29 text
29
● 個⼈開発であればそこまで⾼い可⽤性は求めない
● サービスの特性上⽇中帯以外は全く使われない
○ 利⽤者から年中無休の可⽤性が期待されるサービスじゃないケースがある
● ⼈員がいないためサービスが落ちているのを許容する
オンコールをするかはサービスの特性による
Slide 30
Slide 30 text
30
具体的な事例紹介
Slide 31
Slide 31 text
31
● オンコールに関するシステム構成
● オンコール体制の話
● オンコール当番になった際にやっていること
● オンコールトレーニング
具体的な事例で話すこと
Slide 32
Slide 32 text
32
オンコールに関するシステム構成
Slide 33
Slide 33 text
33
システム構成
Slide 34
Slide 34 text
34
オンコール体制の話
Slide 35
Slide 35 text
35
24時間戦えますか？
Slide 36
Slide 36 text
36
ほぼNo(⼀部例外あり)
Slide 37
Slide 37 text
37
● サービスに詳しい⼈が24時間365⽇対応できれば気にすることは特にない
● それは現実的ではないので複数のメンバーで当番制にする必要がある
○ 平⽇は始業時間〜翌⽇の始業時間
● 全メンバーが同⼀の技術スタックに精通していれば誰がいつやっても良い
● それも現実的ではないので⼯夫してシフトを組む必要がある
オンコール体制
Slide 38
Slide 38 text
38
● オンコールは⼀般的にメインで担当するメンバー + それ以外のメンバーというシフト
● PagerDutyにもエスカレーションポリシーという機能がある
● サービスに詳しいメンバーと新メンバーで交互にエスカレーションをする
オンコール体制の⼯夫: エスカレーションポリシー
Slide 39
Slide 39 text
39
● スキルマップシート
○ 誰がどの分野に詳しいかをスキルマップとして運⽤をしてみた
○ 有効活⽤したいが...
■ アップデートされなかったりして活⽤はできていない
■ 興味がある分野を知るきっかけにはなった
オンコール体制の⼯夫: エスカレーションポリシー
Slide 40
Slide 40 text
40
オンコール当番になった際に
やっていること
Slide 41
Slide 41 text
41
● オンコール当番でも1⽇中すぐに対応できるようにしておくということはない
● 出かける際にPCを持っていくやスマートフォンの通知を切らない
● ⼤きめのリリース当⽇とかで待機を会社から指⽰されることは過去にはあった
○ この場合は待機⼿当をもらった
○ 法律的にはオンコール待機は業務時間にはならないので普段のオンコールでは該当しない
オンコール当番になった際にやっていること① 待機
Slide 42
Slide 42 text
42
● アラートの⼀次受け、⾃分で解決できる場合
○ ⼿動オペレーションで正常な状態へ戻す
○ 根本対応まで実装
■ 設計/実装不備、チューニング不⾜はPull Requestの作成までやって翌営業⽇でリリース
● ⼀次受けした後に⾃分で解決できない場合は詳しい⼈にエスカレーション
○ どのくらいの時間調べてわからなければエスカレーションするかを事前に決めておく
■ サービスの信頼性に直結する部分なので重要！
オンコール当番になった際にやっていること② 対応
Slide 43
Slide 43 text
43
オンコールトレーニング
Slide 44
Slide 44 text
44
● 配属や⼊社して即オンコールシフトは技術的にもメンタル的にも難しい
● 誤った対応による⼆次障害、調査に時間がかかりすぎることによるMTTRの悪化
● オンコールで対応すべき内容は通常業務だけだと⾝につきづらい内容も多くある
○ 「サービスが⾼負荷になった」、「データベースが落ちた」際の対応は通常業務では取り扱
うことあまりない
オンコールトレーニング① 課題
Slide 45
Slide 45 text
45
● シナリオベースの訓練の実施
○ 過去のオンコールで発⽣した対応をモブオペ形式で再現して対応を確認する
○ さまざまなシナリオを想定して対応を練習することで、実際のインシデントに対する対応⼒
を強化する のが狙い
● Playbook(Runbook)の整備
○ システム運⽤や管理において発⽣する作業や⼿順を⽂書化したもの
○ 特定のインシデントやタスクを迅速かつ効率的に処理するためのガイドライン
○ アラート -> 対応を⾃動化しにくいものはドキュメントとして⽤意している
オンコールトレーニング②
Slide 46
Slide 46 text
46
Playbookの例
Slide 47
Slide 47 text
47
アラート整備
Slide 48
Slide 48 text
48
アラートの数が多いと結局⼤変
Slide 49
Slide 49 text
49
⼈を増やして1⼈あたりの負担を減らせばいいじゃない
Slide 50
Slide 50 text
50
アラートが多いならアラートを
減らす取り組みをすればいいじゃない
Slide 51
Slide 51 text
51
● ノイズの削減
○ 緊急ではないアラートや冗⻑なアラートを除去し、重要なものだけが通知されるように設定
● アラートの閾値の調整
○ 過度なアラートを避けるために、適切なしきい値を設定
● 対応の⾃動化
○ ⼿動対応の負担を軽減
■ ⽌⾎対応ばっかりやってるとアラートは減らない
■ 理想は⽌⾎対応とかせずに根本対応までをアラートが出た時点でやれると良い
■ 根本原因を把握して今後発⽣しないor発⽣しても⾃動対応の状態まで持っていく
アラートを減らす取り組み
Slide 52
Slide 52 text
52
https://speakerdeck.com/ryuichi1208/ru-men-zhang-hai-dui-ying
Slide 53
Slide 53 text
53
まとめ
Slide 54
Slide 54 text
54
● システムのダウンタイムを最⼩限に抑えるために、迅速な対応が求められる
● オンコール体制は、システムの安定稼働を維持するための重要な⼿段
● 問題が発⽣した際に迅速に対応することで、顧客の信頼を維持し、サービス品質を向上させる
● 重要なシステムやサービスの中断を最⼩限に抑えることで、ビジネスの継続性を確保できる
まとめ
Slide 55
Slide 55 text
55
ご静聴ありがとうございました
Slide 56
Slide 56 text
56
● SRE サイトリライアビリティエンジニアリング / オライリージャパン
● サイトリライアビリティワークブック / オライリージャパン
● SREの探求 / オライリージャパン
● システム運⽤アンチパターン / オライリージャパン
● ⼊⾨ 監視 / オライリージャパン
● 運⽤設計の教科書 / 技術評論社
● システム障害対応の教科書 / 技術評論社
● システム障害対応 実践ガイド / 翔泳社
● PagerDuty FANBOOK Vol.1
参考書籍など