サイト信頼性エンジニアリング（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.）」という説明がよく知られています。
DevOps
サイト信頼性エンジニアとは、IT運用経験のあるソフトウェア開発者です。コーディング方法を知っていて、大規模なIT環境で「稼働させ続ける」方法もわかっています。
サイト信頼性エンジニアは、手動IT操作やシステム管理作業（ログの分析、パフォーマンス・チューニング、パッチの適用、実動環境のテスト、インシデントへの対応、事後分析の実施）に自分の時間の半分も使いません。残りの時間は、それらの作業を自動化するコードの開発に費やします。彼らの目標は、前者には時間を使わず、後者に時間をかけるようになっていくことです。
より高度なレベルになると、SREチームは開発チームと運用チームの架け橋としての役割を果たします。これにより、開発チームは新しいソフトウェアや新機能を可能な限り迅速に実動化できます。一方、組織が顧客と交わしたサービス・レベル・アグリーメント（SLA）に合致する、IT運用のパフォーマンスおよびエラー・リスクの合意済み許容レベルも保証されます。このような経験と豊富な運用データを基に、SREチームは開発チームと運用チームが、以下を確立するのを支援します。
- サービス・レベル指標（SLI）：システムが提供するサービス・レベルの指標。可用性（アップタイム）やレイテンシーなどの測定基準。
- サービス・レベル目標（SLO）：サービス・レベル指標を測定する合意済みの手段。
- エラー・バジェット：SLAの契約条項に違反することなく、システムの障害やパフォーマンス低下が許容される最大時間。エラー・バジェットは、企業のイノベーションの速度をサービス信頼性に対して自動的に調整するために、サイト信頼性エンジニアリング・チームが測定基準以上に使用するツールです。
エラー・バジェットは、企業のサービスの信頼性をソフトウェア開発とイノベーションの速度に対して自動的に調整するためにSREチームが使用するツールです。
企業のSLAが、年間に99.99%のアップタイム（共通の可用性目標）を約束するものとします。これは、毎月のエラー・バジェット（当月の契約結果なしに許容される合計ダウンタイム）が約4分23秒であることを意味します。
例えば、開発チームは、いくつかの新機能や改善点をシステムに展開することを望んでいます。システムがエラー・バジェット下で稼働している場合、開発チームは新機能をデリバリーできます。そうでない場合、チームは運用チームと連携してこれらのエラーや停止を許容レベル以下にするまで、新機能をデリバリーできません。
このように、エラー・バジェットは、開発チームと運用チームが以下を行うために役立ちます。
- サービスの安定度およびパフォーマンスの向上
- 新しい機能やアプリケーションのデプロイについてデータに基づいた意思決定を行う
- 許容範囲内でリスクを負うことにより、イノベーションを最大化する
DevOpsは、高品質のアプリケーションを迅速にデリバリーするための現代的な方法です。これは、ソフトウェア・デリバリーのライフサイクルを自動化すること、また開発チームと運用チームにより多くの責任を共有させ、より多くのインプットを互いの作業に提供することによって実現します。
SREと同様に、DevOpsは、より多くのアプリケーションおよび変更を迅速にデリバリーする必要性と、実動環境を壊さないようにする必要性とのバランスをとることにより、業務をよりアジャイルなものにします。また、SREと同様に、DevOpsは、エラーの許容可能リスクを設定することによってこのバランスを達成することを目標としています。実際、SREとDevOpsは非常に似ているため、これらは同じものだというエキスパートもいますが、大半のエキスパートはSRE実践を、DevOps原則を実行に移す優れた方法であると考えています。例としては、以下が挙げられます。
DevOps原則：組織のサイロ化を防ぎ、ツールと自動化を活用する
SRE実践：開発者がソフトウェアの開発と改善に使用するものと同じツールを使用して運用を自動化し、改善する
DevOps原則：障害を通常のものとして受け入れ、段階的変更を行う
SRE実践：エラー・バジェットを使用して、許容レベル内で継続的に新機能をデプロイする
DevOps原則：あらゆるものを測定する
SRE実践：SLA測定基準に基づいて新規ソフトウェアのリリースを決定する
DevOpsの詳細については次の動画をご覧ください（5:58）：
DevOps成功のサポートに加えて、サイト信頼性エンジニアリングは以下のように企業に役立ちます。
- サービス正常性に対するより高い可視性を得る。 組織内のすべてのサービスにわたって測定基準、ログ、およびトレースを追跡し、インシデントが発生した場合に根本原因を特定するためのコンテキストを提供します。
- ダウンタイムのコストを数値化する。 開発チームと運用チームがSLA違反のコストを把握するのを支援し、またマネジメントが実動、セールス、マーケティング、カスタマー・サービス、およびその他のビジネス機能でのシステム信頼性の影響を数値化するのを支援します。
- インシデント対応を最適化する。 効率的なオンコール・プロセスを構築し、アラート・ワークフローを合理化します。
- 現代的なネットワーク運用センターを構築する。 IT運用の深い理解と、機械学習および自動化を組み合わせて、問題に対処する責任者にアラートを直接送信します。
平均的なエンタープライズが毎年、運用データを2倍から3倍生成している主な理由の1つには、従来のITおよびオンプレミスのデータ・センターからハイブリッドクラウド環境へのマイグレーションがあります。SREは次第に、このデータを活用して、システムの管理、運用、およびインシデント対応を自動化するために、またIT環境がより複雑になっても企業の信頼性を向上させるために重要なものと見なされるようになってきています。
クラウドネイティブ開発手法（特にマイクロサービスとしてのアプリケーションの構築およびコンテナへのデプロイ）により、アプリケーションの開発、デプロイメント、および拡張性を簡素化することができます。ただし、クラウドネイティブ開発は、管理、運用、およびマネジメントを複雑化し、ますます分散された環境を作り上げることにもなります。SREチームは、クラウドネイティブ手法によって可能になる急速なイノベーションをサポートでき、またこれ以上の運用上のプレッシャーをDevOpsチームに与えることなく、システム信頼性を保証し、向上させます。
移行
ハイブリッドクラウド
クラウドネイティブ
IBM Cloud Pak for Watson AIOpsは、IT運用担当者のために、AIを中核としたIT運用ツールチェーンを実現する、IT運用管理ソリューションです。
よりスマートなリソース管理により、インフラストラクチャーの支出を33％、データセンターの更新コストを75％削減し、エンジニアリングのための時間を30％取り戻すことができます。
インシデント解決の迅速化に必要なコンテキストを提供するために、アプリケーション・パフォーマンスの監視を向上させます。
AIと自動化をどのようにIT運用に適用するかを調べることは、SREが企業のアプリケーションのレジリエンスと堅固性を保証し、イノベーションをサポートするために貴重な時間と能力を確保するのに役立ちます。
IBMが提供するプロフェッショナル・レベルの研修と認定資格により、SREとしてのスキルを向上させることができます。IBM Cloudの環境とツールに関する知識を習得し、仮想ラボで演習を行うことができます。
DevOpsは、ソフトウェア開発チームとIT運用チームの作業を統合して自動化し、高品質なソフトウェアを迅速に提供できるようにします。
クラウドネイティブ・アプリケーションは複数のマイクロサービスから構成され、コンテナでパッケージ/デプロイされ、任意のクラウド環境で実行できるように設計されています。
Kubernetesは、アプリケーションのデプロイメント、管理、スケーリングを自動化する、オープンソースのコンテナ・オーケストレーション・プラットフォームです。