ITサービスマネージャ 2025年 午後1 問02
高可用性システムの信頼性向上に関する次の記述を読んで、設問に答えよ。
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部長は、今後の本格運用に向けて、改善計画を策定することにした。
設問1：
問題文を見る〔Tサービスの開発と運用における課題〕の本文中の下線（ア）について、運用だけでなく開発の業務経験が必要な理由を、30字以内で答えよ。
模範解答
・アプリケーションプログラムの不具合の改修を実施するから
・表1項番8の業務内容を行う必要があるから
解説
解答の導き方
この設問では、Sチームに運用経験だけでなく開発経験も必要な理由を考えます。
表1を見ると、T6サービスでは、監視や障害対応、リリース、インフラ運用などに加えて、「稼働しているアプリケーションプログラムの不具合の改修」もSチームの担当です。不具合の改修は、アプリケーションプログラムの内容を理解し、修正する開発の知識・経験が必要な業務です。
一方、「アプリケーションプログラムの機能追加開発」は開発課の担当です。したがって、Sチームに必要な開発経験は、機能追加開発を担うためではなく、稼働中のプログラムの不具合を改修するためだと分かります。
以上から、表1の項番8の業務をSチームが行う点を理由に挙げれば、運用だけでなく開発の業務経験が必要なことを説明できます。
誤りやすいポイント
- Sチームが機能追加開発を担当するから、と考えないようにします。表1では、機能追加開発は開発課の担当です。
- 監視や障害対応だけを理由にしないようにします。これらは運用経験が必要な業務ですが、設問は開発経験が必要な理由を尋ねています。
- 「不具合の改修」を、単なる障害の検知や利用者への連絡と混同しないようにします。プログラムを修正するため、開発経験が必要です。
FAQ
Q: SチームはT6サービスの機能追加も担当しますか？
A: いいえ。表1では、機能追加開発は開発課の担当です。Sチームが担うのは、稼働中のプログラムの不具合改修などです。
A: いいえ。表1では、機能追加開発は開発課の担当です。Sチームが担うのは、稼働中のプログラムの不具合改修などです。
Q: 障害対応の経験だけでは不十分なのはなぜですか？
A: 障害の原因がプログラムの不具合である場合、原因を調べるだけでなく、プログラムを改修する必要があるためです。
A: 障害の原因がプログラムの不具合である場合、原因を調べるだけでなく、プログラムを改修する必要があるためです。
Q: 開発経験は、どの業務に直接結び付いていますか？
A: 稼働しているアプリケーションプログラムの不具合の改修です。
A: 稼働しているアプリケーションプログラムの不具合の改修です。
関連キーワード: SRE、DevOps、障害対応、アプリケーション保守、リリース管理
設問2：
問題文を見る〔Sチームの目標設定〕の本文中の下線（イ）について、例外規定を設ける理由を、30字以内で答えよ。
模範解答
故障対応などの緊急リリースを行う必要があるから
解説
解答の導き方
設問は、EBがひっ迫したときのリリース凍結に、なぜ例外を設けるのかを問うています。
- 表3のルールでは、「EBが3分以下となった場合」に、翌日から稼働環境へのリリース作業を凍結し、信頼性回復のための改善活動を始めます。EBの残りが少ない段階でリリースを続けると、停止時間が増えて信頼性がさらに低下するおそれがあるためです。
- 一方、本文では定期リリースだけでなく「緊急リリース」も扱われており、不具合の改修など、サービスの故障に対応するために行う場合があります。
- このような状況でもリリースを一律に禁止すると、故障への対応やサービスの復旧に必要な修正まで行えなくなります。
したがって、リリース凍結で信頼性低下のリスクを抑えつつ、故障対応などで緊急リリースが必要な場合には実施できるようにするため、例外規定を設けます。
誤りやすいポイント
- リリースを凍結する目的だけに注目し、「どのような場合もリリースを禁止する」と考えないようにします。
- 定期的な機能追加のリリースと、故障や不具合への対応として行う緊急リリースを区別します。
- 例外規定の理由は、リリースを続けたいからではなく、信頼性回復に必要な緊急対応を妨げないためです。
FAQ
Q: EBが3分以下になったら、リリース作業をすべて止めるのですか？
A: 原則として凍結しますが、故障対応などで緊急リリースが必要な場合まで一律に止めることがないよう、例外を設けます。
A: 原則として凍結しますが、故障対応などで緊急リリースが必要な場合まで一律に止めることがないよう、例外を設けます。
Q: なぜ通常のリリースを凍結するのですか？
A: 残りのEBが少ないときにリリースによる停止が発生すると、SLO未達につながるおそれがあるためです。
A: 残りのEBが少ないときにリリースによる停止が発生すると、SLO未達につながるおそれがあるためです。
関連キーワード: エラーバジェット、SLO、緊急リリース、リリース凍結、サービス信頼性
設問3：〔試行運用の開始〕について答えよ。
設問3（1）
問題文を見る表4中のaに入れる適切な数値を答えよ。
模範解答
3
解説
解答の導き方
-
求めるのは、５月２日のEBです。EBは「前日のEB－当日のEBの消費＋当日のEBの回復」で計算します。
-
表4では、５月１日のEBは2分、５月２日の停止時間は0分です。したがって、５月２日に新たにEBを消費することはありません。
-
一方、EBは対象日を含む過去30日間で管理されます。５月２日の対象期間は４月３日から５月２日までなので、４月２日に発生した1分の停止時間は対象期間から外れます。過去の停止時間が対象期間から外れた場合、その時間をEBに回復として加えます。
-
よって、５月２日のEBは、前日の2分から当日の消費0分を差し引き、４月２日の停止時間1分を回復分として加えた値になります。
誤りやすいポイント
- ５月２日の停止時間が0分だからといって、EBが前日と同じとは限りません。過去の停止時間が対象期間から外れると、EBは回復します。
- ４月２日の停止時間は５月２日の対象期間に含まれると誤認しないようにします。対象期間は対象日を含む過去30日間です。
- EBの回復分は、当日に新しく発生した停止時間ではなく、過去の停止時間が対象期間から外れたことによる加算です。
FAQ
Q: ５月２日はサービス停止がないのに、EBが増えるのはなぜですか？
A: ４月２日の停止時間が過去30日間の対象期間から外れ、その分がEBに回復として加わるためです。
A: ４月２日の停止時間が過去30日間の対象期間から外れ、その分がEBに回復として加わるためです。
Q: 当日のEBの消費と回復は、どちらも確認する必要がありますか？
A: はい。当日の停止時間による消費だけでなく、過去の停止事象が対象期間から外れたことによる回復も反映して計算します。
A: はい。当日の停止時間による消費だけでなく、過去の停止事象が対象期間から外れたことによる回復も反映して計算します。
関連キーワード: エラーバジェット、SLI、SLO、稼働率、ローリングウィンドウ
設問3（2）
問題文を見る本文中の下線（ウ）について、4月26日に信頼性回復のための改善活動を開始した理由を、25字以内で答えよ。
模範解答
4月25日にEBが3分を下回ったから
解説
解答の導き方
-
表3の項番2では、EBが3分以下になった場合、翌日から稼働環境へのリリース作業を凍結し、信頼性回復のための改善活動を開始すると定めています。したがって、EBが基準に達した日と、改善活動を開始する日を区別して考えます。
-
表4では、4月25日のEBは2分です。これは基準の3分を下回っているため、4月25日に改善活動を開始する条件を満たしています。
-
ルールでは、条件を満たした日の翌日から改善活動を開始します。そのため、4月25日にEBが3分を下回ったことが、4月26日に改善活動を開始した理由です。
誤りやすいポイント
- 表3の条件は「EBが3分以下」であり、3分ちょうどの場合も対象です。今回はEBが2分なので、条件を満たします。
- EBが基準に達した日と、改善活動を開始する日を混同しないようにします。項番2では「翌日から」とされています。
- 4月25日の停止時間の内訳だけで判断せず、その日の停止時間を反映した後のEB（2分）を確認します。
FAQ
Q: EBが3分ちょうどになった場合も、改善活動を始めますか？
A: はい。ルールは「3分以下」としているため、3分ちょうども対象です。
A: はい。ルールは「3分以下」としているため、3分ちょうども対象です。
Q: なぜ4月25日ではなく、4月26日に開始するのですか？
A: EBの条件を満たした日の「翌日から」開始するルールだからです。
A: EBの条件を満たした日の「翌日から」開始するルールだからです。
関連キーワード: エラーバジェット、SLO、可用性、サービス停止時間、リリース凍結
設問3（3）
問題文を見る本文中の下線（エ）について、サービスを停止することなくリリース作業が可能となる方式に変更することで得られる利点を、SLOの観点から30字以内で答えよ。
模範解答
・リリース作業でのEB消費を防止できるから
・稼働率が低下することを防ぐことができるから
・障害復旧時間を短縮することができるから
解説
解答の導き方
この設問では、リリース方式を「T6サービスを停止することなく」実施できるようにした場合、SLOにどのような利点があるかを考えます。
表2では、SLIとして稼働率を用い、SLOを99.965%としています。稼働率は、サービス稼働予定時間からサービス停止時間を差し引いて算出します。つまり、サービス停止時間が増えるほど稼働率は低下し、SLOを達成しにくくなります。
また、本文では、T6サービスのEBを、SLOが未達状態とならない範囲で許容できるサービス停止時間として定めています。表4でも、リリースに伴ってT6サービスを停止した日は、停止時間に応じてEBが消費されています。さらに、注記には「定期リリースと緊急リリースは区別せず、サービス停止した場合は、EBを消費する。」とあります。
したがって、サービスを停止しない方式にすれば、リリース作業に伴う停止時間を発生させずに済みます。その結果、リリースによるEBの消費を避け、稼働率が低下する要因を減らして、SLOの達成を維持しやすくできます。
誤りやすいポイント
- リリース作業の効率化だけを利点として述べると、設問が求めるSLOとの関係が明確になりません。停止時間の削減が、EBや稼働率にどう影響するかまで説明します。
- 「EBを消費しない」とだけ述べるのではなく、EBがSLOに対して許容される停止時間であることを踏まえ、稼働率の低下を防ぐ点につなげます。
- 停止しないリリース方式にしても、障害など別の原因によるサービス停止までなくなるわけではありません。防げるのは、リリースに伴う停止時間です。
FAQ
Q: EBが減ることは、なぜSLOに関係するのですか？
A: EBは、SLOが未達にならない範囲で許容されるサービス停止時間です。EBの消費が大きいほど、SLOの達成に使える余裕が少なくなります。
A: EBは、SLOが未達にならない範囲で許容されるサービス停止時間です。EBの消費が大きいほど、SLOの達成に使える余裕が少なくなります。
Q: 停止しないリリース方式にすれば、SLOは必ず達成できますか？
A: 必ず達成できるわけではありません。リリース以外の障害などによる停止やエラーも、SLOに影響します。この方式で抑えられるのは、リリースに伴う停止の影響です。
A: 必ず達成できるわけではありません。リリース以外の障害などによる停止やエラーも、SLOに影響します。この方式で抑えられるのは、リリースに伴う停止の影響です。
Q: 緊急リリースによる停止もEBを消費しますか？
A: 消費します。表4の注記では、定期リリースと緊急リリースを区別せず、サービス停止が発生した場合はEBを消費するとされています。
A: 消費します。表4の注記では、定期リリースと緊急リリースを区別せず、サービス停止が発生した場合はEBを消費するとされています。
関連キーワード: SLO、稼働率、エラーバジェット、サービス停止時間
設問4：〔試行運用の振り返り〕について答えよ。
設問4（1）
問題文を見る本文中のbに入れる適切な字句を、15字以内で答えよ。
模範解答
稼働環境へのリリース作業
解説
解答の導き方
空欄には、開発課と一緒に「実施するかどうか」を判断する作業が入ります。判断の基準となるEBは、サービス停止時間によって消費され、残りが少なくなるほど、さらに停止を伴う作業を行うリスクが高まります。
表3の項番2では、EBが3分以下になった場合、「翌日から稼働環境へのリリース作業を凍結」すると定めています。つまり、EBの残量を見ながら実施するかどうかを話し合う対象は、稼働環境へのリリース作業です。
実際に表4では、４月25日にEBが2分となり、EBが3分以下という条件に該当しています。そのため、翌日の4月26日に信頼性回復のための改善活動が始まっています。この流れからも、EBを使って開発課と実施判断について議論する作業として、「稼働環境へのリリース作業」が当てはまります。
誤りやすいポイント
- 「機能追加開発作業」と混同しないようにします。ここで問われているのは、表3の項番2でEBの条件に応じて凍結すると定められた作業です。
- 「定期リリース作業」だけに限定しないようにします。表4の注記3では、定期リリースと緊急リリースを区別せず、サービス停止した場合はEBを消費するとされています。
- 試験環境へのリリースではなく、表3に明記された稼働環境へのリリース作業を指します。
FAQ
Q: なぜEBが少なくなると、リリース作業の実施判断が必要なのですか？
A: リリースに伴うサービス停止はEBを消費します。残りのEBが少ないときに停止を伴う作業を行うと、信頼性の低下につながるおそれがあるためです。
A: リリースに伴うサービス停止はEBを消費します。残りのEBが少ないときに停止を伴う作業を行うと、信頼性の低下につながるおそれがあるためです。
Q: EBが3分以下になったら、必ずリリース作業を中止するのですか？
A: 表3では、EBが3分以下の場合に凍結するルールが示されています。一方、問題文では凍結に例外規定を設ける検討も指示されているため、EBを踏まえた実施判断が必要になります。
A: 表3では、EBが3分以下の場合に凍結するルールが示されています。一方、問題文では凍結に例外規定を設ける検討も指示されているため、EBを踏まえた実施判断が必要になります。
関連キーワード: エラーバジェット、SLO、SLI、リリース凍結、サービス信頼性
設問4（2）
問題文を見る本文中のcに入れる適切な字句を、リクエスト数に着目して、15字以内で答えよ。
模範解答
成功したリクエスト数
解説
解答の導き方
問われているのは、T6サービスが受け付けた総リクエスト数を分母としたとき、何件を分子にすれば利用者から見た信頼性を評価できるかです。
本文では、4月11日に利用者から「問合せリクエストへの応答がない」という報告があり、調査の結果、プログラムのエラーによってリクエストが失敗していたと説明されています。つまり、サービス自体が稼働していても、個々のリクエストが正常に処理されない場合があります。
稼働率はサービスが稼働していた時間を基に算出するため、このようなリクエスト単位の失敗を十分に表せません。そこで、受け付けた総リクエスト数のうち、正常に処理できたものの数を数え、その割合をSLIに加えます。したがって、空欄には「成功したリクエスト数」が入ります。
誤りやすいポイント
- 稼働率とリクエストの成功率を同じものとして考えないようにします。稼働率は時間を基にした指標であり、リクエストの成功率は処理結果を基にした指標です。
- 分母は「T6サービスが受け付けた総リクエスト数」です。分子もリクエスト数に着目し、成功した件数を入れます。
- 応答がなかったという利用者の報告だけでなく、調査でプログラムエラーによるリクエストの失敗が確認された点が、追加するSLIを判断する根拠です。
FAQ
Q: 稼働率が高ければ、リクエストも正常に処理できているといえますか？
A: いいえ。サービスが稼働中でも、プログラムのエラーなどによって個々のリクエストが失敗することがあります。
A: いいえ。サービスが稼働中でも、プログラムのエラーなどによって個々のリクエストが失敗することがあります。
Q: なぜ総リクエスト数を分母にするのですか？
A: 受け付けたリクエスト全体のうち、どの程度を成功させたかという割合を求めるためです。
A: 受け付けたリクエスト全体のうち、どの程度を成功させたかという割合を求めるためです。
Q: このSLIを追加すると、どのような信頼性を評価できますか？
A: サービスの稼働時間だけでなく、利用者のリクエストが正常に処理される割合も評価できます。
A: サービスの稼働時間だけでなく、利用者のリクエストが正常に処理される割合も評価できます。
関連キーワード: SLI、SLO、稼働率、リクエスト成功率、可用性
