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.7k
チームと成長するSRE
maruloop
2
2.1k
Other Decks in Technology
See All in Technology
TS-S205_昨年対比2倍以上の機能追加を実現するデータ基盤プロジェクトでのAI活用について
kaz3284
1
150
下手な強制、ダメ!絶対! 「ガードレール」を「檻」にさせない"ガバナンス"の取り方とは?
tsukaman
2
450
要件定義・デザインフェーズでもAIを活用して、コミュニケーションの密度を高める
kazukihayase
0
110
[ JAWS-UG 東京 CommunityBuilders Night #2 ]SlackとAmazon Q Developerで 運用効率化を模索する
sh_fk2
3
430
自作JSエンジンに推しプロポーザルを実装したい!
sajikix
1
180
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
260
Agile PBL at New Grads Trainings
kawaguti
PRO
1
430
スマートファクトリーの第一歩 〜AWSマネージドサービスで 実現する予知保全と生成AI活用まで
ganota
2
220
BPaaSにおける人と協働する前提のAIエージェント-AWS登壇資料
kentarofujii
0
140
AWSで始める実践Dagster入門
kitagawaz
1
620
テストを軸にした生き残り術
kworkdev
PRO
0
200
RSCの時代にReactとフレームワークの境界を探る
uhyo
10
3.4k
Featured
See All Featured
What's in a price? How to price your products and services
michaelherold
246
12k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
188
55k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Statistics for Hackers
jakevdp
799
220k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.6k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
810
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 共同創始者