入門障害対応

Transcript

1. 1 入門 障害対応 「サービス運用はTry::Catchの繰り返しだよ、ワトソン君」 渡部 龍一 / GMO PEPABO inc. 2023.03.19 YAPC::Kyoto 2023
2. 2 セッション対象 • サービスの障害対応をやっている方 • サービスの障害対応をやっていきたい方 話す事 • 障害対応の際に気をつけていること • 障害対応をできるメンバーを増やすためにやっていること
3. 3 アジェンダ 1. 自己紹介 2. 担当サービス紹介 3. 所属チーム紹介 4. 障害対応フロー 5. 障害対応能力の向上施策 6. まとめ 7. 参考
4. 4 1. 自己紹介
5. 技術部プラットフォームグループ 2021年 中途入社 5 自己紹介 渡部 龍一 Watanabe Ryuichi • 住んでるところ: 宮城(人生２回目の京都) • ロール: SRE • 趣味: 旅行、ドライブ、(緩めの)自宅サーバ • Perl歴： 3年(Sledgeを使ったウェブサービス) • YAPC歴: 初参加 • Twitter : @ryuichi_1208
6. 6 2. 担当サービス紹介
8. 8 1. インターネットでものを売りたい人を支援 2. 2005年にサービスの提供を開始 3. 総流通額1兆円以上 4. 複数のユーザーで1つのリソースを共有するマルチテナント 5. ざっくりアプリエンジニア : 30〜名、SRE: 6名
9. • カラーミーショップのインフラの歴史 • オンプレ期 • プライベートクラウド期 • k8s on プライベートクラウド期 • ハイブリッドクラウド期 • 詳しく知りたい方へ (https://speakerdeck.com/ch1aki/onpurek8stoeksnobing-xing-yun-yong-noshi-ji ) 9
10. 10 3. 所属チーム紹介
11. • 所属 • 技術部プラットフォームグループ • 役割 • ペパボのサービスの可用性を確保し、成長に合わせて適切な環境を提 供するグループ • ミッション • サーバーの調達やキッティングに止まらず、SRE によるサービスレベ ルの向上やクラウド環境の検証や選定を行い、必要に応じて事業部門 のアプリケーションの改善、開発を通して事業の成長を支える 11
12. • 主な活動 • 私の所属している技術部プラットフォームグループでは事業部を横断し てSRE活動を実施 • 詳しく知りたい方へ(https://tech.pepabo.com/pdf/pepabo-sre-202104.pdf) 12
13. 13 4. 障害対応フロー
14. 14 本セッションにおけるサービス障害と障害対応の定義 • サービス障害 ◦ 通常の運用状態から逸脱して、ユーザーに影響を与える事象のこと ▪ システムダウンやアプリケーションの異常動作 • 障害対応 ◦ 通常の運用状態へ戻すための対応
15. 1. 障害の影響範囲の特定と分類 2. 関係者への連絡 3. 障害原因調査 4. 復旧作業の実施 5. ポストモーテムの実施 15
16. 外形監視が落ちてウェブサイトに繋がらないを例に見ていく 16
17. 外形監視が落ちてウェブサイトに繋がらないを例に見ていく 17 個人的には一番好きなアラート
18. 18 • 影響範囲を特定する ◦ サービスのうちどの機能が使えないのかを特定する ◦ 外形監視が複数あればどこに影響があるかわかる ▪ 影響範囲を評価し、分類することで、問題解決に必要な情報を集める ▪ 影響範囲がわかれば原因特定への方針決定の根拠も得られる 1. 障害の影響範囲の特定と分類
19. 19 • 報告は結論ファースト ◦ 技術的な話をするのではなく、ユーザーにどのように影響があるのかを伝えること を意識する • サービスに関わっているメンバーへ連絡をする ◦ マネージャーやカスタマーサポートチームへの共有 ▪ エンドユーザーに影響が出ているのであれば障害のアナウンスをする必要が ある ◦ SREチームのみで復旧できない可能性もあるので詳しいメンバーを呼ぶ ▪ アプリケーションエンジニア ▪ セキュリティエンジニア 2. 関係者への連絡
20. 20 • なぜ繋がらないのかを調べていく ◦ 外形監視のアラートだけでは「なぜウェブサイトへ繋がらないのか」が分からない ◦ 直近でのシステムへ加えた変更を調べる ▪ デプロイした、サーバの設定を変更、管理画面操作 ▪ なにもしていないけど ... ◦ サービスを構成するコンポーネントから怪しい部分を調べていく ▪ 仮設->確認を繰り返していくフェーズ ▪ ロードバランサ、ウェブアプリ、 DB、ネットワーク、外部連携サービス • 挟み撃ち法で調査したりする • ネットワーク(L3) -> ウェブアプリ(L7) -> L4 -> L6みたいな順番で絞り込んでいく • ログ調査 3. 障害原因調査
21. 21 • 対応方法2パターン ◦ 1. 根本対応 ▪ 繋がらない原因の特定が行えた場合の対応 ◦ 2. その場しのぎの対応 ▪ 止血対応と呼んでいる ▪ 自分が持っている復旧するかもしれない対応手段を試していく ▪ 原因はわかっていなくてもつながるように優先的に対応する • OS、ミドルウェアの再起動 • 何かしらのリリースが直近であればロールバック • リソース不足になっていそうならスケールアウト対応 4. 復旧作業の実施
22. 22 • 障害対応完了後に行われる反省と改善のための分析会議 ◦ 障害が起きてしまった原因や対応時の仕方についての振り返りなどを行っている。 ▪ 今後の改善点を見つけること ◦ 失敗の原因を明確にするだけでなく、成功の要因を明らかにすることも行っている ◦ 参加していないチームや今後、参画するメンバーも学びがあるようにポストモーテ ムを書いてる ▪ なぜこのような対応したのかをドキュメントに残す ▪ アクションアイテムも issue化して後からでも追いやすくする 5. ポストモーテム
23. 23 5. 障害対応能力の向上施策
24. 24 本セッションにおける「障害対応能力」の定義 • 前述した障害対応フローのうち単独で行える範囲の広さ • 全て対応できる = 能力値MAX
25. なぜ障害対応能力の向上施策を行ったのか 25
26. 26 • 障害は完全になくすことはできないを念頭に ◦ 障害を0にするにはリリースをしない、リソースを過剰に常時置いておく • 故に障害と向き合って行く必要がある なぜ障害対応能力の向上施策を行ったのか
27. 27 • 障害が発生した際の対応が一部の優秀なエンジニアで閉じていた ◦ 原因特定、復旧までを短時間で行う • 優秀なエンジニアはいつもいるとは限らない ◦ 休暇、異動、退職 • 優秀なエンジニアがいない=障害対応に時間がかかる=サービスの信頼性 の低下につながる なぜ障害対応能力の向上施策を行ったのか
28. 28 • 障害対応能力が高いメンバーが多い=サービスの信頼性の向上に繋がる • 障害対応能力が高いメンバーを増やすためには ◦ 教科書的に学んで実践するのは難しい ◦ 本番環境での障害で経験を積むのはサービス品質の観点的にも難しい ◦ 障害対応能力を高めるための施策を行うことでそのような課題の解決へアプローチした なぜ障害対応能力の向上施策を行ったのか
29. 実際に行った施策 29
30. 1. Playbookの作成 2. 障害対応訓練の実施 30
31. 31 Playbookの作成 • Playbookとは ◦ アメリカンフットボールの戦略集 ◦ 一定の知識や経験を持った人でなければ理解できない熟練者向けのドキュメント • 障害対応能力が高いメンバーの作業内容と思考をドキュメント化 ◦ 障害対応中は仮設を立てて調査コマンドを打ったりメトリクスを見たりを繰り返す ◦ そのように至った思考の部分がドキュメントとして残すことで他メンバーの障害対応 能力向上へ繋がる
32. 32 Playbookの作成 • 耐障害に特化したドキュメントを作成 ◦ ポストモーテムには以下の内容が書かれていた ▪ 障害発生日時 ▪ サービスの影響度 ▪ 根本原因 ▪ アクションアイテム ▪ 発生復旧までのタイムライン ◦ 具体的な対応方法については記載されていなかった ▪ 障害原因調査の際に見たメトリクスや打ったコマンド ▪ メトリクスがどうなっていたのか ▪ そのメトリクスから何がわかるのか
33. 33 Playbookの例
34. 34 障害対応訓練の実施 • 実践は必要 ◦ ポストモーテムドキュメントもPlaybookも読むだけになりがち ◦ 目的は障害対応をできるメンバーを増やすこと ▪ 実際にメンバーの障害対応能力が向上したのかを評価する必要がある ◦ 実践することができているか分からない状態で本番環境の障害対応に望むとうまく いくかは分からない ▪ 障害対応に時間がかかる =サービスの信頼性の低下につながる
35. 35 障害対応訓練の実施 • 障害対応経験が少ないメンバー向けに訓練を定期的に実施 ◦ 過去の障害と同じ状況をステージングやテスト環境で再現させる ▪ 再現が難しい障害は発生したと仮定して訓練を行う ◦ 出題者と回答者に分かれて障害対応をしていく ▪ 出題者が発生している障害の概要を伝え回答者は復旧のための操作を行っていく ▪ Table Tep Exerciseのようなイメージ
36. 36 6. 施策の効果
37. 37 施策の効果 • 全体の障害対応能力の向上へ繋げることができた ◦ 新規のメンバーが障害対応に参加できる機会が増えた ▪ 復旧まで単独で実施できるレベルのメンバーも増えた ▪ (トレーニングして数時間後にその内容が発生するということもあった ...) ◦ 既存のメンバーもシナリオを考える際の学びが多かった ◦ 特定のコンポーネントが落ちた際の影響範囲は？ ◦ 自分のこれまでのやり方とは違う方法を学ぶことができた
38. 38 7. まとめ
39. 39 まとめ • 障害を完全になくすことはできない ◦ 障害対応と向き合う必要がある ▪ 優秀なメンバーだけが対応している状況は危険 ▪ 対応できるメンバー数を可視化してしいく ◦ 障害対応できるメンバーを増やすために行っている施策 ▪ Playbook、障害訓練 ▪ ローマは一日にしてならず、障害対応も一日にしてならず • Playbookも障害対応訓練を継続的に行っていく必要がある
40. 40 8. 参考
41. • Web • ポストモーテム vs. レトロスペクティブ：それぞれをいつ（そしてどのよう に）効果的に使用するか • 書籍 • システム障害対応の教科書 • SRE サイトリライアビリティエンジニアリング • サイトリライアビリティワークブック • SREの探求 • システム運用アンチパターン • チームトポロジー
 41
42. 42 ご清聴ありがとうございました