SREのフリーランス案件の仕事内容｜案件の種類別の1日・1か月の流れ

フリーランスのSRE（サイト信頼性エンジニア）の仕事は、サービスがどのくらい安定していればよいかを数字で決め、その水準を守るための仕組みをコードと手順でつくることです。ただし、案件によって「仕組みをつくる」比重が大きいのか、「日々の運用と障害対応を回す」比重が大きいのかが違い、1日の過ごし方も向き合う相手も変わります。

この記事では、SREの案件を4つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。求められるスキルはSREのスキルの記事、報酬の決まり方はSREの報酬の記事で扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。

仕事の中身は「改善か運用か」と「基盤の段階」で決まる

SREの募集は、同じ肩書きでも中身に幅があります。違いを生むのは主に次の2つです。

• 改善と運用の比重：信頼性の仕組みを新しくつくる仕事が中心か、すでにある運用を回し障害に対応する仕事が中心か
• 基盤の段階：監視や指標がまだ整っていないか、整っていて磨く段階か、別の基盤へ移す途中か

この2つを掛け合わせると、フリーランスのSRE案件はおおむね次の4種類に分けられます。

以下は典型的な例です。時間の配分は案件ごとに違うため、目安として読んでください。

SLO・可観測性を整える案件の仕事

1日の流れ（例）

朝は、前日のアラートとダッシュボードを見て、鳴ったのに誰も対応しなかったアラートや、障害だったのに鳴らなかった指標を拾います。午前は、開発チームと「利用者が困るのはどんな状態か」を話し合い、SLI（サービスの状態を表す指標）の候補を決めます。午後は、ログやメトリクス、トレースの取り方を設計し、計測の設定やダッシュボードを実装します。

最初の数週間は、今何が計測されていて、何が計測されていないかを把握することに多くの時間を使います。

1か月の流れ（例）

• 月初：前月のSLOの達成状況と、エラーバジェット（許容できる失敗の量）の消費を開発チームに共有する
• 毎週：アラートの見直し会で、不要なアラートを減らし、足りない監視を足す
• 月の半ば：SLOを下回りそうなサービスについて、リリースの進め方や改善の優先度を開発チームと相談する
• 月末：指標の定義や見直しの経緯を文書に残し、翌月に整備するサービスを決める

成果物

SLI・SLOの定義書、ダッシュボード、アラートの設定と対応手順、計測の設計書、エラーバジェットの運用ルールなどです。SLOの定義や目標は、システムのふるまいが分かるにつれて見直していけるものとされています（Googleの『Site Reliability Engineering』による）。一度決めて終わりにせず、利用者の体験と合っているかを確かめ続けることが仕事になります。

トイルを減らす案件の仕事

1日の流れ（例）

運用チームが毎日くり返している手作業を聞き取り、作業の手順と頻度を書き出します。そのうえで、効果の大きいものから、IaC（コードによる基盤の管理）やスクリプト、ジョブの仕組みに置き換えます。午後はコードのレビューや、置き換えた作業が正しく動くかの確認に時間を使います。

トイルとは、手作業でくり返され、自動化でき、続けても価値が積み上がらない運用作業のことです（Googleの『Site Reliability Engineering』による）。どの作業がトイルにあたるかを運用チームと合意することが、この案件の出発点になります。

1か月の流れ（例）

• 月初：手作業の一覧を更新し、今月置き換える作業を決める
• 毎週：置き換えの実装とレビュー、運用チームへの使い方の説明
• 月末：置き換えた作業にかかっていた時間の変化をまとめ、次の候補を並べ直す

成果物

手作業の一覧と優先度、IaCのコード、自動化のスクリプトやジョブ、運用手順書の改訂版などです。外から参画するSREにとっては、自分が抜けた後もチームが保守できる形で残すことが成果物の質を左右します。

オンコールを含む運用SREの仕事

1日・1か月の流れ（例）

当番の日は、アラートが鳴れば一次対応に入り、影響の範囲を確かめ、関係者に状況を伝え、復旧の手を打ちます。当番でない日は、過去の障害の振り返りで決まった再発防止策を実装したり、手順書を直したりします。

1か月の単位では、障害の振り返り会を運営し、原因と対策を文書に残します。再発防止策が実際に入ったかを追いかけるのも大切な仕事です。オンコールの当番表や、時間外に対応したときの扱いは案件ごとに違います。リモートで当番に入るときの注意はSREのリモート案件の記事で解説しています。

成果物

障害の記録、振り返りの文書（ポストモーテム）、再発防止策の実装、手順書（ランブック）、当番の引き継ぎの記録などです。

基盤の移行・刷新の案件の仕事

1日・1か月の流れ（例）

オンプレミスからクラウドへ、仮想マシンからコンテナ基盤へなど、基盤を移す案件です。前半は、各サービスの依存関係と、移行中も守るべき信頼性の水準を整理し、切り替えの手順と戻す手順を設計します。後半は、サービスごとの切り替えに立ち会い、移行後のしばらくは指標を通常より細かく見て安定させます。

移行の山場では、夜間や休日に切り替え作業が入ることがあります。Kubernetesを中心にした基盤の仕事はKubernetesエンジニアの仕事内容、クラウドの構築が中心の仕事はAWSエンジニアの仕事内容もあわせてご覧ください。

成果物

移行計画、依存関係の一覧、切り替えと切り戻しの手順書、移行後の監視とSLOの設定、移行の振り返りなどです。

どの案件にも共通する仕事

種類が違っても、次の仕事はほぼすべてのSRE案件にあります。

1. 数字で話す：障害の件数や復旧までの時間、SLOの達成状況など、合意のもとになる数字をそろえる
2. 開発チームと優先度を決める：信頼性の改善と機能の開発のどちらを先にするかを、数字をもとに話し合う
3. 振り返りを残す：責める場ではなく仕組みを直す場として運営し、決まった対策を追いかける
4. 仕組みを渡す：手順書やコードを、ほかの人が引き継げる形で残す

フリーランスならではの仕事として、自分の稼働の記録もあります。オンコールの待機や時間外の対応がある案件では、通常の稼働とは分けて記録しておくと、精算のときに食い違いが起きにくくなります。精算の仕組みは精算幅の記事をご覧ください。

関わる相手と、その相手に出すもの

働く場所については、仕組みづくりや振り返りはリモートで進めやすい一方、移行の切り替えやデータセンターが関わる作業では出社や現地作業が入ることがあります。

よくある質問

フリーランスのSREは、毎日障害対応をしているのですか？

案件によります。オンコールを含む運用SREの案件では障害対応の比重が高くなりますが、SLOの整備やトイルの削減が中心の案件では、障害対応は当番の日や大きな障害のときに限られることもあります。参画前に、当番の有無と頻度を確かめておきましょう。

SREはどのくらいコードを書きますか？

自動化のスクリプト、IaC、監視の設定、ときにはアプリケーションの修正まで、コードを書く場面は多くあります。どの言語やツールで書くかは案件ごとに違うため、SREのスキルの記事を参考に、得意な範囲を整理しておくと案件を選びやすくなります。

参画して最初の1か月は何をすることが多いですか？

構成と監視の現状の把握、過去の障害の記録の読み込み、関係者と役割の確認から始めるのが一般的です。初月の進め方はSREの参画初月にやることで詳しく解説します。