自動治癒および自己回復システム

1）自動治癒は何であり、なぜそれが必要であるか

自動治癒は、人の介入なしに障害が発生した場合のサービスの自動安定化であり、根本原因検索（RCA）に対する症状回復優先度（SLO）があります。
目標：MTTRを削減し、欠陥のある予算を保護し、運用コストとヒューマンエラーを削減します。

• 検出（メトリック/ログ/合成/イベント）。
• ソリューション（ルール/ポリシー/MLヒューリスティクス）。
• アクション（restart/scale/shedding/ficheflag/rollback/feilover）。
• 検証（指定されたウィンドウのSLO緑色）。
• 劣化を元に戻す。

2）自動治癒のメカニズムの地図

アプリケーションレベル：idempotency、 timeouts、 retry+backoff+jitter、 circuit breaker、 bulkhead、 cache degradation （graceful）。
Kubernetes： liveness/readiness/startupプローブ、restartPolicy、 PDB、 HPA/VPA、 Descheduler、 Pod/Node自動修復。
ネットワーク/エッジ：レート制限、テナントクォータあたり、接続排水、フェイルオープン/クローズ、WAFルール。
キュー/ストリーミング：消費者自動スケール、ラグベースのバックプレッシャー、DLQ/駐車場。
ストレージ/DB：レプリカフェイルオーバー、自動修復（再構築）、スロットルオートバキューム、接続プールのリバランス。
CI/CD：カナリア計算、プログレッシブ配信、自動ロールバック。
イベントオーケストレーション：コントローラ/オペレータ、ワークフローエンジン（Argo、 Airflow）、リトリーポリシー。
ウォッチドッグ/ハートビート：バックグラウンドジョブのためのデッドマンのスイッチ。

3）安全な自己回復の設計原則

1.SLO駆動：すべての自動アクションは、ユーザーエクスペリエンスに関連する症状によってトリガーされます。
2.Canary-first：最初はローカル/ポイントワイズ、次にグローバル。
3.一方通行のドアのガードレール：タイマー/条件によるロールバック、危険な操作のための「二重キー」。
4.Idempotency：各アクション（再起動、移行、回転）は安全に繰り返します。
5.Observability-by-design：アクションラベル、トレースとの相関、who/what/when/why log。
6.最小権限：オートメーションには最小限の権利（RBAC、スコープされた秘密）があります。
7.費用対効果：「高価な」アクション（スケーリング、出力、スナップショット）の制限。

4）検出： 自動治癒を始める信号

5xx％、 p95/p99レイテンシ、Kafkaラグ、DBロック/ラグ、ノード圧力。
合成：アップタイム・フォール/パス回帰（ログイン/デポジット）。
ログ：新しいエラー署名、例外レート。
K8s： CrashLoopBackOff、 NodeNotReady、 FailedScheduling。
ハートビート：仕事の沈黙>N分。

promql
API error regression sum (rate (http_requests_total{status=~"5"..}[5m]) )/sum (rate (http_requests_total[5m]))> 0. 01

Kafka: lag> threshold max by (topic, group) (kafka_consumergroup_lag)> 10000

K8s: pod в CrashLoopBackOff increase(kube_pod_container_status_restarts_total[5m]) > 3

5）自動復元アクション（プレイブック）

5.1アプリケーション/ネットワーク

バックエンド異常→高速フェイルファスト+キャッシュ/スタブ応答によるサーキットブレーカON。
限界と重複除外を伴う再試行+バックオフ+ジッタ。
Rate limit/shed-load：過負荷下-クリティカルパスの優先順位付け。

5.2 Kubernetes

コンテナ（liveness）を再起動し、健全でないノード上の囲炉裏を削除します。
HPA/VPA： RPS/CPU/レイテンシ/遅延による自動スケール。VPA-推奨事項または時間外のみ適用されます。
ノードの自動修復：永続的な問題（テイン）のためのcordon+drain。
AZファイルに対する保護のためのアフィニティ/トポロジースプレッド。

5.3キュー/ストリーミング

自動スケールの消費者の遅延；スループット生産者の一時的な削減。
有毒なメッセージのためのDLQ；アーカイブから再生します。

5.4 DB/キャッシュ

状態/構成の検証によるレプリカへのフェイルオーバー。
接続リークのための接続プールのリセット。
ホットスタンバイは、クライアントの自動再設定で促進します。

5.5 CI/CD

カナリアトラフィックで5xx/p95の成長と自動ロールバック。
フィーチャーフラグ：グローバルロールバックの代わりに問題のある機能の自動OFF。

6）進歩的な配達および自動ロールバック

例（Argo Rolloutsカナリア戦略）

yaml strategy:
canary:
canaryService: api-canary stableService: api-stable steps:
- setWeight: 10
- pause: {duration: 5m}
- analysis:
templates:
- templateName: api-slo-check
- setWeight: 25
- pause: {duration: 10m}
- analysis:
templates:
- templateName: api-slo-check

テンプレート解析が「失敗」（エラー/レイテンシーを超えた）を返すと、ロールアウトは自動的にロールバックされます。

7）自己回復用具として特徴の旗

問題のある機能（サーバーサイド）のキルスイッチ。
ターゲティング：セグメント/リージョンで機能を無効にします。
自動ルール：Y分のフィーチャー>Xの5xx％がOFFで、チケットがバックログにある場合。
検証：予算を持つSLOパネル機能。

8）積み過ぎ： 死に自分自身を「扱う」方法

Shed-load：重要でない要求（関税、重報告）のQoSを拒否/下げます。
トークンバケット/リーキーバケットおよびテナント/キークォータ。
アダプティブコンカレンシー（プロキシ/SDKレベル）-レイテンシが増加した場合のコンカレンシーを削減します。
隔壁：隔離の糸/接続プール。

9）一貫性と偶像性

Idempotentキー（request_id）→反復に対する保護。
恐ろしい取引（支払い、書き込み）-2段階のプロセス、確認/補償（佐賀）。
Outbox/受信トレイは、正確に1回の重複排除ストレージ。

10）安全性とコンプライアンス

自動化のための最小RBAC（必要なリソースのみ）。
すべてのアクションの監査：who/when/what signal/what effect。
自動アクションを無効にするための手動オーバーライドと「赤いボタン」。
法的インシデントのアーティファクトとオートメーションログを保持します。
秘密-秘密のマネージャーを介して、自己行動中にキーの回転。

11） FinOps： 「自己治癒」の価格"

スプラッシュで壊れて行かないように最大オートスケールの制限。
アクションメトリクスあたりのコスト：再起動1件、追加レプリカ1件、出力1TB。
集計：SLO分当たりのコスト、軽減されたインシデントあたりのコスト。
「ナイトモード」ポリシー：ビジネストラフィックが少ない場合、オートメーションの攻撃性が低下します。

12）オートメーションの可視性

グラフ上のラベル：'remediation_action="rollback"、' source="argo"、 'reason="slo_burn''。
個別のダッシュボード：自動操作の頻度、成功、回復時間中央値、ロールバック率。
効果→利点評価のためのSLO相関。

13）構成と例

13.1 K8s：プローブと再起動ポリシー

yaml livenessProbe:
httpGet: { path: /healthz, port: 8080 }
initialDelaySeconds: 20 periodSeconds: 10 timeoutSeconds: 2 readinessProbe:
httpGet: { path: /readyz, port: 8080 }
periodSeconds: 5 failureThreshold: 3 startupProbe:
httpGet: { path: /startupz, port: 8080 }
failureThreshold: 30 periodSeconds: 5

13.2アラート→自動操作（擬似）

yaml rule: api_5xx_rate_high action:
type: feature_flag target: "payments. new_flow"
set: false guardrails:
cooldown: 10m max_actions_per_hour: 2 rollback_if:
- condition: "5xx% not reduced within 5m"

13.3カフカラグオートスケール（カスタムメトリックによるHPA）

yaml metrics:
- type: Pods pods:
metric:
name: kafka_consumer_lag target:
type: AverageValue averageValue: "500"

14）自動治癒のテスト（混乱及びゲーム日）

カオスインジェクション：ネットワークの一時停止、Pod/Nodesの終了、データベース/キャッシュの劣化。
ゲームデー：タイムリミットとMTTRメトリクスによるシナリオトレーニング。
シャドウトラフィック：ユーザーに影響を与えることなくカナリアへのトラフィックのレンタル。
ドライランオートメーションモード（私たちは書いていますが、しないでください）。

15）「自動復旧準備」の基準"

• SLOは定義され、メトリックは安定しており、合成物質があります。
• サンプル/healthz 、/readyz 、/startupzは条件を正しく反映します。
• アイデンティティと二重保護（特に支払い）。
• フィーチャーフラグやカナリアディスプレイをご用意しております。
• ガードレール：クールダウン、レート制限アクション、高リスク操作のためのダブルキー。
• 自動化ダッシュボードと監査ログ。
• 手動で上書きし、詰め込むことの場合のrunbooksの計画。

16）フェーズ別の実装（4つの反復）

1.基本：SLOの定義、プローブの追加、再起動/メインアラートの追加。
2.ローカルアクション：phicheflag-kill-switch、 lag-scaling consumers、 auto-rollback canaries。
3.Infra-level：ノード修復、データベース/キャッシュのフェイルオーバー、ロードシェーディング。
4.最適化：ガードレール、FinOpsの限界、カオステスト、検出のためのMLヒューリスティクス。

17）頻繁なエラーとアンチパターン

症状の原因を治療する→長いMTTR。
カナリアステージのないグローバルアクション。
ロールバックや元に戻す条件はありません。
虚偽の健康チェック（中毒のための200）。
「Bloat」は、制限/コストしきい値のない自動スケールです。
バックオフと重複排除のないブラインドリトレイ嵐。

18） ミニFAQ

オートスコアリングにMLは必要ですか？
いいえ、そうではありません。SLO/メトリクスとガードレールのルールから始めます。MLは異常や述語に有用である。

なぜ再起動が常に役に立たないのですか？
ルートが依存している場合（データベース、キャッシュ、ネットワーク）、再起動は嵐を悪化させるだけです。ブレーカ/shedding/feiloverを必要とします。

どのように利点を証明するには？
予算の前後に誤ったMTTRと消費量を比較します。緩和メトリクスあたりのコストを追加します。

合計

自動治癒はシステムであり、「再起動の松葉杖」のセットではありません：SLO検出→安全ポイントアクション→検証→悪化した場合のロールバック。プローブ、カナリア計算、フィーチャーフラグ、スケーリング、シェーディング、フェイラバー、厳格なガードレールを組み合わせることで、MTTRを削減し、予算を誤った状態に保ち、コストを管理します。