サイト信頼性エンジニアリング (SRE) とは?

サイト信頼性エンジアリングとは、運用プロセスを活用して、それらをソフトウェアエンジニアリングチームに割り当てて自動化するプロセスのことです。

IT チームは SRE 手法の導入を絶えず模索しています。サイト信頼性エンジアリングとは、運用のプラクティスをソフトウェアエンジニアリングに委ねて、人間が行うタスクや、問題解決、システム管理を自動化することです。SRE チームは、サービスの変更管理、緊急事態対応、監視、可用性、パフォーマンス、レイテンシ、効率、キャパシティ計画を担当し、通常はプロセス自動化用のソフトウェアの開発を行っています。

システムはコードで管理できるため、SRE は、ソフトウェアの信頼性と拡張性を実現し、製品と機能の信頼性確保と新しい製品と機能のリリースのバランスを取るうえで価値ある資産となります。

Google の Ben Treynor Sloss 氏が「SRE」という言葉を創造

SRE の立案者である Google の Ben Treynor Sloss 氏は、「運用と呼ばれていたタスクをソフトウェアエンジニアが引き受けると起きること」が SRE であると言い表しています。機能が何も壊さず、エンドユーザーが不便にならず、開発期間に不都合がないことを望む人と、新しい機能を開発し、ロールアウトの準備ができたら直ちにリリースすることを望む人との間の矛盾を検証した結果、この概念が生まれました。SRE は双方の妥協点なのです。

Google エンジニアチームが SRE に関する本を執筆

Google は SRE に関する本を公開して、オンライン上で無料で入手できるようにしています。この本では、SRE が果たす役割と実行に関する推奨されるベストプラクティスを詳細に解説しています。パート 2 は原則、パート 3 はプラクティスに関するものであり、それぞれ注目に値します。

SRE の原則:Google によると、SRE の核となる原則は次のとおりです。

  • リスクの受け入れ:エラーバジェットを使う中立的なアプローチによりサービスを管理します。
  • サービスレベル目標:契約から切り離した指標に関する推奨事項を示し、SRE で使用される用語を検証します。
  • トイルの削減:価値のない日常的なタスクや反復的なタスクから離れることです。
  • 分散したシステムの監視:信頼性を確保するために、組織内で起きている出来事に常に目を光らせます。
  • リリースエンジニアリング:リリースに整合性があり、機能停止の原因とならないように、リリースを慎重に処理します。
  • シンプル:システムが複雑になりすぎると、信頼性が低下し、シンプルなものに戻すことができません。

SRE のプラクティス:SRE は外部や内部ユーザー用の関連システムを実行し、サービスの責任を担います。サービスの運用を成功させる要因には、キャパシティ計画、機能停止の根本原因への対処、監視システムの開発などがあります。Google は、信頼できるサービスを次のように階層化しています。

  • 製品:信頼性階層の最上位。製品が機能し、信頼できることを示します。
  • 開発:企業内でのソフトウェアエンジニアリングとシステム設計作業です。
  • キャパシティ計画:構築済みのキャパシティをロードバランシングによって適切に使用します。
  • テストとリリースの手順:不具合の内容を把握した後に、それを積極的に防止します。製品を注意深くテストしてからリリースします。
  • インシデント後の対処/根本原因分析:非難するのではなく、インシデントが繰り返し発生するのを防止するために問題に対処する文化を築きます。
  • インシデント応答:オンコールの体制を取り、システムの状態を把握し、効果的なトラブルシューティングを実施し、慎重な計画を事前に立てておきます。
  • 監視:エンドユーザーが気づく前に問題を認識します。
What-is-AIOps-1

優れた SRE には経験が必要

サイト信頼性エンジニアリングの役割を最適に実行できるのは、ソフトウェアの経験が豊富な人です。決して初心者に勧められるポジションではありません。SRE の業務を適切に実行するためには、熟練したソフトウェアエンジニアリングと、大規模で複雑なシステムの理解が必要です。

SRE とは哲学である

サイト信頼性エンジニアリングのポジションには、必要とされる心構えがあります。技術的なスキルは必要ですが、重要なのは運用の概念を理解することです。SRE では従来型のソフトウェア開発を基盤にすることも重要ですが、企業のプロセスを総合的に理解し、信頼性の高いシステムを促進することも非常に重要です。

SRE は変更を促す触媒である

SRE の重要な原則を適用して、可能な限り信頼性を上げることは、組織内の全員の仕事であるべきです。各チームに信頼性のモデルを適用し、各チームでモデルがどのように適応し、チーム全員にどのように影響を及ぼすかについて話し合う時間を取ります。

サイト信頼性エンジニア (SRE) のロールと責任

新製品発売のゴーサインは、その時点での製品のパフォーマンスに基づいて出されますが、そのときのアプリケーションは通常、100% の状態ではありません。SRE チームは、サービスレベルアグリーメントを作成して、システムを定義し、エンドユーザーの用途を定義します。サービスレベルアグリーメントには一般的に、エラー予算や、機能停止とエラーの最大しきい値を記載します。

SRE はコードを書くことができる

開発者チームと SRE はスタッフを共有しています。つまり SRE を追加すると開発者が 1 人減るということです。その逆も同じです。この制度は自己調整により、開発者と SRE がスタッフをめぐって争わないようにしています。SRE も開発者もコーディングの能力があるため、開発チームで一緒に作業することができます。

SRE はプロジェクト間を移動できます。これにより SRE のモチベーションが上がり、チームのメンバーは個人の目標と目的の追及に献身的に取り組みます。

サイト信頼性エンジニアの一般的なロールと責任

  • ソフトウェアを構築して運用とチームを支援する
  • エスカレーションされた問題を修正する
  • オンコールプロセスを最適化する
  • チームのナレッジを文書化する
  • インシデント後の検証を実施する

SRE は、IT 運用、ソフトウェアエンジアリング、サポートの中心に位置し、チームの強力な基盤となり、関係を築くことで、フィードバックループとコラボレーションを強化し、信頼性を高めることができます。

サイト信頼性の専門家は SRE を効果的に機能させる

SRE は、大局的な視点からニーズに注意を払い、異なるチームを同一の目標に向けて導きます。

自動化は SRE の基盤である

SRE の最も大きな役割は、非効率性を解消し、簡単に自動化できるものを特定することです。時間のかかるタスクを止めて、手動の作業をあまり行わずに効率を高めることができます。

SRE はテクノロジー企業だけのものではない

SRE のプラクティスは、技術系の業界だけに適用されているわけではありません。サイト信頼性エンジアリングの文化は、e コマース、カスタマーサービス、製造業にまで拡大できます。

DevOps は、良いソフトウェアを構築して提供するための手法であり、運用と開発のロールを融合するために、ソフトウェアの開発と運用を組み合わせます。DevOps の運用側ではなく、開発側が、SRE を推進する傾向があります。

DevOps の詳細
Deliver modern operations for DevOps and SRE teams (DevOps と SRE チームのための最新の運用を実現)

Linux コンテナは、クライウドネイティブな開発に必要なテクノロジーを提供できます。コンテナは環境の統合をサポートし、データ連携、自動化、開発、デリバリーを可能にします。Kubernetes を使用すると、必要な Linux コンテナを自動化できます。

SRE 向けの 1 つに統合されたツールセットはありません。ただし、社内で SRE の機能を構築することと、自動化により拡張性と再現性に対応することが不可欠です。

ServiceNow は価値を高めます。複数のチームの作業を連携させ、マイクロサービスを登録し、観測可能データを相関して、信頼できる測定基準をすぐに利用できるようにし、変更を自動化し、障害を予測します。これらすべてを実行しても、既存のツールは影響を受けません。

ビジネスに合わせて拡張できる機能

次の SRE 変革計画は、 ServiceNow のソリューションを使用して作成しましょう。