失敗？それとも学び？

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© LY Corporation • 『SREサイトリライアビリティエンジニアリング』 • 第II部第三章リスクの受容 10ページ分 >「3章リスクの受容」は「SREの仕事とはどういうものか」、そして「なぜそのような仕事をするのか」について幅広い見地を得たい方にとっては、最重要となる必読の章です。この章で初めて、「エラーバジェット」の話が出る。 4 SRE関連書籍でのリスク受容の扱い *maru調べ

Slide 5

Slide 5 text

© LY Corporation • 『SLOサービスレベル⽬標』 • 2.3 どの程度の信頼性が必要か • 2.3.1 100%は不要である • 2.3.2 信頼性にはコストがかかるエラーバジェットなどを活⽤して、リスクを受容しながら前に進むための⽅法論を解説しているSLO本は⼀冊丸ごと、リスク受容について語っていると⾔っても過⾔ではない(はず)。また、すでに標語のようになっている、「信頼性100%はない」もリスクを受容せよという意味(なはず)。 5 SRE関連書籍でのリスク受容の扱い *maru調べ

Slide 6

Slide 6 text

© LY Corporation • 『カオスエンジニアリング』 • 1.4 複雑性を受け入れる >カオスエンジニアリングは、(中略)特に複雑なシステム、すなわち非線形で、予測不可能かつ望まざる結果につながりやすいシステムを運用するニーズに対処するものです。「リスク」の定義は、ISO31000では「⽬的に対する不確実さの影響」である。つまり、複雑なシステムを受け⼊れ対処することを解説する「カオスエンジニアリング本」も⼀冊丸ごと、リスク受容について語っていると⾔っても過⾔ではない(はず)。 6 SRE関連書籍でのリスク受容の扱い *maru調べ

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© LY Corporation 1. SLO、エラーバジェットの導⼊や運⽤のHow To部分に注⽬されがち • わざわざ受容したことを共有したりしない 2. SLOの⾒直し、エラーバジェットの⾒直しの議論は、ビジネスに寄りがち • 「私たちのビジネスにとって、このくらいのエラーは許容できる」ぐらいで終わりがち 3. リスクの受容はコモンセンスのように当たり前に実施しがち • 「キャッシュの追加」もデータ鮮度(不整合)リスクの受容だが、すでに当たり前 4. リスクの受容事例/失敗事例は、技術的(ツール的/運⽤的)な参考事例にはなりにくい • 当初受容していたリスクだったが、やっぱり受容できませんでした事例になりがち *maruの想像 9 リスク受容の事例や失敗談をあまり聞かない理由

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© LY Corporation 1. ビジネス上のリスク受容 • 不正利用、想定外利用 2. サービスクオリティ低下を受容 • リッチなスタンプの静止画化たったこの2つの判断とエラーハンドリングの修正だけで、 LINEスタンプ⽤のDBがダウンしていても動く。 *もちろん、talk-server⾃体がダウンすれば動かないが、capability-serverのSLOは低くできる受容すれば⾊々できる 19 最重要機能の LINEスタンプ送信機能

Slide 20

Slide 20 text

© LY Corporation • ここまでの例は、LINEのトーク機能としてのスタンプ • トーク以外にも、LINEスタンプを使える場所が増え始めている • つまり、talk-server以外のクライアントも、capability-serverへアクセスしている • Talk-server以外にも同じようにハンドリングしてもらいたいが、(たぶん)できてない • エラーハンドリングについて連絡してるが、そういう風に実装してくれてないかも • 開発環境でエラーを混ぜても、そもそもエラーに気づかれないかも • 開発中にスタンプを使う機能まで動作確認することが稀ちょっとした悩み 20 最重要機能の LINEスタンプ送信機能 ???? (スタンプ) Capability-server DB エラーハンドリングの推奨の共有方法はなかなか悩ましい

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© LY Corporation • バナー広告表⽰のために、ユーザーのみなし属性を取得する必要がある • この処理が⽐較的不安定なため、エラー時にはバナー広告⾃体を⾮表⽰にする対応を⼊れていた • この機能のリリース当時は、広告主も少なく、ターゲティングしたいニーズも⼩さかった • ビジネス上の重要性も高くはなかった 23 バナー広告表⽰のエラーハンドリングこれは受容したエラーだったため、ポストモーテムなどもしていなかった

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© LY Corporation • 受容できていたリスクも、周辺の変化で受容できなくなることがある • なんとなくの空気でサービス提供していると、⼿遅れになってしまう可能性もある • SLOとは、ユーザーの信頼性 = ビジネス上重要性の指標の明⽂化である • 明⽂化すると定期的に⾒直せるため、ビジネス上の重要性について開発チームで共通認識を持てる(はず) • SLOを定期的に⾒直す”⼈”も重要 25 ビジネスの成⻑で影響度は変化する

Slide 26

Slide 26 text

Slide 27

Slide 27 text