失敗？それとも学び？

at https://yuru-sre.connpass.com/event/293783/

Transcript

1. © LY Corporation 失敗？それとも学び？ LINEスタンプや着せかえ、絵⽂字、ホームタブ、ウォレットタブのSRE maru
2. © LY Corporation 2 ゆるSRE
3. © LY Corporation リスクの受容について、 もっと話を聞きたいんです 3
4. © LY Corporation • 『SREサイトリライアビリティエンジニアリング』 • 第II部第三章リスクの受容 10ページ分 >「3章 リスクの受容」は「SREの仕事とはどういうものか」、そして「なぜそのような仕事をするの か」について幅広い見地を得たい方にとっては、最重要となる必読の章です。 この章で初めて、「エラーバジェット」の話が出る。 4 SRE関連書籍でのリスク受容の扱い *maru調べ
5. © LY Corporation • 『SLOサービスレベル⽬標』 • 2.3 どの程度の信頼性が必要か • 2.3.1 100%は不要である • 2.3.2 信頼性にはコストがかかる エラーバジェットなどを活⽤して、リスクを受容しながら前に進むための⽅法論を解説しているSLO本は ⼀冊丸ごと、リスク受容について語っていると⾔っても過⾔ではない(はず)。 また、すでに標語のようになっている、「信頼性100%はない」もリスクを受容せよという意味(なはず)。 5 SRE関連書籍でのリスク受容の扱い *maru調べ
6. © LY Corporation • 『カオスエンジニアリング』 • 1.4 複雑性を受け入れる >カオスエンジニアリングは、(中略)特に複雑なシステム、すなわち非線形で、予測不可能かつ望まざ る結果につながりやすいシステムを運用するニーズに対処するものです。 「リスク」の定義は、ISO31000では「⽬的に対する不確実さの影響」である。 つまり、複雑なシステムを受け⼊れ対処することを解説する「カオスエンジニアリング本」も ⼀冊丸ごと、リスク受容について語っていると⾔っても過⾔ではない(はず)。 6 SRE関連書籍でのリスク受容の扱い *maru調べ
7. © LY Corporation • 『SREエンタープライズロードマップ』 • 第三章2項 リスクの受容 0.5ページ分 エンタープライズ向けの資料でも、特に強調して説明がされている。 7 SRE関連書籍でのリスク受容の扱い *maru調べ
8. © LY Corporation ここまで関連のあるトピックなのに リスク受容の事例、 特に失敗談をあまり聞かない 8
9. © LY Corporation 1. SLO、エラーバジェットの導⼊や運⽤のHow To部分に注⽬されがち • わざわざ受容したことを共有したりしない 2. SLOの⾒直し、エラーバジェットの⾒直しの議論は、ビジネスに寄りがち • 「私たちのビジネスにとって、このくらいのエラーは許容できる」ぐらいで終わりがち 3. リスクの受容はコモンセンスのように当たり前に実施しがち • 「キャッシュの追加」もデータ鮮度(不整合)リスクの受容だが、すでに当たり前 4. リスクの受容事例/失敗事例は、技術的(ツール的/運⽤的)な参考事例にはなりにくい • 当初受容していたリスクだったが、やっぱり受容できませんでした事例になりがち *maruの想像 9 リスク受容の事例や失敗談をあまり聞かない理由
10. © LY Corporation ”ゆる”SREなので、技術的に参考にならなくても良いはず リスク受容について みなさん語りましょう 10
11. © LY Corporation ⾔い出しっぺの法則 11
12. © LY Corporation 01. 最重要機能でのリスク受容事例 12 02. ビジネスの成⻑によるリスク受容失敗事例
13. © LY Corporation 01. 最重要機能でのリスク受容事例 13 02. ビジネスの成⻑によるリスク受容失敗事例
14. © LY Corporation 14 最重要機能のLINEスタンプ送信機能 Talk-server (スタンプ) Capability-server DB Text messageやスタンプ の送信を受け取る スタンプの所有権や有効期限などを確認して、 送信可否判断をする
15. © LY Corporation 15 最重要機能の LINEスタンプ送信機能 Talk-server (スタンプ) Capability-server DB もしDBが死んで、エラーを返さざるを得なくなったら？
16. © LY Corporation 16 最重要機能の LINEスタンプ送信機能 Talk-server (スタンプ) Capability-server DB もしDBが死んで、エラーを返さざるを得なくなったら？ Error Success Talk-serverはクライアントには成功を返すため、 ユーザーは正常にスタンプを送信できる。
17. © LY Corporation 17 最重要機能の LINEスタンプ送信機能 Talk-server (スタンプ) Capability-server DB Error Success 下記のリスクは受容している • 所有権などの確認を省略しているので、不正利用のリスク • スタンプ有効期限の確認を省略しているので、想定外利用のリスク
18. © LY Corporation Graceful degradation(上品な劣化) 18 最重要機能の LINEスタンプ送信機能 アニメーションスタンプなど、特別なスタンプも障害時は静止画スタンプ化。 *障害時は、アニメーションフラグなどをDBから適切に検証できないため
19. © LY Corporation 1. ビジネス上のリスク受容 • 不正利用、想定外利用 2. サービスクオリティ低下を受容 • リッチなスタンプの静止画化 たったこの2つの判断とエラーハンドリングの修正だけで、 LINEスタンプ⽤のDBがダウンしていても動く。 *もちろん、talk-server⾃体がダウンすれば動かないが、capability-serverのSLOは低くできる 受容すれば⾊々できる 19 最重要機能の LINEスタンプ送信機能
20. © LY Corporation • ここまでの例は、LINEのトーク機能としてのスタンプ • トーク以外にも、LINEスタンプを使える場所が増え始めている • つまり、talk-server以外のクライアントも、capability-serverへアクセスしている • Talk-server以外にも同じようにハンドリングしてもらいたいが、(たぶん)できてない • エラーハンドリングについて連絡してるが、そういう風に実装してくれてないかも • 開発環境でエラーを混ぜても、そもそもエラーに気づかれないかも • 開発中にスタンプを使う機能まで動作確認することが稀 ちょっとした悩み 20 最重要機能の LINEスタンプ送信機能 ???? (スタンプ) Capability-server DB エラーハンドリングの推奨の共有方法はなかなか悩ましい
21. © LY Corporation 01. 最重要機能でのリスク受容事例 21 02. ビジネスの成⻑によるリスク受容失敗事例
22. © LY Corporation • スタンプショップ内に掲載されるバナー広告 • ユーザーは無料ダウンロードできる • みなし属性(性別など)にターゲティングされる キャラクターの知名度向上などに利⽤される スポンサードターゲティングスタンプ 22
23. © LY Corporation • バナー広告表⽰のために、ユーザーのみなし属性を取得する必要がある • この処理が⽐較的不安定なため、エラー時にはバナー広告⾃体を⾮表⽰にする対応を⼊れていた • この機能のリリース当時は、広告主も少なく、ターゲティングしたいニーズも⼩さかった • ビジネス上の重要性も高くはなかった 23 バナー広告表⽰のエラーハンドリング これは受容したエラーだったため、ポストモーテムなどもしていなかった
24. © LY Corporation • リデザインやリブランディングを経て、ターゲティングに⾼いニーズを持つ広告主が増加 • ビジネス上の重要性も向上 したが… • 当時の判断のままのエラーハンドリングが継続されており、ある時問題に 24 ビジネスの成⻑とともに… 受容したつもりだった、過去の障害まで数ヶ月遡ってポストモーテム…
25. © LY Corporation • 受容できていたリスクも、周辺の変化で受容できなくなることがある • なんとなくの空気でサービス提供していると、⼿遅れになってしまう可能性もある • SLOとは、ユーザーの信頼性 = ビジネス上重要性の指標の明⽂化である • 明⽂化すると定期的に⾒直せるため、ビジネス上の重要性について開発チームで共通認識を持てる(はず) • SLOを定期的に⾒直す”⼈”も重要 25 ビジネスの成⻑で影響度は変化する
26. © LY Corporation • 現実問題として、細かなすべての機能にSLOを定義して運⽤していくのはしんどい • 今できることは、 いつでもビジネスについて話せるように 開発/事業(企画)と強い連携をとり続けること 26 ビジネスの成⻑で影響度は変化する
27. © LY Corporation “信頼性は会話です” David N. Blank-Edelman 『SREの探求』キュレーター/編集者、SREcon 共同創始者