Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SRE WORKBOOK18

66 views

Published on

SRE

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

SRE WORKBOOK18

  1. 1. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 1/26 1. 製品(サービス)サイクルに応じてSREの関わり方が変わっていくということ 2. 開発チームとSREチームとでの関係を構築するためには戦略があること Phase 製品フェーズとSREの役割など 1 Architecture and Design システム構成のコンサルティングなどを実施 早期に参画することで手戻りが小さくて済む 2 Active Development プロトタイプのサービスが出てくるタイミング。 リリースに向けてモニタリングやアラートなどを設計 3 Limited Availability β(限定)公開の段階 (稼働中の)サービス全般について知見を得て、 SREはサービスにフィードバックをする 4 General Availability PPRを経て完全公開 運用の主はSREにあるが 改善のため開発部門も一部参画 CH.18 SRE Engagement Model(p371) CH.18 まとめ サービスの各フェーズでのSREの関わり⽅について
  2. 2. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 2/26 Phase 製品フェーズとSREの役割など 5 Deprecation 既存サービスの廃止および新サービスへの移行検討段階 既存サービスへのリソース投下は削減されつつ 2つのサービスをサポートする段階 6 Abandoned サービスが廃棄され、開発部門の限定サポート SREはベストエフォートでのフォローに留まる(SLOをコミットしない) 7 Unsupported サービスの完全停止。SREは各種ドキュメンテーションの整理(削除)を実施 ポイント 1 責任主体は開発側にあること 2 SREと開発チームと共同でそれらを書き、目標をマイルストーンに分ける 3 一般的なロードマップは以下のとおり 1. アプリケーションアーキテクチャを確認する 2. 共有目標を定義する 3. キックオフと計画のセッションを開く 4. マイルストーンに達するために開発サイクルを実行する 5. エンゲージメントのフィードバックを求めるための振り返りを設定する 6. プロダクションレディネスレビューを実施する 7. マイルストーンに到達するための開発サイクルを実施する 8. 起動を計画して実行する 共通の⽬標をもって<NYTimesの事例>
  3. 3. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 3/26 ポイント 4 エンゲージメントの影響を計測するために、成熟度モデルを利用する タイトル 内容 1 互いに時間を費やす SREと開発者がより効果的にコラボレーションするのに役立つ 2 プロダクションの現状共有 リソースをどこで投資すべきか、 SREがどの程度製品やサービスを支援しているのかを共有する 3 製品の現状共有 開発者チームが達成したこと、しようとすることの最新情報を共有する 4 SREと開発のリーダーMTG 今後12~18か月間のロードマップを共有する 5 サービスレベルの再評価 優先順序の見直しを行う。場合によっては全員での対応に入る 6 優先順序の見直し SLOやエラーバジェットに応じて判断する 7 ポストモーテム 1.一晩寝かせる →疲れているときや感情が強いときの振り返りを避ける 2.直接会う →コードレビュー(ツール)のみなどではフラストレーションが出やすい 開発とSREの関係構築について<Googleの事例>
  4. 4. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 4/26 タイトル 内容 7 ポストモ テム 3.ポジティブである →前向きな立ち振る舞いをするメンバーに感謝すべき 4.コミュニケーションの差異について →チームによって前提が異なることを理解すること SRE本32章のおさらい https://landing.google.com/sre/sre-book/chapters/evolving-sre-engagement-model/ theNewYorkTimesのSRE関連リソース https://www.youtube.com/watch?v=QCRe-Vo-PPo https://www.infoq.com/jp/news/2019/05/incident-collaboration-nytimes ※以下、全訳 SRE本32章では、SREチームがサービスの信頼性を分析および改善するために 採用できる技術的および手続き的アプローチについて説 明している。 これらの戦略には、PRR1 、早期の取り組み、および 継続的な改善がある。 簡単に言えば、SREの原則は、製品の信頼性を保ちながら、 開発者チームのエンジニアリング速度を最大化することを目指している。 この2つの目標は、製品ユーザーにとっても企業にとっても良いことであるが、 最高のSREチームであっても達成できる量には限界が あり、 ドメインが大きすぎて複雑すぎる場合はSREモデルの効果が低下する。 現在のマイクロサービスの動きは、このダイナミックを さらに深刻なものにしている。 中小企業であっても、単一のSREチームが処理できるよりも多くのマイクロサービスを簡単に持つこと ができてしまい、大規模なプロダクション環境をもち、かつ、すべてのサービスをカバーするに足るナレッジがないたりないというこ その他 CH.18 SRE Engagement Model(p371)
  5. 5. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 5/26 とを考えると、SREチームは、最良の結果を得るためにどこに注意を集中させるかを決定する必要があり、製品開発チームとSREチー ムは協力して正しい焦点を特定できる。 この章では、新しいサービスへのサポートを提供しようとしているSREチームの観点を説明する。 私たちはどのようにしてそのサービ スを、そしてそれを所有する開発者と製品チームと最も効果的に関わっていくかをみていく。 SREエンゲージメントは1つまたは複数 のサービスを中心に構築されることが多くあるが、エンゲージメントはサービス自体よりもはるかに多くのものを必要とする。 この説明の大部分は、組織の規模に関係なく当てはまる。 チームという言葉を頻繁に使用しますが、 チームは理論的には一人の人とし て始めることができる(その人はかなり忙しいだろう)。 チームの規模に関係なく、SREの役割を積極的に定義し、 コミュニケーション と製品開発とのコラボレーションを管理することが重要である。 PRR(プロダクションレディネスレビュー)とは 1. サービスがプロダクション環境のセットアップと運用に関する基準を満たしていること、そしてサービスの責任者がSREと作業 し、SREの専門性を活かす準備ができていることの確認。 2. プロダクション環境におけるサービスの信頼性を改善し、 予想されるインシデントの発生回数と重大度を最小化する。 PRRは、 SREが注意を払うプロダクション環境のすべての側面を対象とする。 SRE本の序文で説明したように、 サービスの信頼性に対するSREチームの貢献は、 サービスライフサイクルのすべてのフェーズを通 じて発生する。 生産に関する知識と経験を適用することで、 SREがサービスのポケットベルを手に入れる前に、 サービスの信頼性を 大幅に向上させることができる。 図18-1(Level of SRE engagement during the service lifecycle)は、 サービス期間中の理想的なSREエンゲージメントレベルを示してい る。 The Service Lifecycle(p372)
  6. 6. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 6/26 SREチームはライフサイクルのどの段階でもサービスへの参加を開始する可能性がある。 たとえば、開発チームがSREでサポートされ ているサービスの代替サービスの計画を開始した場合、SREは非常に早い段階で新しいサービスに関与する可能性がある。 あるいは、 SREチームは、数か月または数年にわたって一般に利用可能になり、 信頼性または規模の拡大という課題に直面している場合に、正式 にサービスに取り組むことがある。 このセクションはSREチームが各フェーズでどのように効果的に貢献できるかについてのガイダン スである。
  7. 7. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 7/26 SREは、さまざまな方法でソフトウェアシステムのアーキテクチャと設計に影響を与える可能性がある。 開発者チームが新製品を構築するときに採用できるベストプラクティス(さまざまな単一障害点に対する回復力など)の作成 開発者がビルディングブロックを賢く選択し、正しく使用し、 既知の落とし穴を回避できるように、特定のインフラストラクチャ システムの利点と欠点を(以前の経験に基づいて)文書化する 特定のアーキテクチャや設計の選択について詳細に議論し、ターゲットを絞ったプロトタイプを使用して前提条件を検証するため の早期エンゲージメントコンサルティングを提供する 開発者チームに参加して開発作業に参加する サービスの一部を署名する アーキテクチャの間違いを修正することは、開発サイクルの後半でより困難になる。初期のSREエンゲージメントは、システムが実際 のユーザーと対話し、 サービスの拡大に対応して拡張する必要がある場合に必要になる、 コストのかかる再設計を回避するのに役立 つ。 積極的な開発中に製品が形作られると、SREはサービスの生産を開始することができる。 生産に投入するためにサービスを形にするこ とができる。 生産化には、通常、キャパシティプランニング、冗長性のための追加リソースの設定、 スパイクおよび過負荷処理のプラ ンニング、ロードバランシングの実装、 モニタリング、アラート、パフォーマンスチューニングなどの 持続可能な運用方法の導入が含 まれる。 サービスがベータに向かって進むにつれて、 ユーザーの数、さまざまなユースケース、使用の強度、 および可用性とパフォーマンスの 要求が高まっている。 この段階で、SREは信頼性の測定と評価に貢献できる。 サービスチームがサービスの信頼性を客観的に判断でき るように、 一般的な可用性(GA)の前にSLOを定義することを強く推奨する。 製品チームには、目標の信頼性を満たすことができない 製品を引き出す選択肢がある。 Phase 1: Architecture and Design(p372) Phase 2: Active Development(p373) Phase 3: Limited Availability(p373)
  8. 8. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 8/26 この段階では、SREチームはキャパシティモデルを構築し、 今後の起動段階に備えてリソースを取得し、 ターンアップとインプレース サービスのサイズ変更を自動化することで、 システムの拡張を支援することもできる。 SREは適切な監視範囲を確保し、今後のサービ スSLOに 理想的に一致するアラートを作成するのに役立つ。 サービスの使用方法は依然として変化しているが、 SREチームはサービスの機能と障害モードの管理方法を引き続き学習しているた め、 インシデント対応および運用上の作業中に作業量が増加すると予想できる。 開発者チームとSREチームの間でこの作業を共有する ことをお勧めする。 このようにして、開発者チームはサービスに関する運用経験を積むことができ、 SREはサービス全般に関する経験 を積むことができる。 運用作業とインシデント管理は、システムの変更とサービスの所有者がGAの前に行う必要がある更新を通知す る。 この段階でサービスはPRRに合格しており、すべてのユーザーを受け入れている。 通常、SREは運用作業の大部分を実行するが、開発 チームは、運用およびインシデント対応作業のすべてのうちのごく一部を引き続き使用して、 サービスのこれらの側面に関する見通し を失わないようにする必要がある。 開発者が運用上の負荷を追跡できるように、1人の開発者をオンコールローテーションに永続的に 含めることができる。 GAの初期段階では、開発者チームがサービスの成熟と新機能の最初のバッチの立ち上げに注力しているため、実際の負荷の下でシステ ムの特性を理解するためにもループにとどまる必要がある。 GAの後期段階で、開発者チームは小さな増分機能と修正を提供する。 そ のうちのいくつかは運用上のニーズと発生した生産上の問題によって知らされる。 永遠に動くシステムはなく、より良い代替システムが利用可能である場合には、 既存のシステムは新しいユーザーのために閉鎖され、 すべてのエンジニアリングは既存のシステムから新しいシステムへのユーザーの移行に焦点を合わせる。 SREは、ほとんど開発者チー ムの関与なしに既存のシステムを運用し、開発と運用作業で移行をサポートする。 既存のシステムに必要なSREの労力は削減されるが、 SREは2つのフルシステムを効果的にサポートしている。 人員数と人員配置はそ れに応じて調整する必要がある。 Phase 4: General Availability Phase 5: Deprecation(p374)
  9. 9. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 9/26 サービスが放棄されると、開発者チームは通常運用サポートを再開する。 SREはベストエフォートベースでサービスインシデントをサ ポートする。 内部ユーザーによるサービスの場合、SREは残りのユーザーにサービス管理を引き継ぐ。 この章では、SREが開発者チ ームにサービスをどのように引き渡すことができるかについて2つのケーススタディを提供する。 これ以上ユーザーはなく、サービスは閉鎖された。 SREは、実稼働構成および文書内のサービスへの参照を削除するのに役立つ。 サービスは真空中には存在しない。 SREチームは、サービスを構築する開発者チームと、 それをどのように進化させるべきかを決定す る製品チームと協力する。 このセクションでは、これらのチームと良好な関係を築き、維持するためのいくつかの戦略と戦略を推奨す る。 あなたが誰かを助けることができる前に、 あなたは彼らのニーズを理解する必要がある。 そのためには、SREは、製品開発者がSRE エンゲージメントの達成に期待することを理解する必要がある。 SREは開発者チームと関わる際には、製品とビジネスの目標について 深く理解する必要がある。 SREは、自分たちの役割と、SREの関与によって開発者がこれらの目標に向かって実行できるようにする方 法を明確にすることができる。 チームは、ビジネス上および生産上の優先事項について定期的に話し合う必要がある。 SREと開発者のリーダーシップチームは理想的 にはユニットとして働き、 定期的に会い、技術的および優先順位付けの課題について意見を交換するべきである。 SREのリーダーが製 品開発のリーダーシップチームに加わることもある。 Phase 6: Abandoned(p374) Phase 7: Unsupported(p374) Setting Up the Relationship(p375) Communicating Business and Production Priorities(p375) Identifying Risks(p375)
  10. 10. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 10/26 SREチームはシステムの信頼性に重点を置いているため、 潜在的なリスクを特定するのに適した立場にある。 定期的な開発と機能の流 れを中断させるコストは製品とエンジニアにとって重要であるため、 これらのリスクの可能性と潜在的な影響をできるだけ正確に測定 することは重要である。 開発者チームとSREチームはどちらも、 信頼性、可用性、パフォーマンス、スケーラビリティ、効率性、および機能と立ち上げの速度 を重視しているものの、 SREはさまざまなインセンティブのもとで運営されており、 主に新機能の発売よりもサービスの長期的な実行 可能性が優先される。 私たちの経験では、開発者チームとSREチームは、 それぞれの焦点を維持しながら、他のグループの目標を明確にサポートすることに よって、 ここで適切なバランスをとることができる。 SREは、開発者チームのリリース速度をサポートし、 承認されたすべての発売 の成功を確実にするという明確な目標を持つことができる。 たとえば、SREは、「安全であるかぎり早くリリースすることをお勧めす る」と述べている場合がある。 「安全」とは、通常、エラー予算内に留まることを意味する。 それから、開発者は妥当な割合のエンジ ニアリング時間を信頼性を壊しているものの修正と防止に捧げることにコミットするべきである。 :設計と実装レベルで進行中のサー ビス問題の解決、技術的負債の返済 デザイン会話に参加できる。 by Surya Prashanth Sanagavarapu (New York Times) New York Timesの組織では、クラウドへの移行、生産の拡大、およびコンテナへのアプリケーションの移行に関して、SREリソースの 需要が高まっている。 さらに、SREチームは、取り組むべき独自のバックログを持っている。 限られたリソースに直面して、これらの 競合する優先事項はSREチームのための成功を定義する。SREを採用することがSREの時間の需要に対処するための1つの明らかな方 法であるが、すべてのチームがそれに対応する余力、経験、または時間を持っているわけではない。 New York TimesのSRE機能の中核となる使命は、 当社のニュースルームをサポートするアプリケーションの信頼性と回復力を最大限に 高め、それによって読者への質の高いジャーナリズムの配信を可能にするツールとプロセスを製品開発チームに提供することである。 自動化のバックログの削減と他のチームとの連携のバランスをとるために、共有目標モデルを採用した。 Aligning Goals(p375) Shared Goals: SRE Engagements at the New York Times(p376)
  11. 11. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 11/26 チームに参加する前に、現在の四半期/年間の全体的なバックログを確認し、 その作業項目とカテゴリを明確に定義する。 たとえば、 バックログ項目には次のものがある。 アプリケーションのサービスステータスエンドポイントにアクセスすることで、ベースラインの監視と警告を設定するための自動 化を追加します。 より信頼性の高い、またはより高速なビルドパイプラインを実装します。 チームがSREに助けを求めるとき、要求を優先するときに考慮する要素の1つは、 共同作業がバックログを減らすのに役立つかどうか である。 当社のSREは、2つの異なるモデルに従って製品開発チームと連携している。 フルタイムベース かなり短時間で制約のあるプロジェクトのためのパートタイムベース SREチームの帯域幅に基づいて、エンゲージメントの種類を定義する。 フルタイムの取り組みのために、私達は製品開発チームにSRE を埋め込むことを好む。 これにより、製品開発チームの負担を軽減するための集中と時間を確保できる。 SREと製品チームは、開発者 がSREのスキルと能力を身につけるにつれて、 互いについて学ぶための最大の時間がある。 長期的な取り組みのために、私達は私達の 会社の戦略に最も適したアプリケーションを優先する。 エンゲージメントの範囲を定義する際に、SREプラクティスに関連してチームまたはアプリケーションの成熟度を測定する。 SREのプ ラクティスと原則について考えると、さまざまなチームの成熟度が異なることが判明したので、我々はアプリケーション成熟度モデル を適用することに取り組んでいる。 適切な期待を設定することは、締め切りとタスクの完了を満たすために重要で、この目的のために、私達は次の原則に従って働いてい る: Defining the Engagement(p376) Setting Shared Goals and Expectations(p377)
  12. 12. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 12/26 SREではなく、アプリケーションの所有者がアプリケーションの変更に直接責任を負うことを強調する SREエンゲージメントは全社的な利益のためである 新しい自動化やツーリングは、全社的に使用されている一般的なツールや自 動化を改善し、 一時的なスクリプト開発を回避する必要がある。 SREは、エンゲージメントがもたらす可能性のある新しいプロセス(負荷テストなど)について開発者チームに率直に説明する必 要がある。 SRE本32章に記述されるように、エンゲージメントにはアプリケーションレディネスレビューとプロダクションレディネスレビュ ーを含むかもしれない。ARRとPRRからの提案された変更は開発者とSREによって共通して優先される必要がある SREは従来の運用エンジニアではなく、デプロイのためのジョブの実行などの手動作業はサポートされていない。 共通の目標を設定するときは、開発チームと共同でそれらを書き、目標をマイルストーンに分ける。 アジャイルベースの会社であれ ば、エピックや(ユーザー)ストーリを書くかもしれない。 その後、SREチームはそれらの目標を独自のbacklogにマッピングできる 目標を設定するときの一般的なパターンは次のとおり。 1. エンゲージメントの範囲を定義する 1. Example: 次の四半期に、私のチームの全メンバーがGKE / GAEの展開を処理し、 運用環境に慣れ、運用停止に対処できるよ うにしたいと考えている 2. Example: 次の四半期には、SREが開発チームと協力して、 スケーリングと監視の観点からアプリを安定させ、 運用のための 運用手順書と自動化を開発するようにしたいと思う 2. 最終結果のサクセスストーリーを特定し、それを明示的に呼び出す Example: エンゲージ後、製品開発チームはGoogle Kubernetes Engineでサービス停止をエスカレーションなしで処理できる 製品開発チームとの関わりは、キックオフおよび計画会議から始まる キックオフの前に、SREチームはアプリケーションアーキテクチ ャと私たちの共通の目標を見直し、 予想される結果が与えられた期間内に現実的であることを確認した。 エピックやストーリーを作成 する共同計画会議は、エンゲージメントのための良い出発点になることができる。 Sprints and Communication(p377)
  13. 13. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 13/26 この取り組みのロードマップは次のようになる。 1. アプリケーションアーキテクチャを確認する 2. 共有目標を定義する 3. キックオフと計画のセッションを開く 4. マイルストーンに達するために開発サイクルを実行する 5. エンゲージメントのフィードバックを求めるための回顧展を設定する 6. 生産準備レビューを実施する。 7. マイルストーンに到達するための開発サイクルを実施する。 8. 起動を計画して実行する 我々は、チームがフィードバック方法を定義し、 そしてその頻度について合意することを要求する。 SREチームと開発チームの両方 が、機能しているものとそうでないものについてのフィードバックを必要としている。 これらの取り組みを成功させるには、合意され た方法で アジャイルスプリントレビューの外に一定のフィードバックループを設けることが有用であることを確認した。 たとえば、隔 週のレトロスペクティブの設定やチームマネージャとのチェックインなどがそれである。 エンゲージメントが機能していない場合、チ ームは解放の計画から逃げてはいけない。 SREが高い価値のある仕事をしていることを確認するために、 エンゲージメントの影響を測定することが重要であることがわかった。 また、各パートナーチームの成熟度レベルを測定して、 SREがチームと協力するための最も効果的な方法を決定できるようにしてい る。 GoogleのCREチームと協力して採用したアプローチの1つは、エンゲージメントを開始する前に、製品開発チームのリーダーと一 緒にポイントインタイムアセスメントを実施することである。 ポイントインタイムアセスメントは、成熟度マトリックスをたどり、 SREに対するさまざまな懸念の軸に沿ってサービスの成熟度を測 定し 、次のような機能分野のスコアについて合意することからなる。 ポイントインタイムアセスメントは、成熟度マトリックスをたどり、SREに対するさまざまな懸念の軸に沿ってサービスの成熟度を測 定し(SRE本32章で説明)、可観測性、キャパシティプランニング、変更管理、およびインシデント対応などの機能分野のスコアについ Measuring Impact(p378)
  14. 14. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 14/26 て合意することからなる。 これはまた、チームの長所、短所、および盲点についてさらに学習した後で、エンゲージメントをより適切 に調整するのにも役立つ。 エンゲージメントが終了し、開発チームが独自に実行している後、 SREが追加した価値を測定するために再度評価を実行する。 当社が 成熟度モデルを導入している場合は、そのモデルに照らし合わせて、 エンゲージメントがより高いレベルの成熟度をもたらすかどうか を確認する。またエンゲージメントが終了すると、お祝いが計画されている。 GoogleのすべてのSREチームに2つの大きな目標があり、 短期目標 保守性を念頭に置いて、利用可能で需要に応じて拡張可能な、 運用上安定したシステムを提供することで、製品のビジネスニーズ を満たす 長期目標 継続的な人的作業が不要になるレベルまでサービス運用を最適化することで、 SREチームはより価値の高いエンゲージメントに取 り組む そのためには、チームは次のような協力の原則に同意する必要がある。 運用作業の定義(およびそれに対する厳しい制限)。 開発者チームとSREチームの両方のエンジニアリング作業に優先順位を付けるために使用される、 サービスについて合意され測 定されたSLO。 SLOがなくても開始は可能だが、関係の最初からこのコンテキストを確立しないと、後でこのステップに戻る必要にある。 SLOが ないケースにおいてエンジニアリング作業の進行が理想的とは言えない事例については、 427ページの「ケーススタディ1:注意 のスケール変更 - アドホックから計画的変更へ」を参照。 Setting Ground Rules(p379)
  15. 15. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 15/26 予想外の使用量の増加を処理するための超過サービス容量など、 リリース速度およびその他の安全性パラメータを決定する、合 意された四半期ごとのエラー予算。 進行中の問題を目に見えるようにし、それらの根本的な原因を修正することを確実にするために 開発者が日常業務に関与するこ と。 予防的な計画と調整された実行により、 SREチームは、運用を最適化し運用コストを削減しながら、 期待と製品の目標を確実に満たす ことができる。 次の2つのレベルで計画することが推奨である。 開発者のリーダーシップにより、製品とサービスの優先順位を設定し、毎年ロードマップを作成する ロードマップを定期的に見直して更新し、ロードマップに沿った目標(四半期ごとなど)を導き出す。 ロードマップは、各チームが明確で影響力のある作業の長期的な展望を持っていることを保証する。 ロードマップを無視するのには、 正当な理由がある(たとえば、開発組織の変化が早すぎる場合など)。 ただし、安定した環境では、ロードマップが存在しないこと は、SREチームが別のチームとマージしたり、 サービス管理作業を開発チームに戻したり、範囲を拡大したり、解消したりできること を示す可能性がある。 開発者のリーダーシップとの戦略的な会話を継続的に行うことで、 焦点のずれをすばやく特定し、SREがビジネスに価値を付加する新 たな機会について話し合い、 製品にとって費用対効果の低い活動を停止することができる。 ロードマップは、製品を改善するだけではない。 また、運用コストを削減するための一般的なSREテクノロジとプロセスの適用方法と 改善方法についても説明する。 健全で効果的な関係は継続的な努力を必要とする。 このセクションでは、Googleでうまくいった戦略を概説する。 Planning and Executing (p379) Sustaining an Effective Ongoing Relationship(p380)
  16. 16. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 16/26 互いに時間を費やすという単純な行為は、 SREと開発者がより効果的にコラボレーションするのに役立つ。 SREがそれらが実行する サービスのために彼らのカウンターパートと定期的に会うことを推奨する。 SREが、トラフィックをサービスに送信するサービスやサ ービスが使用する共通のインフラストラクチャを 提供するサービスを実行している他のSREチームと定期的に会うことも推奨である SREチームは互いを認識し、エスカレーションの開始方法と管理方法についての期待をすでに設定しているため、 停止または意見の相 違があるときに自信を持って迅速にエスカレートできる。 チーム間の日々のコミュニケーションに加えて、 エンゲージメントの過程で特に役立つ2つのより正式な情報交換の方法を見つけた。 SREは四半期ごとに「プロダクションの現状」について製品開発のリーダーと話をして、 リソースをどこで投資すべきか、SREがどの 程度製品やサービスを支援しているのかを理解することができる。 同様に、開発者は定期的に「製品の現状」についてSREチームに話 すことも、 SREを開発者チームのエグゼクティブプレゼンテーションに参加させることもできる。 これにより、SREチームは、前四 半期に開発者チームが達成したことの概要を知ることができる。 (そして、SREは自分たちの仕事がそれを可能にした方法を知ること ができる)。 また、今後数四半期のうちに製品が稼働している場所や、 SREがその実現に向けて取り組んでいると製品の主導者が考え ている場所に関する最新情報も手に入れることができる。 サービスの将来を決定する意思決定者として、 サービスを担当するSREと開発者チームのリーダーは、 少なくとも年に1回は対面で会 う必要がある。 これよりも頻繁に会議を開くことは、 大陸間の移動を伴う可能性があるため、困難な場合がある。 この会議では、通 常、今後12~18か月間のロードマップを共有し、 新しいプロジェクトや立ち上げについて話し合う。 SREチームは振り返りを促進し、 チームがやめること、やり続けること、やり始めることについて リーダーが話し合う。 項目は複数の領域に表示される可能性があり、すべての意見が有効である。 最良の結果はチーム全体の参加から得られるため、 これら のセッションには積極的な円滑化が必要である。 重要なサービス変更を促進する可能性のある詳細が得られるため、 これはサービス会 Investing Time in Working Better Together(p380) Maintaining an Open Line of Communication(p380) Performing Regular Service Reviews(p381)
  17. 17. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 17/26 議で最も有用なセッションと見なされることがよくある。 合意された領域のいずれか(p379Setting Ground Rulesを参照)での協力が 後退し始めた場合、開発者とSREの両方がサービスを元の 状態に戻すために 優先順位を変更する必要がある。 緊急性に応じて、これは次のいずれかを意味する可能性がある。 チームは、優先度の低いタスクをやめて 復帰に集中する必要があるエンジニアを選定する どちらのチームも「信頼性ハッカソン」と呼ぶが、 通常のチーム優先順位はハッカソンの時代の外でも続く。 機能フリーズが宣言され、両チームの大多数がサービスレベル復帰の解決に集中する 技術的なリーダーシップにより、製品の信頼性が深刻なリスクにさらされていると判断され、 チームは全員での対応に入る。 明確なSLOを作成するという微妙な技術は、 チームが適切に優先順位を付けるのに役立つ。 サービスがSLOを見逃す危険性がある、 またはエラー予算を使い果たした場合は、 両方のチームがサービスを安全に戻すために高い優先順位で作業することができる。 それら は、戦術的な対策 (たとえば、トラフィック関連のパフォーマンス低下に対処するための過剰プロビジョニング)と、 より戦略的なソ フトウェア修正(最適化、キャッシュ、および適切な低下など)の両方によって 状況に対処できる。 サービスがSLOの範囲内で十分なエラーバジェットが残っている場合は、 サービスの改善に過度の努力を費やすのではなく、 予備のエ ラーバジェットを使用して機能の速度を上げることを推奨する。 人間は必然的に間違いを犯すものである。 ポストモーテム文化と合わせて、人々を責めるのではなく、 システムの振る舞いに焦点を当 てる必要がある。 ケースは様々かもしれないが、我々は以下の戦術で成功した。 Sleep on it Reassessing When Ground Rules Start to Slip(p381) Adjusting Priorities According to Your SLOs and Error Budget(p381) Handling Mistakes Appropriately(p382)
  18. 18. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 18/26 可能であれば、疲れているときや感情が強いときに フォローアップの会話をしてはならない。 ストレスの多い状況では、 人々は電子 メールのような文書によるコミュニケーションのトーンを 容易に誤解する可能性がある。 読み手は必ずしも書かれたものではなくと も、読み手がどう感じたかを を覚えている。 場所を超えてコミュニケーションをとるときは、 ビデオチャットを設定することを推奨する。 顔の表情を見たり、言葉の曖昧さを解消 するのに役立つ 声のトーンを聞くことができるから。 Meet in person (or as close to it as possible) to resolve issues コードレビューやドキュメンテーションを介してのみ行われるやり取りは、 イライラを引き出す可能性がある。 他のチームの行動や決 断が私たちの期待と矛盾するときは、 自分達の仮定について話を伝え、文脈が欠如していないかを尋ねる。 Be positive 前向きな立ち振る舞いをするメンバーに感謝すべきである。 コードレビュー、デザインレビュー、障害シナリオのトレ ーニングなどの間、 エンジニアに、何が良いのかを指摘し、その理由を説明するよう依頼する。 また、優れたコードコメントを認 識したり、 厳密な設計レビューに投資している時間に感謝することができる。 Understand differences in communication 情報がどのように広められるかについては、 チームによって異なる内部的な期待がある ので、 これらの違いを理解すると、関係を強化するのに役立つ。 これまでに説明したシナリオには、 単一のSREチーム、単一の開発者チーム、および1つのサービスが含まれている。 大企業、または マイクロサービスモデルを使用する中小企業でさえ、 これらの数値の一部または全部を拡張する必要があるかもしれない。 SREは専門的なスキルを持っており乏しいリソースであるため、 Googleは一般的にSREと開発者の比率を<10%に維持している。 した がって、1つのSREチームは通常、 それぞれの製品領域(PA)内の複数の開発者チームと協力する。 Scaling SRE to Larger Environments(p382) Supporting Multiple Services with a Single SRE Team(p382)
  19. 19. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 19/26 SREがSREサポートに値するサービスの数に比べて不足している場合、 SREチームは1つのサービス、または少数の開発者チームから の少数のサービスに 彼らの努力を集中させることができる。 これらのサービスに次のような特徴がある場合、 Googleの経験では、限られたSREリソースを多くのサービスに拡張できる サービスは単一の製品の一部である。 これにより、ユーザーエクスペリエンスのエンドツーエンドの所有権と ユーザーとの調 整が提供される。 サービスは同様の技術スタック上に構築されている。 これにより、認知的負荷が最小限に抑えられ、 技術的スキルの効果的な 再利用が可能になる。 サービスは、同じ開発者チームまたは少数の関連開発者チームによって構築されている。 これにより、関係の数が最小限に抑え られ、優先順位の調整が容易になる。 あなたの会社が複数のSREチーム、 そしておそらく複数の製品を持つことができるほど十分に大きいなら、 SREと製品グループがど のように関連するかのための構造を選ぶ必要がある。 Googleでは、複雑な開発者組織をサポートしている。 図18-2(Large-scale developer-to-SRE team relationships (per product area))に示 すように、 各PAは、それぞれ複数の製品を含む複数の製品グループで構成されている。 Structuring a Multiple SRE Team Environment(p383)
  20. 20. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 20/26 SRE組織は、各レベルで優先順位とベストプラクティスを共有しながら、 開発者組織を階層的に隠す。 このモデルは、グループ内のす べてのチーム、またはPA内のすべてのグループが 同じまたは類似の特定のビジネス目標を共有している場合、 およびすべての製品グ ループが製品リーダーとSREリードの両方を持つ場合に機能する。 組織に複数のSREチームがある場合は、 それらを何らかの方法でグループ化する必要がある。 これまで見てきた2つの主なアプローチ は次のとおりである。 製品内でチームをグループ化すると、 あまりにも多くの異なる開発者チームと調整する必要がなくなる
  21. 21. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 21/26 テクノロジースタック(「ストレージ」や「ネットワーキング」など)内で チームをグループ化する。 開発者の再編成中にSREチームが混乱するのを防ぐために、 開発者PAのレポート構造ではなく、 テクノロジに従ってSREチームを編 成することを推奨する。 たとえば、ストレージシステムをサポートする多くのチームが 同じように構成され、動作する。 テクノロジ を重視した製品グループでストレージシステムをグループ化すると、 たとえそれらが開発者組織の異なる部分から来たとしても、より わかりやすい。 PAのニーズの変化を反映してSREチームの構造を変更する必要がある場合は、 サービスのニーズとエンジニアリングおよび運用上の負 荷に基づいてSREチームを 作成、分割(分割)、結合、および解消することを推奨する。 各SREチームは、それぞれのサービス、テ クノロジ、および運用を反映した明確な憲章を持つべきである。 最初から新しいチームを構築するのではなく、 単一のSREチームでサ ービスが多すぎる場合は、 既存のチームを複数のチームに分割して文化を移し、 既存のリーダーシップを向上させることが推奨であ る。 このような変更は既存のチームには必然的に影響を与えるため、 必要に応じてチームを再編成することを推奨する。 年中無休24時間の補償範囲と事業の継続性を確保する必要があり、 グローバル展開がある場合は、 SREチームを世界中に配置して均 等な補償範囲を提供することを推奨する。 世界中に分散したチームが多数ある場合は、 隣接関係、およびサービスと共有テクノロジの類似性に基づいて チームを配置することを 推奨する。 シングルトンチームは一般的に効果が少なく、 チーム外の組織変更の影響を受けやすいことが判明した。 明確に定義され たビジネスニーズがそれらを必要とする場合にのみ、 そのようなチームを作成する。 多くの企業は、全世界を網羅するためのリソースを持っていませんが、 建物をまたがって(大陸を気にすることなく)分割している場 合でも、 2か所で配置を維持することが重要である。 計画と実行を推進し、共有チームカルチャーを促進し 維持するための組織標準を作成して維持することも重要である。 そのためには、 チーム全体を1か所の物理的な場所、 たとえば12~18か月ごとの組織全体のサミットに定期的に集めると便利である。 Adapting SRE Team Structures to Changing Circumstances(p384) Running Cohesive Distributed SRE Teams(p384)
  22. 22. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 22/26 バックアップから定期的にテストを復元したり、 会社間の技術的な義務を実行するなど、 チームの全員が特定の責任を負うことに意味 がない場合がある。 チームの分散サイト間でこれらの責任を分散させるときは、次の戦略に留意すべきである。 ・個々の責任を単一の場所に割り当てますが、 定期的に(例:年1回)ローテーションする。 ・拠点間であらゆる責任を共有し、 関与と作業負荷のバランスをとるための積極的な取り組みを行う。 ・何年もの間、責任を単一の場所に限定しないでください。 この 構成のコストが最終的にメリットを上回ることが判明した。 その場所はそれらの責任を実行するのに本当によくなる傾向があります が、 これは「私たち対彼ら」の考え方を助長し、 知識の配布を妨げ、そして事業継続のリスクにつながる これらの戦略はすべて、戦術的かつ戦略的なコミュニケーションを 維持するための場所を必要とする。 SREのエンゲージメントは必ずしも永遠ではない。 SREはインパクトのあるエンジニアリング作業を行うことによって価値を提供する ため、 その作業がもはや影響を及ぼさない(すなわち、SREエンゲージメントの価値提案が消滅する)場合、 またはその作業の大部分 がもはや(運用に対して)エンジニアリング側ではない場合、 進行中のSREエンゲージメントを再検討する必要がある。 一般に、個々 のSREは、大変な重いチームから、 より興味深いエンジニアリング作業を伴うチームへと移行する。 チームレベルでは、SREがコストに見合うだけの十分なビジネス価値を提供しなくなった場合は、 サービスを引き渡すことができる。 例えば: 進行中のSRE契約が不要になるレベルにサービスが最適化されている場合 サービスの重要性または関連性が低下した場合 サービスが寿命に近づいている場合 以下のケーススタディでは、 2つのGoogle SREエンゲージメントモデルがどのように終了したかを示す。 前者は概ね肯定的な結果で 終わり、後者はより微妙な結果で終わったものである。 Ending the Relationship(p385) Case Study 1: Ares (p385)
  23. 23. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 23/26 Googleの不正利用対策SREチームとCAT(Common Abuse)ツールチームは、 ほとんどのGoogleの資産に不正使用防止の保護を提供 し、 ユーザー向けの製品と連携してユーザーを安全に保った。 Abuse SREチームはCATの運用サポートの負担を軽減するために エン ジニアリング作業を行い、開発者がユーザーをサポートする上で 直接的な役割を果たすことができた。 これらのユーザーはGoogle社 員で、彼らはCATが保護する資産を運用を担当していて、 CATの効果と対応時間に高い期待を抱いていたのだった。 不正利用との効率的な闘いには、絶え間ない注意、迅速な適応の変化、 そして新たな脅威や攻撃に直面したときの機敏な柔軟性が必要 である。 これらの要件は、信頼性が高く計画された機能開発というSREの一般的な目標と衝突した。 CATチームは攻撃のたびに定期的 に迅速な開発を実施し、適切に新しい保護を導入する必要があったが、Abuse SREは要求された変更を押し戻し、 それぞれの新しい保 護が生産システム全体に与える影響について、 より詳細な分析を要求した。 チーム間の協議やレビューに対する時間的な制約がこの緊 張を悪化させた。 状況を改善するために、Abuse SREとCATのリーダーシップは、 CAT内に専用のインフラストラクチャチームを作成するための 複数年 にわたるプロジェクトに携わった。 新たに結成された「Ares」チームは、 Googleの資産のために不正利用と戦うためのインフラを統 一することとし、 このチームは、本番インフラストラクチャの知識を持ち、 大規模サービスの構築と運用を経験したCATエンジニアに よって配置されました。 チームはproductionの知識をAbuse SREからCATインフラストラクチャチームのメンバーに 移転するための交 換プログラムを開始した。 SREチームはアレスチームに、大規模な分散サービスを既に運用している場合に、 本番環境で新しいサービスを開始する最も簡単な方 法は、 サービスにかかる追加の認知的負荷を最小限に抑えることだと伝えた。 この認知的負荷を減らすために、システムはできるだけ同質であるべきである。 プロダクションサービスのコレクションをまとめて展 開および管理することは、 同じリリース構造、キャパシティプランニング、ストレージにアクセスするための サブサービスなどを共有 できることを意味する。 このアドバイスに従って、Aresはモジュール化の概念を適用してマイクロサービスモデルに移行することで、不正利用防止スタック全 体を再設計した。 彼らはまた、開発者に抽象化を提供する新しいレイヤーを構築したので、 モニタリング、ロギング、そしてストレージのような低レベ ルのプロダクションの詳細について心配する必要がなかった。
  24. 24. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 24/26 この時点で、Aresチームは新しい不正利用対策インフラストラクチャを管理することによって、 CATのSREチームのように振る舞うよ うになり、 その一方で、虐待SREは、全体的な虐待インフラストラクチャの運用展開と 効率的な日常運用に焦点を当てていた。 AresのエンジニアとAbuse SREとの共同作業により、次のような改善がもたらされた。 CATチームには不正利用防止の専門家でもある「社内」の制作専門家がいたため、 Abuse SREは新しい機能の統合を検討する必 要がなくなった。 これにより、新機能の生産までの時間が大幅に短縮された。 同時に、新しいインフラが生産管理の詳細を抽 象化したことにより、 CATチームの開発者の速度は向上した。 Abuse SREチームは、ほとんどの要求が インフラの変更を必要としなかったため、 CATチームからの新機能の起動要求が大 幅に減少した。 インフラの変更はほとんど必要ないため、 チームは新機能の影響を評価するために必要な知識も少なくて済 む。 インフラの変更が必要な場合は、 Abuse SREは特定の機能ではなく、インフラへの影響を明確にするだけで済む。 製品の統合は機能の開始と同等の努力で行われたため、 悪用防止のためのインフラと統合する必要がある製品は、 より迅速で 予測可能な所要時間がありました。 このプロジェクトの終わりに、ABUSE SREはCATの直接サポートから解放され、 代わりに基盤となるインフラに焦点を当てた。 これ によってCATの信頼性が損なわれたり、 CATチームに追加の運用作業が行われたりすることはなかった。 代わりに、それはCATの全体 的な開発速度を速めました。 現在、Aresは多数のGoogle資産でユーザーを保護しています。 チームの創設以来、SREと製品開発は、 インフラが本番環境でどのよ うに機能するかについて 共同で決定を下すために協力してきた。 このパートナーシップは、アレスの努力が 運命の分かち合いを生み 出したためにのみ可能でした。 SREサポート関係を維持するためのコストが、 SREが提供する価値(知覚または測定)よりも高い場合がある。 このような場合は、 SREチームを解散させて関係を終了させるのが合理的である。 関係の価値が時間の経過とともに低下すると、 その関係を終了することが理にかなっている時点を特定することは非常に困難である。 収益重視のデータ分析パイプラインをサポートしているGoogleの2つのチームが、 この課題に直面した。 やり方を分けることが適切で Case Study 2: Data Analysis Pipeline(p387)
  25. 25. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 25/26 あると考えることは、 特に10年間の協力の後、些細なことではなかった。 振り返ってみると、SREチームと製品チームの関係を再考 するために必要な強力な指標である、 チームインタラクション内のいくつかのパターンを特定することができた。 The pivot ターンダウンの3年前、関係者全員が、 主要なデータ分析パイプラインが拡張性の限界に直面していることを認識した。 その時、開発者チームは彼らの新しいシステムの計画を始めることを決め、 そして新しい努力に少数のエンジニアをアサインし た。 その努力が合体し始めたので、新しいシステムでの作業を支持して、 既存のシステムのための大きな、複雑な、または危険な 機能の開発を優先しないことは 理にかなっていた。 これは時間とともに2つの重要な影響を及ぼした: 新しいプロジェクトには非公式の規則が適用された。 プロジェクトの複雑さや既存のシステムを プロジェクトに合わせ て変更することに伴うリスクが十分に高かった場合は、 新しいシステムに投資するほうが良かった。 リソースが新しいシステムの開発に移行するにつれて、 既存のシステムに対する比較的保守的な変更でさえもより困難に なった。 それにもかかわらず、使用量は非常に高い割合で増え続けまた。 Communication breakdown 交換システムを同時に設計、構築、立ち上げしながら、既存のシステムを運用し続けることは、 どのエンジニアリングチームにとって も困難である。 新しいシステムと古いシステムに重点を置いた人々の間には、 当然のことながらストレスが発生する。 チームは、困 難な優先順位付けの決定を必要がある。 チームが組織的に分離されている場合、 これらの問題はさらに複雑になる可能性がある。 た とえば、SREチームが既存のシステムの保守と運用に重点を置いている場合や、 次世代システムに取り組んでいる開発チームに分かれ ている場合なである。 チーム全体で良好な仕事上の関係を維持し維持するためには、 このサイクル全体を通して、定期的でオープンで協力的なコミュニケー ションが不可欠である。 この例では、コミュニケーションのギャップがチーム間の仕事上の関係の分断をもたらした。 Decommission SREと開発者チームの間の切断が克服できないことに気付くまでには少し時間がかかった。 結局のところ、最も簡 単な解決策は、組織の障壁を取り除き、 開発者チームに新旧システムの作業の優先順位付けを完全に制御させることだった。 これ らのシステムは、古いシステムが完全に廃止されるまでの 18~24か月間重複すると予想されていた。 SREと製品開発機能を1つのチームにまとめることで、 上級管理職は説明責任の分野に最大限対応できるようになった。 その間、チー ムは運用上のニーズと速度のバランスをとる方法を決定できる。 2つのSREチームを廃止することは楽しい経験ではありませんでした
  26. 26. 5/14/2019 SRWBE18 file:///C:/Users/jun/Desktop/20190513/20190514/SRWBE18.md.html 26/26 が、 どこにリソースを投資するかという絶え間ない緊張が解消された。 開発者チームには避けられない追加の運用上の負荷があったが、 サービス内部の知識が豊富な人々と古いシステムの所有権を再調整す ることで、 運用上の問題により迅速に対処する機会が与えられた。 このチームはまた、停止の潜在的な原因についてより多くの洞察を 持っていた。 それは一般的により効果的なトラブルシューティングとより迅速な問題解決をもたらした。 ただし、開発チームがサービ スを短期間でサポートするために 必要な運用作業の微妙な違いについて学んだ一方で、避けられない悪影響がいくつかあった。 SREチ ームの最後の仕事は、開発チームが作業を引き受けることができるように、 この知識の伝達をできる限り円滑にすることだった。 チームが効果的に協力して問題を解決することで、 仕事上の関係がより健全であれば、 SREは短期間のうちに開発作業を開発者チーム に渡していたはずである。 予想される成長ニーズに合わせてシステムが再安定化され強化された後、 SREは通常、システムの責任を取 り戻す。 SREと開発チームは、正面から直面している問題に対処し、 再設定が必要な問題点を特定する必要がある。 SREの仕事の1つ は、変化するビジネスニーズに直面しても 生産の卓越性を維持することを支援することであり、 多くの場合、これは開発者と協力して 困難な問題に対する解決策を見つけることを意味した。 SREチームの関与形態は、サービスのライフサイクルのさまざまな段階で変化する。 この章では、各フェーズに固有のアドバイスを提 供した。 グーグルとニューヨークタイムズのSREチームの例は、 エンゲージメントを効果的に管理することは、 優れた技術設計を決 定することと同じくらい重要であることを示している。 時にはSREエンゲージメントは自然な結論に達するべきです。 アレスとデータ 分析パイプラインチームのケーススタディは、 これがどのように起こり得るのか、そしてどのようにして エンゲージメントを終わらせ るのが最もよいかの例を提供しました。 SREと製品開発チームの間に効果的な関係を築くためのベストプラクティスになると、 共通の目的意識と目標を定期的かつオープンな コミュニケーションで確立することが重要である。 SREチームの影響をさまざまな方法でスケールすることができるが、 関係管理に関 するこれらの原則は常に当てはまるはずである。 エンゲージメントの長期的な成功を維持するためには、 チームの目標を調整し、互い の目的を理解することに投資することが、 SLOを防御するのと同じくらい重要である。 Conclusion(p389)

×