Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
計測プラットフォームSREチームとシステム障害対応 / measurement platfor...
Search
TAKAyukiatkwsk
April 22, 2022
Technology
0
1.1k
計測プラットフォームSREチームとシステム障害対応 / measurement platform SRE team's incident response
2022/04/22「ZOZO Tech Talk #5 - チーム開発と運用」で発表した資料です。
https://zozotech-inc.connpass.com/event/244019/
TAKAyukiatkwsk
April 22, 2022
Tweet
Share
More Decks by TAKAyukiatkwsk
See All by TAKAyukiatkwsk
Claude Codeと共に構成図を作る
takayukiatkwsk
0
17
argo-rolloutsにコミットした話
takayukiatkwsk
0
40
EnvoyのWasm filterを体験する
takayukiatkwsk
0
48
自分用趣味アプリを作っている話
takayukiatkwsk
0
110
zoxideのご紹介
takayukiatkwsk
0
96
Kanazawa.rbに参加してからのふりかえり
takayukiatkwsk
0
50
git-secretsとgitフックをざっと理解する
takayukiatkwsk
0
340
Flutterに入門して体重グラフアプリを作る / Get started Flutter and build a weight graph app
takayukiatkwsk
0
420
リモートワークを振り返る / Look back on remote-working
takayukiatkwsk
0
130
Other Decks in Technology
See All in Technology
RAID6 を楔形文字で組んで現代人を怖がらせましょう(実装編)
mimifuwa
1
310
開発と脆弱性と脆弱性診断についての話
su3158
1
1.1k
TypeScript入門
recruitengineers
PRO
20
6.6k
Effective Match Types - Scala Days 2025
bishabosha
1
110
どこで動かすか、誰が動かすか 〜 kintoneのインフラ基盤刷新と運用体制のシフト 〜
ueokande
0
190
[CVPR2025論文読み会] Linguistics-aware Masked Image Modelingfor Self-supervised Scene Text Recognition
s_aiueo32
0
210
Gaze-LLE: Gaze Target Estimation via Large-Scale Learned Encoders
kzykmyzw
0
320
広島発!スタートアップ開発の裏側
tsankyo
0
240
Browser
recruitengineers
PRO
4
340
そのコンポーネント、サーバー?クライアント?App Router開発のモヤモヤを可視化する補助輪
makotot
4
570
あとはAIに任せて人間は自由に生きる
kentaro
3
1.1k
EKS Pod Identity における推移的な session tags
z63d
1
200
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
283
13k
4 Signs Your Business is Dying
shpigford
184
22k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
A better future with KSS
kneath
239
17k
Side Projects
sachag
455
43k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
What's in a price? How to price your products and services
michaelherold
246
12k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Music & Morning Musume
bryan
46
6.7k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Designing for Performance
lara
610
69k
Why Our Code Smells
bkeepers
PRO
338
57k
Transcript
計測プラットフォームSREチームとシ ステム障害対応 ZOZO Tech Talk #5 2022/04/22 株式会社ZOZO 計測プラットフォーム開発本部 計測システム部
SREブロック 髙木 貴之 Copyright © ZOZO, Inc.
© ZOZO, Inc. 株式会社ZOZO 計測プラットフォーム開発本部 計測システム部 SREブロック 髙木 貴之 •
業務委託を経て2021年4月に入社 • 石川県金沢市在住、リモートワーク • ビール好き🍻 2
© ZOZO, Inc. 3 今日の話 • システム障害対応の現状やこの先考えていることについて話していきます • 皆さんに持って帰ってもらいたいこと ◦
計測プラットフォームのSREチームがどんなことを行っているか ◦ 計測プラットフォームのSREチームがどんなことを考えているか ◦ 皆さんの受け持つサービスにあてはめて考える(きっかけになればいいな!) • 話さないこと ◦ システム内のコンポーネントについて ◦ システム障害事例の詳細について(例示はあります) ◦ 完璧な対応策
© ZOZO, Inc. • 計測プラットフォームについて • システム障害対応の現状 ◦ 概要 ◦
対応ステップの紹介 • 課題とこの先考えていること 4 アジェンダ
© ZOZO, Inc. • 計測プラットフォームについて • システム障害対応の現状 ◦ 概要 ◦
対応ステップの紹介 • 課題とこの先考えていること 5 アジェンダ
© ZOZO, Inc. 6 https://zozo.jp/zozomat/ • 自宅にいながら簡単に高精度な足の3D計測ができる計測マット • 計測したデータをもとに、自分の足型と靴の“相性度”
を表示 • NIKEやCONVERSEなど3,000型以上のアイテムに対応 (2021年6月末時点)
© ZOZO, Inc. 7 https://zozo.jp/zozoglass/ • 自宅で簡単・高精度にご自身の顔の肌の色を計測できる フェイスカラー計測ツール • ECにおけるコスメ購入時の課題であった「色選び」に関する
不安や悩みを解消 • 肌の色を構成する成分、ヘモグロビン量とメラニン量を画像 から推定 • コスメ専門モール「ZOZOCOSME」で取り扱うベースメイク の一部に対応 • 計測者数110万人を突破(2022年1月末時点)
© ZOZO, Inc. • ZOZOMATやZOZOGLASSなどのツールを利用した身体計測や診断、推奨機能を提供 • これらの機能を提供するアプリケーションの総体 • システム構成については以下のZOZOテックブログ参照 ◦
EKSのマルチテナント化を踏まえたZOZOGLASSのシステム設計 ◦ ZOZOMATのマルチテナントEKSクラスタへの移行 ▪ 「ZOZOテックブログ EKS」で検索 • ざっくり言うと ◦ AWS上に構築、コンピューティング基盤はEKS ◦ ZOZOTOWNのシステムとは別で管理 8 計測プラットフォームって?
© ZOZO, Inc. • 計測プラットフォームについて • システム障害対応の現状 ◦ 概要 ◦
対応ステップの紹介 • 課題とこの先考えていること 9 アジェンダ
© ZOZO, Inc. 障害対応の概念が広いので、以下のステップに分類して見ていきたい • 監視・計測 • 検知 • 初期対応(報告・調査・回復)
• ポストモーテム • 恒久対応 10 システム障害対応 - ステップ
© ZOZO, Inc. • 障害が起きた後の対応ではない • 顧客体験が損なわれていないかどうかを見ておく ◦ 速く検知できれば影響を小さくすることに繋がる ◦
そのためにメトリクス収集や外形監視を行い、異常が見られれば通知する仕組みが必要 • シンプルなものからアラート設定していくと良さそう ◦ 『SRE サイトリライアビリティエンジニアリング』や『サイトリライアビリティワークブック』のチーム輪読会をきっ かけに議論がなされた ◦ まずはエラーレスポンス数 ◦ レスポンスタイムについてもアラート設定したいができていない(後述) 11 監視・計測
© ZOZO, Inc. • PagerDutyに即時対応すべきアラートを集約しメンバーに対して電話をかけてもらう ◦ 同時にSlackチャンネルに通知もしている ◦ オンコール担当はSREs+バックエンドエンジニア 12
検知 アラートのレベル 1: 即時対応する必要がある 2: 翌営業日に対応すれば良い 3: 短期での対応は不要だがイベント を周知したい
© ZOZO, Inc. • 社内のガイドラインが存在するので、それに沿ったフローをチームごとに用意 • 初手何すれば良いのか分からない問題 ◦ 対応の流れを掴む ▪
Slackのワークフローを実行すると表示される ▪ 場作り(Slackのスレッド・huddleの開始) ▪ 早めの報告や困ったら誰か呼ぶとかも大事 ◦ Playbook/Runbook ▪ 場面ごとに用意された手順書(集) ▪ cf. https://www.pagerduty.com/resources/learn/what-is-a-runbook/ ▪ まだ属人的に対処するものもあるので絶賛整備中 13 初期対応
© 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 ポストモーテム
© ZOZO, Inc. • 後で見返した時に何が起きてどのような対応をしたのかが分かるもの(を意識する) ◦ チャットのやりとり、コマンドの履歴、メトリクスのグラフなどから時系列で起きたことをまとめる ◦ 対応時の判断についての背景が記載されているとさらに良い •
原因や恒久的な対応、初動対応における上手くいった点・上手くいかなかった点もまとめる • 原因分析やふりかえりで人を非難しない(blameless postmortem) ◦ 👎 ◦◦さんが入力ミスしたせいで障害が発生した ◦ 👍 プロセス△△で入力ミスが発生し、それによって障害が発生した ▪ 問題のあったプロセスにフォーカスして、みんなの学びにつなげる ◦ cf. https://www.pagerduty.com/resources/learn/incident-postmortem/#toc-2 15 障害報告書の作成
© ZOZO, Inc. • 原因分析や初期対応で上手くいかなかった点から見つけた問題点を解消する対応 • チケット管理して着実に対応を進めるのが大事 ◦ トイルや新規案件などに埋もれがち ◦
SREチーム内で恒久対応チケットの完了率を指標とし月一でふりかえり ▪ 障害が発生すると対応チケットが増えるので、数より率を見る方が進捗追いやすい ◦ cf. 修復負債(『SREの探求』p.37) • どこまで対応するか悩ましい ◦ 対応コストと効果のバランスを見ながらになる? 16 恒久対応
© ZOZO, Inc. • 「k8sのRBAC設定の適用対象を誤り、サービスを停止させた」という障害について • このときは、フィッシュボーンチャートを使って原因を分析した • 事象に対して主な要因(例:環境など)を定義し関連する事柄をつけ加えていく 17
原因分析〜恒久対応の例 導き出した対策すべき要因 • 複数クラスタの存在 • 手動による反映 恒久対応 • 単一クラスタへの移行 ◦ 別途進行していたので継続 • ArgoCDを導入し、反映を自動化 ◦ 新規で対応
© ZOZO, Inc. • 計測プラットフォームについて • システム障害対応の現状 ◦ 概要 ◦
対応ステップの紹介 • 課題とこの先考えていること 18 アジェンダ
© ZOZO, Inc. 19 課題と考えていること 課題 今後に向けて考えていること レスポンスタイムのアラート追加 • APIによって処理時間が異なる(例:計測処理と結果の
参照処理)ので一律設定だと閾値が大きくなりがち ユーザージャーニー毎にAPIを分類し、アラート設定するこ とを検討中 属人化している対応手順、役割の固定化、新規メンバー へのオンボーディング Playbook/Runbook整備 定期的な訓練の実施
© ZOZO, Inc. • システム障害対応と言っても広い概念なので、ステップに分けてプロセスや仕組みを考えると良さそう ◦ 障害に気づける仕組みも大事 • 社内のガイドラインやテンプレートを使いつつチーム事情にあったやり方を考える ◦
組織規模にもよるが、予め整備しておくことで障害時に対応しやすくなる • 障害は残念ながら起きてしまうものなので、次に起きても影響が最小になるように改善していく ◦ 何が問題だったのかをふりかえることで学び、改善に繋げられる ◦ 着実に改善・恒久対応を進めるのも大事(トラッキングできると良い) ◦ まだまだできていないこともあるが、進めていきたい 20 まとめ
None