[SREcon21 Conference Program | USENIX](https://www.usenix.org/conference/srecon21/program) - Nishant Singh, LinkedIn, [[Spike Detection in Alert Correlation at LinkedIn - SREcon21]] > LinkedInのスタックは、何千もの異なるマイクロサービスと、それに関連するマイクロサービス間の複雑な依存関係で構成されています。誤動作するサービスの問題で本番停止が発生した場合、停止の原因となったサービスを正確に見つけるのは困難で時間がかかります。各サービスには分散型インフラストラクチャで複数のアラートが設定されていますが、障害発生時に問題の真の根本原因を見つけることは、適切な計測器があったとしても、干し草の中から針を探すようなものです。お客様のリクエストのクリティカルパスにあるすべてのサービスには、複数のアクティブなアラートが存在するからです。これらの独立したアラートから意味のある情報を導き出す適切なメカニズムがないと、誤ったエスカレーションが発生し、問題解決に要する時間が長くなってしまいます。本講演では、LinkedInのアラート相関システムでスパイク（異常）検知をどのように使用したかを紹介します。これにより、偽陽性のアラートからアラートを見つけ出し、エンジニアの負担を軽減することができます。 - Dr. Michael Krax, Google , [[A Political Scientist's View on Site Reliability - SREcon21]] > 政治学は、ソフトウェア工学の問題に斬新で新鮮な洞察を与えてくれる。社会の変化に関する実証的な研究は、チームのダイナミクスやチームを進化させる方法を理解するのに役立ちます。また、政治システムを自己組織化システムとして分析することで、現代の生産環境をどのように簡素化するかについての洞察を得ることができます。 日常の疑問を違った角度から見てみたいという方は、ぜひご参加ください。事前の政治学のトレーニングや知識は必要ありません。 - Danny Chen, Bloomberg LP, [[Latency Distributions and Micro-Benchmarking to Identify and Characterize Kernel Hotspots]] > 多くのシステムでは、完全に水平方向にスケールする完全分散型のマイクロサービス・アーキテクチャは、まだ実現されていません。多くのシステムでは、パフォーマンスを考慮したり、ホスト上のローカルな状態を共有する必要があるため、ホスト上にプロセスを配置しています。ブルームバーグLPの私たちの部署では、アーキテクチャとパフォーマンスの制約から、多数のコアとテラバイトのメインメモリを持つベアメタルハードウェア上で動作させています。 > ベアメタルハードウェア用のOSは、より大きなスケール（大量のプロセス/スレッド、大量のオープンファイルなど）を可能にするために開発・成長してきました。しかし、OSはランタイムのスケール（大規模なレベルの同時実行/コンテンション）に対応して常にスケールするわけではありません。さらに、我々が管理しているシステムは、より新しく、より大きく、より速いハードウェアに対応しているとは限りません。 > 本講演では、様々なOSのケーススタディを紹介し、OSのスケール制限にどのように遭遇したか、また、修正や回避策を開発するために、マイクロベンチマークを使用してスケール制限の性質に関する洞察をどのように収集したかを説明します。また、これらのマイクロベンチマークは、"ノイズ "を排除し、カーネルの "ホットスポット "にデータ収集を集中させることで、最新のOSに搭載されている素晴らしい新しいトレース機能を補完しています。 - Emily Freeman, AWS, [[Rethinking the SDLC]] > ソフトウェア（またはシステム）開発のライフサイクルは、1960年代から使われています。そしてそれは、カラーテレビやタッチトーン電話が登場する前から、ほぼ変わらないものです。ソフトウェア開発ライフサイクルは、カラーテレビやタッチトーン電話が登場する前からほぼ同じものです。 > しかし、私たちがソフトウェアを開発するエコシステムは根本的に異なっています。私たちは、分散し、切り離され、複雑化したシステムの中で仕事をしており、古風なモデルではもはや捉えることができません。今までとは違う考え方をする時が来ました。革命を起こす時が来たのです。 > [[SDLC]]の革命モデルは、現代のソフトウェア開発のマルチスレッドで非連続的な性質を表現しています。これは、エンジニアが担う役割と、その過程で遭遇する考慮事項を具現化したものです。このモデルは、アジャイルとDevOpsの上に構築され、DevSecOpsやAIOpsといったDevOpsの派生型の関心事を捉えています。そして、継続的なイノベーションの反復的な性質を受け入れるために、回転します。この講演では、この新しいモデルを紹介し、ソフトウェアについての話し方を開発の経験と一致させる必要性について議論します。 - Christina Tan and Emily Arnott, Blameless, Elephant in the Blameless War Room—Accountability > 非の打ちどころがないという理想と、責任を求めることをどう両立させるか。誰かに責任を負わせることは、どのような場合に、どのようにすれば建設的なのでしょうか？非難される文化を変えるには、非難する人に共感し、その人の目標が自分の目標と一致していることを確認する必要があります。そして、彼らの目標が自分の目標と一致していることを確認し、彼らの目標が非難されることなく達成できることを伝える方法を紹介します。最後に、真のアカウンタビリティーを確保する方法を紹介します。 > クリスティーナは、Blameless社の戦略チームに所属し、紛争解決、ハイパフォーマンスチーム、エグゼクティブ・アライメントのための対人関係ダイナミクスを構築しています。それ以前は、TEDスピーカーのスピーチやスタートアップ企業の創業者の資金調達のコーチをしていました。彼女のクライアントは、合計で2億4,000万ドル以上を調達しています。余暇には、マインドフルネス・コミュニティ「Serenity Lounge」を運営している。 - Qian Ding and Xuan Zhang, Ant Group, SLX: An Extended SLO Framework to Expedite Incident Recovery > この講演は、99.999%以上の可用性を目標とするインフラストラクチャSREチームのSLOを確立するための実際の旅に基づいています。まず、SLOを定義する際のプロセスを明らかにし、開発チームでSLOを使用する際の期待と現実のギャップを示します。次に、SRE が何百もの SLO を管理しやすくするための統一された SLO フレームワーク（SLX）の設計を紹介します。例えば、SLOのデータを基本的な警告や週次報告に使用するだけでなく、SLOフレームワークと統計的な異常検知アルゴリズムを組み合わせることで、自動的に落とし穴を見つけることができます。そのために、SLF（Service-Level-Factor）やSLD（Service-Level-Dependency）などの新しい概念を導入し、それらを用いて複数のインフラシステムにわたるSLOナレッジグラフを構築します。最後に、Kubernetesのデザインと[[GitOps]]のパラダイムにインスパイアされた、意図駆動型のSLXの実装を紹介します。 - Nick Spain, Stile Education, Watching the Watchers: Generating Absent Alerts for Prometheus > Prometheus モニタリングシステムのために素晴らしい記録ルールとアラートを書き、アラートが発火するかどうかをチェックするためにシナリオを慎重に再現しました......素晴らしい! アプリが静かに失敗することは二度とありません。しかし、数ヶ月後、あなたはシステムが静かに倒れていることに気づきました。なぜでしょう？メトリクスをエクスポートする cron ジョブが実行されなかったり、コレクターのラベルが変更されたりして、メトリクスがなくなってしまったのです。Prometheusのアラートは鳴らないし、消えてしまったことにも気づかない。手動でアラートを書くこともできますが、手間がかかりますし、自分が忘れないとも限らないので、自動化しましょう スティルエデュケーションでは、このアラートを自動生成するツールを作りました。何のために作ったのか、なぜ作ったのか、そして導入してから6ヶ月間でどのように役立ったのかをご紹介します。 Marianne Bellotti, Rebellion Defense, Let's Bring System Dynamics Back to CS! > システムダイナミックスとは、システムをフィードバックループでモデル化する手法である。MITのコンピュータ科学者によって開発されたシステムダイナミックスは、技術的なアプローチとしては形式的な検証が主流となり、やがて廃れていきました。しかし、分散型アプリケーションやそれをサポートする自動化環境を構築していく中で、フィードバックループの機能不全が引き金となった障害が発生するケースが増えています。このような問題は、形式的な検証ではモデル化することができませんが、システムダイナミックスでは推論することができます。本講演では、システムダイナミックスの歴史、ソフトウェアエンジニアがモデルを構築・実行するために利用できるツール、システムダイナミックスの抽象化を用いて様々なアーキテクチャを表現する方法などについて説明します。 Alexey Skorikov, Google, Horizontal Data Freshness Monitoring in Complex Pipelines > 複雑なパイプラインにおけるデータの信頼性は難しいものです。データ依存性グラフと水平方向のデータ鮮度モニタリングがどのように収益の損失を削減するかをご覧ください。 David D. Woods, Ohio State University and Adaptive Capacity Labs; Laura Nolan, Slack, [[You've Lost That Process Feeling - Some Lessons from Resilience Engineering - SREcon21]] > ソフトウェアシステムは様々な点で脆く、故障が発生しやすいものです。ソフトウェアシステムのロバスト性を向上させることは可能ですが、真のレジリエンスを実現するためには、常に人間の関与が必要となります。 > しかし、これは実際には容易ではありません。Woodsの定理によると、システムの複雑さが増すにつれて、単一のエージェントが持つシステムのモデル（「プロセス・フィール」）の精度は急速に低下します。私たちはチームで仕事をしており、持続可能なオンコール・ローテーションには数人の人間が必要であるため、これは重要なことです。 > 本講演では、研究者と実務家が一緒になって、SREに適用されるレジリエンス工学の概念について議論します。特に、チームがシステムの異常に関する経験を共有することに体系的に取り組み、重大なインシデントだけでなく「弱い信号」からも継続的な学習を行う方法に焦点を当てます。 Niall Murphy, RelyAbility, [[What If the Promise of AIOps Was True? - SREcon21]] > 多くのSREは、AIOpsのアイデアを冗談のように扱っており、コミュニティにはそれなりの理由があります。しかし、もしそれが本当だったらどうでしょう？私たちの仕事が危険にさらされているとしたら？チェスや囲碁、ブレイクアウトを人間よりもスムーズにプレイできるAIが、プロダクションエンジニアリングの世界をも征服しようとしているとしたら？私たちはそれに対して何ができるのか、あるいはすべきなのか。 > この講演では、AIOps企業が約束していることに照らし合わせて、現状と未来を検証してみましょう。つまり、「もしAIOpsが本当だったら」という問いかけです。 D. Brent Chapman, Slack, Evolution of Incident Management at Slack > Slackでは、ピーク時には毎分1億5000万通以上のメッセージを配信しています。そのうちの何割かは、多くの人が自分のインシデントを管理するために頼りにしてきた同じプラットフォームに影響を与えるインシデントを管理している私たちです。大小さまざまなインシデントが週に何十件も発生し、そのほとんどがユーザーに気づかれないものであるにもかかわらず、私たちはどのように処理しているのでしょうか。私たちがどのようにしてインシデント管理をエンジニアリングチーム全員の中核的な能力としたのか、現在の状況、これまでの経緯、そしてこれからの方向性についてご紹介します。 Dan Shoop, Improving Observability in Your Observability: Simple Tips for SREs > 時系列データは、科学、統計学、データ収集の初期の頃、何百年も前から存在していたことを知って驚かれたでしょうか。時系列データは、科学や統計学、データ収集の黎明期から数百年の歴史を持っています。 > 「本セミナーでは、エンジニアがメトリクスや観測データの情報提示において、視覚的な理解と信頼性を向上させるために、様々な業務やあらゆるレベルですぐに活用できる実用的な教訓を紹介します。 > テレメトリをより良く見せることに関心のあるSREとして、ガリレオ、チャールズ・ジョセフ・ミナード、エドワード・タフトの作品からどのような実用的な教訓を得られるか、また、ダッシュボードやその他のエンジニアリンググラフィックの転送やコンテンツ密度を向上させるために避けるべき簡単な落とし穴やできることを探ります。 Stefano Doni, Akamas, [[Automating Performance Tuning with Machine Learning - SREcon21]] > SREの主な目的は、アプリケーションのパフォーマンス、安定性、可用性を最適化することです。その際に重要な役割を果たすのが、設定（コンテナのリソース制限やレプリカ、ランタイムの設定など）です。誤った設定は、パフォーマンスや効率性の低下、インシデントの原因の上位に挙げられます。しかし、コンフィグレーションのチューニングは、スタック内に何百もの設定があるため、非常に複雑で手動の作業となります。そこで、機械学習を活用して、技術スタックの最適な設定を自動で見つけるという新しいアプローチを提案します。このアプローチでは、強化学習技術を活用して、SREが定義できる最適化目標（サービスの遅延やクラウドコストの最小化など）に基づいて最適な構成を見つけます。ここでは、Kubernetesマイクロサービスのコストとレイテンシーを最適化するために、コンテナリソースとJVMオプションを調整する例を示します。見つかった最適な構成、最も影響の大きいパラメータ、マイクロサービスのチューニングに関する教訓などを分析します。 Todd Underwood, Google, [[Nothing to Recommend It: An Interactive ML Outage Fable]] > これは、実際の障害をベースにした、あるMLの障害の話ですが、無実の人（および有罪の人）を守るために、匿名化され、再構成されています。あるMLモデルが悪さをして、会社に大きな損害を与えています。多くの障害がそうであるように、根本的な原因は明らかではありません。それどころか、障害の発生時期さえも不明です。この講演では、どのようにして障害が検出されたのか、どのようにトラブルシューティングが行われたのか、どのようにして障害が緩和され解決されたのか、そしてどのようなフォローアップ作業が予定されているのかを紹介します。この講演では、（非同期のための優等生的）インタラクティブな講演を目指します。 Anika Mukherji, Pinterest, [[User Uptime in Practice - SREcon21]] > SREとしては、最終的にはユーザーエクスペリエンスが最も重要な指標となります。Pinterestでは、他の多くの企業と同様に、ユーザーへのサービスの質を表す指標として成功率を使用していました。しかし、成功率は製品の品質を表す上で多くの問題を抱えており、「Pinner」の体験の変化を理解し、測定し、対応することが困難でした。 > そこで私たちがたどり着いたのが、「ユーザーアップタイム[[2020__NSDI__Meaningful Availability]]」という指標でした。これは「時間ベース」の指標であり、成功率のような「数ベース」の指標に比べて多くの利点があります。本講演では、Pinterestがどのようにしてこのような指標を導入したのか、技術的な積み重ねや設計上の決定事項、そしてその過程で私たちの製品とユーザーの両方について学んだことについてお話しします。 - Andrew Hatch, LinkedIn, Learning More from Complex Systems > 複雑なシステムはどこにでもあります。スライムカビのような単純な生物から、人間の脳の神経処理能力、ラッシュアワーの交通機関のナビゲーション、あるいは現代の組織で相互に作用し合う人と技術の膨大なリソースまで。これらのシステムには、有機的なものも人工的なものもあり、環境に適応して進化し、多くの共通の特徴を持っています。特に、創発的な行動、生来のレベルの回復力、現在の状態に責任を持つ歴史、そして最も重要なことは、より複雑になっているということです。 > しかし、私たちは複雑なシステムをどのようにして学ぶのでしょうか？直線的な分析による知識の追求だけでいいのでしょうか？根本的な原因を分析して失敗を回避することで、複雑さに対処できるのでしょうか？それとも、他の学習方法が必要なのでしょうか？ > この講演では、歴史、科学、哲学の要素を抽出し、複雑なシステムで発生した事故からどのようにして学ぶことができるかについて、聴衆がこれまでとは違った考えを持つことができるようなヒントを提供します。 John Allspaw, Adaptive Capacity Labs, Hard Problems We Handle in Incidents but Aren't Recognized > どこをどのように見ればいいのかがわかれば、インシデントを処理する際に人々が行っている様々なダイナミクス、ジレンマ、犠牲を見つけることができます。本講演では、このような見逃されがちな事件の側面をいくつか取り上げ、それらに気づくのが難しい理由を説明し、将来それらに気づいたときに使用できる説明用の語彙を紹介します。 Narayan Desai, Google, [[Beyond Goldilocks Reliability]] > 信頼性工学はまだ初期段階にあり、ベストプラクティスは主にコミュニティでの経験や苦労から生まれたものです。アラートや SLO を含む SRE のプラクティスは、主観的なしきい値に基づいて構築されており、信頼性の難解なモデルを体系化しています。しかし、このアプローチには亀裂が入っており、このゴルディロックスのようなアプローチでは不十分であることがますます明らかになってきています。 > 現在、信頼性は不定形の概念です。信頼性にしっかりと取り組むためには、まず信頼性を簡潔に体系化する必要があります。具体的なモデルがあれば、サービスに関する複雑な問題にも原理的に答えることができるようになります。そもそも信頼性とは何か？ > 信頼性とは何かを理解した上で、現在のベストプラクティスや緩和策を精査することができます。なぜそれが有効なのか、なぜそれが効果的なのか。なぜアグリゲーションが普及しているのか？バックエンド・ドレインがうまく機能しているのはなぜか？根本的なメカニズムを明らかにすることで、求める信頼性を強化し、必要に応じて新たな緩和策を講じることができます。 Adam Newman, USAA, [[The Origins of USAA's Postmortem of the Week]] > WARNING: Bad Joke Alert! USAA社がIT全体の死後検討会議を構築するまでのストーリーをご紹介します。大規模なPostmortem Reviewミーティングを自分で立ち上げるためのヒントを紹介します。USAAは、悪いジョークによって引き起こされる精神的苦痛に対して責任を負いません。 Rob Skillington, Chronosphere, [[Taking Control of Metrics Growth and Cardinality: Tips for Maximizing Your Observability Function]] > クラウドネイティブアーキテクチャへの移行に伴い、生成されるメトリクスデータの量は急激に増加しており、SREチームは、メトリクスのカーディナリティを制限または制御する方法を見つけるなど、これらの要求の増加に対応することを余儀なくされています。このような成長が続く中、クラウドネイティブ企業（およびそのSREチーム）は、この成長を持続的かつ確実に管理する方法を見つけることが重要です。 > このセッションでは、大規模なスケールでメトリクスデータの増加とカーディナリティを効率的に制御するためのベストプラクティスとヒントを紹介します。また、ワールドクラスのオブザーバビリティ機能を実行、維持、成長させる際に留意すべき、大規模環境で実証されたKPIやメトリクスを紹介します。オブザーバビリティ分野のリーダーやエンジニアによる実例を中心に、これらの学びを既存のSREリソースで実現する方法や、その取り組みを追跡・測定する方法などについて理解を深めていただきます。 Austin King, OpsDrill, [[Games We Play to Improve Incident Response Effectiveness]] > 効果的なインシデントマネジメントは重要ですが、どのように実践し、改善していけばよいのでしょうか？ > チームの結束と文化が重要であることはわかっていますが、どのようにしてそれらを成長させるのでしょうか？ > その答えは...ゲームです。パーティーゲームからゲームデイのシナリオまで、私たちが日常的に使用するスキルを調査します。そして、そのスキルをチームで練習できるような様々なゲームを紹介します。