令和7年度 春期 ITサービスマネージャ試験 午後I 問2 SREとエラーバジェットの運用

問2 高可用性システムの信頼性向上に関する次の記述を読んで，設問に答えよ。

U社は，一般のインターネット利用者に動画配信サービス（以下，Tサービスという）を24時間365日提供している。Tサービスは，W社のパブリッククラウドサービスを使ったTシステムによって実現されている。稼働環境と試験環境が存在し，稼働環境では高い可用性が求められている。Tサービスは，現在T1からT5の五つのマイクロサービス（以下，T1～T5サービスという）で構成されている。

〔Tサービスの開発と運用における課題〕

U社情報システム部は，開発課と運用課で構成され，開発課は開発課長の下でTサービスの開発を，運用課は運用課長の下でTサービスの運用を担当している。情報システム部では，スクラムによるアジャイル開発を採用し，開発課と運用課が連携してリリースサイクルを短縮することを目的にDevOpsを推進してきた。スクラム開発によってリリース頻度が高まる一方で，運用課の受入準備が追い付かないといった事象が度々発生するようになった。また，停止時間は僅かではあるがサービス停止の事象も何回か発生しており，システムの信頼性が確保された安定した運用が求められている。

そこで，情報システム部のX部長は，SRE (Site Reliability Engineering) の考え方を取り入れ，開発から運用までのライフサイクルに関わり，稼働するTサービスの信頼性に責任をもつ組織を作る必要があると考えた。X部長は，U社の経営層から了承を得て，暫定的なSREチーム（以下，Sチームという）を作り，3か月後に正式なサービス開始を予定しているTサービスの一つのマイクロサービス（以下，T6サービスという）を対象として，検証を行うことにした。検証期間の間，情報システム部は，開発課，運用課及びSチームの三つの組織構成とし，SチームはX部長が直轄する。

T6サービスは，今後も反復アプローチに基づいた開発が継続する状況にあり，開発課は機能追加の開発に専念する必要がある。X部長は，チームの編成に当たって，開発課長及び運用課長と調整を行い，開発課と運用課からア開発経験と運用経験をともに有する要員をSチームに参画させることにし，T6サービスを含むTサービスに関する役割分担を表1に整理した。

〔Sチームの目標設定〕

サービスの信頼性には，スループットや可用性などが該当し，サービスの信頼性を示す指標には，SLI（Service Level Indicator：サービスレベル指標）とSLO（Service Level Objective：サービスレベル目標）がある。SLIは，信頼性の目標が守られているかどうかを評価するために使うサービスレベルの計測値のことである。SLOは，SLIで計測されるサービスレベルの目標値のことである。

Sチームは，T6サービスにおけるSLIとSLOについて検討を行った。その結果を表2に示す。ここで，稼働率は算出式に基づいて毎日算出することにし，対象期間は対象日を含む過去30日間とする。

また，Sチームは，エラーバジェット（以下，EBという）の運用を採用することにした。EBとは，サービスの信頼性が一定程度損なわれても許容できる時間を示す指標のことであり，定期リリースや緊急リリースの展開に伴って発生する稼働停止の時間及びエラー対処に要した時間をEBから消費させていく運用を行う。T6サービスのEBはSLOが未達状態とならないサービス停止時間の最大値とする。具体的には，SLOが表2の場合，対象日を含む過去30日間の対象期間の中で15分をEBの最大値とし，その範囲でのサービス停止を許容した上でサービスを運用する。

EBの消費がひっ迫した場合は，開発課と協議を行い，更なる信頼性低下のリスクを抑えるためにリリース作業と機能追加開発作業を凍結し，サービスの安定性を重視した信頼性回復のための作業を優先して行うことにする。EBの消費ひっ迫をEBが3分以下（EBを12分消費）となった場合と定め，信頼性回復作業はSチームと開発課が主体的に取り組む。Sチームで検討したEBの運用ルール案を表3に示す。

Sチームは，X部長に運用ルール案を報告したところ，イ項番2について（イ）リリース作業の凍結については，例外規定を設けることを検討するように指示を受けた。Sチームは，検討した結果をX部長に提案し，X部長は提案内容を含めて運用ルール案を承認し，試行運用を開始するようにSチームに指示した。

〔試行運用の開始〕

Sチームは，4月1日からEBの試行運用を開始した。T6サービスは，2月1日からサービス開始に向けた準備を進めて稼働環境で稼働しており，3月はリリース作業などによるサービス停止の停止時間は発生していない。したがって，4月1日開始時点でのSLIの稼働率は，対象日を含む過去30日間のサービス稼働予定時間である43,200分から算出された100%となり，EBは15分である。試行運用開始後の結果を表4に示す。ここで，EBは，次の計算式に基づいて計算される。

当日のEB＝前日のEB－当日のEBの消費＋当日のEBの回復

当日のEBの消費とは“当日発生したサービス停止時間のこと”であり，当日のEBの回復とは“過去に発生したサービス停止事象が対象日（当日）を含む過去30日間から外れたので，EBに追加する当該事象のサービス停止時間のこと”である。例えば，4月2日のEBの計算では，前日のEBが15分，当日のEBの消費が1分，当日のEBの回復が0分であり、計算結果は14分となる。

また、Sチームは、ウ4月26日に信頼性回復のための改善活動を開始した。改善活動を開始するに当たって、Sチームは、開発課と、EBの推移を示して議論を行い、T6サービスの信頼性についての認識を合わせた。改善活動の候補を議論したところ、稼働環境へのリリース方法について、エT6サービスを停止することなくリリース作業が可能となる方式が実現できないかどうかの検討に取り組むことにした。

〔試行運用の振り返り〕

X部長は，試行運用の振り返りと今後の本格運用に向けた改善点などについて，Sチームにヒアリングを行ったところ，次の意見が出された。

• 開発課と b の実施判断について，EBを使って効果的な議論を行い，T6サービスの信頼性低下のリスクを抑えることができた。
• 4月11日は，“数名の利用者が，問合せリクエストへの応答がないので再度リクエスト入力したという報告”を受けた対策をしている。調査したところ，プログラムでエラーが発生していて，リクエストが失敗となっていた。稼働時間を基に算出する稼働率のSLIだけでは，十分でないように感じる。そこで，サービス利用者からの客観的な評価を反映したサービスの信頼性指標として“T6サービスが受け付けた総リクエスト数に対する c の割合”をSLIに追加した方がよい。

X部長は，今後の本格運用に向けて，改善計画を策定することにした。