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

入門障害対応

ryuichi1208
March 19, 2023
4.2k

 入門障害対応

ryuichi1208

March 19, 2023
Tweet

Transcript

  1. 技術部プラットフォームグループ 2021年 中途入社 5 自己紹介 渡部 龍一 Watanabe Ryuichi •

    住んでるところ: 宮城(人生2回目の京都) • ロール: SRE • 趣味: 旅行、ドライブ、(緩めの)自宅サーバ • Perl歴: 3年(Sledgeを使ったウェブサービス) • YAPC歴: 初参加 • Twitter : @ryuichi_1208
  2. 7

  3. • カラーミーショップのインフラの歴史 • オンプレ期 • プライベートクラウド期 • k8s on プライベートクラウド期

    • ハイブリッドクラウド期 • 詳しく知りたい方へ (https://speakerdeck.com/ch1aki/onpurek8stoeksnobing-xing-yun-yong-noshi-ji ) 9
  4. • 所属 • 技術部プラットフォームグループ • 役割 • ペパボのサービスの可用性を確保し、成長に合わせて適切な環境を提 供するグループ •

    ミッション • サーバーの調達やキッティングに止まらず、SRE によるサービスレベ ルの向上やクラウド環境の検証や選定を行い、必要に応じて事業部門 のアプリケーションの改善、開発を通して事業の成長を支える 11
  5. 19 • 報告は結論ファースト ◦ 技術的な話をするのではなく、ユーザーにどのように影響があるのかを伝えること を意識する • サービスに関わっているメンバーへ連絡をする ◦ マネージャーやカスタマーサポートチームへの共有

    ▪ エンドユーザーに影響が出ているのであれば障害のアナウンスをする必要が ある ◦ SREチームのみで復旧できない可能性もあるので詳しいメンバーを呼ぶ ▪ アプリケーションエンジニア ▪ セキュリティエンジニア 2. 関係者への連絡
  6. 20 • なぜ繋がらないのかを調べていく ◦ 外形監視のアラートだけでは「なぜウェブサイトへ繋がらないのか」が分からない ◦ 直近でのシステムへ加えた変更を調べる ▪ デプロイした、サーバの設定を変更、管理画面操作 ▪

    なにもしていないけど ... ◦ サービスを構成するコンポーネントから怪しい部分を調べていく ▪ 仮設->確認を繰り返していくフェーズ ▪ ロードバランサ、ウェブアプリ、 DB、ネットワーク、外部連携サービス • 挟み撃ち法で調査したりする • ネットワーク(L3) -> ウェブアプリ(L7) -> L4 -> L6みたいな順番で絞り込んでいく • ログ調査 3. 障害原因調査
  7. 21 • 対応方法2パターン ◦ 1. 根本対応 ▪ 繋がらない原因の特定が行えた場合の対応 ◦ 2.

    その場しのぎの対応 ▪ 止血対応と呼んでいる ▪ 自分が持っている復旧するかもしれない対応手段を試していく ▪ 原因はわかっていなくてもつながるように優先的に対応する • OS、ミドルウェアの再起動 • 何かしらのリリースが直近であればロールバック • リソース不足になっていそうならスケールアウト対応 4. 復旧作業の実施
  8. 22 • 障害対応完了後に行われる反省と改善のための分析会議 ◦ 障害が起きてしまった原因や対応時の仕方についての振り返りなどを行っている。 ▪ 今後の改善点を見つけること ◦ 失敗の原因を明確にするだけでなく、成功の要因を明らかにすることも行っている ◦

    参加していないチームや今後、参画するメンバーも学びがあるようにポストモーテ ムを書いてる ▪ なぜこのような対応したのかをドキュメントに残す ▪ アクションアイテムも issue化して後からでも追いやすくする 5. ポストモーテム
  9. 27 • 障害が発生した際の対応が一部の優秀なエンジニアで閉じていた ◦ 原因特定、復旧までを短時間で行う • 優秀なエンジニアはいつもいるとは限らない ◦ 休暇、異動、退職 •

    優秀なエンジニアがいない=障害対応に時間がかかる=サービスの信頼性 の低下につながる なぜ障害対応能力の向上施策を行ったのか
  10. 31 Playbookの作成 • Playbookとは ◦ アメリカンフットボールの戦略集 ◦ 一定の知識や経験を持った人でなければ理解できない熟練者向けのドキュメント • 障害対応能力が高いメンバーの作業内容と思考をドキュメント化

    ◦ 障害対応中は仮設を立てて調査コマンドを打ったりメトリクスを見たりを繰り返す ◦ そのように至った思考の部分がドキュメントとして残すことで他メンバーの障害対応 能力向上へ繋がる
  11. 32 Playbookの作成 • 耐障害に特化したドキュメントを作成 ◦ ポストモーテムには以下の内容が書かれていた ▪ 障害発生日時 ▪ サービスの影響度

    ▪ 根本原因 ▪ アクションアイテム ▪ 発生復旧までのタイムライン ◦ 具体的な対応方法については記載されていなかった ▪ 障害原因調査の際に見たメトリクスや打ったコマンド ▪ メトリクスがどうなっていたのか ▪ そのメトリクスから何がわかるのか
  12. 34 障害対応訓練の実施 • 実践は必要 ◦ ポストモーテムドキュメントもPlaybookも読むだけになりがち ◦ 目的は障害対応をできるメンバーを増やすこと ▪ 実際にメンバーの障害対応能力が向上したのかを評価する必要がある

    ◦ 実践することができているか分からない状態で本番環境の障害対応に望むとうまく いくかは分からない ▪ 障害対応に時間がかかる =サービスの信頼性の低下につながる
  13. 37 施策の効果 • 全体の障害対応能力の向上へ繋げることができた ◦ 新規のメンバーが障害対応に参加できる機会が増えた ▪ 復旧まで単独で実施できるレベルのメンバーも増えた ▪ (トレーニングして数時間後にその内容が発生するということもあった

    ...) ◦ 既存のメンバーもシナリオを考える際の学びが多かった ◦ 特定のコンポーネントが落ちた際の影響範囲は? ◦ 自分のこれまでのやり方とは違う方法を学ぶことができた
  14. 39 まとめ • 障害を完全になくすことはできない ◦ 障害対応と向き合う必要がある ▪ 優秀なメンバーだけが対応している状況は危険 ▪ 対応できるメンバー数を可視化してしいく

    ◦ 障害対応できるメンバーを増やすために行っている施策 ▪ Playbook、障害訓練 ▪ ローマは一日にしてならず、障害対応も一日にしてならず • Playbookも障害対応訓練を継続的に行っていく必要がある
  15. • Web • ポストモーテム vs. レトロスペクティブ:それぞれをいつ(そしてどのよう に)効果的に使用するか • 書籍 •

    システム障害対応の教科書 • SRE サイトリライアビリティエンジニアリング • サイトリライアビリティワークブック • SREの探求 • システム運用アンチパターン • チームトポロジー
 41