SREの現場はどうなっているのか――従来型の運用との決定的な違いとは：特集：情シスに求められる「SRE」という新たな役割（3）（2/2 ページ）

Site Reliability Engineering（以下、SRE）の現場はどうなっているのか。SREの日常的な仕事とはどのようなものなのか。開発エンジニアと運用担当エンジニアは、実際どのように役割分担し、協力し合っているのか。「SRE本」の監訳者などが語った。

[三木泉，＠IT]

　では、定めたSLOが達成できなかった場合、どのようなアクションを取るべきか。

　まず、障害の多くは、新たな変更に付随して発生することが多いため、新規リリースをフリーズすることが考えられる。また、信頼性に関する改善の優先順位を上げ、一定期間（例えば1カ月間）、改善にリソースを集中することもできる。あるいは、目標そのものを見直す必要があるかもしれない。

SLOを「エラーバジェット」で管理する

GoogleのSRE Advocate、ポール・ニューソン氏

　「SLOを実際に管理し、サービス提供に生かすには、『エラーバジェット』というコンセプトが役立つ」と、GoogleのSRE Advocateであるポール・ニューソン（Paul Newson）氏は説明した。

　「エラーバジェット」は「エラーの予算」。ある一定の期間に、SLOに照らしてどれくらいのエラー時間が許されるかを示す言葉だ。1からSLOを引くと、エラーバジェットになる。

　例えばSLOとして可用性を99％に定めれば、エラーバジェットは1％。SLOを単純に「ある期間内のエラー時間」と定義しているのであれば、30日間でSLOを定めている場合エラーバジェットは43.2分、365日間で定めている場合は8.76時間となる。

　「『エラーバジェット』を考えた方がいい理由は、顧客や自社のCEOにとって、理解しやすい数字だからだ」とニューソン氏は話した。

　SLO上、あとどれくらいエラー時間が発生しても許されるのかが把握できていれば、行動の判断基準として使える。

　例えば「この新機能をリリースすべきか」「変更をどれくらいの頻度で実施するべきか」「検証をもう少し行うべきか」「機能と信頼性のどちらにどのように力を入れて開発すべきか」などだ。

　「コストおよび開発スピードと、信頼性はトレードオフの関係」だが、エラーバジェットを把握していれば、特定の行動によって生じるエラーの確率を勘案し、「今それをやるべきかどうか」「全体的にスピードを現在よりも高められる余地があるか」などを、共通の情報に基づき、関係者間で合意しやすい。

「トイルの撲滅」とはどういうことか

　SREでは、「トイルの撲滅」も、日常的なテーマの1つという。

　英語で「toil（トイル）」といえば、一般的には「苦労」を意味する言葉だ。SREの文脈では、「プロダクションサービスを動作させるのに必要な作業で、自動化できるにもかかわらず、手作業で行われている、それ自体に価値のないもの」を示すと、澤田氏は話した。トイルはサービスの成長とともに作業量を増加させ、生産性を引き下げる要因になる。

　トイルには例えば、リリース作業、障害対応、バックアップ、仮想マシンの設定／追加／削除、データベースのクリーンアップなどが該当する。

　トイルが多すぎると、「ポジションの魅力が下がり、エンジニアの採用が難しくなる」「生産性が低下する」「手作業によるミスが発生する」といった問題が起こる。従って、トイルを減らす努力を積極的にすべきだという。とはいえ、トイルをゼロにするのは難しく。また、ゼロにすることが必ずしも最善とはいえない。グーグルでは50％を目標としているという。

特集：情シスに求められる「SRE」という新たな役割

IoT、X Techトレンドの本格化に伴い、ニーズの変化に合わせて「いかにスピーディにITサービスを企画・開発するか」が重視されている。だがビジネス差別化の上で重要なのは「作ること」だけではない。リリース後の運用が大きなカギを握る。本特集では米グーグルが提唱する「SRE――Site Reliability Engineer（サイト信頼性エンジニア）」という概念を深堀りし、「運用管理のビジネス価値」を再定義する。

特集：情シスに求められる「SRE」という新たな役割