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
argo-rolloutsにコミットした話
takayukiatkwsk
0
26
EnvoyのWasm filterを体験する
takayukiatkwsk
0
44
自分用趣味アプリを作っている話
takayukiatkwsk
0
90
zoxideのご紹介
takayukiatkwsk
0
86
Kanazawa.rbに参加してからのふりかえり
takayukiatkwsk
0
45
git-secretsとgitフックをざっと理解する
takayukiatkwsk
0
320
Flutterに入門して体重グラフアプリを作る / Get started Flutter and build a weight graph app
takayukiatkwsk
0
400
リモートワークを振り返る / Look back on remote-working
takayukiatkwsk
0
120
ブログでのアウトプットが減っている件 / What long intervals my blog posts have!
takayukiatkwsk
0
100
Other Decks in Technology
See All in Technology
Amazon ECS & AWS Fargate 運用アーキテクチャ2025 / Amazon ECS and AWS Fargate Ops Architecture 2025
iselegant
16
5.6k
なぜ私はいま、ここにいるのか? #もがく中堅デザイナー #プロダクトデザイナー
bengo4com
0
470
How Community Opened Global Doors
hiroramos4
PRO
1
120
SalesforceArchitectGroupOsaka#20_CNX'25_Report
atomica7sei
0
170
Wasm元年
askua
0
140
Кто отправит outbox? Валентин Удальцов, автор канала Пых
lamodatech
0
340
Oracle Audit Vault and Database Firewall 20 概要
oracle4engineer
PRO
3
1.7k
HiMoR: Monocular Deformable Gaussian Reconstruction with Hierarchical Motion Representation
spatial_ai_network
0
110
変化する開発、進化する体系時代に適応するソフトウェアエンジニアの知識と考え方(JaSST'25 Kansai)
mizunori
1
220
生成AI時代 文字コードを学ぶ意義を見出せるか?
hrsued
1
510
2025-06-26_Lightning_Talk_for_Lightning_Talks
_hashimo2
2
100
地図も、未来も、オープンに。 〜OSGeo.JPとFOSS4Gのご紹介〜
wata909
0
110
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
24
1.7k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
670
GraphQLとの向き合い方2022年版
quramy
48
14k
It's Worth the Effort
3n
185
28k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
The Cult of Friendly URLs
andyhume
79
6.5k
The Language of Interfaces
destraynor
158
25k
For a Future-Friendly Web
brad_frost
179
9.8k
Producing Creativity
orderedlist
PRO
346
40k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
A Modern Web Designer's Workflow
chriscoyier
694
190k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
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