効果的なオンコール対応と障害対応

Transcript

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