サイト信頼性エンジアリングとは、運用プロセスを活用して、それらをソフトウェアエンジニアリングチームに割り当てて自動化するプロセスのことです。
IT チームは SRE 手法の導入を絶えず模索しています。サイト信頼性エンジアリングとは、運用のプラクティスをソフトウェアエンジニアリングに委ねて、人間が行うタスクや、問題解決、システム管理を自動化することです。SRE チームは、サービスの変更管理、緊急事態対応、監視、可用性、パフォーマンス、レイテンシ、効率、キャパシティ計画を担当し、通常はプロセス自動化用のソフトウェアの開発を行っています。
システムはコードで管理できるため、SRE は、ソフトウェアの信頼性と拡張性を実現し、製品と機能の信頼性確保と新しい製品と機能のリリースのバランスを取るうえで価値ある資産となります。
SRE の立案者である Google の Ben Treynor Sloss 氏は、「運用と呼ばれていたタスクをソフトウェアエンジニアが引き受けると起きること」が SRE であると言い表しています。機能が何も壊さず、エンドユーザーが不便にならず、開発期間に不都合がないことを望む人と、新しい機能を開発し、ロールアウトの準備ができたら直ちにリリースすることを望む人との間の矛盾を検証した結果、この概念が生まれました。SRE は双方の妥協点なのです。
Google は SRE に関する本を公開して、オンライン上で無料で入手できるようにしています。この本では、SRE が果たす役割と実行に関する推奨されるベストプラクティスを詳細に解説しています。パート 2 は原則、パート 3 はプラクティスに関するものであり、それぞれ注目に値します。
SRE の原則：Google によると、SRE の核となる原則は次のとおりです。
- リスクの受け入れ：エラーバジェットを使う中立的なアプローチによりサービスを管理します。
- サービスレベル目標：契約から切り離した指標に関する推奨事項を示し、SRE で使用される用語を検証します。
- トイルの削減：価値のない日常的なタスクや反復的なタスクから離れることです。
- 分散したシステムの監視：信頼性を確保するために、組織内で起きている出来事に常に目を光らせます。
- リリースエンジニアリング：リリースに整合性があり、機能停止の原因とならないように、リリースを慎重に処理します。
- シンプル：システムが複雑になりすぎると、信頼性が低下し、シンプルなものに戻すことができません。
サイト信頼性エンジニアリングの役割を最適に実行できるのは、ソフトウェアの経験が豊富な人です。決して初心者に勧められるポジションではありません。SRE の業務を適切に実行するためには、熟練したソフトウェアエンジニアリングと、大規模で複雑なシステムの理解が必要です。
サイト信頼性エンジニアリングのポジションには、必要とされる心構えがあります。技術的なスキルは必要ですが、重要なのは運用の概念を理解することです。SRE では従来型のソフトウェア開発を基盤にすることも重要ですが、企業のプロセスを総合的に理解し、信頼性の高いシステムを促進することも非常に重要です。
SRE の重要な原則を適用して、可能な限り信頼性を上げることは、組織内の全員の仕事であるべきです。各チームに信頼性のモデルを適用し、各チームでモデルがどのように適応し、チーム全員にどのように影響を及ぼすかについて話し合う時間を取ります。
新製品発売のゴーサインは、その時点での製品のパフォーマンスに基づいて出されますが、そのときのアプリケーションは通常、100% の状態ではありません。SRE チームは、サービスレベルアグリーメントを作成して、システムを定義し、エンドユーザーの用途を定義します。サービスレベルアグリーメントには一般的に、エラー予算や、機能停止とエラーの最大しきい値を記載します。
開発者チームと SRE はスタッフを共有しています。つまり SRE を追加すると開発者が 1 人減るということです。その逆も同じです。この制度は自己調整により、開発者と SRE がスタッフをめぐって争わないようにしています。SRE も開発者もコーディングの能力があるため、開発チームで一緒に作業することができます。
SRE はプロジェクト間を移動できます。これにより SRE のモチベーションが上がり、チームのメンバーは個人の目標と目的の追及に献身的に取り組みます。
- ソフトウェアを構築して運用とチームを支援する
- エスカレーションされた問題を修正する
- オンコールプロセスを最適化する
- チームのナレッジを文書化する
- インシデント後の検証を実施する
SRE は、IT 運用、ソフトウェアエンジアリング、サポートの中心に位置し、チームの強力な基盤となり、関係を築くことで、フィードバックループとコラボレーションを強化し、信頼性を高めることができます。
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 のソリューションを使用して作成しましょう。