Upgrade to Pro — share decks privately, control downloads, hide ads and more …

SLI, SLOとカオスエンジニアリング、そしてオブザーバビリティ SRE Lounge #12

SLI, SLOとカオスエンジニアリング、そしてオブザーバビリティ SRE Lounge #12

12年に渡ってモニタリング、オブザーバビリティプラットフォームを提供してきたNew Relicに、サービス運用から改善にいたるプラクティ スが詰まっています。プラットフォーム提供を通じ て得た知見はもちろん、New Relic自身を運営してきた知見がまとまったブログ blog.newrelic.com から、より良いSREを実 践するためtipsをいくつか紹介していきます。

Kazunori Otani

May 22, 2020
Tweet

More Decks by Kazunori Otani

Other Decks in Technology

Transcript

  1. ©2008–20 New Relic, Inc. All rights reserved 2 Safe Harbor

    This presentation and the information herein (including any information that may be incorporated by reference) is provided for informational purposes only and should not be construed as an offer, commitment, promise or obligation on behalf of New Relic, Inc. (“New Relic”) to sell securities or deliver any product, material, code, functionality, or other feature. Any information provided hereby is proprietary to New Relic and may not be replicated or disclosed without New Relic’s express written permission. Such information may contain forward-looking statements within the meaning of federal securities laws. Any statement that is not a historical fact or refers to expectations, projections, future plans, objectives, estimates, goals, or other characterizations of future events is a forward-looking statement. These forward-looking statements can often be identified as such because the context of the statement will include words such as “believes,” “anticipates,” “expects” or words of similar import. Actual results may differ materially from those expressed in these forward-looking statements, which speak only as of the date hereof, and are subject to change at any time without notice. Existing and prospective investors, customers and other third parties transacting business with New Relic are cautioned not to place undue reliance on this forward-looking information. The achievement or success of the matters covered by such forward-looking statements are based on New Relic’s current assumptions, expectations, and beliefs and are subject to substantial risks, uncertainties, assumptions, and changes in circumstances that may cause the actual results, performance, or achievements to differ materially from those expressed or implied in any forward-looking statement. Further information on factors that could affect such forward-looking statements is included in the filings New Relic makes with the SEC from time to time. Copies of these documents may be obtained by visiting New Relic’s Investor Relations website at ir.newrelic.com or the SEC’s website at www.sec.gov. New Relic assumes no obligation and does not intend to update these forward-looking statements, except as required by law. New Relic makes no warranties, expressed or implied, in this presentation or otherwise, with respect to the information provided.
  2. 3 ©2008–19 New Relic, Inc. All rights reserved 大谷 和紀(おおたに

    かずのり) • @katzchang • New Relic株式会社 Senior Customer Success Manager • 略歴 ◦ SI業界 7年 ◦ VOYAGE GROUP / Zucks 8年 ◦ New Relic 6.5ヶ月 • 技術バックグラウンド ◦ AWS, Scala, Go, Make • ajito.fm 準レギュラー • / 万年中級者 自己紹介
  3. ©2008–20 New Relic, Inc. All rights reserved 12年に渡ってモニタリング、オブザーバビリティ のプラットフォームを提供してきたNew Relicに

    は、サービスの運用から改善にいたるプラクティ スが詰まっています。プラットフォーム提供を通じ て得た知見はもちろん、New Relic自身を運営 してきた知見がまとまったブログ blog.newrelic.com から、より良いSREを実 践するためのtipsをいくつか紹介していきます。 5 今日のあらすじ
  4. ©2008–20 New Relic, Inc. All rights reserved 8 モダンなシステムにSLI/SLOを設定するときのベストプラクティス 1.

    SLI, SLOをどのように定義するか 2. システムの境界にSLIとSLOを設定する 3. SLIとSLOの始め方 4. 機能がSLIを駆動する 5. SLIは可用性の広範なプロキシ 6. それぞれの論理的ユニット毎にSLOを定義する 7. 顧客体験を測定し、SLI/SLOを理解する 8. ハードの依存関係には強いSLOが必要 9. 最後に、全体的にチェックしよう https://blog.newrelic.co.jp/engineering/best-practices-for-setting-slos-and-slis-for-modern-complex-systems/
  5. ©2008–20 New Relic, Inc. All rights reserved 9 New Relic流、オンコールとインシデント対応の成功への道

    1. DevOpsプラクティスを採用し、浸透させる 2. 自主性を持ちつつ説明責任を果たす 3. オンコールのパフォーマンスを追跡・計測する 4. オンコール担当者がいなくなると何が起こるのか 5. 顧客よりも先にインシデントを発見する 6. インシデントの深刻度を評価するシステムを開発する 7. 対応チームのロールを定義し、アサインする 8. インシデント対応シナリオを用意する 9. 最善を望み、最悪に備える 10. インシデントによって学び、改善し、成長する 11. Don’t Repeat Incidents (DRI) を実施する https://blog.newrelic.co.jp/engineering/on-call-and-incident-response-new-relic-best-practices-2/
  6. ©2008–20 New Relic, Inc. All rights reserved 10 New Relic流、オンコールとインシデント対応の成功への道

    1. DevOpsプラクティスを採用し、浸透させる 2. 自主性を持ちつつ説明責任を果たす 3. オンコールのパフォーマンスを追跡・計測する 4. オンコール担当者がいなくなると何が起こるのか 5. 顧客よりも先にインシデントを発見する 6. インシデントの深刻度を評価するシステムを開発する 7. 対応チームのロールを定義し、アサインする 8. インシデント対応シナリオを用意する 9. 最善を望み、最悪に備える 10. インシデントによって学び、改善し、成長する 11. Don’t Repeat Incidents (DRI) を実施する https://blog.newrelic.co.jp/engineering/on-call-and-incident-response-new-relic-best-practices-2/
  7. ©2008–20 New Relic, Inc. All rights reserved 11 New Relic流、オンコールとインシデント対応の成功への道

    1. DevOpsプラクティスを採用し、浸透させる 2. 自主性を持ちつつ説明責任を果たす 3. オンコールのパフォーマンスを追跡・計測する 4. オンコール担当者がいなくなると何が起こるのか 5. 顧客よりも先にインシデントを発見する 6. インシデントの深刻度を評価するシステムを開発する 7. 対応チームのロールを定義し、アサインする 8. インシデント対応シナリオを用意する 9. 最善を望み、最悪に備える 10. インシデントによって学び、改善し、成長する 11. Don’t Repeat Incidents (DRI) を実施する https://blog.newrelic.co.jp/engineering/on-call-and-incident-response-new-relic-best-practices-2/
  8. ©2008–18 New Relic, Inc. All rights reserved 12 Two Roles

    “Pure” SRE Build and support our core internal platform: Container Fabric Networking Systems Embedded SRE Partner with Eng Teams Domain Experts in: Reliability Tooling Scaling @ToriWieldt Reliability Awareness Reliability Fitness https://www.slideshare.net/ToriWieldt/sreiously-defining-the-principles-habits-and-practices-of-site-reliability-engineering
  9. ©2008–20 New Relic, Inc. All rights reserved 1. プロアクティブな異常検知 2.

    アラートノイズと疲労を軽減 13 New Relic AIの一般提供を発表: 多忙なDevOpsチームおよびSREチームのため のAIOpsとインシデントレスポンスの高速化 https://blog.newrelic.co.jp/product-news/announcing-new-relic-ai-general-availability/
  10. ©2008–20 New Relic, Inc. All rights reserved 1. プロアクティブな異常検知 2.

    アラートノイズと疲労を軽減 14 New Relic AIの一般提供を発表: 多忙なDevOpsチームおよびSREチームのため のAIOpsとインシデントレスポンスの高速化 https://blog.newrelic.co.jp/product-news/announcing-new-relic-ai-general-availability/
  11. ©2008–20 New Relic, Inc. All rights reserved 1. プロアクティブな異常検知 2.

    アラートノイズと疲労を軽減 15 New Relic AIの一般提供を発表: 多忙なDevOpsチームおよびSREチームのため のAIOpsとインシデントレスポンスの高速化 https://blog.newrelic.co.jp/product-news/announcing-new-relic-ai-general-availability/
  12. ©2008–20 New Relic, Inc. All rights reserved 1. ただのテストではない: 知識を創造する実験である

    a. 「定常状態」を定義して測定する b. 仮説を立てる。他の実験と同様に、テストのための仮説が必要 c. 現実で起こり得ることをシミュレートする d. 仮説を証明/反証する 2. システムを壊すのではない、学んで改善しよう 16 5分で学ぶ: カオスエンジニアリングの説明書 https://blog.newrelic.co.jp/engineering/chaos-engineering-explained/
  13. ©2008–20 New Relic, Inc. All rights reserved 1. Shedding workload(ワークロードを落とせ)

    2. Time shifting workloads(ワークロードを遅らせろ) 3. Reducing quality of service(サービスの品質を落とせ) 4. Adding more capacity(キャパを追加しろ) 最新のソフトウェアの究極の約束は 100% のアップタイムですが、SRE および DevOps チームは、避けられない、しかし予想されるシステムのワークロード・パターンや複雑な 障害モードに備えなければなりません。アプリケーションを設計する際にこれらの要因 を考慮に入れておけば、回復力があり、劣化に強いシステムを構築するための準備が 整います。うまくいけば、稼働時間に影響を与えることなく、システムを構築することが できます。 19 Four Considerations When Designing Systems For Graceful Degradation https://blog.newrelic.com/engineering/design-software-for-graceful-degradation/
  14. ©2008–20 New Relic, Inc. All rights reserved 1. Change as

    a competitive weapon 2. No “pain,” no gain? 3. DevOps fights burnout! アジリティと品質という概念は相反するもののように思われがち • 要求のサイロ化(コストダウン) • Shift to the Leftへの抵抗 • 収益構造への積極的関与 20 2015 State of DevOps: Speed Meets Quality https://blog.newrelic.com/technology/devops-report-puppet-labs/
  15. ©2008–20 New Relic, Inc. All rights reserved 1. Change as

    a competitive weapon 2. No “pain,” no gain? 3. DevOps fights burnout! 21 2015 State of DevOps: Speed Meets Quality https://blog.newrelic.com/technology/devops-report-puppet-labs/
  16. ©2008–20 New Relic, Inc. All rights reserved 1. Change as

    a competitive weapon 2. No “pain,” no gain? 3. DevOps fights burnout! 22 2015 State of DevOps: Speed Meets Quality https://blog.newrelic.com/technology/devops-report-puppet-labs/
  17. ©2008–20 New Relic, Inc. All rights reserved 23 2015 State

    of DevOps: Speed Meets Quality https://blog.newrelic.com/technology/devops-report-puppet-labs/
  18. ©2008–20 New Relic, Inc. All rights reserved 1. Our PRs

    are polite 2. Our PRs don’t include many back-and-forth exchanges 3. Our PRs are readable 4. Our PRs are well-tested—by robots 5. Our PRs are well-tested—by humans 6. Our PRs contain only the needed changes 7. Our PRs add instrumentation すべてのマネージャーは、幸せで生産性の高い、高機能なチームを率いることを夢見ていま す。私は自分のチームの成功を自分の手柄にしたいと思っていますが、彼らが一緒に仕事を していることは、実はNew Relicのエンジニアリング文化と実践の証であることを知っていま す。そして、健全なコーディング文化が有機的に成長していくのを見て、それに参加することに とてもやりがいを感じています。 24 Seven Reasons Why I Read My Team’s Pull Requests https://blog.newrelic.com/culture/pull-requests-team-health/
  19. ©2008–20 New Relic, Inc. All rights reserved 1. Our PRs

    are polite 2. Our PRs don’t include many back-and-forth exchanges 3. Our PRs are readable 4. Our PRs are well-tested—by robots 5. Our PRs are well-tested—by humans 6. Our PRs contain only the needed changes 7. Our PRs add instrumentation 25 Seven Reasons Why I Read My Team’s Pull Requests https://blog.newrelic.com/culture/pull-requests-team-health/
  20. ©2008–20 New Relic, Inc. All rights reserved 1. Our PRs

    are polite 2. Our PRs don’t include many back-and-forth exchanges 3. Our PRs are readable 4. Our PRs are well-tested—by robots 5. Our PRs are well-tested—by humans 6. Our PRs contain only the needed changes 7. Our PRs add instrumentation 26 Seven Reasons Why I Read My Team’s Pull Requests https://blog.newrelic.com/culture/pull-requests-team-health/
  21. ©2008–20 New Relic, Inc. All rights reserved The New Relic

    One Platform 28 Traces Metrics Events Logs NRDB NR Proprietary Agents METRICS TRACES LOGS APPS SERVICES HOSTS Open Telemetry
  22. ©2008–20 New Relic, Inc. All rights reserved 29 Observability on

    New Relic 定常状態の監視 定常状態を発見・定義し、 ダッシュボードによる可視化 およびアラートによる通知 高いオブザーバビリティ 様々なエージェントから収集した 様々なデータによって、 発生した事象に素早く到達 障害対応速度を向上させます