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

2022/04/22「ZOZO Tech Talk #5 - チーム開発と運用」で発表した資料です。
https://zozotech-inc.connpass.com/event/244019/

Transcript

1. 計測プラットフォームSREチームとシ
   ステム障害対応

   ZOZO Tech Talk #5 2022/04/22

   株式会社ZOZO

   計測プラットフォーム開発本部 計測システム部 SREブロック

   髙木 貴之
   Copyright © ZOZO, Inc.
   

   View Slide

2. © ZOZO, Inc.
   株式会社ZOZO

   計測プラットフォーム開発本部 計測システム部

   SREブロック

   髙木 貴之

   ● 業務委託を経て2021年4月に入社

   ● 石川県金沢市在住、リモートワーク

   ● ビール好き🍻

   2
   

   View Slide

3. © ZOZO, Inc.
   3
   今日の話

   ● システム障害対応の現状やこの先考えていることについて話していきます

   ● 皆さんに持って帰ってもらいたいこと

   ○ 計測プラットフォームのSREチームがどんなことを行っているか

   ○ 計測プラットフォームのSREチームがどんなことを考えているか

   ○ 皆さんの受け持つサービスにあてはめて考える（きっかけになればいいな！）

   ● 話さないこと

   ○ システム内のコンポーネントについて

   ○ システム障害事例の詳細について（例示はあります）

   ○ 完璧な対応策

   

   View Slide

4. © ZOZO, Inc.
   ● 計測プラットフォームについて

   ● システム障害対応の現状

   ○ 概要

   ○ 対応ステップの紹介

   ● 課題とこの先考えていること

   

   4
   アジェンダ

   

   View Slide

5. © ZOZO, Inc.
   ● 計測プラットフォームについて

   ● システム障害対応の現状

   ○ 概要

   ○ 対応ステップの紹介

   ● 課題とこの先考えていること

   

   5
   アジェンダ

   

   View Slide

6. © ZOZO, Inc.
   6
   https://zozo.jp/zozomat/

   

   ● 自宅にいながら簡単に高精度な足の3D計測ができる計測マット

   ● 計測したデータをもとに、自分の足型と靴の“相性度” を表示

   ● NIKEやCONVERSEなど3,000型以上のアイテムに対応

   （2021年6月末時点）

   

   

   View Slide

7. © ZOZO, Inc.
   7
   https://zozo.jp/zozoglass/

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

   View Slide

8. © ZOZO, Inc.
   ● ZOZOMATやZOZOGLASSなどのツールを利用した身体計測や診断、推奨機能を提供

   ● これらの機能を提供するアプリケーションの総体

   ● システム構成については以下のZOZOテックブログ参照

   ○ EKSのマルチテナント化を踏まえたZOZOGLASSのシステム設計

   ○ ZOZOMATのマルチテナントEKSクラスタへの移行

   ■ 「ZOZOテックブログ EKS」で検索

   ● ざっくり言うと

   ○ AWS上に構築、コンピューティング基盤はEKS

   ○ ZOZOTOWNのシステムとは別で管理

   8
   計測プラットフォームって？

   

   View Slide

9. © ZOZO, Inc.
   ● 計測プラットフォームについて

   ● システム障害対応の現状

   ○ 概要

   ○ 対応ステップの紹介

   ● 課題とこの先考えていること

   

   9
   アジェンダ

   

   View Slide

10. © ZOZO, Inc.
    障害対応の概念が広いので、以下のステップに分類して見ていきたい

    ● 監視・計測

    ● 検知

    ● 初期対応（報告・調査・回復）

    ● ポストモーテム

    ● 恒久対応

    10
    システム障害対応 - ステップ

    

    View Slide

11. © ZOZO, Inc.
    ● 障害が起きた後の対応ではない

    ● 顧客体験が損なわれていないかどうかを見ておく

    ○ 速く検知できれば影響を小さくすることに繋がる

    ○ そのためにメトリクス収集や外形監視を行い、異常が見られれば通知する仕組みが必要

    ● シンプルなものからアラート設定していくと良さそう

    ○ 『SRE サイトリライアビリティエンジニアリング』や『サイトリライアビリティワークブック』のチーム輪読会をきっ
    かけに議論がなされた

    ○ まずはエラーレスポンス数

    ○ レスポンスタイムについてもアラート設定したいができていない（後述）

    11
    監視・計測

    

    View Slide

12. © ZOZO, Inc.
    ● PagerDutyに即時対応すべきアラートを集約しメンバーに対して電話をかけてもらう

    ○ 同時にSlackチャンネルに通知もしている

    ○ オンコール担当はSREs+バックエンドエンジニア

    12
    検知

    アラートのレベル

    

    1: 即時対応する必要がある

    2: 翌営業日に対応すれば良い

    3: 短期での対応は不要だがイベント
    を周知したい

    

    View Slide

13. © ZOZO, Inc.
    ● 社内のガイドラインが存在するので、それに沿ったフローをチームごとに用意

    ● 初手何すれば良いのか分からない問題

    ○ 対応の流れを掴む

    ■ Slackのワークフローを実行すると表示される

    ■ 場作り（Slackのスレッド・huddleの開始）

    ■ 早めの報告や困ったら誰か呼ぶとかも大事

    ○ Playbook/Runbook

    ■ 場面ごとに用意された手順書（集）

    ■ cf. https://www.pagerduty.com/resources/learn/what-is-a-runbook/

    ■ まだ属人的に対処するものもあるので絶賛整備中

    13
    初期対応

    

    View Slide

14. © 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
    ポストモーテム

    

    View Slide

15. © ZOZO, Inc.
    ● 後で見返した時に何が起きてどのような対応をしたのかが分かるもの（を意識する）

    ○ チャットのやりとり、コマンドの履歴、メトリクスのグラフなどから時系列で起きたことをまとめる

    ○ 対応時の判断についての背景が記載されているとさらに良い

    ● 原因や恒久的な対応、初動対応における上手くいった点・上手くいかなかった点もまとめる

    ● 原因分析やふりかえりで人を非難しない(blameless postmortem)

    ○ 👎 ○○さんが入力ミスしたせいで障害が発生した

    ○ 👍 プロセス△△で入力ミスが発生し、それによって障害が発生した

    ■ 問題のあったプロセスにフォーカスして、みんなの学びにつなげる

    ○ cf. https://www.pagerduty.com/resources/learn/incident-postmortem/#toc-2

    15
    障害報告書の作成

    

    View Slide

16. © ZOZO, Inc.
    ● 原因分析や初期対応で上手くいかなかった点から見つけた問題点を解消する対応

    ● チケット管理して着実に対応を進めるのが大事

    ○ トイルや新規案件などに埋もれがち

    ○ SREチーム内で恒久対応チケットの完了率を指標とし月一でふりかえり

    ■ 障害が発生すると対応チケットが増えるので、数より率を見る方が進捗追いやすい

    ○ cf. 修復負債（『SREの探求』p.37）

    ● どこまで対応するか悩ましい

    ○ 対応コストと効果のバランスを見ながらになる？

    16
    恒久対応

    

    View Slide

17. © ZOZO, Inc.
    ● 「k8sのRBAC設定の適用対象を誤り、サービスを停止させた」という障害について

    ● このときは、フィッシュボーンチャートを使って原因を分析した

    ● 事象に対して主な要因（例：環境など）を定義し関連する事柄をつけ加えていく

    17
    原因分析〜恒久対応の例

    導き出した対策すべき要因

    ● 複数クラスタの存在

    ● 手動による反映

    恒久対応

    ● 単一クラスタへの移行

    ○ 別途進行していたので継続

    ● ArgoCDを導入し、反映を自動化

    ○ 新規で対応

    

    View Slide

18. © ZOZO, Inc.
    ● 計測プラットフォームについて

    ● システム障害対応の現状

    ○ 概要

    ○ 対応ステップの紹介

    ● 課題とこの先考えていること

    

    18
    アジェンダ

    

    View Slide

19. © ZOZO, Inc.
    19
    課題と考えていること

    課題
 今後に向けて考えていること

    レスポンスタイムのアラート追加

    ● APIによって処理時間が異なる（例：計測処理と結果の
    参照処理）ので一律設定だと閾値が大きくなりがち

    ユーザージャーニー毎にAPIを分類し、アラート設定するこ
    とを検討中

    属人化している対応手順、役割の固定化、新規メンバー
    へのオンボーディング

    Playbook/Runbook整備

    定期的な訓練の実施

    

    View Slide

20. © ZOZO, Inc.
    ● システム障害対応と言っても広い概念なので、ステップに分けてプロセスや仕組みを考えると良さそう

    ○ 障害に気づける仕組みも大事

    ● 社内のガイドラインやテンプレートを使いつつチーム事情にあったやり方を考える

    ○ 組織規模にもよるが、予め整備しておくことで障害時に対応しやすくなる

    ● 障害は残念ながら起きてしまうものなので、次に起きても影響が最小になるように改善していく

    ○ 何が問題だったのかをふりかえることで学び、改善に繋げられる

    ○ 着実に改善・恒久対応を進めるのも大事（トラッキングできると良い）

    ○ まだまだできていないこともあるが、進めていきたい

    20
    まとめ

    

    View Slide

21. View Slide