<iframe class="hatenablogcard" style="width:100%;height:155px;max-width:680px;" title="(1) Taichi Nakashima on Twitter: "2012年からTwitterがどのようにSRE Teamを導入していったかの話良かった．SLOとRPC framework連携してLoad sheddingとかCircuit breakingをやってるのはおもろいね - Twitter’s Reliability Journey https://t.co/BvYXJGzfEd - SLO Adoption at Twitter https://t.co/lkzv1L6ISi" / Twitter" src="https://hatenablog-parts.com/embed?url=https://twitter.com/deeeet/status/1278498887049728000" width="300" height="150" frameborder="0" scrolling="no"></iframe> [SLO Adoption at Twitter](https://www.blameless.com/blog/slo-adoption-twitter) Twitterでは，[[SLI]]として成功率、待ち時間、分散サービスエコシステム全体のスループットなどを採用していた．そこから，Finagleに[[SLO]]機能を組み込んだ（今ひとつよくわからない）．SLOに基づいたload-shedding（負荷制御）などを組み込んだ． SLOの定義について: 重要なユーザー体験を最もよく反映するシグナルを特定することが重要だが難しい．例えば，データセンター内のサービス・エラー率を分析する際に，クライアントがリクエストを再試行することがあるが、これは、真のユーザー成功率が何であるかを推論するための誤ったデータポイントとなる． “context, not control” (Netflixの造語): 善意で有能なチームメイトがより良い意思決定ができるように、可視化や洞察力でチームに力を与えることに重点が置かれている． （[[Seeking SRE]]の第1章と関連） SLOの可能性：分散サービスの共通言語，適切な量のコンテキスト，SLOベースの負荷分散と負荷制御，Graceful Degradation，選択的なcircuit breaker． (Twitter Command CenterのメンバーはTwitterを構成する数百のほとんどのサービスを知っているとのこと．）