LINEスタンプの実例紹介 小さく始める障害検知・対応・振り返りの 改善プラクティス

SRE NEXT 2022 ONLINE
スポンサーセッションの登壇資料です

登壇者
LINE株式会社 Communication & Service Integration室SRE / Tech Lead
加藤俊弥(@maruloop)

Transcript

1. 自己紹介 1 @maruloop 名前 HN 経歴 趣味 加藤 俊弥 maru • 2020年12月にLINEに入社 • LINEスタンプおよび関連システムのSREを担当 漫画、ゲーム、アニメ
2. 直近の大きなタスク 2 2022年あけおめLINEの準備 約9倍のアクセススパイクがあるLINEスタンプの「あけおめLINE」を対応。 対応した内容は2022年3⽉の6社合同SRE勉強会で紹介しました。
3. 今回の発表について 3 テキスト読み上げソフトウェアを利⽤ 録画された動画の修正を簡単にするために、TextToSpeechソフトウェアを利⽤。 Q&Aでは⼈間が登壇します。 SREプラクティスのEnablingの事例集 Whatより、whyとhowを重視した説明。
4. -*/&ελϯϓͷ࣮ྫ঺հ খ࢝͘͞ΊΔো֐ݕ஌ɾରԠɾৼΓฦΓͷ վળϓϥΫςΟε Ճ౻ ढ़໻ !NBSVMPPQ -*/&גࣜձࣾ $PNNVOJDBUJPO
   
   4FSWJDF
   *OUFHSBUJPOࣨ 43&
   
   5FDI
   -FBE
5. 3つの障害対応改善事例のテーマ 5
6. 3つの障害対応改善事例のテーマ 脱・ヒロイズム 6
7. 7 ヒロイズムなチーム？ 7
8. ヒロイズムなチームとは？ 8 障害解決 障害発生 • エキスパートが一番に反応 • すぐにエキスパートが調査・対応開始 • ユーザー影響が小さくても • 単純な作業で終わる場合でも • エキスパートが最も迅速に解決できるため
9. ヒロイズムなチームとは？ 9 障害解決 • メンバーからは感謝と労い • 再発防止もエキスパートが率先して検討 • 最もシステムに詳しく、障害対応を行った エキスパートが率先して、再発防止の検討 • メンバーからは提案や質問は特になし 障害発生 • エキスパートが一番に反応 • すぐにエキスパートが調査・対応開始 • ユーザー影響が小さくても • 単純な作業で終わる場合でも • エキスパートが最も迅速に解決できるため
10. ヒロイズムなチームとは？ 10 ஌ࣝͱܦݧ ো֐ରԠΛ࣮ࡍʹߦ͍ɺ࠶ൃ๷ࢭࡦͷݕ౼΋཰ઌͯ͠ߦͬͨ ΤΩεύʔτʹ஌ࣝͱܦݧ͕ूத͢Δ
11. ヒロイズムなチームとは？ 11 ஌ࣝͱܦݧ ো֐ରԠΛ࣮ࡍʹߦ͍ɺ࠶ൃ๷ࢭࡦͷݕ౼΋཰ઌͯ͠ߦͬͨ ΤΩεύʔτʹ஌ࣝͱܦݧ͕ूத͢Δ ײ౓ͷ௿Լ ಛఆݸਓͷো֐ରԠͷৗଶԽͰɺଞϝϯόʔͷΞϥʔτ΁ͷײ౓͕௿Լɻ Ξϥʔτʹؾ͕͍ͭͯ΋ղܾͰ͖ͣɺΤεΧϨʔγϣϯ͢Δ೔ৗɻ
12. ヒロイズムなチームとは？ 12 ஌ࣝͱܦݧ ো֐ରԠΛ࣮ࡍʹߦ͍ɺ࠶ൃ๷ࢭࡦͷݕ౼΋཰ઌͯ͠ߦͬͨ ΤΩεύʔτʹ஌ࣝͱܦݧ͕ूத͢Δ ײ౓ͷ௿Լ ಛఆݸਓͷো֐ରԠͷৗଶԽͰɺଞϝϯόʔͷΞϥʔτ΁ͷײ౓͕௿Լɻ Ξϥʔτʹؾ͕͍ͭͯ΋ղܾͰ͖ͣɺΤεΧϨʔγϣϯ͢Δ೔ৗɻ ঝೝཉٻ ࿑͍ͱײँΛड͚ɺ཰ઌͨ͠໰୊ղܾͷ࢟੎͸ࠪఆʹ΋൓өɻ ෛ୲Ͱ͸͋Δ͕ɺঝೝཉٻ΋ຬͨ͞Εɺͦͷঢ়ଶΛվΊʹ͍͘ɻ ·ͨɺଞͷϝϯόʔʹো֐ରԠΛґཔ͢Δ͜ͱࣗମɺԕྀͯ͠͠·͏ɻ
13. ヒロイズムなチームは悪いのか？ 13 SPOFを避けるという意味では、アンチパターン しかし、ビジネス上の理由からスピード優先で、 ⼀時的に特定個⼈にナレッジが偏るのは仕⽅ないことも。
14. ヒロイズムなチームは悪いのか？ 14 SPOFを避けるという意味では、アンチパターン しかし、ビジネス上の理由からスピード優先で、 ⼀時的に特定個⼈にナレッジが偏るのは仕⽅ないことも。 チームによる持続的な開発を目指すならば、脱却した方が良い
15. ヒロイズムの問題点 15 暗黙知が増えやすい・再発防止の視点が限定的 特定個人が常にイレギュラーに対応するため
16. ヒロイズムの問題点 16 暗黙知が増えやすい・再発防止の視点が限定的 特定個人が常にイレギュラーに対応するため 特定個人の能力に障害対応の品質や速度が律速される 常にパフォーマンスを発揮できるとは限らないため
17. ヒロイズムの問題点 17 暗黙知が増えやすい・再発防止の視点が限定的 特定個人が常にイレギュラーに対応するため 特定個人の能力に障害対応の品質や速度が律速される 常にパフォーマンスを発揮できるとは限らないため ヒロイズム脱却のインセンティブが当事者に少ない ヒーローの承認欲求が満たされやすく、 他のメンバーは障害のような割り込み対応を行いたくないため
18. 脱ヒロイズムのための3つの事例 18 障害によるReactiveな割込みを減らす Proactiveに状態を確認するSLO Letter文化を定着 リバースエンジニアリングの訓練も兼ねる 典型的な障害は、誰もが同じように対応できるように 台本ベースと実際に障害を発生させる2つの障害訓練を実施 pre-ポストモーテムレビュー ポストモーテムの品質向上のための共著する仕組み 過去のポストモーテムの再読を兼ねる
19. 脱ヒロイズムのための3つの事例 19 障害によるReactiveな割込みを減らす Proactiveに状態を確認するSLO Letter文化を定着 リバースエンジニアリングの訓練も兼ねる 典型的な障害は、誰もが同じように対応できるように 台本ベースと実際に障害を発生させる2つの障害訓練を実施 pre-ポストモーテムレビュー ポストモーテムの品質向上のための共著する仕組み 過去のポストモーテムの再読を兼ねる
20. 20 Proactiveな対応としての SLO Letter文化 20
21. Proactiveとは？ 21
22. Proactiveな対応としてのSLO Letter文化 22 毎週ダッシュボードを確認して、変化を共有する⽂化 1. ⼀週間のメトリクスの変化を、前週⽐・前⽉⽐で⽐較 2. エラー率・レイテンシ・アクセス数に変化があれば、Slackで共有 3. 変化があれば、リバースエンジニアリングして原因も調査
23. 学習のためのリバースエンジニアリング 23 ஌ࣝͱ৘ใ • γεςϜؒͷґଘؔ܎ͷ஌ࣝ • ৽نػೳϩʔϯνͷ৘ใ • Ωϟϯϖʔϯͷ։࢝৘ใ ܇࿅ • ࣮ࡍͷো֐ରԠͱಉ༷ͷϦόʔεΤϯδχΞϦϯάͷ܇࿅ ༧ݟతରॲ • ো֐Λະવʹ๷͛Δ͜ͱ΋
24. SLO Letter文化の定着まで 24 01 • まず一人で始めてみる • 特に相談も合意も取らず、とりあえずやる • ダッシュボードを毎週確認して、調査共有
25. SLO Letter文化の定着まで 25 01 • まず一人で始めてみる • 特に相談も合意も取らず、とりあえずやる • ダッシュボードを毎週確認して、調査共有 02 • チームのルーチンへ • 三ヶ月ほど続けて、認知され当たり前になったら チームのルーチンワークとして提案 • 適宜サポートを実施
26. SLO Letter文化の定着まで 26 01 • まず一人で始めてみる • 特に相談も合意も取らず、とりあえずやる • ダッシュボードを毎週確認して、調査共有 02 • チームのルーチンへ • 三ヶ月ほど続けて、認知され当たり前になったら チームのルーチンワークとして提案 • 適宜サポートを実施 このSLO Letter文化(日常的なリバースエンジニアリング)は 既に1年継続中
27. 脱ヒロイズムのための3つの事例 27 障害によるReactiveな割込みを減らす Proactiveに状態を確認するSLO Letter文化を定着 リバースエンジニアリングの訓練も兼ねる 典型的な障害は、誰もが同じように対応できるように 台本ベースと実際に障害を発生させる2つの障害訓練を実施 pre-ポストモーテムレビュー ポストモーテムの品質向上のための共著する仕組み 過去のポストモーテムの再読を兼ねる
28. 28 典型的な障害に 普段通り対応するための 障害訓練 28
29. 障害と対処の分類 29 छྨ ༧๷ ݕ஌ ରॲ աෛՙ • 4DBMBCMF
    BSDIJUFDUVSF • $BQBDJUZ
    QMBOOJOH • 5PUBM
    SFRVFTUT • &SSPS
    SBUF • -BUFODZ • 5ISPUUMJOH • 4DBMJOH )8ো֐ • )BSEXBSF
    WJSUVBMJ[BUJPO • %JTUSJCVUFE
    BSDIJUFDUVSF • &SSPS
    SBUF • -BUFODZ જࡏతͳ48όά • .PEFSOJ[F • 5FTU σϓϩΠ • 5FTU
    2" • $PEF
    GSFF[F ώϡʔϚϯ Τϥʔ • "VUPNBUJPO • 5SBJOJOH • &SSPS
    SBUF • -BUFODZ • &SSPS
    SBUF • -BUFODZ • &SSPS
    SBUF • -BUFODZ • 4FSWJDF
    PVU • .PWF
    UP
    BOPUIFS
    OPEF • 3FTUBSU • 1BUDI • 3PMMCBDL • )PUGJY • $BTF
    CZ
    DBTF
30. 障害と対処の分類 30 छྨ ༧๷ ݕ஌ ରॲ աෛՙ • 4DBMBCMF
    BSDIJUFDUVSF • $BQBDJUZ
    QMBOOJOH • 5PUBM
    SFRVFTUT • &SSPS
    SBUF • -BUFODZ • 5ISPUUMJOH • 4DBMJOH )8ো֐ • )BSEXBSF
    WJSUVBMJ[BUJPO • %JTUSJCVUFE
    BSDIJUFDUVSF • &SSPS
    SBUF • -BUFODZ જࡏతͳ48όά • .PEFSOJ[F • 5FTU σϓϩΠ • 5FTU
    2" • $PEF
    GSFF[F ώϡʔϚϯ Τϥʔ • "VUPNBUJPO • 5SBJOJOH • &SSPS
    SBUF • -BUFODZ • &SSPS
    SBUF • -BUFODZ • &SSPS
    SBUF • -BUFODZ • 4FSWJDF
    PVU • .PWF
    UP
    BOPUIFS
    OPEF • 3FTUBSU • 1BUDI • 3PMMCBDL • )PUGJY • $BTF
    CZ
    DBTF
31. 障害訓練 第一回目 31 第⼀回⽬の障害訓練の特徴と流れ 1. 事前に過去の障害を元にした台本を準備 2. 訓練時の実作業はエキスパート2名に依頼 3. 実際のシステムには問題を起こさない 4. 台本には、原因や対応⼿順がすべて⽂章で記載 5. Zoomに全員揃った状態からスタートし、台本に従って対応を進⾏ 初回は作業者のプレッシャー軽減のために、 なるべく自由度を下げた障害訓練を実施
32. 障害訓練の台本例 1. キャンペーンによるアクセス数増加で過負荷が発生 2. ダッシュボードを確認して、影響範囲を確認 3. 影響範囲がわかり次第、Slackで情報共有 4. API throttlingを実行して、影響範囲を最小化 5. 1台サーバーを追加し、スケールアウト 32
33. エキスパートの経験からくる工夫 33 ੾Γ෼͚ • ෳ਺ͷμογϡϘʔυΛ૊Έ߹ΘͤͯɺݪҼͱӨڹൣғ֬ೝ ঢ়گڞ༗ • ςϯϓϨʔτ͸࢖Θͣɺաڈͷྨࣅͷো֐ใࠂΛվม͠ ਝ଎ʹڞ༗จݴΛ࡞੒ 5ISPUUMJOH • 5ISPUUMJOHͷର৅"1*Λܦݧଇ͔Βܾఆ • ϢʔβʔӨڹ͕খ͘͞ɺޮՌ͕ߴ͍΋ͷΛબผ
34. 障害訓練 第二回目 34 第⼀回⽬からの変更点 1. ⽇時と担当者のみ事前に決定 2. 台本をなくし、アラートを受けてから対応 3. 実際に開発環境で過負荷による障害を発⽣させた 二回目は、実際の障害を可能な範囲で再現。 みんなで相談しながら、調査や対処を実施。
35. 実際の大まかな流れ 1. 担当者がすぐさまZoom会議を用意 2. 画面共有しながら、原因とユーザー影響を調査 3. ユーザー影響をSlackで報告 4. Throttlingで障害影響を最小化できるか検討 5. Scale outして解決 35 最初の調査時、負荷発生元のインスタンスをIPアドレスから見つけられ 直接、そのノードを殺されそうになるアクシデントも・・・ ※ルール違反ということで、見なかったことに
36. 脱ヒロイズムのための3つの事例 36 障害によるReactiveな割込みを減らす Proactiveに状態を確認するSLO Letter文化を定着 リバースエンジニアリングの訓練も兼ねる 典型的な障害は、誰もが同じように対応できるように 台本ベースと実際に障害を発生させる2つの障害訓練を実施 pre-ポストモーテムレビュー ポストモーテムの品質向上のための共著する仕組み 過去のポストモーテムの再読を兼ねる
37. 37 障害からの学びを 最大化するpreポストモーテム 37
38. LINEプラットフォームやスタンプ、公式アカウントでは 38 1. 誰が執筆しますか？ 2. 誰がレビューしますか？ 3. 誰が閲覧できますか？ 4. 上記はいつまでに実施されますか？
39. LINEプラットフォームやスタンプ、公式アカウントでは 39 ドメインエキスパートとそのチームメンバーが執筆 必須参加として、LINEのサーバーサイドエンジニアのリーダー20名程度 任意参加として、ポストモーテムレビュー会議に招待されるのは200名程度 原則、すべて社内でオープン。Slackチャンネルで通知もあり。 ポストモーテムを記載できる範囲のみで1営業日以内で、まず共有 5営業日以内に完成させ、ポストモーテムレビュー会議を開催 1. 誰が執筆しますか？ 2. 誰がレビューしますか？ 3. 誰が閲覧できますか？ 4. 上記はいつまでに実施されますか？
40. 40 利点 • 知見を広い範囲で共有できる • 他システムについて知る機会 チーム横断の大規模なポストモーテムレビュー 欠点 • 参加人数が多く、質問しにくい • ドメイン知識の共有に時間がかかる • ドメインに特化した対策は検討しにくい 40
41. 41 利点 • 知見を広い範囲で共有できる • 他システムについて知る機会 チーム横断の大規模なポストモーテムレビュー 欠点 • 参加人数が多く、質問しにくい • ドメイン知識の共有に時間がかかる • ドメインに特化した対策は検討しにくい 41 ⽋点を補うために 1. ポストモーテム⾃体の品質向上 • ⾮ドメインエキスパートでも理解しやすくするため、説明や図を追加 2. ドメインに特化した対策は、事前に⼗分に検討したものを記載
42. ポストモーテムレビューフローの変更 42 ポストモーテムの執筆 preポストモーテム レビュー会議 大規模ポストモーテム レビュー会議 • 主にエキスパートが執筆 • 障害の概要・原因・タイムテーブル・再発防止などを一通り記載 • チーム内でレビュー(非ドメインエキスパート含む) • 非ドメインエキスパートでも理解しやすいように仕上げる • ドメイン特化の対策もここで十分検討する • 組織的な再発防止の検討 • ポリシーやプラットフォームの見直しなど • 同じ障害を他チームで発生させないようにするための情報共有 NEW
43. preポストモーテムレビューの進め方 43 初回(1時間ver) 会議前 15分 15分 15分 15分 • SREが過去の類似の障害をリストアップして追記 • ポストモーテムを各自黙読し、コメント • コメントの頭に、「Suggestion」や「Question」を明記 • Questionから順にすべて確認し、すべての疑問を解決 • Suggestionを確認し、ディスカッション • 再発防止策の検討
44. preポストモーテムレビューの進め方 44 二回目以降(30分間ver) 会議前 10分 10分 10分 • SREが過去の類似の障害をリストアップして追記 • 会議前に事前に読み込み&コメント • Questionから順にすべて確認し、すべての疑問を解決 • Suggestionを確認し、ディスカッション • 再発防止策の検討
45. preポストモーテムレビューの3つの効果 45 ϙετϞʔςϜͷ ඼࣭޲্ • ඇυϝΠϯΤΩεύʔτʹ΋ཧղ͠΍͍͢ϙετϞʔςϜʹ࢓্͛Δ • ͦͷ݁Ռɺେن໛ϙετϞʔςϜϨϏϡʔձ͕ٞ୹࣌ؒɾޮՌతͳٞ࿦ʹ ϙετϞʔςϜͷ ڞஶ • ΤΩεύʔτ΍43&͸ɺϙετϞʔςϜͷୟ͖୆Λ࡞Δͱ͜Ζ·Ͱ • ࢓্͛͸νʔϜશମͰߦ͍ɺڞஶ͢Δ͜ͱʹΑͬͯυϝΠϯ஌ࣝΛशಘ աڈͷ ϙετϞʔςϜͷ ֬ೝ • ྨࣅͷো֐ͷϙετϞʔςϜΛಡΉػձͱͯ͠׆༻ • ະணखͩͬͨ࠶ൃ๷ࢭࡦͷ༏ઌ౓ΛվΊΔ͜ͱ΋
46. 脱ヒロイズムのための3つの事例 46 障害によるReactiveな割込みを減らす Proactiveに状態を確認するSLO Letter文化を定着 リバースエンジニアリングの訓練も兼ねる 典型的な障害は、誰もが同じように対応できるように 台本ベースと実際に障害を発生させる2つの障害訓練を実施 pre-ポストモーテムレビュー ポストモーテムの品質向上のための共著する仕組み 過去のポストモーテムの再読を兼ねる
47. SRE本28章 新人からオンコール担当、そしてその先へ 47 Google SRE本 28章にオンコール担当までの Googleでの教育方法が記載されています。
48. SRE本28章 新人からオンコール担当、そしてその先へ 48 Google SRE本 28章にオンコール担当までの Googleでの教育方法が記載されています。 今回紹介した3つの改善は、 私たち向けにカスタマイズした上で このように対応しています。 SLO Letter文化 preポストモーテム 障害訓練
49. 脱ヒロイズムに必要なこととは？ 新たなオンコール担当の育成の仕組み化 49
50. 今回紹介した3つのEnabling事例について 50 私のオンボーディングとEnablingの並⾏ 1ヶ⽉⽬︓SLO Letter開始 3ヶ⽉⽬︓Pre ポストモーテムレビュー開始 3ヶ⽉⽬︓障害訓練 台本ベース実施 6ヶ⽉⽬︓障害訓練 実障害ベース実施 一人目の専任SREとしてオンボーディングしながら チームにSREのプラクティスをEnablingした事例の紹介でした
51. 51 Thank you!!