Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

LINE Developers

May 14, 2022
Tweet

More Decks by LINE Developers

Other Decks in Technology

Transcript

  1. 自己紹介 1 @maruloop 名前 HN 経歴 趣味 加藤 俊弥 maru

    • 2020年12月にLINEに入社 • LINEスタンプおよび関連システムのSREを担当 漫画、ゲーム、アニメ
  2. ヒロイズムなチームとは? 9 障害解決 • メンバーからは感謝と労い • 再発防止もエキスパートが率先して検討 • 最もシステムに詳しく、障害対応を行った エキスパートが率先して、再発防止の検討

    • メンバーからは提案や質問は特になし 障害発生 • エキスパートが一番に反応 • すぐにエキスパートが調査・対応開始 • ユーザー影響が小さくても • 単純な作業で終わる場合でも • エキスパートが最も迅速に解決できるため
  3. SLO Letter文化の定着まで 25 01 • まず一人で始めてみる • 特に相談も合意も取らず、とりあえずやる • ダッシュボードを毎週確認して、調査共有

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

    02 • チームのルーチンへ • 三ヶ月ほど続けて、認知され当たり前になったら チームのルーチンワークとして提案 • 適宜サポートを実施 このSLO Letter文化(日常的なリバースエンジニアリング)は 既に1年継続中
  5. 障害と対処の分類 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
  6. 障害と対処の分類 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
  7. 障害訓練 第一回目 31 第⼀回⽬の障害訓練の特徴と流れ 1. 事前に過去の障害を元にした台本を準備 2. 訓練時の実作業はエキスパート2名に依頼 3. 実際のシステムには問題を起こさない

    4. 台本には、原因や対応⼿順がすべて⽂章で記載 5. Zoomに全員揃った状態からスタートし、台本に従って対応を進⾏ 初回は作業者のプレッシャー軽減のために、 なるべく自由度を下げた障害訓練を実施
  8. 実際の大まかな流れ 1. 担当者がすぐさまZoom会議を用意 2. 画面共有しながら、原因とユーザー影響を調査 3. ユーザー影響をSlackで報告 4. Throttlingで障害影響を最小化できるか検討 5.

    Scale outして解決 35 最初の調査時、負荷発生元のインスタンスをIPアドレスから見つけられ 直接、そのノードを殺されそうになるアクシデントも・・・ ※ルール違反ということで、見なかったことに
  9. 41 利点 • 知見を広い範囲で共有できる • 他システムについて知る機会 チーム横断の大規模なポストモーテムレビュー 欠点 • 参加人数が多く、質問しにくい

    • ドメイン知識の共有に時間がかかる • ドメインに特化した対策は検討しにくい 41 ⽋点を補うために 1. ポストモーテム⾃体の品質向上 • ⾮ドメインエキスパートでも理解しやすくするため、説明や図を追加 2. ドメインに特化した対策は、事前に⼗分に検討したものを記載
  10. ポストモーテムレビューフローの変更 42 ポストモーテムの執筆 preポストモーテム レビュー会議 大規模ポストモーテム レビュー会議 • 主にエキスパートが執筆 •

    障害の概要・原因・タイムテーブル・再発防止などを一通り記載 • チーム内でレビュー(非ドメインエキスパート含む) • 非ドメインエキスパートでも理解しやすいように仕上げる • ドメイン特化の対策もここで十分検討する • 組織的な再発防止の検討 • ポリシーやプラットフォームの見直しなど • 同じ障害を他チームで発生させないようにするための情報共有 NEW
  11. preポストモーテムレビューの進め方 43 初回(1時間ver) 会議前 15分 15分 15分 15分 • SREが過去の類似の障害をリストアップして追記

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

    会議前に事前に読み込み&コメント • Questionから順にすべて確認し、すべての疑問を解決 • Suggestionを確認し、ディスカッション • 再発防止策の検討
  13. preポストモーテムレビューの3つの効果 45 ϙετϞʔςϜͷ ඼࣭޲্ • ඇυϝΠϯΤΩεύʔτʹ΋ཧղ͠΍͍͢ϙετϞʔςϜʹ࢓্͛Δ • ͦͷ݁Ռɺେن໛ϙετϞʔςϜϨϏϡʔձ͕ٞ୹࣌ؒɾޮՌతͳٞ࿦ʹ ϙετϞʔςϜͷ ڞஶ

    • ΤΩεύʔτ΍43&͸ɺϙετϞʔςϜͷୟ͖୆Λ࡞Δͱ͜Ζ·Ͱ • ࢓্͛͸νʔϜશମͰߦ͍ɺڞஶ͢Δ͜ͱʹΑͬͯυϝΠϯ஌ࣝΛशಘ աڈͷ ϙετϞʔςϜͷ ֬ೝ • ྨࣅͷো֐ͷϙετϞʔςϜΛಡΉػձͱͯ͠׆༻ • ະணखͩͬͨ࠶ൃ๷ࢭࡦͷ༏ઌ౓ΛվΊΔ͜ͱ΋