トップ > SRE > SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときに起こること

SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときに起こること

SRE

参考 : https://sre.google/sre-book/table-of-contents/

SREって何?

SRE誕生の経緯

歴史的に、企業は複雑なコンピューティング システムを実行するためにシステム管理者を雇用してきました。 シスアドとも呼ばれるこの役職は、サービスを運用し、イベントが発生したり、イベントに応じてアップデートが必要になるたびに対処します。

システム管理者の役割には、製品の開発者に求められるスキル セットとは著しく異なるスキル セットが求められるため、開発者とシステム管理者は「開発」と「運用」または「ops」という別々のチームに分割されている状態です。

しかし、この開発者とシステム管理者という役割分担は、大きな問題があります。

一つは、システム管理者は手作業が中心となっていたため、システムが大きくなるにつれて、必要となる人数も増えていたということです。 もう一つは、開発者とシステム管理者の間に発生する心理的/技術的な溝です。

  • 開発者は「いつでも、支障なく何でもリリースしたい」という要求を持っています
  • システム管理者は「「いったんシステムが機能したら、絶対に何も変更したくない」という要求を持っています

ほとんどの障害は、新しい構成、新機能のリリース、新しいタイプのユーザー トラフィックなど、何らかの変更によって発生するため、2 つのチームの目標は根本的に対立してしまうのです。

Googleはどのようにこの問題に対応したのか？

SRE とは、ソフトウェアエンジニアに運用チームの設計を依頼したときに起こることです。

GOogleの運用チームは、以下の割合で構成されていました。

  • 50～60% は Google ソフトウェア エンジニア、より正確には Google ソフトウェア エンジニアの標準手順で採用された人々です。
  • 40～50% は、Google ソフトウェア エンジニアリングの資格 (必要なスキル セットの 85～99%) に非常に近い候補者であり、さらにSRE には役立つもののほとんどのソフトウェア エンジニアには珍しい技術スキル セットも持っています。(UNIXシステムの内部とネットワークの詳細)

SRE に共通するのは、複雑な問題を解決するソフトウェア システムを開発するという信念と適性です。

SRE の採用に対する当社のアプローチの結果、(a) 手作業でタスクを実行することにすぐに飽きてしまい、(b) 複雑なソリューションであっても、以前の手作業に代わるソフトウェアを作成するために必要なスキルセットを持つ人々で構成されるチームが誕生しました。

SREは何をしているのか?

  • すべての SRE の「運用」作業 (チケット、オンコール、手動タスクなど) の合計に 50% の上限を設けています。この上限により、SRE チームはサービスを安定して運用可能にするのに十分な時間をスケジュールに確保できます。
  • SRE チームは残りの 50% の時間を実際の開発に費やす必要があります。

このように、SREチームは運用作業を実行しつつ、運用を自動化するための開発を行うことで、サービスが拡大した場合でも人数を増やさずに対応ができるのです。

SREの目標

エンジニアリングへの注力

前提として、SREが行う運用作業の量は、常にモニタリングされています。 そして、全作業の割合のうち50%以下になるように管理されています。

SREが勤務する8時間から12時間のうち、一度のオンコールシフトの間に受けるイベントは平均して2つです。 この量を目安とすると、イベントの正確な処理に加えてクリーンアップとサービスのリストア、ポストモーテムへの取り組みへの時間の確保が可能です。

サービスのSLOを確保しつつ、変更の速度を最大化する

DevOpsには両者の間に対立がありましたが、これはイノベーションのペースと製品の安定性のトレードオフが発生することによるものです。 SRE では、この対立を エラーバジェット を導入して解決します。

エラー バジェットは可用性目標から 1 を引いた値になります。 99.99% の可用性があるサービスは、0.01%がエラーバジェットです。 予算を使い過ぎない限り、SREチームはこのエラーバジェットを好きなことに使うことができます。

開発チームは、機能をリリースして新しいユーザーを引き付けたいと考えていますが、 リリースする製品にリスクを負ってエラー バジェットのすべてを使うことが理想です。

また、SREチームにとってもこの活動をフレームワークとして導入していくことで、エラーバジェットを節約しようと考え始めます。 この考えが、段階的ロールアウトや 1%experiment につながるのです。

モニタリング

  • 監視の従来型で一般的なアプローチは、特定の値または状態を監視し、その値を超えたりその状態が発生したりしたときに電子メール アラートをトリガーすることです。 しかし、このタイプの電子メール アラートは効果的なソリューションではありません。人間が電子メールを読んで、それに応じて何らかのアクションを実行する必要があるかどうかを判断する必要があるシステムには、根本的な欠陥があります。
  • SREにおけるモニタリングでは、ソフトウェアが解釈を行い、人間はアクションを実行する必要がある場合にのみ通知を受ける必要があります。

有効なモニタリングのアウトプットには次の 3 種類があります。

  • レベル hight : アラート
    • 状況を改善するために、現在起こっている、またはこれから起ころうとしている何かに対して人間が直ちに行動を起こす必要があることを示します。
  • レベル middle : チケット
    • 人間が行動を起こす必要があるが、すぐに行動を起こす必要はないことを示します。システムは状況を自動的に処理することはできませんが、人間が数日以内に行動を起こせば、被害は発生しません。
  • レベル low : ログ
    • この情報を見る必要のある人はいませんが、診断や法医学の目的で記録されます。何か他の理由でログを読むように指示されない限り、誰もログを読まないことが予想されます。

インシデント対応

以下のサイトによると、可用性は以下の関数で表すことができます。

https://orangematter.solarwinds.com/2015/12/21/the-factors-that-impact-availability-visualized/

MTBFとMTTRの MTは mean time のことで、日本語だと平均時間に該当します。それぞれの定義は以下の通りです。

  • MTBF (平均故障間隔) : 正常に動いている時間
  • MTTR (平均復旧時間) : 正常に動いていない時間

SREのインシデント対応に関係があるのは、MTTR(平均復旧時間)であり、この数字が少ないほど可用性が高いと言えます。

SREはMTTR（平均復旧時間）に対して、次の二つのアプローチを行い、数値を減少させてます。

  • 人間が必要ない自動化されたインシデント対応を推進する。
  • 人間が必要な場合、事前にベストプラクティスを検討して「プレイブック」に記録しておくと、「即興で対応する」戦略と比較して MTTR が約3倍向上することがわかっています。

CICD

ダウンタイムの原因のうち、約 70% が稼働中のシステムの変更によるものです。 この分野のベスト プラクティスでは、自動化を使用して次のことを実現します。

  • 段階的な展開の実施(自動デプロイ)
  • 問題を迅速かつ正確に検出(自動テスト、ヘルスチェック?)
  • 問題が発生した場合に元に戻す(自動ロールバック)

つまり、CICD?

需要予測とキャパシティプランニング

多くのサービスとチームが、必要なときに必要なキャパシティが確保されるようにするために必要な手順を実行していません。 キャパシティ プランニングでは、予想されている以上に、いくつかの手順が必須です。

  • 生産能力の獲得に必要なリードタイムを超える正確な有機的需要予測
  • 需要予測に非有機的な需要源を正確に組み込む
  • システムの定期的な負荷テストを実施して、生の容量（サーバー、ディスクなど）とサービス容量を相関させる

page:https://minegishirei.hatenablog.com/entry/2025/01/06/075315