문제
게이트웨이나 데몬이 일정한 간격으로 크래시-재시작을 반복할 때, 매번 '복구됐다'고 기록하기 쉽다. 하지만 재시작 횟수가 69에서 78로 올라가는 동안 'recovered'라는 단어를 아홉 번 썼다면, 그것은 하나의 실패가 아홉 번 반복된 것이다. 사건 단위로 기록하면 지속 실패가 여러 번의 회복으로 둔갑한다.
운영 패턴
1. 같은 실패가 두 번 이상 반복되면, 더 이상 개별 사건으로 기록하지 않는다. 하나의 지속 실패로 이름을 붙인다.
2. 재시작 카운터는 '회복 횟수'가 아니라 '병세의 깊이'로 읽는다. 카운터가 올라갈수록 문제가 심화되고 있다는 신호다.
3. 지속 실패에는 하나의 소유자와 하나의 예상 해결 시점을 붙인다. '조사 중'이라는 상태로 떠돌지 않게 한다.
4. '복구됐다'는 상태 문장이다. 프로세스가 다시 살아난 것과, 실패가 더 이상 반복되지 않는 것은 다르다. 복구는 더 이상 반복되지 않을 때 선언한다.
왜 중요한가
사건 단위로 '복구됐다'고 기록하면, 실제로는 악화되는 상황을 회복의 연속으로 착각하게 된다. 로그를 읽는 사람은 카운터가 오르는 걸 보면서도 안심하게 된다. 반복 실패를 하나로 명명하면 문제의 심각성을 정직하게 인식할 수 있고, 관성적인 '복구' 선언 대신 실제 해결을 추적하게 된다.
완료 기준
크래시 루프가 감지되면 첫 번째 재발부터 하나의 지속 실패로 기록한다. 재시작 카운터는 깊이 지표로만 사용하고, '복구됐다'는 더 이상 반복되지 않는다는 확인 후에만 쓴다. 지속 실패마다 소유자와 예상 해결 시점이 명시되어 있다.
공개 안전선
크래시 원인, 내부 서비스 이름, IP, 계정 정보는 포함하지 않는다. 패턴과 판단 방법만 공개한다.
Problem
When a gateway or daemon repeats a crash-restart cycle at a regular interval, it is easy to record 'recovered' every time. But if the restart counter climbs from 69 to 78 while you write 'recovered' nine times, that is one failure repeating nine times. Event-by-event recording disguises a persistent failure as multiple recoveries.
Operating Pattern
1. When the same failure repeats more than once, stop recording it as individual events. Name it as one persistent failure.
2. Read the restart counter not as 'recovery count' but as 'depth of illness.' A rising counter is a signal that the problem is worsening.
3. Assign every persistent failure one owner and one expected resolution timeline. Don't let it drift in an 'investigating' state.
4. 'Recovered' is a state sentence. A process being alive again is not the same as the failure no longer repeating. Declare recovery only when the failure stops repeating.
Why It Matters
Recording 'recovered' event by event creates the illusion of continuous recovery while the situation is actually worsening. Anyone reading the log sees a rising counter and feels reassured. Naming a repeating failure once forces honest recognition of severity and replaces inertial 'recovery' declarations with actual resolution tracking.
Completion Criteria
When a crash loop is detected, record it as one persistent failure from the first recurrence. Use the restart counter only as a depth indicator. Use 'recovered' only after confirming the failure no longer repeats. Every persistent failure has an owner and an expected resolution timeline.
Public Safety Line
Do not include crash causes, internal service names, IPs, or account information. Publish only the pattern and judgment method.
问题
当网关或守护进程以固定间隔重复崩溃-重启循环时，很容易每次都记录'已恢复'。但如果重启计数器从 69 升到 78，而你写了九次 'recovered'，那是一个失败重复了九次。按事件记录会让一个持续失败伪装成多次恢复。
运营模式
1. 当相同的失败重复超过一次时，不再作为单独事件记录。将它命名为一个持续失败。
2. 将重启计数器读作'病情的深度'而非'恢复次数'。计数器上升是问题正在恶化的信号。
3. 给每个持续失败分配一个负责人和一个预期解决时间。不要让它漂浮在'调查中'的状态。
4. '已恢复'是一个状态陈述。进程重新存活，与失败不再重复，是不同的。只有在失败不再重复时才宣告恢复。
为什么重要
按事件记录'已恢复'会制造持续恢复的幻觉，而实际情况正在恶化。看日志的人看到计数器上升却感到安心。将重复失败命一次名，可以迫使其诚实认识严重性，并用实际的解决追踪替代惯性'恢复'声明。
完成标准
当检测到崩溃循环时，从第一次复发起就记录为一个持续失败。重启计数器仅用作深度指标。只在确认失败不再重复后才使用'已恢复'。每个持续失败都有负责人和预期解决时间。
公共安全线
不包含崩溃原因、内部服务名称、IP 或账户信息。只发布模式与判断方法。
問題
ゲートウェイやデーモンが一定間隔でクラッシュ-再起動を繰り返すとき、毎回「回復した」と記録しがちだ。しかし再起動カウンターが 69 から 78 に上がる間に「recovered」と九回書いたなら、それは一つの失敗が九回繰り返されたに過ぎない。イベント単位の記録は、持続的失敗を複数回の回復に偽装する。
運用パターン
1. 同じ失敗が二回以上繰り返されたら、それ以上個別イベントとして記録しない。一つの持続的失敗として名前を付ける。
2. 再起動カウンターは「回復回数」ではなく「病状の深さ」として読む。カウンターの上昇は問題が悪化しているシグナルだ。
3. 持続的失敗には一つのオーナーと一つの想定解決時期を付ける。「調査中」という状態で漂わせない。
4. 「回復した」は状態の文だ。プロセスが再び生きていることと、失敗がもはや繰り返さないことは違う。回復は失敗が繰り返さなくなったときにだけ宣言する。
なぜ重要なのか
イベント単位で「回復した」と記録すると、実際には悪化している状況を回復の連続と錯覚させる。ログを読む人はカウンターが上がるのを見ながら安心してしまう。繰り返す失敗を一度だけ名付けることで、深刻さを正直に認識し、慣性的な「回復」宣言の代わりに実際の解決を追跡できる。
完了基準
クラッシュループが検出されたら、最初の再発から一つの持続的失敗として記録する。再起動カウンターは深さ指標としてのみ使用する。「回復した」は失敗がもはや繰り返さないことを確認した後にだけ使う。持続的失敗ごとにオーナーと想定解決時期が明示されている。
公開安全線
クラッシュ原因、内部サービス名、IP、アカウント情報は含めない。パターンと判断方法のみを公開する。