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
ワークロードを処理しないプラットフォームに専念する
maruloop
0
36
When Walking like SREs
maruloop
6
1.7k
チームと成長するSRE
maruloop
2
2.1k
Other Decks in Technology
See All in Technology
S3アクセス制御の設計ポイント
tommy0124
3
200
職種の壁を溶かして開発サイクルを高速に回す~情報透明性と職種越境から考えるAIフレンドリーな職種間連携~
daitasu
0
170
「全員プロダクトマネージャー」を実現する、Cursorによる仕様検討の自動運転
applism118
22
12k
COVESA VSSによる車両データモデルの標準化とAWS IoT FleetWiseの活用
osawa
1
390
AIエージェントで90秒の広告動画を制作!台本・音声・映像・編集をつなぐAWS最新アーキテクチャの実践
nasuvitz
3
340
[ JAWS-UG 東京 CommunityBuilders Night #2 ]SlackとAmazon Q Developerで 運用効率化を模索する
sh_fk2
3
460
JTCにおける内製×スクラム開発への挑戦〜内製化率95%達成の舞台裏/JTC's challenge of in-house development with Scrum
aeonpeople
0
250
新規プロダクトでプロトタイプから正式リリースまでNext.jsで開発したリアル
kawanoriku0
1
200
Modern Linux
oracle4engineer
PRO
0
160
エンジニアリングマネージャーの成長の道筋とキャリア / Developers Summit 2025 KANSAI
daiksy
3
950
ブロックテーマ時代における、テーマの CSS について考える Toro_Unit / 2025.09.13 @ Shinshu WordPress Meetup
torounit
0
130
はじめてのOSS開発からみえたGo言語の強み
shibukazu
3
970
Featured
See All Featured
Designing Experiences People Love
moore
142
24k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Site-Speed That Sticks
csswizardry
10
820
Music & Morning Musume
bryan
46
6.8k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Done Done
chrislema
185
16k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
The Straight Up "How To Draw Better" Workshop
denniskardys
236
140k
Being A Developer After 40
akosma
90
590k
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 共同創始者