MTTRとは？計算式・MTBFとの違いと稼働率への影響、短縮策を実装目線で解説【2026年版】

MTTRとは、障害が起きたシステムを直すのに平均どれだけ時間がかかったかを表す指標で、Mean Time To Repair（平均修復時間）の略です。この記事では、MTTRの計算式と単位の決め方、MTBF・MTTF・MTTDとの違い、稼働率（可用性）へ効いてくる計算関係、SQLとPromQLでの集計方法、ヘルスチェックによる自動復旧の設定例、そしてDORAが2026年時点で使っている呼び名までを、公式ドキュメントの実物とコードで整理します。

まとめ｜MTTRで測る復旧速度と稼働率・SRE指標での位置づけ

MTTRは「壊れにくさ」ではなく「直りの速さ」を測る指標です。故障のしにくさを示すMTBFと対にして使い、稼働率＝MTBF÷（MTBF＋MTTR）で可用性に効いてきます。設計判断としては、まず「どの時刻を開始・終了に取るか」を先に決めることが精度を左右します。

実務での結論は4点です。第一に、MTTRは検知（MTTD）・対応・復旧の合算であり、内訳を分けて計測しないと改善点が見えません。第二に、平均値は長時間の1件に引きずられるため、中央値やパーセンタイルの併記が要点になります。第三に、MTTRの短縮は自動復旧・ランブック・冗長化で狙う一方、数値だけを追うと恒久対策が後回しになりがちです。第四に、指標名そのものが移り変わっており、DORAの中核指標では「MTTR」という語は使われていません。稼働率設計の全体像は可用性とは？稼働率の計算と高可用性の設計と合わせて読むと、MTTRの位置づけが掴めます。

MTTRの定義と平均修復時間としての計算式、4種類のMTTRの区別

MTTRという略語は文脈で指す範囲が変わります。まず基本の計算式と単位を押さえ、次に「R」が何を指すかで分かれる4系統を区別しましょう。

MTTRの計算式（総修理時間÷修理回数）と測定に使う時間の単位

MTTRの基本式は「対象期間の総修理時間 ÷ その期間の修理（対応）回数」です。例えば1か月で障害が5回起き、復旧に要した時間の合計が10時間なら、MTTRは10 ÷ 5 ＝ 2時間になります。単位は分・時間のいずれでもよく、SLA監視では分単位、設備保全では時間単位が多く使われています。ここで注意したいのは「総修理時間」に何を含めるかです。検知の遅れや連絡待ちの時間を入れるかどうかを社内で定義しておかないと、同じ障害でもMTTRが数倍ずれてしまいます。

公式ドキュメント側の定義も、区間の取り方を明示しています。MicrosoftはAzure Well-Architected Framework の信頼性ターゲットで、平均復旧時間（MTTR）を「故障が検出された後にコンポーネントを復元するのにかかった時間」と定義しました。この書き方では検知までの時間はMTTRに含みません。自社の定義を作るときは、この「検出後から」を採るのか、「発生から」を採るのかを最初に決めておくと、後からダッシュボードを作り直さずに済みます。

Repair・Recover・Respond・ResolveでずれるMTTRの意味

MTTRは1つの言葉に複数の定義が同居しています。実装で混乱しやすいので、測る区間を明示して使い分けましょう。

• Mean Time To Repair（平均修復時間）：修理作業そのものにかかった時間。設備・ハードの保全で中心に使う。
• Mean Time To Recover（平均復旧時間）：障害発生からサービスが正常に戻るまで。SRE・IT運用の主指標。
• Mean Time To Respond（平均応答時間）：検知から対応着手までの反応の速さ。オンコール体制の評価に使う。
• Mean Time To Resolve（平均解決時間）：復旧後の恒久対策・再発防止まで含めた全体。

同じ「MTTR」でもRepairとResolveでは対象時間が数倍違います。ダッシュボードやSLOで扱うときは、どの定義かを列名やメトリクス名に書き込み、チーム間の解釈ずれを防ぎましょう。

MTTD・MTBF・MTTFとMTTRの位置関係（故障ライフサイクルでの役割）

MTTRは故障ライフサイクルの一部分です。障害が起きてから直るまでを、検知・対応・復旧の順に各指標が受け持ちます。MTTD（Mean Time To Detect＝平均検知時間）は「起きてから気づくまで」、MTTRは「気づいてから直るまで」、MTBF（平均故障間隔）は「直ってから次に壊れるまで」を担当します。MTTF（平均故障時間）は修理せず使い切る部品の寿命を指し、繰り返し修理する対象のMTBFとは別物です。この4つを取り違えると、改善すべき区間を誤って投資先を外してしまいます。

MTBF・MTTFとMTTRの違いと、稼働率（可用性）を決める計算関係

MTTRとMTBFは「直りの速さ」と「壊れにくさ」で役割が逆です。両者を組み合わせると稼働率が算出でき、99.9%系の可用性目標に直結します。

MTBF（平均故障間隔）とMTTRの役割分担と、混同しやすいMTTF

MTBF（Mean Time Between Failures）は、ある故障から次の故障までの平均稼働時間で、値が大きいほど壊れにくい設計です。MTTRは値が小さいほど早く直ります。設計改善では「MTBFを伸ばす（壊れにくくする）」と「MTTRを縮める（早く直す）」の二正面があり、コストの掛け先が違います。MTTF（Mean Time To Failure）は交換前提の部品の平均寿命で、修理して使い続けるサーバーやディスクにはMTBFを用いるのが通例です。この区別が曖昧だと、保守契約や部品調達の見積りがずれてしまいます。

MTBFの目標値を外部サービスに対して置くときは、前提を確認しておきましょう。前掲のAzure Well-Architected Frameworkは、PaaSやSaaSでは利用者に気づかれないまま障害と復旧が完了しうるため、MTBFの目標は「制御下にあるコンポーネントのみを対象とする」よう注記しています。自社が触れないマネージド領域までMTBFで縛ると、測れない数字を契約に書くことになってしまいます。

稼働率＝MTBF÷（MTBF＋MTTR）の計算と、年間停止許容時間への影響

稼働率（可用性）は、稼働率 ＝ MTBF ÷（MTBF ＋ MTTR）× 100 で求めます。MTBFが大きくMTTRが小さいほど100%に近づく関係です。例えばMTBFが1,000時間、MTTRが1時間なら稼働率は約99.9%になります。この式はAWS Well-Architected Framework 信頼性の柱の Availabilityでも、可用性が公表されていない依存コンポーネントを見積もる方法として同じ形で示され、MTBF 150日・MTTR 1時間なら約99.97%という計算例も添えられました。可用性目標を年間の停止許容時間に換算すると、目標の厳しさが実感できます。

この年間ダウンタイムの対応表は、前掲のAWS 信頼性の柱に載っている値（99%で3 days 15 hours、99.99%で52 minutes、99.999%で5 minutes）と同じ並びです。four nines以上になると、1件の障害で許される年間停止は1時間を切る計算になります。ここではMTTRを人手で縮めるより、冗長化とは？二重化との違いと企業の設計判断で解説する自動フェイルオーバーへ設計を切り替える判断が要ります。切り替えられれば、稼働率は人の反応速度に左右されません。壊れても止めない側の設計思想はフォールトトレラントとは？耐障害性の仕組みで扱っており、MTTRを縮める打ち手と対で読むと投資先を選びやすくなります。

MTTRを稼働率目標（SLA/SLO）に翻訳するときの注意点

稼働率をSLAやSLOとして約束する場合、MTTRは「守れる復旧速度」の裏付けになります。稼働率99.9%を掲げても、実測MTTRが5時間なら年間許容8時間45分をわずか2件で使い切ってしまいます。目標稼働率から逆算して許容MTTRを決め、その値を体制で担保できるかを検証しましょう。稼働率とSLA/SLOの決め方はSLAとは？SLO・SLIとの違いと稼働率の決め方で扱っており、MTTRはその測定側の指標として噛み合います。

DORAが指標名をMTTRから変えた経緯と2026年時点の呼び方

MTTRという呼び名は、標準側では置き換えが進みました。DevOpsの調査プログラムであるDORAは、長く「Four Keys」と呼ばれた4指標を見直し、現在は5つのソフトウェアデリバリー指標を公開しています。社内で指標名を揃えるときは、この変更を踏まえておくと外部の資料と噛み合います。

Four KeysからFive Metricsへ変わったDORAの指標一覧

DORAのガイド（DORA metrics）は、中核となる指標を5つとして「Change lead time」「Deployment frequency」「Failed deployment recovery time」「Change fail rate」「Deployment rework rate」を挙げています。同ガイドは指標が技術環境とともに変わってきたと述べ、変更の一例として「the move from MTTR to Failed Deployment Recovery Time」を明示しました。つまり、かつて4指標に含まれていた復旧時間の指標は、MTTRという名前では扱われていません。

ただし、これは「MTTRという指標が消えた」という話ではない点に注意しましょう。DORAが測っているのはデプロイに起因した障害からの回復時間で、対象が変更起因に絞られます。運用現場のSLA・保守契約・設備保全では、MTTRの語はいまも現役です。用語を統一するのではなく、どちらの文脈の数字かをラベルで分けるほうが実務では扱いやすくなります。

デプロイ起因の復旧時間と運用障害のMTTRを分けて測るべき理由

2つを混ぜると、改善の打ち手がぶつかります。デプロイ起因の障害はロールバックやフィーチャーフラグで数分に縮められる一方、ハード故障やクラウド側の広域障害は自社のリリース手順を直しても短くなりません。母集団を分けずに平均を取ると、リリース改善の効果が広域障害の1件に埋もれてしまいます。集計時はインシデントに「変更起因かどうか」のフラグを持たせ、DORA向けの回復時間と運用全体のMTTRを別々に出しましょう。指標を分けておくと、リリースプロセスへの投資と冗長化への投資のどちらが効いたかを後から言い分けられます。

MTTRを検知・対応・復旧に分解する計測設計とツール実装のポイント

MTTRを縮めるには、まず正しく測る必要があります。一枚岩の「復旧までの時間」ではなく、区間ごとにタイムスタンプを取ると、遅れの原因が検知にあるのか対応にあるのかが分かります。

検知（MTTD）から対応着手・復旧完了までのタイムスタンプ設計

計測の起点と終点を機械的に定めます。実装では次の順にイベント時刻を記録しましょう。

1. 障害発生時刻：監視のしきい値超過やヘルスチェック失敗を検知した時刻。
2. 検知・通知時刻：アラートが担当者へ届いた時刻（ここまでがMTTD）。
3. 対応着手時刻：オンコール担当が確認・着手した時刻（ここまでがMTTA＝平均応答）。
4. 復旧完了時刻：サービスが正常応答に戻った時刻（発生からここまでがMTTR）。

この4点を取れば、MTTRを「検知の遅れ」「駆けつけの遅れ」「復旧作業そのもの」に分解できます。多くの現場でボトルネックは復旧作業ではなく検知・通知の遅延にあり、まず監視のしきい値と通知経路を見直すと効果が出ます。分解しないまま総時間だけを追っても、どこに手を入れるべきか見えてきません。検知と相関をAIで自動化してこの遅延を縮める考え方はAIOpsとは？IT運用×AIの仕組みと主要機能で整理しています。

インシデント管理ツールでMTTRを自動集計するための実装の勘所

MTTRの集計を手作業の記録に頼ると、多忙な障害対応中に時刻が抜け落ちます。PagerDuty・Opsgenie・New Relic・Datadogなどのインシデント管理／監視基盤は、アラート発報・確認（acknowledge）・解決（resolve）の各イベント時刻を自動で記録し、MTTA・MTTRをレポート化してくれます。実装の勘所は、監視側のアラートとチケット（インシデント）を一意のIDで紐づけ、resolveの押し忘れを運用ルールで防ぐことです。障害対応の体制づくりとの接続について、インシデント管理の全体像は別記事（ITIL準拠のプロセスと実装）で整理しています。

平均値の落とし穴と、中央値・パーセンタイル併用によるMTTRの読み方

MTTRは平均であるため、極端に長い1件が数値を大きく押し上げます。月に10件の障害があり9件は5分で復旧、1件だけ6時間かかった場合、平均MTTRは約41分になりますが、実態の大半は5分です。改善状況を正しく追うには、平均に加えて中央値（p50）や95パーセンタイル（p95）を併記しましょう。Google の SRE Book（Service Level Objectives）も「We generally prefer to work with percentiles rather than the mean (arithmetic average) of a set of values.」と述べ、高次パーセンタイルが最悪値、50パーセンタイルが典型値を示すと整理しています。p95が突出していれば「まれに起きる長時間障害」に焦点を当てるべきで、平均だけを見ていると打ち手を外します。

SQLとPromQLでMTTR・MTTA・p95を集計するクエリの書き方

定義を決めたら、集計を人手のスプレッドシートから外します。ここではインシデント台帳を持っている場合のSQLと、監視側で検知時刻を機械的に固定するPrometheusの設定を、そのまま動かせる形で置きます。

インシデント表からMTTA・MTTR・p95を出すSQLの実装例

インシデント1件を1行で持ち、検知・着手・復旧の3時刻を列にしておけば、集計はSQLだけで完結します。PostgreSQLでの例が次のクエリで、月ごとに件数・MTTA・MTTR・p50・p95を並べて出します。

-- インシデント台帳から MTTA・MTTR と分位点を月次で集計する（PostgreSQL）
SELECT
  date_trunc('month', detected_at) AS month,
  count(*) AS incidents,
  avg(acknowledged_at - detected_at) AS mtta,
  avg(resolved_at - detected_at) AS mttr,
  percentile_cont(0.5) WITHIN GROUP (ORDER BY resolved_at - detected_at) AS p50,
  percentile_cont(0.95) WITHIN GROUP (ORDER BY resolved_at - detected_at) AS p95,
  count(*) FILTER (WHERE caused_by_deploy) AS deploy_caused
FROM incidents
WHERE resolved_at IS NOT NULL
  AND detected_at >= now() - interval '12 months'
GROUP BY 1
ORDER BY 1;

最終行の deploy_caused が、前章で触れた変更起因の切り分けにあたる列です。同じ表からDORA向けの回復時間だけを抜くときは、WHERE 句に caused_by_deploy を足すだけで済みます。avg と percentile_cont を同時に出しておくと、平均が1件に引きずられた月をその場で見抜けます。

Prometheusのアラートルールで検知時刻を機械的に固定する

検知時刻を人が記録すると、MTTDは実態より短く出がちです。Prometheusのアラートルールに for 句を置くと、条件を満たし続けた時間だけ pending にとどめ、そのあと firing へ移すという判定を機械が担います。Prometheus の公式ドキュメント（Alerting rules）は for 句を「first encountering a new expression output vector element と firing とみなすまでの待ち時間」と説明し、条件が外れたあとも発報を維持する keep_firing_for も併せて定義しています。

# 外形監視の失敗を2分連続で検知したら発報する（Prometheus）
groups:
  - name: availability
    rules:
      - alert: ServiceDown
        expr: probe_success{job="blackbox"} == 0
        for: 2m
        keep_firing_for: 5m
        labels:
          severity: page
        annotations:
          summary: "外形監視が2分連続で失敗"

この for に置いた2分は、そのままMTTDの下限になる値です。値を短くすれば検知は早まる代わりに、一時的なゆらぎで人が起こされる回数が増えます。呼び出し回数と検知速度のつり合いをどう取るかはアラート疲れとは｜原因と対策を監視の実装視点で解説で扱いました。稼働率そのものを同じ監視データから出すなら、次の一行で直近30日の成功率を取れます。

# 直近30日の外形監視成功率＝実測の稼働率（PromQL）
avg_over_time(probe_success{job="blackbox"}[30d])

監視ツールごとに違うMTTR定義を突き合わせる読み替えの手順

製品のレポート画面が出す「MTTR」は、自社の定義と一致するとはかぎりません。Datadog の Incident Management Analyticsは、時刻を detected・declared・resolved の3つで持ち、指標を Time to Detect（最初の顧客影響から検知まで）、Time to Internal Response（検知から宣言まで）、Time to Repair（検知から顧客影響の終了まで）、Time to Resolve（宣言から解決まで）に分けています。自社の呼び名と製品の呼び名を、次の表のように一度だけ突き合わせておきましょう。

読み替え表を作らずに製品の数字をそのまま社外へ出すと、SLA報告の値が翌月から静かにずれます。ツールを乗り換えたときも、この表を先に更新してから過去分を再集計するのが安全な順序です。

ヘルスチェックと自動再起動でMTTRを縮める設定ファイルの実装

人が駆けつけるより先に、基盤側が直すか切り離すほうが速く済みます。ここではコンテナの自動再起動と、振り分けからの自動切り離しという2つの設定を実装の粒度で見ます。

LivenessとReadinessを分けて自動再起動を効かせる設定

Kubernetesでは、liveness と readiness を分けて書くと「壊れたら再起動」「起動途中は振り分けない」を同時に成立させられます。Kubernetes 公式ドキュメント（Configure Liveness, Readiness and Startup Probes）は liveness の失敗時の挙動を「If the handler returns a failure code, the kubelet kills the container and restarts it.」と記しており、再起動までを人手なしで回せます。

# Liveness で再起動、Readiness で振り分け停止を分担させる（Kubernetes）
apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  containers:
    - name: api
      image: registry.example.com/api:1.4.0
      readinessProbe:
        httpGet:
          path: /readyz
          port: 8080
        periodSeconds: 5
        failureThreshold: 2
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 20
        periodSeconds: 10
        failureThreshold: 3

readiness を短い周期にして liveness を緩めるのが基本の組み方です。逆に liveness を厳しくしすぎると、負荷で応答が遅れただけのコンテナを次々に落として障害を広げます。しきい値の決め方はヘルスチェックとは？LivenessとReadinessの分離と閾値設計で詳しく扱っています。

ロードバランサーのヘルスチェック設定で切り離しを自動化する手順

コンテナを使わない構成でも、振り分け側で同じことができます。ロードバランサーにヘルスチェックを設定し、異常なサーバーを自動で振り分け対象から外せば、利用者から見た停止時間は検知間隔とタイムアウトの合計まで縮みます。設定は「チェック間隔」「タイムアウト」「異常と判定する連続失敗回数」の3つで決まり、間隔5秒・失敗2回なら切り離しまで約10秒です。チェック先には、DBやキャッシュへの疎通まで確かめる専用のエンドポイントを用意しましょう。トップページを叩くだけの設定では、アプリが半分死んでいても200を返して切り離しが働きません。

MTTRを短縮する実装策と、短縮を優先すべきでない場面の判断基準

MTTR短縮の打ち手は明確です。ただし、数値そのものを目的化すると品質を損なう場面があります。ここでは採用する打ち手と、あえて追わない条件を切り分けましょう。

復旧自動化・ランブック・冗長化でMTTRを縮める打ち手の優先順位

MTTR短縮で効果が大きい順に手を打ちます。まず検知と通知の自動化（監視しきい値・オンコール自動呼び出し）で待ち時間を消しましょう。次に、頻出障害の復旧手順をランブック化し、判断を挟まず実行できる状態にするのが次の一手です。復旧作業の一部はスクリプトで自動化すると、再起動や切り離しを人手から外せます。そのうえで単一障害点を冗長化し、フェイルオーバーで「直す前に切り替える」設計にすれば、体感の復旧時間はほぼゼロに近い水準です。障害ノードの切り離しには前章のヘルスチェック連動が効き、異常なサーバーを自動で振り分け対象から外せる仕組みになります。こうした復旧設計と日々の運用体制づくりは、一創の保守運用・内製化支援でも、監視・オンコール・ランブック整備を含めて伴走しています。

MTTRだけを追うと壊れる場面（恒久対策の軽視・数値操作）の失敗パターン

MTTRの短縮は手段であって目的ではありません。数値だけを評価軸にすると、次の失敗が起きます。ひとつは、暫定復旧（再起動でしのぐ）を繰り返してMTTRは縮むのに、根本原因が残って同じ障害が再発するケースです。この場合はMTBFが縮み、稼働率はむしろ悪化してしまいます。もうひとつは、軽微な事象をインシデントに数えない・resolveを早めに押すといった数値操作で、指標が実態から乖離するパターンです。MTTRを追うなら、MTBF（再発のしにくさ）とResolve（恒久対策完了）を必ず併走させ、短縮と再発防止のどちらかに偏らせないことが判断の軸になります。障害頻度が低い小規模システムに、five nines前提の自動復旧を作り込むのは過剰投資で、この場合はMTTR短縮より監視の整備を先に置くべきです。

受託開発・保守運用でMTTR目標を契約（SLA/SLO）に落とす設計

外部委託や内製移行では、MTTRを合意可能な数値に落とし込みます。運用側が約束できるのは「対応着手までの時間（応答）」までで、復旧完了時間は障害の性質に左右されるため、MTTA（応答）とMTTR（復旧）を分けて目標化するのが実務的です。契約では、稼働率目標→許容ダウンタイム→許容MTTRの順に逆算し、その体制（オンコール・冗長構成・ランブック）を用意できるかで実現性を見極めます。稼働率をSLA/SLOへ落とす具体はSLAとは？SLO・SLIとの違いを、システムの止まらない設計そのものは可用性の設計を土台にすると、MTTR目標が絵に描いた餅になりません。

MTTR（平均修復時間）に関するよくある質問と実務での回答例

MTTRの計算や関連指標について、実務で問われやすい5点に答えます。

MTTRの計算式と単位はどう決めればよいですか？

基本式は「総修理（復旧）時間 ÷ 障害件数」です。単位は分・時間のどちらでも構いませんが、SLA監視では分、設備保全では時間が一般的です。式そのものより定義が肝心で、開始時刻（発生か検知か）と終了時刻（暫定復旧か恒久対策完了か）を社内で固定してから測ります。Azure Well-Architected Framework のように「検出された後から」を起点に置く定義もあるため、外部資料の数字と並べるときは前提を確認しましょう。定義が揺れると、同じ障害でもMTTRが数倍ぶれてしまいます。

MTTRとMTBFの違いは何ですか？

MTTRは「直るまでの平均時間（直りの速さ）」、MTBFは「故障から次の故障までの平均時間（壊れにくさ）」を指します。MTTRは小さいほど良く、MTBFは大きいほど良い、と向きが逆です。両者は稼働率 ＝ MTBF ÷（MTBF ＋ MTTR）で結びつき、可用性の高さを決めます。AWS の信頼性の柱は、この式を可用性が非公開の依存先を見積もる手段として示しました。

MTTRとMTTD・MTTAはどう区別しますか？

故障発生からの時間軸で分かれます。MTTD（平均検知時間）は「起きてから気づくまで」、MTTA（平均応答時間）は「気づいてから対応着手まで」、MTTR（平均復旧時間）は「発生から復旧完了まで」の全体です。MTTRを分解するとMTTD・MTTAが内訳として現れ、どの区間を縮めるべきかが見えてきます。監視製品では Time to Detect・Time to Internal Response といった別名で並ぶことがあるので、読み替え表を先に作っておくと混乱しません。

MTTRの目安・平均値はどのくらいですか？

一律の基準値はなく、システムの可用性目標から逆算します。稼働率99.9%（年間許容約8時間45分）で月数件の障害を見込むなら、1件あたり許容MTTRは1〜2時間程度が目安です。他社比較の絶対値より、自社の目標稼働率と障害頻度から許容値を決め、実測を近づける進め方が実務に合っています。業界横断の順位づけを引きたい場合も、DORAが指標名をFailed deployment recovery timeへ改めている点を踏まえ、比較対象の定義を先に確認してください。

MTTRを短縮する最初の一手は何ですか？

多くの現場では復旧作業より検知・通知の遅れがボトルネックです。まず監視のしきい値とアラートの通知経路（オンコール自動呼び出し）を見直すと、対応着手が早まりMTTR全体が縮みます。Prometheus であれば for 句の値がそのままMTTDの下限になるので、ここを実測しながら詰めるのが手早い進め方でしょう。そのうえで頻出障害のランブック化、単一障害点の冗長化へと進めると、費用対効果の高い順に短縮できます。

関連記事

• 可用性とは：稼働率の計算と高可用性の設計を、MTTRを含む上位概念として整理しています。
• SLAとは：MTTRから逆算した稼働率を、SLO・SLIとして約束に落とす手順を解説しています。
• インシデント管理とは：MTTRを自動集計する土台となるプロセスとオンコール実装を扱っています。
• ヘルスチェックとは：本記事のプローブ設定を、閾値設計の粒度まで掘り下げています。
• フォールトトレラントとは：MTTRを縮める代わりに止めない設計へ振る判断を比較しています。
• アラート疲れとは：検知を早めるほど増える呼び出しをどう抑えるかを実装視点で扱っています。
• 冗長化とは：自動フェイルオーバーで復旧時間そのものを消す構成を判断軸つきで解説しています。
• 保守運用・内製化支援：監視・オンコール・ランブック整備までを含めて相談できます。