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
550
失敗?それとも学び?
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
4
920
チームと成長するSRE
maruloop
2
1.7k
Other Decks in Technology
See All in Technology
学びの敷居を下げるためにどんな工夫をしたの?
mineo_matsuya
2
200
Cloud Nativeを支える要素技術・プロダクト・プラクティスの歩み / infrastudy-returns-01-amsy810
masayaaoyama
3
370
20240621_フルリモート環境ざっくばらんにご紹介
1210yuichi0
0
290
2024年のRailsと自由について考える
takahashim
7
1.8k
EC2の脆弱性対応で何が使える? Inspector や SSM あたりを整理する #nakanoshima_dev
masahirokawahara
1
150
モノリスから小さなシステムへ / Chatworkシステム移行の現在地と今後について@開発生産性カンファレンス
tanakayuki
0
140
Next.js の fetch 拡張とキャッシュ機構の違いを理解する
ryo_manba
3
540
スクラムチームの品質戦略 1年の歩み
hacomono
PRO
1
130
やさしいITを目指すために
ishity__
0
290
超アナログ中心な印刷会社で「エンジニアリング」を見直す
logica0419
4
150
プロダクト拡大フェーズでプロダクト検証サイクル効率化を目指す過程で見えたもの / Streamlining Product Validation in Growth Phase
kakehashi
2
450
RAG構築におけるKendraとPineconeの使い分け
sonoda_mj
1
120
Featured
See All Featured
Facilitating Awesome Meetings
lara
44
5.7k
Typedesign – Prime Four
hannesfritz
36
2.2k
The Power of CSS Pseudo Elements
geoffreycrofte
63
5.1k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
9k
GraphQLの誤解/rethinking-graphql
sonatard
58
9.5k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
88
46k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
128
32k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.2k
Producing Creativity
orderedlist
PRO
338
39k
Debugging Ruby Performance
tmm1
70
11k
Writing Fast Ruby
sferik
623
60k
Building Adaptive Systems
keathley
33
2k
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 共同創始者