문제
운영 중에 "이 경로/디렉터리가 없으니 이게 문제"라는 진단이 들어오면, 그 진단에 딸려오는 제안된 수정까지 덩달아 타당하다고 받아들이기 쉽다. 하지만 없는 경로가 있어야 할 경로인지, 애초에 그 시스템에는 그 경로가 존재하지 않는 게 정상인지부터 확인하지 않으면, 존재하지도 않던 문제를 고치겠다고 실제 작동 중인 배치 구조를 건드리게 된다.
운영 패턴
1. 제안된 수정이 특정 디렉터리나 경로를 전제로 한다면, 그 수정을 평가하기 전에 같은 종류의 시스템이 실제로 정상 작동 중인 다른 곳에서 그 경로가 실제로 쓰이는지부터 확인한다.
2. "그 경로가 없다"는 관찰은 그 자체로 증거가 아니다. 애초에 그 배치 구조에 그런 경로가 없는 게 설계라면, 부재는 문제의 증상이 아니라 정상 상태다.
3. 정상 작동 중인 인스턴스를 실측해서 실제 노출 방식(예: 심볼릭 링크, 별도 디렉터리, 다른 이름의 실행 파일)을 먼저 파악한다.
4. 실측 결과가 제안된 수정과 다르면, 증거와 함께 판정을 뒤집고 왜 뒤집혔는지 기록한다. 원래 제안을 지운다고 되는 게 아니라, 판정이 바뀐 이유를 남겨야 다음 사람이 같은 실수를 반복하지 않는다.
5. 실제 배치 구조를 바꿀 권한이 없는 영역이면, 억지로 적용하지 말고 올바른 수정 내용만 명시한 채 열어 둔다.
왜 중요한가
그럴듯한 증상에 그럴듯한 수정을 그냥 붙이면, 그 수정은 적용되고 아무것도 고치지 못한 채 다음 사람이 "왜 아직도 안 고쳐졌지"부터 다시 조사하게 만든다. 게다가 그 사이엔 "처리됨"으로 보이는 항목 뒤에 진짜 원인이 계속 방치된다.
완료 기준
제안된 수정을 적용하기 전에 정상 작동 중인 배치 구조를 실측했고, 그 결과가 제안과 다르면 판정을 뒤집은 근거를 기록했으며, 권한 밖의 시스템은 실제로 건드리지 않고 올바른 수정 내용만 남겼다면 완료다.
Problem
When a diagnosis arrives saying "this path/directory is missing, that's the problem," it's easy to accept the attached proposed fix as valid along with it. But without first checking whether that path was ever supposed to exist on this kind of system, you risk touching a real, working deployment layout to fix a problem that was never there.
Operating pattern
1. If a proposed fix assumes a specific directory or path, measure whether that path is actually used on another instance of the same kind of system that is genuinely working, before evaluating the fix.
2. "That path doesn't exist" is not evidence by itself. If the deployment layout was never designed to have that path, its absence is the normal state, not a symptom.
3. Measure a working instance directly to learn how it's actually exposed (a symlink, a separate directory, a differently named executable).
4. If the measurement contradicts the proposed fix, reverse the verdict with the evidence attached, and record why it reversed. Deleting the original proposal isn't enough — recording the reason for the reversal is what keeps the next person from repeating the same mistake.
5. If you don't have authority to change the actual deployment layout, don't force the fix through. Leave it open with the correct remedy stated explicitly instead.
Why it matters
Attaching a plausible fix to a plausible symptom without checking gets the fix applied, fixes nothing, and leaves the next person re-investigating "why isn't this fixed yet." Meanwhile the real cause sits untouched behind an item that looks "handled."
Completion bar
Done means the working deployment layout was measured before the proposed fix was applied, any reversal of the verdict was recorded with its evidence, and no system outside your authority was actually touched — only the correct remedy was stated.
问题
当收到"这个路径/目录不存在，这就是问题所在"的诊断时，很容易连带接受附带的修复方案。但如果不先确认这个路径本来是否应该存在于这类系统上，就可能为了修复一个根本不存在的问题，去动一个正常运行的真实部署结构。
运行模式
1. 如果提议的修复方案假定某个特定目录或路径存在，在评估该修复之前，先在同类系统中真正正常运行的另一个实例上实测这个路径是否真的被使用。
2. "那个路径不存在"本身并不是证据。如果部署结构从设计上就不该有这个路径，它的缺失就是正常状态，而不是问题的症状。
3. 直接实测一个正常运行的实例，弄清楚它实际的暴露方式（符号链接、独立目录，或名字不同的可执行文件）。
4. 如果实测结果与提议的修复矛盾，就附上证据推翻原判断，并记录推翻的原因。删掉原提议是不够的，记录判断改变的理由才能防止下一个人重蹈覆辙。
5. 如果你没有权限改动实际的部署结构，不要强行应用修复，而是明确写出正确的修复内容并保持开放。
为什么重要
不加核实就把一个看似合理的修复贴到一个看似合理的症状上，结果是修复被应用了却什么也没解决，下一个人还要重新调查"为什么还没修好"。与此同时，真正的原因一直被藏在一个看起来"已处理"的条目背后。
完成标准
在应用提议的修复之前先实测了正常运行的部署结构，如果推翻了原判断就记录了推翻的依据，并且没有实际改动权限之外的系统——只是明确写出了正确的修复内容，这样才算完成。
問題
「このパス／ディレクトリが存在しない、それが問題だ」という診断が来ると、それに付随する提案された修正までそのまま妥当だと受け入れてしまいがちだ。しかし、その種のシステムにそのパスが本来存在すべきものかどうかを先に確認しなければ、そもそも存在しなかった問題を直すために、実際に稼働中の配置構造に手を出してしまうことになる。
運用パターン
1. 提案された修正が特定のディレクトリやパスを前提にしているなら、その修正を評価する前に、同種のシステムで実際に正常稼働している別のインスタンスでそのパスが本当に使われているかを実測する。
2. 「そのパスが存在しない」という観察自体は証拠にならない。その配置構造が最初からそのパスを持たない設計であれば、不在は問題の症状ではなく正常な状態である。
3. 正常稼働中のインスタンスを直接実測し、実際の露出方法（シンボリックリンク、別ディレクトリ、名前の異なる実行ファイルなど）を先に把握する。
4. 実測結果が提案された修正と食い違うなら、証拠とともに判定を覆し、なぜ覆ったのかを記録する。元の提案を消すだけでは不十分で、判定が変わった理由を残すことで次の担当者が同じ誤りを繰り返さずに済む。
5. 実際の配置構造を変更する権限がない領域であれば、無理に適用せず、正しい修正内容だけを明示して未解決のまま残す。
なぜ重要か
もっともらしい症状にもっともらしい修正を確認せずに貼り付けると、その修正は適用されても何も直らず、次の担当者は「なぜまだ直っていないのか」から調査をやり直すことになる。その間、本当の原因は「対応済み」に見える項目の裏でずっと放置される。
完了基準
提案された修正を適用する前に正常稼働中の配置構造を実測し、判定を覆した場合はその根拠を記録し、権限外のシステムには実際に手を出さず正しい修正内容だけを明示していれば完了である。