サイト信頼性エンジニアリング（SRE）では、ソフトウェア・エンジニアリングを使用することで、他の方法ではシステム管理者（sysadmins）が手動で行っているIT運用作業（実動システム管理、変更管理、インシデント対応、緊急対応など）を自動化します。

SREの背後にある原則は、ソフトウェア・コードを使用して大規模なソフトウェア・システム監視を自動化することが、手動操作による介入よりも拡張性が高く持続可能な戦略であるということです（特に、このようなシステムがクラウドに拡張または移行される場合）。

SREはまた、新規ソフトウェアや更新を継続的に実動へリリースしたい開発チームと、動作の停止やその他運用上の問題が絶対に起こらないという確信がない限りはどんなタイプの更新や新規ソフトウェアもリリースしたくない運用チームとの間に、当然起こりうる軋轢の大部分を減らす、あるいはなくすことも可能です。結果として、DevOpsに絶対に必要というわけではありませんが、SREはDevOps原則に密接に合致し、DevOpsの成功において重要な役割を担います。

SREという概念は、GoogleのVPoEであるBen Treynor Sloss氏によるもので、「SREは、ソフトウェア・エンジニアに運用チームの設計を依頼した時にできあがるものです。（SRE is what happens when you ask a software engineer to design an operations team.）」という説明がよく知られています。

サイト信頼性エンジニアは、IT 運用の経験を持つソフトウェア開発者で、コーディングに関する知識を持ち、大規模なIT環境で「ダウンタイムなく稼働させる」方法を理解している人物です。

サイト信頼性エンジニアは、ログ分析、パフォーマンス・チューニング、パッチ適用、本番環境のテスト、インシデントへの対応、事後検証など、手動のIT運用とシステム管理タスクの実行に時間の半分を費やし、残りの時間で、それらのタスクを自動化するコードを開発しています。このチームは、前者に費やす時間を減らし、後者に費やす時間を増やしたいと考えています。

その理由は、SREチームは開発チームと運用チームの間の橋渡しとして機能し、開発チームが新しいソフトウェアや新機能をできるだけ早く本番環境に導入できるようにすることを目的としているためです。これを実行すると同時に、組織が顧客と締結したサービス・レベル契約（SLA）に従い、IT運用のパフォーマンスとエラー・リスクが合意された許容範囲内となるようにしています。SREチームは、豊富な経験と運用データに基づいて、開発チームと運用チームが以下を開発または確立できるようにサポートしています。

• サービス・レベル指標（SLI）：システムによって提供されるサービス・レベル、つまり可用性（アップタイム）やレイテンシーなどの測定値。
  
  
• サービス・レベル目標（SLO）：サービス・レベル指標を測定するために合意された手段。
  
  
• エラー・バジェット：SLAの契約義務に違反することなく、システムが障害を起こしたりパフォーマンスが低下したりすることが許容されている最大時間。エラー・バジェットは単なる指標ではなく、サイト信頼性エンジニアリング・チームが企業のイノベーションのペースとサービスの信頼性を自動的に調整するために使用する実用的なツールです。

エラー・バジェットは、サイト信頼性エンジニアリング・チームが企業のイノベーションのペースとサービスの信頼性を自動的に調整するために使用する実用的なツールです。

例えば、ある会社のSLAが年間99.99%の稼働率（一般的な可用性目標）を義務付けているとします。つまり、月間エラー・バジェット（特定の月において契約上の義務を違反せず許容されるダウンタイムの合計時間）は約4分23秒になります。

ここで、開発チームがいくつかの新しい主要機能やシステムの改善を展開したいとします。システムがエラー・バジェット内で動作している場合、チームは新しい機能をリリースできますが、そうでない場合、チームは運用チームと協力してこれらのエラーや停止を許容レベルまで改善するまで、新しい機能を投入することはできません。

このように、エラー・バジェットは、開発チームと運用チームが以下の行動をするよう働きかけます。

• サービスの安定性とパフォーマンスを向上させること。
  
  
• 新しい機能またはアプリケーションの導入についてデータ駆動型の意思決定を行うこと。
  
  
• 許容範囲内でリスクを負うことで最大限のイノベーションを促進すること。

DevOpsは、ソフトウェア配信ライフサイクルを自動化し、開発チームと運用チームに責任を共有させ、お互いの作業に役立つインプットを増やすことで、より高品質のアプリケーションをより迅速に提供できるようにする最新の方法です。

SREと同様、DevOpsは、より多くのアプリケーションと変更をより迅速にリリースする必要性と、本番環境の「停止」を回避する必要性のバランスをとることで、ビジネス・アジリティーを高めます。また、サイト信頼性エンジニアリングと同様、DevOpsの許容可能なエラー・リスクを明確にすることで、このバランスの均衡を保つようにします。実際、サイト信頼性エンジニアリングとDevOpsは非常に似ているため、これらを同じものだと主張する専門家もいますが、ほとんどの専門家は、サイト信頼性エンジニアリングがDevOps原則を実行する優れた方法だと考えています。例：

DevOpsの原則：ツールとオートメーションを活用して組織のサイロ化を排除します。

SREの実践：開発者がソフトウェアの開発と改善に使用するのと同じツールを使用して、運用を自動化および改善します。

DevOpsの原則：失敗を正常なものとして受け入れ、段階的に変更を適用します。

SREの実践：エラー・バジェットに基づき、許容レベル内で新機能を継続的にデプロイします。

DevOpsの原則：すべてを測定します。

SREの実践：SLAに記載されるメトリクスに基づき、新しいソフトウェアをリリースするかどうかを決定します。

サイト信頼性エンジニアリングはDevOpsの成功をサポートするだけではなく、企業が次のことを行えるようにします。

• 組織内のすべてのサービスにわたりメトリクス、ログ、痕跡を追跡し、インシデントが発生した場合に根本原因を特定するためのコンテキストを提供することで、サービスの健全性に対する可視性を高めること。
  
  
• 開発チームと運用チームがSLAに違反した場合に発生するコストについて理解できるようにし、経営陣がシステムの信頼性が製造部、営業部、マーケティング部、カスタマー・サービス部などの部署に与える影響を定量化できるようにすることで、ダウンタイムによりかかるコストを定量化すること。
  
  
• 効率的なオンコール・プロセスを構築し、アラート・ワークフローを合理化することで、インシデントへの対応を最適化すること。
  
  
• IT運用に関する深い理解と機械学習およびオートメーションを組み合わせて、最新のネットワーク運用センターを構築し、問題に対処する担当者に直接アラートを送信すること。

平均的なエンタープライズが毎年、運用データを2倍から3倍生成している主な理由の1つには、従来のITおよびオンプレミスのデータ・センターからハイブリッドクラウド環境へのマイグレーションがあります。SREは次第に、このデータを活用して、システムの管理、運用、およびインシデント対応を自動化するために、またIT環境がより複雑になっても企業の信頼性を向上させるために重要なものと見なされるようになってきています。

クラウドネイティブ開発手法（特にマイクロサービスとしてのアプリケーションの構築およびコンテナへのデプロイ）により、アプリケーションの開発、デプロイメント、および拡張性を簡素化することができます。ただし、クラウドネイティブ開発は、管理、運用、およびマネジメントを複雑化し、ますます分散された環境を作り上げることにもなります。SREチームは、クラウドネイティブ手法によって可能になる急速なイノベーションをサポートでき、またこれ以上の運用上のプレッシャーをDevOpsチームに与えることなく、システム信頼性を保証し、向上させます。