# Self-healingの安全な範囲を定める

Taiga Learning・ワークシート
https://taiga.training/ja/lessons/self-healing/

架空の情報か、承認された情報を使ってください。このワークシートにシークレットを入れないでください。

## 学習目標
- Self-healingと、ソフトウェアの恒久的な修正を区別する。
- 範囲を限定した復旧ポリシーと、独立した成功確認を定義する。
- 自動化を停止してエスカレーションすべき状況を見分ける。

## 演習
このレッスンの架空のエクスポート用ワーカーについて、復旧ポリシーを設計してください。トリガー、除外条件、許可する操作、再試行の上限、待機期間、成功確認、エスカレーション先の責任者を指定します。データベース停止と、原因不明のデータ完全性の障害に対してテストしてください。

## あなたの回答
- シナリオと範囲：
- 前提条件と未解決の問い：
- 回答案または判断案と、その理由：

## 回答を検証する
| 主張または基準 | 証拠またはテスト | 結果または不足 | 担当者 |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

## 次の対応
- 対応、担当者、日付：
- この回答をいつ見直しますか？

## 覚えておく原則
Self-healingには、定義された障害、承認された操作、測定できる結果、停止条件が必要です。復旧しないまま操作を繰り返すことも、別の障害です。

## 出典
- [Kubernetes: Self-Healing](https://kubernetes.io/docs/concepts/architecture/self-healing/)
- [AWS Builders’ Library: Timeouts, retries, and backoff with jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
- [Google SRE: Automation at Google](https://sre.google/sre-book/automation-at-google/)

このワークシートは、学習を支援します。完了しても、それだけで本番の変更が許可されるわけではありません。