目录不是登记那一刻坏的，是随时间腐坏的
一句话总结
目录崩溃不是第一次注册的时候，而是半年后。腐烂几乎总是以三种形式出现。缺失必填字段的实体、指代不存在的对象的引用，以及指代彼此的依赖关系。这三者都可以静态地找到，无需启动门户。
##为什么需要这个
当您第一次打开门户网站时，它通常是干净的，因为它是由人手输入的，而且输入的人还记得这个服务。问题在于接下来。
-
随着团队的合并
team-payments消失了，只剩下列出该团队为所有者的十二个实体。 -
服务已经转移到了其他系统。
spec.system是以前的名字。 -
删除了临时制作的数据库
dependsOn仍然有那个Resource。
这里重要的是Backstage不会将这些标记为错误。违反模式的实体会显示目录为错误，但指向不存在的对象的引用只是“关系未计算”。屏幕上只显示空格，没有红色字体。
而且目录死亡的途径总是一样的。参考断开，图形碎裂，画面空白，人们看不到，没有人修复。因为空白的画面看不出是障碍所以没有人举报。
怎么操作
###要诊断的有四种
**第一，缺少必填字段。**必填字段因kind而异。Component和API是spec.type，spec.lifecycle，spec.owner必须有所有，Resource是spec.type科spec.owner，System和Domain是spec.owner必须去。这里所有kind共同apiVersion，kind，metadata.name需要这个。“三个必填字段”如果全部背下来的话，kind变的时候会出错。
**第二，断开的拥有者。**这是最昂贵的缺陷。如果拥有者断开，故障呼叫、漏洞票据、费用归属、废弃决定都会失去方向。而且原因往往不是实体文件。组织数据同步停止了，导致Group本身没有进入目录。只要修复文件，下周就会再次发生同样的事情。
第三，断开的引用。spec.system，spec.domain，spec.dependsOn，spec.providesApis是对象。与所有者分开看的原因是对应不同。所有者是组织问题，其余的通常是名字换了或者还没有创建实体。
第四，依赖循环。A dependsOn B并且B dependsOn A处于状态。这样的话，影响分析也失去了意义。“如果把这个拿下来，什么会坏掉”的时候，答案会回到自己身上。原因通常是误解。A调用B，B认为也应该写A，但关系是以一方的声明为 katalogs计算双向。
比较之前将参考规范化
如果遗漏这个，检查器会报告检查器完好的参考为缺陷。text team-orders → group:default/team-orders group:team-orders → group:default/team-orders group:default/team-orders → group:default/team-orders 三指的是同一个东西。kind每个字段都有基本值，命名空间的基本值是 default是。如果直接比较字符串的话，三个表示方式都会变成完全不同的。经过规范化后再比较是这项工作的第一步。
有修复的顺序
-
**先组织数据。**填写没有的Group和User。
-
组装后。 创建或使用没有的System和Domain，或使用移动到的地方的名字进行引用。
-
**个别实体最后。**填写缺失的必填字段，整理剩余的参考。
如果把顺序倒过来，就会两次纠正相同的错误。如果依次纠正每个实体的所有者，然后创建Group，刚刚纠正的值就会再次变得尴尬。
还有必须遵守的一件事。**删除有缺陷的实体，使列表变得干净，并不是修复了什么。**目录的目的是无遗漏地展示我们拥有的东西。隐藏的服务也会在凌晨三点被破坏。
###用大门堵住catalog-info.yaml因为住在这个代码存储库里，所以可以在PR中进行检查。在文件合并之前阻止它，会大大降低目录腐烂的速度。门对干净的输入必须输出0，对有缺陷的输入必须输出非0的值。
在现场相遇的样子
这个存储库里有关于门的令人痛心的记录。“文件中没有明文密码”的检查项目长期以来一直处于绿色状态，但实际上只看到了一种形状。在此期间，两个文件的多个工具管理员密码都是明文的，而且三种形状都不一样，所以没有被任何模式发现。
教训不是正规式。**如果要做门，一定要实际放进去想阻止的东西，确认红灯是否亮。**只确认通过就行，那个门就什么都没有地运行几个月。目录lint也是一样的。只要在干净的目录中只看到0，就满足了，就会发布即使有缺陷也能输出0的门。
同样的感觉接着是这个集群重复的教训“状态是Ready，实际运行是不同的命题”，目录屏幕看起来正常与其中内容实际连接的关系是另一回事。后者是看不见的，必须通过计算来确定。
##下次实习要做的事情/root/cba-audit/incoming/将接收的八个目录原封不动地再现。其中故意包含四种错误类型。然后分别诊断缺失必填字段、断开的拥有者、断开的引用、依赖循环，并将其列出为列表，制作修改后的副本，使所有诊断均为0。最后编写相同的检查的lint脚本，在干净的输入和有错误的输入两端进行测试，并将审计结果记录到群集中。