Upgrade to Pro — share decks privately, control downloads, hide ads and more …

入門障害対応

ryuichi1208
March 19, 2023
3.5k

 入門障害対応

ryuichi1208

March 19, 2023
Tweet

Transcript

  1. 1
    入門 障害対応
    「サービス運用はTry::Catchの繰り返しだよ、ワトソン君」
    渡部 龍一 / GMO PEPABO inc.
    2023.03.19 YAPC::Kyoto 2023

    View full-size slide

  2. 2
    セッション対象
    ● サービスの障害対応をやっている方
    ● サービスの障害対応をやっていきたい方
    話す事
    ● 障害対応の際に気をつけていること
    ● 障害対応をできるメンバーを増やすためにやっていること

    View full-size slide

  3. 3
    アジェンダ
    1. 自己紹介
    2. 担当サービス紹介
    3. 所属チーム紹介
    4. 障害対応フロー
    5. 障害対応能力の向上施策
    6. まとめ
    7. 参考

    View full-size slide

  4. 4
    1. 自己紹介

    View full-size slide

  5. 技術部プラットフォームグループ
    2021年 中途入社
    5
    自己紹介
    渡部 龍一 Watanabe Ryuichi
    ● 住んでるところ: 宮城(人生2回目の京都)
    ● ロール: SRE
    ● 趣味: 旅行、ドライブ、(緩めの)自宅サーバ
    ● Perl歴: 3年(Sledgeを使ったウェブサービス)
    ● YAPC歴: 初参加
    ● Twitter : @ryuichi_1208

    View full-size slide

  6. 6
    2. 担当サービス紹介

    View full-size slide

  7. 8
    1. インターネットでものを売りたい人を支援
    2. 2005年にサービスの提供を開始
    3. 総流通額1兆円以上
    4. 複数のユーザーで1つのリソースを共有するマルチテナント
    5. ざっくりアプリエンジニア : 30〜名、SRE: 6名

    View full-size slide

  8. ● カラーミーショップのインフラの歴史
    ● オンプレ期
    ● プライベートクラウド期
    ● k8s on プライベートクラウド期
    ● ハイブリッドクラウド期
    ● 詳しく知りたい方へ (https://speakerdeck.com/ch1aki/onpurek8stoeksnobing-xing-yun-yong-noshi-ji
    )
    9

    View full-size slide

  9. 10
    3. 所属チーム紹介

    View full-size slide

  10. ● 所属
    ● 技術部プラットフォームグループ
    ● 役割
    ● ペパボのサービスの可用性を確保し、成長に合わせて適切な環境を提
    供するグループ
    ● ミッション
    ● サーバーの調達やキッティングに止まらず、SRE によるサービスレベ
    ルの向上やクラウド環境の検証や選定を行い、必要に応じて事業部門
    のアプリケーションの改善、開発を通して事業の成長を支える
    11

    View full-size slide

  11. ● 主な活動
    ● 私の所属している技術部プラットフォームグループでは事業部を横断し
    てSRE活動を実施
    ● 詳しく知りたい方へ(https://tech.pepabo.com/pdf/pepabo-sre-202104.pdf)
    12

    View full-size slide

  12. 13
    4. 障害対応フロー

    View full-size slide

  13. 14
    本セッションにおけるサービス障害と障害対応の定義
    ● サービス障害
    ○ 通常の運用状態から逸脱して、ユーザーに影響を与える事象のこと
    ■ システムダウンやアプリケーションの異常動作
    ● 障害対応
    ○ 通常の運用状態へ戻すための対応

    View full-size slide

  14. 1. 障害の影響範囲の特定と分類
    2. 関係者への連絡
    3. 障害原因調査
    4. 復旧作業の実施
    5. ポストモーテムの実施
    15

    View full-size slide

  15. 外形監視が落ちてウェブサイトに繋がらないを例に見ていく
    16

    View full-size slide

  16. 外形監視が落ちてウェブサイトに繋がらないを例に見ていく
    17
    個人的には一番好きなアラート

    View full-size slide

  17. 18
    ● 影響範囲を特定する
    ○ サービスのうちどの機能が使えないのかを特定する
    ○ 外形監視が複数あればどこに影響があるかわかる
    ■ 影響範囲を評価し、分類することで、問題解決に必要な情報を集める
    ■ 影響範囲がわかれば原因特定への方針決定の根拠も得られる
    1. 障害の影響範囲の特定と分類

    View full-size slide

  18. 19
    ● 報告は結論ファースト
    ○ 技術的な話をするのではなく、ユーザーにどのように影響があるのかを伝えること
    を意識する
    ● サービスに関わっているメンバーへ連絡をする
    ○ マネージャーやカスタマーサポートチームへの共有
    ■ エンドユーザーに影響が出ているのであれば障害のアナウンスをする必要が
    ある
    ○ SREチームのみで復旧できない可能性もあるので詳しいメンバーを呼ぶ
    ■ アプリケーションエンジニア
    ■ セキュリティエンジニア
    2. 関係者への連絡

    View full-size slide

  19. 20
    ● なぜ繋がらないのかを調べていく
    ○ 外形監視のアラートだけでは「なぜウェブサイトへ繋がらないのか」が分からない
    ○ 直近でのシステムへ加えた変更を調べる
    ■ デプロイした、サーバの設定を変更、管理画面操作
    ■ なにもしていないけど ...
    ○ サービスを構成するコンポーネントから怪しい部分を調べていく
    ■ 仮設->確認を繰り返していくフェーズ
    ■ ロードバランサ、ウェブアプリ、 DB、ネットワーク、外部連携サービス
    ● 挟み撃ち法で調査したりする
    ● ネットワーク(L3) -> ウェブアプリ(L7) -> L4 -> L6みたいな順番で絞り込んでいく
    ● ログ調査
    3. 障害原因調査

    View full-size slide

  20. 21
    ● 対応方法2パターン
    ○ 1. 根本対応
    ■ 繋がらない原因の特定が行えた場合の対応
    ○ 2. その場しのぎの対応
    ■ 止血対応と呼んでいる
    ■ 自分が持っている復旧するかもしれない対応手段を試していく
    ■ 原因はわかっていなくてもつながるように優先的に対応する
    ● OS、ミドルウェアの再起動
    ● 何かしらのリリースが直近であればロールバック
    ● リソース不足になっていそうならスケールアウト対応
    4. 復旧作業の実施

    View full-size slide

  21. 22
    ● 障害対応完了後に行われる反省と改善のための分析会議
    ○ 障害が起きてしまった原因や対応時の仕方についての振り返りなどを行っている。
    ■ 今後の改善点を見つけること
    ○ 失敗の原因を明確にするだけでなく、成功の要因を明らかにすることも行っている
    ○ 参加していないチームや今後、参画するメンバーも学びがあるようにポストモーテ
    ムを書いてる
    ■ なぜこのような対応したのかをドキュメントに残す
    ■ アクションアイテムも issue化して後からでも追いやすくする
    5. ポストモーテム

    View full-size slide

  22. 23
    5. 障害対応能力の向上施策

    View full-size slide

  23. 24
    本セッションにおける「障害対応能力」の定義
    ● 前述した障害対応フローのうち単独で行える範囲の広さ
    ● 全て対応できる = 能力値MAX

    View full-size slide

  24. なぜ障害対応能力の向上施策を行ったのか
    25

    View full-size slide

  25. 26
    ● 障害は完全になくすことはできないを念頭に
    ○ 障害を0にするにはリリースをしない、リソースを過剰に常時置いておく
    ● 故に障害と向き合って行く必要がある
    なぜ障害対応能力の向上施策を行ったのか

    View full-size slide

  26. 27
    ● 障害が発生した際の対応が一部の優秀なエンジニアで閉じていた
    ○ 原因特定、復旧までを短時間で行う
    ● 優秀なエンジニアはいつもいるとは限らない
    ○ 休暇、異動、退職
    ● 優秀なエンジニアがいない=障害対応に時間がかかる=サービスの信頼性
    の低下につながる
    なぜ障害対応能力の向上施策を行ったのか

    View full-size slide

  27. 28
    ● 障害対応能力が高いメンバーが多い=サービスの信頼性の向上に繋がる
    ● 障害対応能力が高いメンバーを増やすためには
    ○ 教科書的に学んで実践するのは難しい
    ○ 本番環境での障害で経験を積むのはサービス品質の観点的にも難しい
    ○ 障害対応能力を高めるための施策を行うことでそのような課題の解決へアプローチした
    なぜ障害対応能力の向上施策を行ったのか

    View full-size slide

  28. 実際に行った施策
    29

    View full-size slide

  29. 1. Playbookの作成
    2. 障害対応訓練の実施
    30

    View full-size slide

  30. 31
    Playbookの作成
    ● Playbookとは
    ○ アメリカンフットボールの戦略集
    ○ 一定の知識や経験を持った人でなければ理解できない熟練者向けのドキュメント
    ● 障害対応能力が高いメンバーの作業内容と思考をドキュメント化
    ○ 障害対応中は仮設を立てて調査コマンドを打ったりメトリクスを見たりを繰り返す
    ○ そのように至った思考の部分がドキュメントとして残すことで他メンバーの障害対応
    能力向上へ繋がる

    View full-size slide

  31. 32
    Playbookの作成
    ● 耐障害に特化したドキュメントを作成
    ○ ポストモーテムには以下の内容が書かれていた
    ■ 障害発生日時
    ■ サービスの影響度
    ■ 根本原因
    ■ アクションアイテム
    ■ 発生復旧までのタイムライン
    ○ 具体的な対応方法については記載されていなかった
    ■ 障害原因調査の際に見たメトリクスや打ったコマンド
    ■ メトリクスがどうなっていたのか
    ■ そのメトリクスから何がわかるのか

    View full-size slide

  32. 33
    Playbookの例

    View full-size slide

  33. 34
    障害対応訓練の実施
    ● 実践は必要
    ○ ポストモーテムドキュメントもPlaybookも読むだけになりがち
    ○ 目的は障害対応をできるメンバーを増やすこと
    ■ 実際にメンバーの障害対応能力が向上したのかを評価する必要がある
    ○ 実践することができているか分からない状態で本番環境の障害対応に望むとうまく
    いくかは分からない
    ■ 障害対応に時間がかかる =サービスの信頼性の低下につながる

    View full-size slide

  34. 35
    障害対応訓練の実施
    ● 障害対応経験が少ないメンバー向けに訓練を定期的に実施
    ○ 過去の障害と同じ状況をステージングやテスト環境で再現させる
    ■ 再現が難しい障害は発生したと仮定して訓練を行う
    ○ 出題者と回答者に分かれて障害対応をしていく
    ■ 出題者が発生している障害の概要を伝え回答者は復旧のための操作を行っていく
    ■ Table Tep Exerciseのようなイメージ

    View full-size slide

  35. 36
    6. 施策の効果

    View full-size slide

  36. 37
    施策の効果
    ● 全体の障害対応能力の向上へ繋げることができた
    ○ 新規のメンバーが障害対応に参加できる機会が増えた
    ■ 復旧まで単独で実施できるレベルのメンバーも増えた
    ■ (トレーニングして数時間後にその内容が発生するということもあった ...)
    ○ 既存のメンバーもシナリオを考える際の学びが多かった
    ○ 特定のコンポーネントが落ちた際の影響範囲は?
    ○ 自分のこれまでのやり方とは違う方法を学ぶことができた

    View full-size slide

  37. 38
    7. まとめ

    View full-size slide

  38. 39
    まとめ
    ● 障害を完全になくすことはできない
    ○ 障害対応と向き合う必要がある
    ■ 優秀なメンバーだけが対応している状況は危険
    ■ 対応できるメンバー数を可視化してしいく
    ○ 障害対応できるメンバーを増やすために行っている施策
    ■ Playbook、障害訓練
    ■ ローマは一日にしてならず、障害対応も一日にしてならず
    ● Playbookも障害対応訓練を継続的に行っていく必要がある

    View full-size slide

  39. ● Web
    ● ポストモーテム vs. レトロスペクティブ:それぞれをいつ(そしてどのよう
    に)効果的に使用するか
    ● 書籍
    ● システム障害対応の教科書
    ● SRE サイトリライアビリティエンジニアリング
    ● サイトリライアビリティワークブック
    ● SREの探求
    ● システム運用アンチパターン
    ● チームトポロジー

    41

    View full-size slide

  40. 42
    ご清聴ありがとうございました

    View full-size slide