SREとは何か（後編）

システム運用の分野は従来の人的な作業が継続されており、自動化や効率化により成果をあげている企業が少ない。「SREとは何か（前編）」ではGoogle社のSRE（Site Reliability Engineering）を取り上げ、運用をソフトウェア・エンジニアリングとして捉えるこの新しい試みの価値を解説した。後編では、SREの代表的なプラクティスと、IT部門がどのようなアプローチでSREに取り組むべきかを述べる。

SREの基本原則

国内においてアジャイル開発／DevOpsに取り組む企業が増えているが、これまでシステムやインフラ運用に関してはさまざまな標準やフレームワークが存在するも、その多くは人的作業によるものであり、エンジニアリングとして捉える企業は希有であった。Google社が最初に提唱したSREは「The Site Reliability Workbook」としてWebサイトで無償公開されており、基本原則（図1）と代表的なプラクティス、そして実行のためのプロセスが記載されている。

図1．SREの基本原則

SREの基本原則の第1には、サービスレベル目標（Service Level Objectives：SLO）をいくつか定め、それらをほぼ毎月達成していること、および運用チームが開発部門や事業部門の一部ではない場合は、これらの部門のメンバーと共同で実施することが必要である、としている。

第2には、「ポストモーテム」を行うカルチャーがあり、ポストモーテムを障害やインシデントを発生させた担当者や部門を非難することに用いないことが必要、としている。「ポストモーテム」とは事後に振り返りを行う「事後検証」を指す。組織や個人が過去の失敗から学ぶ文化を創ることが非常に重要である、とGoogle社は述べている。

第3には、本番システムやそれに用いられているインフラ環境において発生した各種インシデントを管理するプロセスが確立していることが必要であり、かつ、これらのプロセスは全社的な取り組みであることが望ましい、としている。