サイトリライアビリティエンジニアリング（SRE）とは？

サイトリライアビリティエンジニアリング（SRE）は運用をソフトウェアの問題として扱います。スケールに人を増やして対応するのではなく、それを自動化し、測定可能な信頼性の目標で統制します。

SREは、大規模なサービスを大勢のオペレーターなしで信頼性高く運用する方法としてGoogleで始まりました。中核となる考え方は、信頼性は望むものではなく、エンジニアリングし、測定し、速度とトレードオフする機能だということです。SREチームは、そのトレードオフを明示的にするツールとカルチャーを構築します。

SREの由来

SREは、手作業のtoilを行うのではなくソフトウェアを書くことでproductionシステムを運用するエンジニアのチームを表すためにGoogleで生まれた言葉です。前提は、運用作業は手作業で行うとスケールが悪いということであり、そのため自動化を構築する人々が自らpagerを持ち、信頼性の低いシステムの結果を体感します。

エンジニアリング目標としての信頼性

完璧なuptimeを目指すのではなく、SREは明示的な信頼性の目標を設定し、それに向けてエンジニアリングします。これにより信頼性は願望ではなく、システムの測定可能な性質になります。目標は計画のインプットになります。信頼性が目標を余裕をもって上回っていればチームはより速く出荷でき、下回っていれば減速して堅牢化します。

SLO、SLI、error budget

SREは、挙動を測定するservice level indicator（SLI）、目標を設定するservice level objective（SLO）、許容される失敗を定量化するerror budgetの上に構築されています。これらを合わせることで、「十分に信頼できるか」をめぐる議論を、誰もが同意できるデータ駆動の意思決定に変えます。

Toilの排除

Toilとは、サービスの規模に比例して増え、持続的な価値を生まない手作業で反復的な運用作業です。SREはtoilに費やす時間の割合を明示的に上限として設け、エンジニアが自動化のために時間を取り戻せるようにします。toilの削減は生産性と信頼性の両方の勝利です。自動化されたプロセスは人間によるものよりも一貫しているからです。

非難のないカルチャー

SREは技術的なプラクティスを、失敗に対する非難のないアプローチと組み合わせます。インシデントは責任を割り当てるためではなく、システムを改善する機会として扱われます。postmortemは失敗を許した条件に焦点を当て、これが正直な報告と持続的な修正を促します。

SREとDevOpsの関係

DevOpsは開発と運用の協働に関する広範なカルチャー運動です。SREは、SLOやerror budgetといった具体的なプラクティスを備えた、それらの考え方を実装する一つの具体的で規範的な方法です。SREはDevOpsの原則の特定の実装だと考えることができます。

重要なポイント

SREはソフトウェアエンジニアリングの規律を運用に適用します。
信頼性は、願望ではなく、測定可能でエンジニアリングされた目標として扱われます。
SLO、error budget、toilの上限、非難のないpostmortemがその代表的なプラクティスです。