ストーリー
田
田中VPoE
IaCで基盤を管理できるようになった。最後のピースは「自己修復」と「セルフサービス」だ
あなた
自己修復というのは、障害が起きたら自動的に復旧するということですか？
あ
田
田中VPoE
そうだ。プラットフォームチーム5人で20チームを24時間365日サポートするのは不可能だ。基盤自身が問題を検知し、可能な限り自動で修復する仕組みが必要だ。そしてチームがプラットフォームチームに依頼しなくても自分で必要な操作ができる「セルフサービス」も不可欠だ
自己修復パターン
パターン1: ランナーの自動復旧
| 障害 | 検知方法 | 自動修復 |
|---|---|---|
| ランナーPodのクラッシュ | Kubernetes Liveness Probe | Pod自動再起動 |
| ランナーの応答なし | Health Check タイムアウト | Pod自動置換 |
| ノードの障害 | Node Not Ready | Pod再スケジュール |
| キュー滞留 | メトリクス閾値 | 追加ランナー自動起動 |
パターン2: キャッシュの自動再構築
ビルドキャッシュの破損や期限切れを自動的に検知し、再構築します。
| トリガー | アクション |
|---|---|
| キャッシュヒット率が50%以下に低下 | 共通依存のキャッシュを自動ウォームアップ |
| ビルド時間がp95で2倍以上に劣化 | キャッシュの自動パージと再構築 |
パターン3: 設定ドリフトの自動修正
IaCで定義された状態と実際の状態の差分（ドリフト）を検知し、自動修正します。
# 設定ドリフト検知ワークフロー
name: Configuration Drift Check
on:
schedule:
- cron: "0 */6 * * *" # 6時間ごと
jobs:
drift-check:
runs-on: ubuntu-latest
steps:
- name: Terraform Plan
run: terraform plan -detailed-exitcode
# exit code 2 = 差分あり
- name: Auto Correct (if drift detected)
if: steps.plan.outcome == 'failure'
run: |
# 軽微なドリフト: 自動修正
# 重大なドリフト: アラート発報
terraform apply -auto-approveセルフサービスポータル
チームが自分でできること
プラットフォームチームに依頼せずに、チームが自律的に実行できる操作を提供します。
| 操作 | セルフサービス方法 | 承認 |
|---|---|---|
| 新プロジェクト作成 | テンプレートリポジトリからの作成 | 自動（テンプレート選択のみ） |
| 環境変数の追加 | GitHub Settings UI | チームリード承認 |
| デプロイの実行 | ワークフローの手動トリガー | 環境に応じた承認 |
| ランナーラベルの追加 | PRで設定ファイル変更 | プラットフォームチーム承認 |
| ダッシュボードの閲覧 | Grafanaダッシュボード | 認証のみ |
セルフサービスの段階
Level 1: 情報の自己取得
→ ダッシュボード、ドキュメント、FAQ
Level 2: 標準操作の自己実行
→ プロジェクト作成、デプロイ、環境変数
Level 3: カスタマイズの自己実行
→ パイプラインのカスタマイズ、追加ツール導入まとめ
| ポイント | 内容 |
|---|---|
| 自己修復 | ランナー復旧、キャッシュ再構築、ドリフト修正を自動化 |
| セルフサービス | チームが自律的に操作できるポータルを提供 |
| 目的 | 5人のプラットフォームチームで20チームを持続的にサポート |
チェックリスト
- 自己修復の3パターンを理解した
- セルフサービスの段階を理解した
- プラットフォームチームの負荷軽減の考え方を理解した
次のステップへ
次は演習です。ここまで学んだ自動化戦略、IaC、自己修復、セルフサービスを統合して、運用自動化を設計してみましょう。
推定読了時間: 15分