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.2k
計測プラットフォーム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
60
argo-rolloutsにコミットした話
takayukiatkwsk
0
49
EnvoyのWasm filterを体験する
takayukiatkwsk
0
49
自分用趣味アプリを作っている話
takayukiatkwsk
0
110
zoxideのご紹介
takayukiatkwsk
0
100
Kanazawa.rbに参加してからのふりかえり
takayukiatkwsk
0
53
git-secretsとgitフックをざっと理解する
takayukiatkwsk
0
350
Flutterに入門して体重グラフアプリを作る / Get started Flutter and build a weight graph app
takayukiatkwsk
0
430
リモートワークを振り返る / Look back on remote-working
takayukiatkwsk
0
140
Other Decks in Technology
See All in Technology
Zephyr(RTOS)にEdge AIを組み込んでみた話
iotengineer22
1
270
混合雲環境整合異質工作流程工具運行關鍵業務 Job 的經驗分享
yaosiang
0
140
Introduction to Sansan, inc / Sansan Global Development Center, Inc.
sansan33
PRO
0
2.8k
Linux カーネルが支えるコンテナの仕組み / LF Japan Community Days 2025 Osaka
tenforward
1
110
物体検出モデルでシイタケの収穫時期を自動判定してみた。 #devio2025
lamaglama39
0
270
生成AI時代のセキュアコーディングとDevSecOps
yuriemori
0
150
AIフル活用で挑む!空間アプリ開発のリアル
taat
0
140
もう外には出ない。より快適なフルリモート環境を目指して
mottyzzz
12
9k
Claude Code Subagents 再入門 ~cc-sddの実装で学んだこと~
gotalab555
10
17k
AI-Readyを目指した非構造化データのメダリオンアーキテクチャ
r_miura
1
280
Introduction to Bill One Development Engineer
sansan33
PRO
0
300
AIとともに歩んでいくデザイナーの役割の変化
lycorptech_jp
PRO
0
810
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
54k
Context Engineering - Making Every Token Count
addyosmani
7
300
The Straight Up "How To Draw Better" Workshop
denniskardys
238
140k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
How GitHub (no longer) Works
holman
315
140k
Being A Developer After 40
akosma
91
590k
Scaling GitHub
holman
463
140k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.2k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
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