Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
失敗?それとも学び?
Search
maru
October 23, 2023
Technology
1
760
失敗?それとも学び?
at
https://yuru-sre.connpass.com/event/293783/
maru
October 23, 2023
Tweet
Share
More Decks by maru
See All by maru
When Walking like SREs
maruloop
6
1.6k
チームと成長するSRE
maruloop
2
2.1k
Other Decks in Technology
See All in Technology
生成AI利用プログラミング:誰でもプログラムが書けると 世の中どうなる?/opencampus202508
okana2ki
0
180
JOAI発表資料 @ 関東kaggler会
joai_committee
1
180
Exadata Database Service on Dedicated Infrastructure セキュリティ、ネットワーク、および管理について
oracle4engineer
PRO
1
350
AWSの最新サービスでAIエージェント構築に楽しく入門しよう
minorun365
PRO
10
570
GCASアップデート(202506-202508)
techniczna
0
230
マイクロモビリティシェアサービスを支える プラットフォームアーキテクチャ
grimoh
1
150
LLM時代の検索とコンテキストエンジニアリング
shibuiwilliam
2
1.1k
2025新卒研修・Webアプリケーションセキュリティ #弁護士ドットコム
bengo4com
3
10k
Amazon Bedrock AgentCore でプロモーション用動画生成エージェントを開発する
nasuvitz
6
360
20250818_KGX・One Hokkaidoコラボイベント
tohgeyukihiro
0
130
ZOZOTOWNフロントエンドにおけるディレクトリの分割戦略
zozotech
PRO
3
300
Telemetry APIから学ぶGoogle Cloud ObservabilityとOpenTelemetryの現在 / getting-started-telemetry-api-with-google-cloud
k6s4i53rx
0
170
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
338
57k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
20k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
Optimizing for Happiness
mojombo
379
70k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Building Applications with DynamoDB
mza
96
6.6k
Thoughts on Productivity
jonyablonski
69
4.8k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Speed Design
sergeychernyshev
32
1.1k
Transcript
© LY Corporation 失敗?それとも学び? LINEスタンプや着せかえ、絵⽂字、ホームタブ、ウォレットタブのSRE maru
© LY Corporation 2 ゆるSRE
© LY Corporation リスクの受容について、 もっと話を聞きたいんです 3
© LY Corporation • 『SREサイトリライアビリティエンジニアリング』 • 第II部第三章リスクの受容 10ページ分 >「3章 リスクの受容」は「SREの仕事とはどういうものか」、そして「なぜそのような仕事をするの
か」について幅広い見地を得たい方にとっては、最重要となる必読の章です。 この章で初めて、「エラーバジェット」の話が出る。 4 SRE関連書籍でのリスク受容の扱い *maru調べ
© LY Corporation • 『SLOサービスレベル⽬標』 • 2.3 どの程度の信頼性が必要か • 2.3.1
100%は不要である • 2.3.2 信頼性にはコストがかかる エラーバジェットなどを活⽤して、リスクを受容しながら前に進むための⽅法論を解説しているSLO本は ⼀冊丸ごと、リスク受容について語っていると⾔っても過⾔ではない(はず)。 また、すでに標語のようになっている、「信頼性100%はない」もリスクを受容せよという意味(なはず)。 5 SRE関連書籍でのリスク受容の扱い *maru調べ
© LY Corporation • 『カオスエンジニアリング』 • 1.4 複雑性を受け入れる >カオスエンジニアリングは、(中略)特に複雑なシステム、すなわち非線形で、予測不可能かつ望まざ る結果につながりやすいシステムを運用するニーズに対処するものです。
「リスク」の定義は、ISO31000では「⽬的に対する不確実さの影響」である。 つまり、複雑なシステムを受け⼊れ対処することを解説する「カオスエンジニアリング本」も ⼀冊丸ごと、リスク受容について語っていると⾔っても過⾔ではない(はず)。 6 SRE関連書籍でのリスク受容の扱い *maru調べ
© LY Corporation • 『SREエンタープライズロードマップ』 • 第三章2項 リスクの受容 0.5ページ分 エンタープライズ向けの資料でも、特に強調して説明がされている。
7 SRE関連書籍でのリスク受容の扱い *maru調べ
© LY Corporation ここまで関連のあるトピックなのに リスク受容の事例、 特に失敗談をあまり聞かない 8
© LY Corporation 1. SLO、エラーバジェットの導⼊や運⽤のHow To部分に注⽬されがち • わざわざ受容したことを共有したりしない 2. SLOの⾒直し、エラーバジェットの⾒直しの議論は、ビジネスに寄りがち
• 「私たちのビジネスにとって、このくらいのエラーは許容できる」ぐらいで終わりがち 3. リスクの受容はコモンセンスのように当たり前に実施しがち • 「キャッシュの追加」もデータ鮮度(不整合)リスクの受容だが、すでに当たり前 4. リスクの受容事例/失敗事例は、技術的(ツール的/運⽤的)な参考事例にはなりにくい • 当初受容していたリスクだったが、やっぱり受容できませんでした事例になりがち *maruの想像 9 リスク受容の事例や失敗談をあまり聞かない理由
© LY Corporation ”ゆる”SREなので、技術的に参考にならなくても良いはず リスク受容について みなさん語りましょう 10
© LY Corporation ⾔い出しっぺの法則 11
© LY Corporation 01. 最重要機能でのリスク受容事例 12 02. ビジネスの成⻑によるリスク受容失敗事例
© LY Corporation 01. 最重要機能でのリスク受容事例 13 02. ビジネスの成⻑によるリスク受容失敗事例
© LY Corporation 14 最重要機能のLINEスタンプ送信機能 Talk-server (スタンプ) Capability-server DB Text
messageやスタンプ の送信を受け取る スタンプの所有権や有効期限などを確認して、 送信可否判断をする
© LY Corporation 15 最重要機能の LINEスタンプ送信機能 Talk-server (スタンプ) Capability-server DB
もしDBが死んで、エラーを返さざるを得なくなったら?
© LY Corporation 16 最重要機能の LINEスタンプ送信機能 Talk-server (スタンプ) Capability-server DB
もしDBが死んで、エラーを返さざるを得なくなったら? Error Success Talk-serverはクライアントには成功を返すため、 ユーザーは正常にスタンプを送信できる。
© LY Corporation 17 最重要機能の LINEスタンプ送信機能 Talk-server (スタンプ) Capability-server DB
Error Success 下記のリスクは受容している • 所有権などの確認を省略しているので、不正利用のリスク • スタンプ有効期限の確認を省略しているので、想定外利用のリスク
© LY Corporation Graceful degradation(上品な劣化) 18 最重要機能の LINEスタンプ送信機能 アニメーションスタンプなど、特別なスタンプも障害時は静止画スタンプ化。 *障害時は、アニメーションフラグなどをDBから適切に検証できないため
© LY Corporation 1. ビジネス上のリスク受容 • 不正利用、想定外利用 2. サービスクオリティ低下を受容 •
リッチなスタンプの静止画化 たったこの2つの判断とエラーハンドリングの修正だけで、 LINEスタンプ⽤のDBがダウンしていても動く。 *もちろん、talk-server⾃体がダウンすれば動かないが、capability-serverのSLOは低くできる 受容すれば⾊々できる 19 最重要機能の LINEスタンプ送信機能
© LY Corporation • ここまでの例は、LINEのトーク機能としてのスタンプ • トーク以外にも、LINEスタンプを使える場所が増え始めている • つまり、talk-server以外のクライアントも、capability-serverへアクセスしている •
Talk-server以外にも同じようにハンドリングしてもらいたいが、(たぶん)できてない • エラーハンドリングについて連絡してるが、そういう風に実装してくれてないかも • 開発環境でエラーを混ぜても、そもそもエラーに気づかれないかも • 開発中にスタンプを使う機能まで動作確認することが稀 ちょっとした悩み 20 最重要機能の LINEスタンプ送信機能 ???? (スタンプ) Capability-server DB エラーハンドリングの推奨の共有方法はなかなか悩ましい
© LY Corporation 01. 最重要機能でのリスク受容事例 21 02. ビジネスの成⻑によるリスク受容失敗事例
© LY Corporation • スタンプショップ内に掲載されるバナー広告 • ユーザーは無料ダウンロードできる • みなし属性(性別など)にターゲティングされる キャラクターの知名度向上などに利⽤される
スポンサードターゲティングスタンプ 22
© LY Corporation • バナー広告表⽰のために、ユーザーのみなし属性を取得する必要がある • この処理が⽐較的不安定なため、エラー時にはバナー広告⾃体を⾮表⽰にする対応を⼊れていた • この機能のリリース当時は、広告主も少なく、ターゲティングしたいニーズも⼩さかった •
ビジネス上の重要性も高くはなかった 23 バナー広告表⽰のエラーハンドリング これは受容したエラーだったため、ポストモーテムなどもしていなかった
© LY Corporation • リデザインやリブランディングを経て、ターゲティングに⾼いニーズを持つ広告主が増加 • ビジネス上の重要性も向上 したが… • 当時の判断のままのエラーハンドリングが継続されており、ある時問題に
24 ビジネスの成⻑とともに… 受容したつもりだった、過去の障害まで数ヶ月遡ってポストモーテム…
© LY Corporation • 受容できていたリスクも、周辺の変化で受容できなくなることがある • なんとなくの空気でサービス提供していると、⼿遅れになってしまう可能性もある • SLOとは、ユーザーの信頼性 =
ビジネス上重要性の指標の明⽂化である • 明⽂化すると定期的に⾒直せるため、ビジネス上の重要性について開発チームで共通認識を持てる(はず) • SLOを定期的に⾒直す”⼈”も重要 25 ビジネスの成⻑で影響度は変化する
© LY Corporation • 現実問題として、細かなすべての機能にSLOを定義して運⽤していくのはしんどい • 今できることは、 いつでもビジネスについて話せるように 開発/事業(企画)と強い連携をとり続けること 26
ビジネスの成⻑で影響度は変化する
© LY Corporation “信頼性は会話です” David N. Blank-Edelman 『SREの探求』キュレーター/編集者、SREcon 共同創始者