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

by LINE Developers

Slide 1

Slide 1 text

自己紹介 1 @maruloop 名前 HN 経歴趣味加藤俊弥 maru • 2020年12月にLINEに入社 • LINEスタンプおよび関連システムのSREを担当漫画、ゲーム、アニメ

Slide 2

Slide 2 text

直近の大きなタスク 2 2022年あけおめLINEの準備約9倍のアクセススパイクがあるLINEスタンプの「あけおめLINE」を対応。対応した内容は2022年3⽉の6社合同SRE勉強会で紹介しました。

Slide 3

Slide 3 text

今回の発表について 3 テキスト読み上げソフトウェアを利⽤録画された動画の修正を簡単にするために、TextToSpeechソフトウェアを利⽤。 Q&Aでは⼈間が登壇します。 SREプラクティスのEnablingの事例集 Whatより、whyとhowを重視した説明。

Slide 4

Slide 4 text

-*/&ελϯϓͷ࣮ྫ঺հ খ࢝͘͞ΊΔো֐ݕ஌ɾରԠɾৼΓฦΓͷ վળϓϥΫςΟε Ճ౻ ढ़໻ !NBSVMPPQ -*/&גࣜձࣾ $PNNVOJDBUJPO4FSWJDF*OUFHSBUJPOࣨ 43&5FDI-FBE

Slide 5

Slide 5 text

3つの障害対応改善事例のテーマ 5

Slide 6

Slide 6 text

3つの障害対応改善事例のテーマ脱・ヒロイズム 6

Slide 7

Slide 7 text

7 ヒロイズムなチーム？ 7

Slide 8

Slide 8 text

ヒロイズムなチームとは？ 8 障害解決障害発生 • エキスパートが一番に反応 • すぐにエキスパートが調査・対応開始 • ユーザー影響が小さくても • 単純な作業で終わる場合でも • エキスパートが最も迅速に解決できるため

Slide 9

Slide 9 text

ヒロイズムなチームとは？ 9 障害解決 • メンバーからは感謝と労い • 再発防止もエキスパートが率先して検討 • 最もシステムに詳しく、障害対応を行ったエキスパートが率先して、再発防止の検討 • メンバーからは提案や質問は特になし障害発生 • エキスパートが一番に反応 • すぐにエキスパートが調査・対応開始 • ユーザー影響が小さくても • 単純な作業で終わる場合でも • エキスパートが最も迅速に解決できるため

Slide 10

Slide 10 text

ヒロイズムなチームとは？ 10 ஌ࣝͱܦݧ ো֐ରԠΛ࣮ࡍʹߦ͍ɺ࠶ൃ๷ࢭࡦͷݕ౼΋཰ઌͯ͠ߦͬͨ ΤΩεύʔτʹ஌ࣝͱܦݧ͕ूத͢Δ

Slide 11

Slide 11 text

ヒロイズムなチームとは？ 11 ஌ࣝͱܦݧ ো֐ରԠΛ࣮ࡍʹߦ͍ɺ࠶ൃ๷ࢭࡦͷݕ౼΋཰ઌͯ͠ߦͬͨ ΤΩεύʔτʹ஌ࣝͱܦݧ͕ूத͢Δ ײ౓ͷ௿Լ ಛఆݸਓͷো֐ରԠͷৗଶԽͰɺଞϝϯόʔͷΞϥʔτ΁ͷײ౓͕௿Լɻ Ξϥʔτʹؾ͕͍ͭͯ΋ղܾͰ͖ͣɺΤεΧϨʔγϣϯ͢Δ೔ৗɻ

Slide 12

Slide 12 text

ヒロイズムなチームとは？ 12 ஌ࣝͱܦݧ ো֐ରԠΛ࣮ࡍʹߦ͍ɺ࠶ൃ๷ࢭࡦͷݕ౼΋཰ઌͯ͠ߦͬͨ ΤΩεύʔτʹ஌ࣝͱܦݧ͕ूத͢Δ ײ౓ͷ௿Լ ಛఆݸਓͷো֐ରԠͷৗଶԽͰɺଞϝϯόʔͷΞϥʔτ΁ͷײ౓͕௿Լɻ Ξϥʔτʹؾ͕͍ͭͯ΋ղܾͰ͖ͣɺΤεΧϨʔγϣϯ͢Δ೔ৗɻ ঝೝཉٻ ࿑͍ͱײँΛड͚ɺ཰ઌͨ͠໰୊ղܾͷ࢟੎͸ࠪఆʹ΋൓өɻ ෛ୲Ͱ͸͋Δ͕ɺঝೝཉٻ΋ຬͨ͞Εɺͦͷঢ়ଶΛվΊʹ͍͘ɻ ·ͨɺଞͷϝϯόʔʹো֐ରԠΛґཔ͢Δ͜ͱࣗମɺԕྀͯ͠͠·͏ɻ

Slide 13

Slide 13 text

ヒロイズムなチームは悪いのか？ 13 SPOFを避けるという意味では、アンチパターンしかし、ビジネス上の理由からスピード優先で、⼀時的に特定個⼈にナレッジが偏るのは仕⽅ないことも。

Slide 14

Slide 14 text

ヒロイズムなチームは悪いのか？ 14 SPOFを避けるという意味では、アンチパターンしかし、ビジネス上の理由からスピード優先で、⼀時的に特定個⼈にナレッジが偏るのは仕⽅ないことも。チームによる持続的な開発を目指すならば、脱却した方が良い

Slide 15

Slide 15 text

ヒロイズムの問題点 15 暗黙知が増えやすい・再発防止の視点が限定的特定個人が常にイレギュラーに対応するため

Slide 16

Slide 16 text

ヒロイズムの問題点 16 暗黙知が増えやすい・再発防止の視点が限定的特定個人が常にイレギュラーに対応するため特定個人の能力に障害対応の品質や速度が律速される常にパフォーマンスを発揮できるとは限らないため

Slide 17

Slide 17 text

ヒロイズムの問題点 17 暗黙知が増えやすい・再発防止の視点が限定的特定個人が常にイレギュラーに対応するため特定個人の能力に障害対応の品質や速度が律速される常にパフォーマンスを発揮できるとは限らないためヒロイズム脱却のインセンティブが当事者に少ないヒーローの承認欲求が満たされやすく、他のメンバーは障害のような割り込み対応を行いたくないため

Slide 18

Slide 18 text

脱ヒロイズムのための3つの事例 18 障害によるReactiveな割込みを減らす Proactiveに状態を確認するSLO Letter文化を定着リバースエンジニアリングの訓練も兼ねる典型的な障害は、誰もが同じように対応できるように台本ベースと実際に障害を発生させる2つの障害訓練を実施 pre-ポストモーテムレビューポストモーテムの品質向上のための共著する仕組み過去のポストモーテムの再読を兼ねる

Slide 19

Slide 19 text

脱ヒロイズムのための3つの事例 19 障害によるReactiveな割込みを減らす Proactiveに状態を確認するSLO Letter文化を定着リバースエンジニアリングの訓練も兼ねる典型的な障害は、誰もが同じように対応できるように台本ベースと実際に障害を発生させる2つの障害訓練を実施 pre-ポストモーテムレビューポストモーテムの品質向上のための共著する仕組み過去のポストモーテムの再読を兼ねる

Slide 20

Slide 20 text

20 Proactiveな対応としての SLO Letter文化 20

Slide 21

Slide 21 text

Proactiveとは？ 21

Slide 22

Slide 22 text

Proactiveな対応としてのSLO Letter文化 22 毎週ダッシュボードを確認して、変化を共有する⽂化 1. ⼀週間のメトリクスの変化を、前週⽐・前⽉⽐で⽐較 2. エラー率・レイテンシ・アクセス数に変化があれば、Slackで共有 3. 変化があれば、リバースエンジニアリングして原因も調査

Slide 23

Slide 23 text

学習のためのリバースエンジニアリング 23 ஌ࣝͱ৘ใ • γεςϜؒͷґଘؔ܎ͷ஌ࣝ • ৽نػೳϩʔϯνͷ৘ใ • Ωϟϯϖʔϯͷ։࢝৘ใ ܇࿅ • ࣮ࡍͷো֐ରԠͱಉ༷ͷϦόʔεΤϯδχΞϦϯάͷ܇࿅ ༧ݟతରॲ • ো֐Λະવʹ๷͛Δ͜ͱ΋

Slide 24

Slide 24 text

SLO Letter文化の定着まで 24 01 • まず一人で始めてみる • 特に相談も合意も取らず、とりあえずやる • ダッシュボードを毎週確認して、調査共有

Slide 25

Slide 25 text

SLO Letter文化の定着まで 25 01 • まず一人で始めてみる • 特に相談も合意も取らず、とりあえずやる • ダッシュボードを毎週確認して、調査共有 02 • チームのルーチンへ • 三ヶ月ほど続けて、認知され当たり前になったらチームのルーチンワークとして提案 • 適宜サポートを実施

Slide 26

Slide 26 text

SLO Letter文化の定着まで 26 01 • まず一人で始めてみる • 特に相談も合意も取らず、とりあえずやる • ダッシュボードを毎週確認して、調査共有 02 • チームのルーチンへ • 三ヶ月ほど続けて、認知され当たり前になったらチームのルーチンワークとして提案 • 適宜サポートを実施このSLO Letter文化(日常的なリバースエンジニアリング)は既に1年継続中

Slide 27

Slide 27 text

脱ヒロイズムのための3つの事例 27 障害によるReactiveな割込みを減らす Proactiveに状態を確認するSLO Letter文化を定着リバースエンジニアリングの訓練も兼ねる典型的な障害は、誰もが同じように対応できるように台本ベースと実際に障害を発生させる2つの障害訓練を実施 pre-ポストモーテムレビューポストモーテムの品質向上のための共著する仕組み過去のポストモーテムの再読を兼ねる

Slide 28

Slide 28 text

28 典型的な障害に普段通り対応するための障害訓練 28

Slide 29

Slide 29 text

障害と対処の分類 29 छྨ ༧๷ ݕ஌ ରॲ աෛՙ • 4DBMBCMFBSDIJUFDUVSF • $BQBDJUZQMBOOJOH • 5PUBMSFRVFTUT • &SSPSSBUF • -BUFODZ • 5ISPUUMJOH • 4DBMJOH )8ো֐ • )BSEXBSFWJSUVBMJ[BUJPO • %JTUSJCVUFEBSDIJUFDUVSF • &SSPSSBUF • -BUFODZ જࡏతͳ48όά • .PEFSOJ[F • 5FTU σϓϩΠ • 5FTU 2" • $PEFGSFF[F ώϡʔϚϯ Τϥʔ • "VUPNBUJPO • 5SBJOJOH • &SSPSSBUF • -BUFODZ • &SSPSSBUF • -BUFODZ • &SSPSSBUF • -BUFODZ • 4FSWJDFPVU • .PWFUPBOPUIFSOPEF • 3FTUBSU • 1BUDI • 3PMMCBDL • )PUGJY • $BTFCZDBTF

Slide 30

Slide 30 text

障害と対処の分類 30 छྨ ༧๷ ݕ஌ ରॲ աෛՙ • 4DBMBCMFBSDIJUFDUVSF • $BQBDJUZQMBOOJOH • 5PUBMSFRVFTUT • &SSPSSBUF • -BUFODZ • 5ISPUUMJOH • 4DBMJOH )8ো֐ • )BSEXBSFWJSUVBMJ[BUJPO • %JTUSJCVUFEBSDIJUFDUVSF • &SSPSSBUF • -BUFODZ જࡏతͳ48όά • .PEFSOJ[F • 5FTU σϓϩΠ • 5FTU 2" • $PEFGSFF[F ώϡʔϚϯ Τϥʔ • "VUPNBUJPO • 5SBJOJOH • &SSPSSBUF • -BUFODZ • &SSPSSBUF • -BUFODZ • &SSPSSBUF • -BUFODZ • 4FSWJDFPVU • .PWFUPBOPUIFSOPEF • 3FTUBSU • 1BUDI • 3PMMCBDL • )PUGJY • $BTFCZDBTF

Slide 31

Slide 31 text

障害訓練第一回目 31 第⼀回⽬の障害訓練の特徴と流れ 1. 事前に過去の障害を元にした台本を準備 2. 訓練時の実作業はエキスパート2名に依頼 3. 実際のシステムには問題を起こさない 4. 台本には、原因や対応⼿順がすべて⽂章で記載 5. Zoomに全員揃った状態からスタートし、台本に従って対応を進⾏初回は作業者のプレッシャー軽減のために、なるべく自由度を下げた障害訓練を実施

Slide 32

Slide 32 text

障害訓練の台本例 1. キャンペーンによるアクセス数増加で過負荷が発生 2. ダッシュボードを確認して、影響範囲を確認 3. 影響範囲がわかり次第、Slackで情報共有 4. API throttlingを実行して、影響範囲を最小化 5. 1台サーバーを追加し、スケールアウト 32

Slide 33

Slide 33 text

エキスパートの経験からくる工夫 33 ੾Γ෼͚ • ෳ਺ͷμογϡϘʔυΛ૊Έ߹ΘͤͯɺݪҼͱӨڹൣғ֬ೝ ঢ়گڞ༗ • ςϯϓϨʔτ͸࢖Θͣɺաڈͷྨࣅͷো֐ใࠂΛվม͠ ਝ଎ʹڞ༗จݴΛ࡞੒ 5ISPUUMJOH • 5ISPUUMJOHͷର৅"1*Λܦݧଇ͔Βܾఆ • ϢʔβʔӨڹ͕খ͘͞ɺޮՌ͕ߴ͍΋ͷΛબผ

Slide 34

Slide 34 text

障害訓練第二回目 34 第⼀回⽬からの変更点 1. ⽇時と担当者のみ事前に決定 2. 台本をなくし、アラートを受けてから対応 3. 実際に開発環境で過負荷による障害を発⽣させた二回目は、実際の障害を可能な範囲で再現。みんなで相談しながら、調査や対処を実施。

Slide 35

Slide 35 text

実際の大まかな流れ 1. 担当者がすぐさまZoom会議を用意 2. 画面共有しながら、原因とユーザー影響を調査 3. ユーザー影響をSlackで報告 4. Throttlingで障害影響を最小化できるか検討 5. Scale outして解決 35 最初の調査時、負荷発生元のインスタンスをIPアドレスから見つけられ直接、そのノードを殺されそうになるアクシデントも・・・ ※ルール違反ということで、見なかったことに

Slide 36

Slide 36 text

脱ヒロイズムのための3つの事例 36 障害によるReactiveな割込みを減らす Proactiveに状態を確認するSLO Letter文化を定着リバースエンジニアリングの訓練も兼ねる典型的な障害は、誰もが同じように対応できるように台本ベースと実際に障害を発生させる2つの障害訓練を実施 pre-ポストモーテムレビューポストモーテムの品質向上のための共著する仕組み過去のポストモーテムの再読を兼ねる

Slide 37

Slide 37 text

37 障害からの学びを最大化するpreポストモーテム 37

Slide 38

Slide 38 text

LINEプラットフォームやスタンプ、公式アカウントでは 38 1. 誰が執筆しますか？ 2. 誰がレビューしますか？ 3. 誰が閲覧できますか？ 4. 上記はいつまでに実施されますか？

Slide 39

Slide 39 text

LINEプラットフォームやスタンプ、公式アカウントでは 39 ドメインエキスパートとそのチームメンバーが執筆必須参加として、LINEのサーバーサイドエンジニアのリーダー20名程度任意参加として、ポストモーテムレビュー会議に招待されるのは200名程度原則、すべて社内でオープン。Slackチャンネルで通知もあり。ポストモーテムを記載できる範囲のみで1営業日以内で、まず共有 5営業日以内に完成させ、ポストモーテムレビュー会議を開催 1. 誰が執筆しますか？ 2. 誰がレビューしますか？ 3. 誰が閲覧できますか？ 4. 上記はいつまでに実施されますか？

Slide 40

Slide 40 text

40 利点 • 知見を広い範囲で共有できる • 他システムについて知る機会チーム横断の大規模なポストモーテムレビュー欠点 • 参加人数が多く、質問しにくい • ドメイン知識の共有に時間がかかる • ドメインに特化した対策は検討しにくい 40

Slide 41

Slide 41 text

41 利点 • 知見を広い範囲で共有できる • 他システムについて知る機会チーム横断の大規模なポストモーテムレビュー欠点 • 参加人数が多く、質問しにくい • ドメイン知識の共有に時間がかかる • ドメインに特化した対策は検討しにくい 41 ⽋点を補うために 1. ポストモーテム⾃体の品質向上 • ⾮ドメインエキスパートでも理解しやすくするため、説明や図を追加 2. ドメインに特化した対策は、事前に⼗分に検討したものを記載

Slide 42

Slide 42 text

ポストモーテムレビューフローの変更 42 ポストモーテムの執筆 preポストモーテムレビュー会議大規模ポストモーテムレビュー会議 • 主にエキスパートが執筆 • 障害の概要・原因・タイムテーブル・再発防止などを一通り記載 • チーム内でレビュー(非ドメインエキスパート含む) • 非ドメインエキスパートでも理解しやすいように仕上げる • ドメイン特化の対策もここで十分検討する • 組織的な再発防止の検討 • ポリシーやプラットフォームの見直しなど • 同じ障害を他チームで発生させないようにするための情報共有 NEW

Slide 43

Slide 43 text

preポストモーテムレビューの進め方 43 初回(1時間ver) 会議前 15分 15分 15分 15分 • SREが過去の類似の障害をリストアップして追記 • ポストモーテムを各自黙読し、コメント • コメントの頭に、「Suggestion」や「Question」を明記 • Questionから順にすべて確認し、すべての疑問を解決 • Suggestionを確認し、ディスカッション • 再発防止策の検討

Slide 44

Slide 44 text

preポストモーテムレビューの進め方 44 二回目以降(30分間ver) 会議前 10分 10分 10分 • SREが過去の類似の障害をリストアップして追記 • 会議前に事前に読み込み&コメント • Questionから順にすべて確認し、すべての疑問を解決 • Suggestionを確認し、ディスカッション • 再発防止策の検討

Slide 45

Slide 45 text

preポストモーテムレビューの3つの効果 45 ϙετϞʔςϜͷ ඼࣭޲্ • ඇυϝΠϯΤΩεύʔτʹ΋ཧղ͠΍͍͢ϙετϞʔςϜʹ࢓্͛Δ • ͦͷ݁Ռɺେن໛ϙετϞʔςϜϨϏϡʔձ͕ٞ୹࣌ؒɾޮՌతͳٞ࿦ʹ ϙετϞʔςϜͷ ڞஶ • ΤΩεύʔτ΍43&͸ɺϙετϞʔςϜͷୟ͖୆Λ࡞Δͱ͜Ζ·Ͱ • ࢓্͛͸νʔϜશମͰߦ͍ɺڞஶ͢Δ͜ͱʹΑͬͯυϝΠϯ஌ࣝΛशಘ աڈͷ ϙετϞʔςϜͷ ֬ೝ • ྨࣅͷো֐ͷϙετϞʔςϜΛಡΉػձͱͯ͠׆༻ • ະணखͩͬͨ࠶ൃ๷ࢭࡦͷ༏ઌ౓ΛվΊΔ͜ͱ΋

Slide 46

Slide 46 text

脱ヒロイズムのための3つの事例 46 障害によるReactiveな割込みを減らす Proactiveに状態を確認するSLO Letter文化を定着リバースエンジニアリングの訓練も兼ねる典型的な障害は、誰もが同じように対応できるように台本ベースと実際に障害を発生させる2つの障害訓練を実施 pre-ポストモーテムレビューポストモーテムの品質向上のための共著する仕組み過去のポストモーテムの再読を兼ねる

Slide 47

Slide 47 text

SRE本28章新人からオンコール担当、そしてその先へ 47 Google SRE本 28章にオンコール担当までの Googleでの教育方法が記載されています。

Slide 48

Slide 48 text

SRE本28章新人からオンコール担当、そしてその先へ 48 Google SRE本 28章にオンコール担当までの Googleでの教育方法が記載されています。今回紹介した3つの改善は、私たち向けにカスタマイズした上でこのように対応しています。 SLO Letter文化 preポストモーテム障害訓練

Slide 49

Slide 49 text

脱ヒロイズムに必要なこととは？新たなオンコール担当の育成の仕組み化 49

Slide 50

Slide 50 text

今回紹介した3つのEnabling事例について 50 私のオンボーディングとEnablingの並⾏ 1ヶ⽉⽬︓SLO Letter開始 3ヶ⽉⽬︓Pre ポストモーテムレビュー開始 3ヶ⽉⽬︓障害訓練台本ベース実施 6ヶ⽉⽬︓障害訓練実障害ベース実施一人目の専任SREとしてオンボーディングしながらチームにSREのプラクティスをEnablingした事例の紹介でした

Slide 51

Slide 51 text

51 Thank you!!