計測プラットフォームSREチームとシステム障害対応 / measurement platform SRE team's incident response

by TAKAyukiatkwsk

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© ZOZO, Inc. 3 今日の話  ● システム障害対応の現状やこの先考えていることについて話していきます  ● 皆さんに持って帰ってもらいたいこと  ○ 計測プラットフォームのSREチームがどんなことを行っているか  ○ 計測プラットフォームのSREチームがどんなことを考えているか  ○ 皆さんの受け持つサービスにあてはめて考える（きっかけになればいいな！）  ● 話さないこと  ○ システム内のコンポーネントについて  ○ システム障害事例の詳細について（例示はあります）  ○ 完璧な対応策 

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© ZOZO, Inc. 7 https://zozo.jp/zozoglass/  ● 自宅で簡単・高精度にご自身の顔の肌の色を計測できるフェイスカラー計測ツール ● ECにおけるコスメ購入時の課題であった「色選び」に関する不安や悩みを解消 ● 肌の色を構成する成分、ヘモグロビン量とメラニン量を画像から推定 ● コスメ専門モール「ZOZOCOSME」で取り扱うベースメイクの一部に対応 ● 計測者数110万人を突破（2022年1月末時点）

Slide 8

Slide 8 text

© ZOZO, Inc. ● ZOZOMATやZOZOGLASSなどのツールを利用した身体計測や診断、推奨機能を提供  ● これらの機能を提供するアプリケーションの総体  ● システム構成については以下のZOZOテックブログ参照  ○ EKSのマルチテナント化を踏まえたZOZOGLASSのシステム設計  ○ ZOZOMATのマルチテナントEKSクラスタへの移行  ■ 「ZOZOテックブログ EKS」で検索  ● ざっくり言うと  ○ AWS上に構築、コンピューティング基盤はEKS  ○ ZOZOTOWNのシステムとは別で管理  8 計測プラットフォームって？ 

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© ZOZO, Inc. ● 障害が起きた後の対応ではない  ● 顧客体験が損なわれていないかどうかを見ておく  ○ 速く検知できれば影響を小さくすることに繋がる  ○ そのためにメトリクス収集や外形監視を行い、異常が見られれば通知する仕組みが必要  ● シンプルなものからアラート設定していくと良さそう  ○ 『SRE サイトリライアビリティエンジニアリング』や『サイトリライアビリティワークブック』のチーム輪読会をきっかけに議論がなされた  ○ まずはエラーレスポンス数  ○ レスポンスタイムについてもアラート設定したいができていない（後述）  11 監視・計測 

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© ZOZO, Inc. ● 社内のガイドラインが存在するので、それに沿ったフローをチームごとに用意  ● 初手何すれば良いのか分からない問題  ○ 対応の流れを掴む  ■ Slackのワークフローを実行すると表示される  ■ 場作り（Slackのスレッド・huddleの開始）  ■ 早めの報告や困ったら誰か呼ぶとかも大事  ○ Playbook/Runbook  ■ 場面ごとに用意された手順書（集）  ■ cf. https://www.pagerduty.com/resources/learn/what-is-a-runbook/  ■ まだ属人的に対処するものもあるので絶賛整備中  13 初期対応 

Slide 14

Slide 14 text

© ZOZO, Inc. ● > A postmortem (or post-mortem) is a process intended to help you learn from past incidents.  ○ https://www.pagerduty.com/resources/learn/incident-postmortem/  ● 過去のインシデントから学ぶのに役立つことを意図したプロセス  ● 障害報告書の作成をこのプロセスと見なしている  ● 初期対応が一段落したら時間を空けずに行う  14 ポストモーテム 

Slide 15

Slide 15 text

© ZOZO, Inc. ● 後で見返した時に何が起きてどのような対応をしたのかが分かるもの（を意識する）  ○ チャットのやりとり、コマンドの履歴、メトリクスのグラフなどから時系列で起きたことをまとめる  ○ 対応時の判断についての背景が記載されているとさらに良い  ● 原因や恒久的な対応、初動対応における上手くいった点・上手くいかなかった点もまとめる  ● 原因分析やふりかえりで人を非難しない(blameless postmortem)  ○ 👎 ○○さんが入力ミスしたせいで障害が発生した  ○ 👍 プロセス△△で入力ミスが発生し、それによって障害が発生した  ■ 問題のあったプロセスにフォーカスして、みんなの学びにつなげる  ○ cf. https://www.pagerduty.com/resources/learn/incident-postmortem/#toc-2  15 障害報告書の作成 

Slide 16

Slide 16 text

© ZOZO, Inc. ● 原因分析や初期対応で上手くいかなかった点から見つけた問題点を解消する対応  ● チケット管理して着実に対応を進めるのが大事  ○ トイルや新規案件などに埋もれがち  ○ SREチーム内で恒久対応チケットの完了率を指標とし月一でふりかえり  ■ 障害が発生すると対応チケットが増えるので、数より率を見る方が進捗追いやすい  ○ cf. 修復負債（『SREの探求』p.37）  ● どこまで対応するか悩ましい  ○ 対応コストと効果のバランスを見ながらになる？  16 恒久対応 

Slide 17

Slide 17 text

© ZOZO, Inc. ● 「k8sのRBAC設定の適用対象を誤り、サービスを停止させた」という障害について  ● このときは、フィッシュボーンチャートを使って原因を分析した  ● 事象に対して主な要因（例：環境など）を定義し関連する事柄をつけ加えていく  17 原因分析〜恒久対応の例  導き出した対策すべき要因  ● 複数クラスタの存在  ● 手動による反映  恒久対応  ● 単一クラスタへの移行  ○ 別途進行していたので継続  ● ArgoCDを導入し、反映を自動化  ○ 新規で対応 

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© ZOZO, Inc. 19 課題と考えていること  課題  今後に向けて考えていること  レスポンスタイムのアラート追加  ● APIによって処理時間が異なる（例：計測処理と結果の参照処理）ので一律設定だと閾値が大きくなりがち  ユーザージャーニー毎にAPIを分類し、アラート設定することを検討中  属人化している対応手順、役割の固定化、新規メンバーへのオンボーディング  Playbook/Runbook整備  定期的な訓練の実施 

Slide 20

Slide 20 text

© ZOZO, Inc. ● システム障害対応と言っても広い概念なので、ステップに分けてプロセスや仕組みを考えると良さそう  ○ 障害に気づける仕組みも大事  ● 社内のガイドラインやテンプレートを使いつつチーム事情にあったやり方を考える  ○ 組織規模にもよるが、予め整備しておくことで障害時に対応しやすくなる  ● 障害は残念ながら起きてしまうものなので、次に起きても影響が最小になるように改善していく  ○ 何が問題だったのかをふりかえることで学び、改善に繋げられる  ○ 着実に改善・恒久対応を進めるのも大事（トラッキングできると良い）  ○ まだまだできていないこともあるが、進めていきたい  20 まとめ 

Slide 21

Slide 21 text

No content