Web制作者のためのSRE入門｜無料の外形監視とSLOの決め方

Web制作者にとってのSREとは、作ったサイトが落ちたことを依頼主より先に検知し、どこまでの停止を許容するかを数字で決めて運用することです。クラウドの構築やKubernetesの運用は、その先の話になります。

学ぶ順番も同じです。最初にやるのは「自分のサイトを外から叩いて、落ちたら通知が飛ぶ」を1本作ること。この記事では、無料の範囲でその1本を作り、意図的にダウンを起こして通知が本当に手元に届くかを確かめるところまでを扱います。

掲載しているコマンド・スクリプト・ワークフローはすべて実際に実行して出力を確認したものです。無料プランでできることとできないことは、料金ページの実データを読んで表にしました。記事の後半には、SLOとエラーバジェットの早見表と、検証が外れたときの分岐表を用意しています。

Web制作者にとってのSREとは何か

SRE（Site Reliability Engineering）は、Googleが2003年に始めた運用の実践です。創設者のBenjamin Treynor Slossは、Google SRE本の冒頭で「SREとは、ソフトウェアエンジニアに運用チームを設計させたときに起きることである」と定義しています（Google, Site Reliability Engineering, Introduction・2026年8月2日時点）。つまりSREは職種名である前に、運用をソフトウェアの問題として扱うという考え方です。

この考え方をWeb制作の規模に落とすと、やることは驚くほど少なくなります。「サイトが生きているかを機械に見張らせ、どこまでの停止を許すかを数字で決める」——この2つだけです。そしてこの2つは、無料の道具だけで今日始められます。

SLI・SLO・エラーバジェット・トイルを1つの表で押さえる

SREの話が難しく感じるのは、似た略語が4つ出てくるからです。定義はGoogle SRE本に書かれているので、そのまま押さえます。

出典はService Level Objectives（SLI・SLO・SLA）、Embracing Risk（エラーバジェット）、Eliminating Toil（トイル）です（いずれも2026年8月2日時点）。Google SRE本はsre.google 上で全文が無料公開されています。

ここでひとつだけ間違えやすい点があります。「SLOを改善する」という言い方は、定義上ねじれています。SLOは自分で決める目標値であって、改善する対象ではありません。改善するのはSLIで測っている実測値のほうです。「表示速度を上げたらSLOが良くなった」ではなく、「SLIの実測値が上がり、SLOに対する余裕（エラーバジェット）が増えた」が正しい言い方になります。

Web制作の経験がそのまま効く3つ

SREを別世界の職種だと感じる必要はありません。Web制作で身につけた次の3つは、そのまま使えます。

1. 数字を測ってから直す習慣。LCPやINPといったCore Web Vitalsは、Google SRE Workbookの分類でいうリクエスト駆動型サービスのSLIタイプ「latency（遅延）」に相当する測定値です。SLIを選ぶ作業は、いつもやっている計測の延長にあります。
2. キャッシュの効き方の見立て。WordPressでページキャッシュやCDNを運用していると、どこまでがキャッシュから返っていて、どこからがPHPの処理なのかの感覚が身につきます。応答時間が伸びたときに、どのレイヤを疑うかの起点になります。
3. DNSとサーバー構成の把握。ドメイン・ネームサーバー・Webサーバーの関係を知っていれば、通知が来たときに「サイトが落ちた」のか「そもそも名前が引けていない」のかを分けて考えられます。

サーバー・データベース・APIの関係そのものが曖昧なら、監視の前にそこを埋めたほうが早いです。全体像はバックエンドとは？サーバー・DB・APIの全体像にまとめています。

逆に、Web制作では身につかない3つ

誇張しないために、効かないものも書いておきます。次の3つはWeb制作を続けても身につきません。

• オンコール運用——当番制で夜間・休日に呼び出される前提の設計、エスカレーションの取り決め、障害後のポストモーテム
• 分散システムの障害設計——リトライ、サーキットブレーカ、縮退運転など、部分的な故障を前提にした作り
• キャパシティプランニング——需要予測にもとづく容量確保と、その予測が外れたときの回復

SREを名乗るにはこの3つが要ります。ただしこの記事が扱う範囲（自分のサイトの死活監視とSLO）は、この3つが無くても成立します。順番として、先に手が届くほうから始めるという話です。

最初の一歩｜無料で外形監視を1本入れる

Google SRE Workbookは、過去の実績データが手元に無い場合の「低忠実度な解」として、次のように書いています。HTTPサービスなら、定期的なヘルスチェック（pingやHTTP GET）を行って成功したリクエスト数を報告してくれる外部の監視サービスを立てればよい、と（The Site Reliability Workbook, Implementing SLOs・2026年8月2日時点）。

つまりこれから作る「外から叩いて生死を記録する仕組み」は、間に合わせではなく、公式が最初の一歩として想定している形そのものです。まだ監視する対象のサイトを公開していない場合は、ポートフォリオ公開のためのレンタルサーバーの選び方を先に読んで、1本公開してからのほうが実感が湧きます。

UptimeRobotの無料プランでできること・できないこと

無料の外形監視ではUptimeRobotがよく使われますが、料金ページの機能一覧は「載っている＝使える」ではありません。各項目には内部的に「使える／使えない／制限あり」のフラグが付いていて、無料プランは多くが「使えない」側です。料金ページのデータを読んで整理したものが次の表です（UptimeRobot Pricing・2026年8月2日時点）。

とくに間違えやすいのが次の2点です。「無料プランでSSL証明書の期限切れを監視できる」「無料プランでSlackへ通知できる」——この2つはどちらも誤りです。SSL／ドメイン期限監視もSlack連携も、Solo（月10米ドルから）以上でないと使えません。クライアントに監視を提案する前に、ここを取り違えていないか確認してください。

HTTPモニタとキーワードモニタを作る

無料プランで使えるモニター種別のうち、Webサイトの監視で実際に選ぶのはHTTPかキーワードの2つです。違いは本文を見るかどうかです。

テーマやプラグインの不具合で本文が真っ白になっても、HTTPステータスは200のまま返ることがあります。この場合HTTPモニタはUPと判定し続けます。本番サイトにはキーワードモニタを選んでおくほうが安全です。加えて、後述する検証（意図的なダウンの再現）はキーワードモニタでないと安全に行えません。

1. モニター種別にKeywordを選び、監視するURLに自分のサイトのトップページを指定する
2. 監視キーワードに、そのページへ確実に存在する文字列（サイト名など）を入れる
3. 通知先（Alert contact）にメールアドレスを登録し、確認メールのリンクを踏んでVerify済みにする
4. 保存して5〜10分待ち、ダッシュボードの表示がUpになることを確認する

キーワードを決めるときの注意がひとつあります。外形監視が見るのは取得したHTMLのソースであって、ブラウザが後からJavaScriptで描画した文字列ではありません。ブラウザの画面に見えている文字列が本当にHTMLに入っているかは、手元で次のコマンドを打てば1秒で分かります。

# 監視キーワード候補が HTML に何回出てくるかを数える
curl -sS https://codequest.work/ | grep -c "CodeQuest"
# => 4    （1以上なら監視キーワードとして使える）

curl -sS https://codequest.work/ | grep -c "zzz-uptime-test-20260802"
# => 0    （0ならキーワードとして機能しない）

通知先を決める｜無料で使える5つと、使えないもの

無料プランの通知手段は、メール・SMS・音声通話・Email2SMSに加えて、サードパーティ連携が5つ（Google Chat・Discord・Pushover・Pushbullet・Splunk）です。SMSと音声通話はクレジット制で、無料プランに付いてくるクレジットは0のため、実質的にはメールかこの5連携のいずれかになります。

制作者が1人で見るなら、メール通知だけで十分です。ただしメール通知には「届かないのに気づけない」という弱点があります。迷惑メールに振り分けられても、通知先が未認証のままでも、画面上はモニターが動いているように見えるからです。だからこそ、設定した直後に一度わざと落として、通知が本当に届くかを確かめる必要があります。その手順はこの記事の後半で扱います。

アカウントを作らずに試す｜curlとGitHub Actionsで自作する

外部サービスに登録したくない、あるいは社内の事情で使えない場合でも、手元の道具だけで同じことができます。ここで作るものは常設の監視の代わりにはなりませんが、「監視とは何をしているのか」を1回自分の手で通しておくと、設定画面の項目の意味が分かるようになります。

curl一発でHTTPステータスと応答時間を測る

まず、外形監視が毎回やっていることを1コマンドで再現します。curlの-wオプションは、リクエストの各段階にかかった秒数を取り出せます。

curl -sS -o /dev/null -w "http_code=%{http_code} time_namelookup=%{time_namelookup} time_connect=%{time_connect} time_appconnect=%{time_appconnect} time_starttransfer=%{time_starttransfer} time_total=%{time_total}\n" https://codequest.work/

# 実行結果（同じコマンドを3回続けて実行したもの）
http_code=200 time_namelookup=0.002261 time_connect=0.013093 time_appconnect=0.029647 time_starttransfer=0.221200 time_total=0.243312
http_code=200 time_namelookup=0.002594 time_connect=0.012764 time_appconnect=0.027825 time_starttransfer=0.247118 time_total=0.274262
http_code=200 time_namelookup=0.002288 time_connect=0.012750 time_appconnect=0.027291 time_starttransfer=0.225702 time_total=0.247612

数字の読み方は、差分を見るのがコツです。上の実測（3回とも同じ傾向）を分解すると、こうなります。

この例では、TLSまでが0.027秒で終わっているのに対し、そこから最初の1バイトが返るまでに約0.198秒かかっています。遅さの大半はネットワークではなくサーバー側の処理です。この分解ができると、「サイトが遅い」という報告に対してCDNを疑うのかアプリを疑うのかを、当てずっぽうではなく数字で決められます。

UP/DOWNを判定するシェルスクリプト

先ほどのcurlに「200かどうか」と「キーワードがあるか」の判定を足すと、外形監視の中身とほぼ同じものになります。mon.sh として保存し、実行権限を付けて使います。

#!/bin/bash
# mon.sh <URL> <監視キーワード（省略可）>
URL="$1"; KEYWORD="$2"
BODY=$(mktemp)
READ=$(curl -sS -o "$BODY" -m 10 -A "my-monitor/1.0" -w '%{http_code} %{time_total}' "$URL") || READ="000 0"
CODE=${READ% *}; TIME=${READ#* }
STATUS=UP; REASON=""
[ "$CODE" != "200" ] && { STATUS=DOWN; REASON="http_code=$CODE"; }
if [ "$STATUS" = UP ] && [ -n "$KEYWORD" ] && ! grep -qF -- "$KEYWORD" "$BODY"; then
  STATUS=DOWN; REASON="keyword-missing:$KEYWORD"
fi
rm -f "$BODY"
echo "$(date -u +%FT%TZ) $STATUS code=$CODE time=${TIME}s $REASON"
[ "$STATUS" = UP ]

最後の行が効きます。[ "$STATUS" = UP ] はUPなら終了コード0、DOWNなら1を返すので、cronやCIから呼んだときに「失敗」として扱われるようになります。実際に4パターンを走らせた出力が次のとおりです。

$ ./mon.sh "https://codequest.work/" "CodeQuest"
2026-08-01T23:36:50Z UP code=200 time=0.273008s
exit=0

$ ./mon.sh "https://codequest.work/no-such-page-xyz/" ""
2026-08-01T23:36:50Z DOWN code=404 time=0.112608s http_code=404
exit=1

$ ./mon.sh "https://codequest.work/" "存在しない語ABCXYZ"
2026-08-01T23:36:50Z DOWN code=200 time=0.287689s keyword-missing:存在しない語ABCXYZ
exit=1

$ ./mon.sh "https://no-such-host-abcxyz.example.com/" ""
curl: (6) Could not resolve host: no-such-host-abcxyz.example.com
2026-08-01T23:36:50Z DOWN code=000 time=0s http_code=000
exit=1

3つ目に注目してください。HTTPステータスは200なのにDOWNと判定されています。これがキーワード監視の値打ちで、「サーバーは生きているが中身が壊れている」を捕まえられます。4つ目のcode=000は「サーバーが落ちている」ではなく「そもそも到達していない」を意味します。000が出たときは切り分けの起点がサーバーではなくDNSやネットワークに変わります。

GitHub Actionsで定期チェックを回す（制約つき）

このスクリプトをGitHub Actionsのスケジュール実行に載せると、自分のPCを起動していなくても定期チェックが回ります。次のワークフローを.github/workflows/uptime.ymlとして置きます。

name: uptime-check

on:
  schedule:
    # 最短は5分。毎時00分は混みやすいので4分ずらして10分おきにする
    - cron: "4,14,24,34,44,54 * * * *"
  workflow_dispatch:

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - name: Check site
        env:
          URL: "https://example.com/"
          KEYWORD: "Example Domain"
        run: |
          BODY=$(mktemp)
          READ=$(curl -sS -o "$BODY" -m 10 -A "gha-monitor/1.0" -w '%{http_code} %{time_total}' "$URL") || READ="000 0"
          CODE=${READ% *}; TIME=${READ#* }
          STATUS=UP; REASON=""
          [ "$CODE" != "200" ] && { STATUS=DOWN; REASON="http_code=$CODE"; }
          if [ "$STATUS" = UP ] && [ -n "$KEYWORD" ] && ! grep -qF -- "$KEYWORD" "$BODY"; then
            STATUS=DOWN; REASON="keyword-missing:$KEYWORD"
          fi
          echo "$(date -u +%FT%TZ) $STATUS code=$CODE time=${TIME}s $REASON"
          [ "$STATUS" = UP ]

ジョブが失敗すると、GitHubから通知が飛びます。公式ドキュメントによれば、スケジュール実行の通知は、そのワークフローを最初に作成したユーザーに送られます。cronの記述を別のユーザーが更新した場合は、以降その人に送られます。「失敗したときだけ通知する」設定も選べます（GitHub Docs, Notifications for workflow runs・2026年8月2日時点）。

ただし、スケジュール実行には知っておくべき制約が3つあります。これを知らずに常設の監視として使うと、静かに止まります。

出典はGitHub Docs, Events that trigger workflows（2026年8月2日時点）です。そしてもうひとつ、原理的な弱点があります。GitHub側が不調なときは、検知の仕組みそのものが止まります。常設の監視は外部サービスに任せ、こちらは手元での確認や、外部サービスを使えない環境での代替として位置づけるのが現実的です。

自分のサイトのSLOを決める

監視を入れただけでは「落ちていた気がする」の域を出ません。どこまでの停止なら許すのかを先に数字で決めておくと、通知が来たときに慌てる／慌てないの判断ができるようになります。ここがロードマップを読むだけでは絶対に身につかない部分です。

SLIを1つだけ選ぶ

Google SRE Workbookは、システムを部品の型に抽象化してからSLIを選ぶことを勧めています。Webサイトはリクエスト駆動型（ユーザーが操作し、応答を待つ）に当てはまり、この型に対して挙げられているSLIは次の3つです。

最初に選ぶのはAvailability一択です。理由は単純で、5分間隔の外形監視のログがそのまま母数になるからです。Workbook自身も「特にSLIを始めたばかりなら、関連はあるが測りやすい側面を1つ選べばよい。後からいくらでも反復して精緻にできる」と書いています。

Latencyを選ぶ場合、実測手段はCore Web Vitalsになります。改善の手順はCore Web Vitals改善ガイドにまとめています。ここで冒頭の注意を繰り返します。Core Web Vitalsを改善することはSLOを改善することではありません。Core Web VitalsはSLIの候補（latency）であり、SLOはその測定値に対して自分で決める目標値です。

SLO目標値とエラーバジェットの早見表

SLOを決めると、その裏返しとしてエラーバジェット（許される停止時間）が自動的に決まります。30日を1周期としたときの計算結果が次の表です。

個人サイトや小規模案件で99.99%を選ぶ意味はほとんどありません。30日で4分19秒しか停止できない計算になり、WordPress本体のメジャーアップデートで1回つまずけばその時点で赤字です。まずは99.9%（30日で43分12秒）を出発点にするのが現実的です。Workbookも、他に情報が無く、あとから見直す仕組みがあるなら、現在の実績値を出発点にしてよいとしています。

大事なのは数字の高さではありません。超えたときに何をやめて何を直すかを、超える前に決めておくことです。エラーバジェットを使い切ったら新しい機能追加を止めて安定化に回す、という運用の線引きに使うのが本来の役割です。

監視ログから今月の可用性を計算する

無料プランは5分間隔なので、30日で8,640回チェックが走ります。このうち何回DOWNだったかが分かれば、可用性は割り算で出ます。SLO 99.9%と突き合わせると次のようになります。

この数字には必ず但し書きが要ります。5分間隔ということは、1回のDOWN判定が「最大5分の停止」を意味し、5分未満の瞬断はそもそも記録に残りません。つまりここで出る可用性は5分粒度の近似値です。自分の把握のために使うぶんには十分ですが、この数字をそのまま契約書の稼働率保証として書くのは危険です。

【検証】本当に落ちたら気づけるかを確かめる

ここまでで監視は動いています。しかし「落ちたときに通知が手元に届く」ことは、まだ一度も確認できていません。通知先が未認証だった、迷惑メールに振り分けられていた、モニター種別を間違えていた——このどれかが起きていると、画面上は正常に動いているように見えたまま、何か月も気づけない状態が続きます。

確かめる方法は単純です。意図的にダウンを起こします。ただし本番サイトを実際に止める必要はありません。監視キーワードのほうを、ページに存在しない文字列へ一時的に書き換えます。サイトは正常に動いたまま、監視側だけがDOWNと判定します。訪問者には何の影響もありません。

手順

1. UptimeRobotのダッシュボードで、対象のキーワードモニタがUpになっていることを確認する。ここがスタートラインになる
2. 通知先（Alert contact）がVerify済みであることを確認する
3. 監視キーワードを、そのページに絶対に存在しない文字列（例: zzz-uptime-test-20260802）へ変更して保存する
4. 変更した時刻をメモする
5. 待つ。この間、サイト自体は普段どおり動いている
6. 通知が届いたら監視キーワードを元に戻し、復旧の通知が来るところまで確認する

手順3で使う文字列は、書き換える前に手元で確認しておくと確実です。前掲のcurl -sS URL | grep -c "文字列"が0を返せば、そのページに存在しない文字列であることが確かめられます。

合否ライン

判定は2段階に分けます。「監視側が気づいたか」と「自分に届いたか」は別の問題で、原因も対処も違うからです。まとめて「通知が来ない」と扱うと切り分けができなくなります。

一次が通らない場合は、監視の設定そのものが効いていません（モニター種別・キーワード・キャッシュのいずれか）。一次だけ通って二次が通らない場合は、通知経路の問題です（通知先が未認証、または迷惑メール振り分け）。どちらで止まったかが、そのまま次の分岐表の入口になります。

15分という上限の根拠は、無料プランのチェック間隔が5分であることです。書き換えた直後にチェックが走ったばかりなら、次のチェックまで最大5分待ちます。そこに判定が確定するまでの追加のチェックぶんを見込み、チェック3回ぶんにあたる15分を上限としています。5分で切り替わることもよくあるので、早く届いたぶんには何の問題もありません。

アカウントを作らずにmon.shで試した場合の合否ラインは、終了コードで判定します。UPなら0、DOWNなら1。次の4パターンすべてで期待どおりの終了コードになれば合格です。

3つ目が0を返してしまう場合、キーワード判定が働いていません。grep -qF -- "$KEYWORD" の部分と、キーワードを引数の2番目に渡せているかを確認してください。

外れたときの分岐表

合否ラインを外れたときは、次の表で原因を切り分けます。ここで確認するのは「DOWNを検知して通知が手元に届く」までです。届いた通知から障害の原因を突き止める手順や、メールが使えない環境での代替通知経路の設計は、この検証の範囲外とします。

制作の仕事にどう載せるか

ここまでの内容は、そのまま保守メニューの中身になります。納品して終わりにせず、監視を継続の入口にするときに何を約束して何を約束しないかを先に決めておくと、あとで食い違いません。

監視を保守メニューの1項目にする

無料プランで提供できる範囲は限られています。約束できることとできないことを分けると次のようになります。

SSL証明書の期限は無料プランでは監視できないので、別途カレンダーに登録するなど手動で管理します。自動更新が効いている環境でも、更新の失敗に気づく仕組みは別に要ります。

納品前のサーバー設定と初期チェックの手順はWordPress案件を受注したら最初にやるサーバー設定にまとめています。監視はその続きに置くと収まりがよくなります。

通知が来たときの切り分け順

DOWNの通知が届いたら、上から順に見ます。順番を決めておくと、焦っていても手が動きます。

1. 自分のブラウザで開く。開けるなら、自分の回線だけの問題か監視側の誤検知の可能性がある
2. 外から叩く。curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/ を実行し、返ってくる数字を見る
3. 000なら名前解決かネットワーク、5xxならサーバー側、200なら監視側の設定かキャッシュを疑う
4. 同じサーバーの他のサイトや管理画面が生きているかを確認し、サイト単位の問題かサーバー単位の問題かを分ける

「Webは見えているのにメールだけ届かない」のように、ドメインの設定側に原因があることもあります。ネームサーバーとDNSレコードの読み方はHTML・WordPress・メールのサーバー構成の読み方で扱っています。

ここから先の学習順

ロードマップを載せる記事は多いのですが、「何ができたら次へ進んでよいのか」が書かれていないと、入門書を何冊も往復して終わります。各段階に、そこを抜けたと判断してよい合図を付けます。

Linux → Docker → CI/CD → IaC の順と、それぞれの終わり方

段階2の入口はDocker Composeで作るPHP・MySQLのローカル開発環境にまとめています。段階3については、この記事のGitHub Actionsのワークフローを動かした時点ですでに片足を踏み入れています。監視という小さな題材で1本通してあるので、そこからデプロイに広げるのが最短です。

なお、roadmap.shにSRE専用のロードマップは存在しません（roadmap.sh/sreは404です・2026年8月2日時点）。同サイトのDevOpsロードマップが「DevOpsエンジニアまたはSREになるための道筋」と銘打たれており、これがSREを兼ねています。SRE専用の教材を探し回る必要はありません。

学習時間の配分をどう決めるか

筆者はWeb制作7割・SRE3割で配分しています。これは筆者の配分であって、根拠のある推奨値ではありません。収益に直結する制作の時間を削らずに済む線がここだった、というだけです。

配分に迷ったときの物差しとして、Google側の数字を置いておきます。Googleは全SREの「ops」作業（チケット対応・オンコール・手作業）の合計に50%の上限を設けています。これは目標ではなく上限で、SREの時間の半分以上をエンジニアリング作業に確保するための線引きです。

制作者に読み替えると、「監視の面倒を見る手作業が、制作の時間を食い始めたら、そこは自動化するかメニューから外す」という判断になります。この判断にはトイルの定義がそのまま使えます。手作業で反復的・自動化可能・戦術的で、永続的な価値がなく、サービスの成長に比例して増える作業がトイルです。毎朝サイトを開いて目視するのは典型的なトイルで、だからこそ最初に自動化する価値があります。

よくある質問

Q. SREとDevOpsは何が違いますか？

SREは「ソフトウェアエンジニアに運用チームを設計させたときに起きること」と定義される具体的な実践で、Googleが2003年に始めました。DevOpsは開発と運用の分断をなくすための文化・原則の総称であり、特定の職種名ではありません。実際、roadmap.shは両者を1本のロードマップで扱っており、SRE専用のロードマップは用意されていません。

Q. Web制作者がSREを学ぶとき、最初にやるべきことは何ですか？

自分が公開しているサイトに外形監視を1本入れ、落ちたら通知が届く状態を作ることです。クラウドやコンテナより先で構いません。Google SRE Workbookも、SLIを始めたばかりなら「関連はあるが測りやすい側面」を1つ選び、後から反復して精緻にすればよいとしています。

Q. UptimeRobotの無料プランだけで実務に足りますか？

自分のサイトや小規模案件の死活監視であれば足ります。50モニター・5分間隔で、HTTP・ポート・Ping・キーワードの各監視とメール通知が無料で使えます。ただしSSL証明書やドメインの期限監視・DNS監視・API監視・多地点監視は無料では使えず、SlackやWebhookへの通知も有料プランからです。クライアントに監視を約束するなら、この線引きを先に伝えておく必要があります。

Q. SLOは何パーセントに設定すればいいですか？

最初は99.9%（30日で43分12秒の停止を許容）から始めて構いません。Google SRE Workbookも、他に情報が無く、あとから見直す仕組みがあるなら現在の実績値を出発点にしてよいとしています。重要なのは数字の高さではなく、超えたときに何をやめて何を直すかを先に決めておくことです。

Q. 監視を保守契約に入れるとき、何を約束すればいいですか？

約束するのは「検知と連絡」までにとどめ、復旧時間を安易に約束しないことです。無料プランは5分間隔なので検知に最大5分かかり、5分未満の瞬断は記録に残りません。またデータ保持は3か月なので、それ以前の稼働率は証明できません。この粒度を見積書か契約書に書いておくと、後から食い違いません。

Q. サーバーを持っていなくてもSREの練習はできますか？

できます。curlでHTTPステータスと応答時間を測るところから始められ、GitHub Actionsのスケジュール実行を使えば無料で定期チェックも回せます。ただしスケジュール実行の最短間隔は5分で、混雑時には遅延したりジョブが破棄されたりすること、パブリックリポジトリでは60日間の活動が無いと自動的に無効化されることは知っておく必要があります。

まとめ

Web制作者がSREに近づく最短の道は、教材を積み上げることではなく、自分のサイトに監視を1本入れて、それが本当に鳴るかを確かめることです。

• SLIは測定値、SLOはそれに対して自分で決める目標値。SLOは「改善するもの」ではなく「決めるもの」
• 無料の外形監視は5分間隔・キーワード監視まで。SSL期限監視とSlack通知は無料では使えない
• 監視を入れた直後に、監視キーワードをわざと外して通知が届くかを確かめる。判定はダッシュボードがDownになるか（15分以内）と、通知が届くか（そこから10分以内）の2段階
• SLOは99.9%（30日で43分12秒）から。5分間隔の可用性はあくまで近似値で、契約の保証値にはしない
• 保守メニューで約束するのは検知と連絡まで。復旧時間は約束しない

まずは監視を1本入れて、この記事の検証セクションを1回通してみてください。通知が手元に届いた時点で、あなたのサイトは「落ちても誰も気づかない状態」から抜け出しています。

自社サイトやクライアント案件で、監視を含めた運用体制の設計から相談したい場合は、RINIAで承っています。