Slide 1
Slide 1 text
1
効果的なオンコール対応と障害対応
改善と最適化への戦略
渡部 ⿓⼀
IT 運⽤管理セミナー 2024 夏
2024/9/3
Slide 2
Slide 2 text
2
Slide 3
Slide 3 text
3
セッション対象
● オンコール対応/障害対応をやっている方
● オンコール対応/障害対応に課題を感じている方
Slide 4
Slide 4 text
4
アジェンダ
1. ⾃⼰紹介、サービスの紹介
2. イントロダクション
3. オンコール対応の現状と改善策
4. 障害対応
5. (コラム) 障害対応を楽しむコツ
6. 統合的アプローチと最適化のための提案
7. まとめ
Slide 5
Slide 5 text
5
⾃⼰紹介
Slide 6
Slide 6 text
技術部プラットフォームグループ
2021年 中途入社
6
自己紹介
渡部 龍一 Watanabe Ryuichi
● ロール: SRE
● SNS: @ryuichi_1208
● 仙台市在住
● 好きなこと: 障害対応、EOL対応
Slide 7
Slide 7 text
7
サービス紹介
Slide 8
Slide 8 text
ペパボは、主に個⼈の表現活動を⽀援するためのさまざまなウェブサービスおよびスマートフォンアプ
リを提供しています。それぞれのサービスは、以下のようにセグメント分けされています。
8
ホスティング
事業
EC支援
事業
ハンドメイド
事業
金融支援
事業
Slide 9
Slide 9 text
9
● 国内最⼤級のECサイト作成サービス
○ 無料で始められる
○ 流通規模が⼤きくても使える
● 2005年にサービス開始
○ 現在のショップ数は約4万店舗
○ 現在の流通総額は約2000億円
カラーミーショップ
Slide 10
Slide 10 text
10
● B2B2C & Developer
● ホスティングサービス
● マルチテナントアーキテクチャ
カラーミーショップの特徴
Slide 11
Slide 11 text
11
イントロダクション
Slide 12
Slide 12 text
12
“オンコール対応やってますか？”
Slide 13
Slide 13 text
13
“⼤変じゃないですか？”
Slide 14
Slide 14 text
14
日中帯の割り込み 休日・夜間対応
Slide 15
Slide 15 text
15
“重⼤な障害だったら？”
Slide 16
Slide 16 text
16
数日単位で対応 夜通しで対応
Slide 17
Slide 17 text
17
“なんとかしたい！”
Slide 18
Slide 18 text
18
オンコール対応の現状と改善策
Slide 19
Slide 19 text
19
● システム運⽤やITサポートにおいて、緊急のインシデントや問題が発⽣した際に即座
に対応するために、特定の時間帯やシフトで待機している体制のことを指す
● 元々医療分野からきている⾔葉で医師や看護師が24時間体制で患者の緊急事態に対応
するために待機している状態を意味する
オンコールとは
Slide 20
Slide 20 text
20
● アラートの受信と確認
○ Webページに繋がらない、閾値以上の時間がかかっている
● インシデントの分類と優先順位付け
● 初期(⼀次)対応
○ 重⼤なインシデントの場合は即エスカレーションするケースも
● 詳細なトラブルシューティング
● 対応できない場合は開発の担当者などへエスカレーション
○ エンジニア以外にも告知を出す担当者や事業の責任者などへも共有
オンコール対応では何をやるのか？
Slide 21
Slide 21 text
21
● サービスに詳しい⼈が24時間365⽇対応できれば気にすることは特にない
● それは現実的ではないので複数のメンバーで当番制にする必要がある
○ 平⽇は始業時間〜翌⽇の始業時間
● 全メンバーが同⼀の技術スタックに精通していれば誰がいつやっても良い
● それも現実的ではないので⼯夫してシフトを組む必要がある
オンコール体制の課題
Slide 22
Slide 22 text
22
● オンコールは⼀般的にメインで担当するメンバー + それ以外のメンバーというシフト
● PagerDutyにもエスカレーションポリシーという機能がある
● サービスに詳しいメンバーと新メンバーで交互にエスカレーションをする
オンコール体制の⼯夫: エスカレーションポリシー
Slide 23
Slide 23 text
23
● 配属や⼊社して即オンコールシフトは技術的にもメンタル的にも難しい
● 誤った対応による⼆次障害、調査に時間がかかりすぎることによるMTTRの悪化
● オンコールで対応すべき内容は通常業務だけだと⾝につきづらい内容も多くある
○ 「サービスが⾼負荷になった」、「データベースが落ちた」際の対応は通常業務では取り扱
うことあまりない
オンコールトレーニング① 課題
Slide 24
Slide 24 text
24
● シナリオベースの訓練の実施
○ 過去のオンコールで発⽣した対応をモブオペ形式で再現して対応を確認する
○ さまざまなシナリオを想定して対応を練習することで、実際のインシデントに対する対応⼒
を強化する のが狙い
オンコールトレーニング②
Slide 25
Slide 25 text
25
● Playbook(Runbook)の整備
○ システム運⽤や管理において発⽣する作業や⼿順を⽂書化したもの
○ 特定のインシデントやタスクを迅速かつ効率的に処理するためのガイドライン
○ 復旧までの対応を⾃動化しにくいものに絞って作成していく
Playbookの整備
Slide 26
Slide 26 text
26
Playbookの例
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
● ノイズの削減
○ 緊急ではないアラートや冗⻑なアラートを除去し、重要なものだけが通知されるように設定
● アラートの閾値の調整
○ 過度なアラートを避けるために、適切なしきい値を設定
● 対応の⾃動化
○ ワークアラウンドの対応ばかりやってるとアラートは減らない
○ 理想は⽌⾎対応とかせずに根本対応までをアラートが出た時点でやれると良い
○ 根本原因を把握して今後発⽣しない or 発⽣しても⾃動対応の状態まで持っていく
アラートを減らす取り組み
Slide 34
Slide 34 text
34
● オンコール対応のシフトに⼊るためにやっている施策としてトレーニングがある
● アラートを減らすための活動も重要
オンコール対応のまとめ
Slide 35
Slide 35 text
35
障害対応
Slide 36
Slide 36 text
36
障害対応とは？
Slide 37
Slide 37 text
37
● 運⽤中のシステムに継続できない障害が発⽣した際に、復旧させるための作業
● Webシステムにおける障害対応は、システムの信頼性を維持し、ビジネスの
継続性を確保するために不可⽋な活動
障害対応とは
Slide 38
Slide 38 text
38
● ビジネス継続性の確保
● ビジネスの競争優位性の確保
● 顧客満⾜度の維持
● ブランドイメージの保護
● 法的‧規制要件の遵守
障害対応は何故必要なのか？
Slide 39
Slide 39 text
39
ビジネスにおいて障害対応は重要！
Slide 40
Slide 40 text
40
障害発⽣を0にするために頑張ろう！
Slide 41
Slide 41 text
41
● 全く⼿を⼊れないサービスでCDNとかで静的なコンテンツだけを返すみたいな
Webサービスなら可能かもしれない？
● とはいえそんなサービスで利益を得続けるのは現実的ではない
● サービスをローンチしても競合他社がすぐに現れてくる時代
● サービスも進化させなければ留まることすらできずに緩やかに後退する
● 継続して新機能の開発は必要だしよりよいプロダクトを作り続ける必要が出てく
る
障害0は可能なのか？
Slide 42
Slide 42 text
42
● 動いているものに⼿を加える必要が出てくる
● 開発環境やステージング環境でプロダクション環境と同等のテスト、シミュレー
ションができれば障害は起きないかもしれない？
● 実ユーザーやインフラの規模など完璧にシミューレートするのは困難
○ スロークライアント
○ 今はサポートしてないようなクライアント、プロトコル
○ 想定してないリクエストが数倍やってくる
障害0は可能なのか？
Slide 43
Slide 43 text
43
障害発⽣を0にするのは難しそう
Slide 44
Slide 44 text
44
● ビジネス継続性の確保
● ビジネスの競争優位性の確保
● 顧客満⾜度の維持
● ブランドイメージの保護
● 法的‧規制要件の遵守
障害対応は何故必要なのか？(再掲)
Slide 45
Slide 45 text
45
実際の障害対応の流れや⼯夫
Slide 46
Slide 46 text
46
障害検知 関係者連絡
影響範囲調査 原因調査 復旧作業
Slide 47
Slide 47 text
47
Slide 48
Slide 48 text
48
● 外形監視によるHTTPリクエストのエラー
● ユーザー問い合わせによる検知
障害検知
Slide 49
Slide 49 text
49
● 影響範囲を特定する
○ サービスのうちどの機能が使えないのかを特定する
○ 外形監視が複数あればどこに影響があるかわかる
■ 影響範囲を評価し、分類することで、問題解決に必要な情報を集める
■ 影響範囲がわかれば原因特定への方針決定の根拠も得られる
障害の影響範囲の特定と分類
Slide 50
Slide 50 text
50
● サービスに関わっているメンバーへ連絡をする
○ マネージャーやカスタマーサポートチームへの共有
○ SREチームのみで復旧できない可能性もあるので詳しいメンバーを呼ぶ
● 報告は結論ファースト
○ 技術的な話をするのではなく、ユーザーにどのように影響があるのかを伝えることを意識す
る
関係者への連絡
Slide 51
Slide 51 text
51
● なぜ繋がらないのかを調べていく
○ 外形監視のアラートだけでは「なぜウェブサイトへ繋がらないのか」が分からない
○ 直近でのシステムへ加えた変更を調べる
■ デプロイした、サーバーの設定を変更、管理画面操作
■ なにもしていないけど ...
○ サービスを構成するコンポーネントから怪しい部分を調べていく
■ 仮設->確認を繰り返していくフェーズ
■ ロードバランサ、ウェブアプリ、 DB、ネットワーク、外部連携サービス
障害原因調査
Slide 52
Slide 52 text
52
● 根本対応
○ 繋がらない原因の特定が行えた場合の対応
○ 再発しないよう状態までコード修正や設定の修正までを行う
● ワークアラウンド対応
○ 止血対応と呼んでいる
○ 自分が持っている復旧するかもしれない対応手段を試していく
○ 原因はわかっていなくてもつながるように優先的に対応する (再起動、ロールバック )
復旧作業の実施
Slide 53
Slide 53 text
No content
Slide 54
Slide 54 text
54
(コラム) 障害対応を楽しむコツ
Slide 55
Slide 55 text
55
● 障害対応中は緊張状態だったりでパフォーマンスを発揮しにくい
○ 怖い、緊張する、やりたくない
● 長時間続くことで燃え尽き症候群
障害対応を楽しむコツ
Slide 56
Slide 56 text
56
● 障害発⽣時を⾒越してツールを整備しておく
● 特定技術における得意分野を作っておく
● プロダクションでやりたいことを考えておく
● ゲーム感覚で楽しんでみる
● インシデントコマンダーになってみる
障害対応を楽しむコツ
Slide 57
Slide 57 text
57
https://speakerdeck.com/ryuichi1208/zhang-hai-dui-ying-wole-simu7tunokotu
Slide 58
Slide 58 text
58
統合的アプローチと最適化のための提案
Slide 59
Slide 59 text
59
オンコール体制を整え
障害対応ができれば終わり？
Slide 60
Slide 60 text
60
日中帯の割り込み 休日・夜間対応
Slide 61
Slide 61 text
61
システムは変わっていく
Slide 62
Slide 62 text
62
対応の前後でもできることがある
Slide 63
Slide 63 text
63
振り返り
対応
準備
63
Slide 64
Slide 64 text
64
● 全体の信頼性強化
● 障害発生時のルールの制定
● SLI/SLOの導入と継続的改善
● インシデント後の振り返り
統合的な改善へのアプローチ案
Slide 65
Slide 65 text
65
振り返り
対応
準備
65
Slide 66
Slide 66 text
66
● 信頼性
○ ⼀定の条件下においてシステムが正常に稼働し、サービスを安定的に提供しつづけられるか
● 障害が発⽣してもサービスを継続できるシステムを構成する
○ マルチリージョン‧マルチゾーン構成
○ フェイルオーバー
○ セルフヒーリング
○ オートスケール
全体の信頼性強化
Slide 67
Slide 67 text
67
● 障害を前提としてシステム設計
○ 単⼀障害点（Single Point of Failure, SPOF）の排除
○ フォールトトレラント設計
全体の信頼性強化
サーバーに直接アクセス LBを通してアクセス
Slide 68
Slide 68 text
68
● 障害対応のルールを明確にすることで、対応が⼀貫性を持ち、効率的かつ迅速に⾏わ
れるようになることを狙い
○ 初動対応のフロー
○ エスカレーションポリシー
○ 障害レベルの分類⽅法(SEV)
○ 復旧後のプロセス
障害発⽣時のルールの制定
Slide 69
Slide 69 text
69
● 全ての障害を最⼤の優先度で対応すると開発タスクが進まなくなってしまう
● サービス特性次第ではある程度の障害は許容できるケースがある
● 許容できる度合いを全体で定量化して合意を得ておくことで回避できる
SLI/SLOの導⼊と継続的改善
Slide 70
Slide 70 text
70
● SLI/SLOの導⼊により、オンコールや障害対応の⽬標を定量化し、改善の基準を
明確にする
○ SLI = サービスレベル指標
■ 例) リクエスト成功率、レスポンス時間、エラーレート
○ SLO = サービスレベル⽬標
■ 例) 「リクエスト成功率99.9%」や「平均レスポンス時間500ms以下」
○ 定期的にSLOを⾒直し、パフォーマンスを最適化するためのアプローチを導⼊
SLI/SLOの導⼊と継続的改善
Slide 71
Slide 71 text
71
https://speakerdeck.com/ryuichi1208/slo-docsnosu-me
Slide 72
Slide 72 text
72
振り返り
対応
準備
72
Slide 73
Slide 73 text
73
● 障害対応完了後に行われる反省と改善のための分析会議
○ 障害が起きてしまった原因や対応時の仕方についての振り返りなどを行う
○ 障害が発生した際の時系列にそって何が起きたかを詳細に記載しておく
○ 失敗の原因を明確にするだけでなく、成功の要因を明らかにすることも行う
○ 参加していないチームや今後、参画するメンバーも学びがあるように
ドキュメントは詳細に記載する
ポストモーテム
Slide 74
Slide 74 text
74
Slide 75
Slide 75 text
https://sre-magazine.net/articles/3/ryuichi_1208/
Slide 76
Slide 76 text
76
まとめ
Slide 77
Slide 77 text
77
● オンコール対応/障害対応はサービスの運⽤において重要
● ⼀⽅で発⽣したものに対して対応だけしていると本来やりたいことが進まない
● 通常業務と対応のバランスを取るのが重要
● 発⽣数を0にすることも困難なのでうまく付き合っていく必要がある分野
まとめ
Slide 78
Slide 78 text
78
参考
Slide 79
Slide 79 text
79
● SRE サイトリライアビリティエンジニアリング / オライリージャパン
● サイトリライアビリティワークブック / オライリージャパン
● SREの探求 / オライリージャパン
● システム運⽤アンチパターン / オライリージャパン
● ⼊⾨ 監視 / オライリージャパン
● ウェブオペレーション / オライリージャパン
● 運⽤設計の教科書 / 技術評論社
● システム障害対応の教科書 / 技術評論社
● システム障害対応 実践ガイド / 翔泳社
● PagerDuty FANBOOK Vol.1
参考書籍など
Slide 80
Slide 80 text
80
ご静聴ありがとうございました