mcpField
A
architecture-review

architecture-review

github.com/ionfury云与 DevOps2545 次安装今天更新
代码仓库

关于 architecture-review

用于评估技术选型和架构变更的评审框架，面向维护家庭实验环境技术栈的团队。它结合原则契合度、现有技术栈、运维成本、复杂度、替代方案和故障模式进行检查。

主要功能

  1. 01核心原则契合度评估
  2. 02技术栈及 GitOps 适配检查
  3. 03运维成本与复杂度评估
  4. 04替代方案和故障模式审查

适用场景

  1. 01评估引入新技术是否适合现有环境
  2. 02检查架构变更的监控与恢复方案

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/ionfury/homelab --skill architecture-review

安装后在 Claude Code 中输入/architecture-review确认已加载。

附带文件references/technology-decisions.mdtests.yaml

详细介绍

架构评估框架

当前技术栈

当前技术栈：见 references/technology-decisions.md

评估标准

在评估任何提议新增的技术或架构变更时，请按以下标准打分：

1. 原则一致性

对每项核心原则打分（强/弱/中性）：

  • 企业级在家：它是否体现生产级模式？
  • 一切皆代码：它能否完全以 git 表示？
  • 自动化是关键：它会减少还是增加手动劳作？
  • 学习优先：它是否教会有价值的企业技能？
  • DRY 与代码复用：它是利用现有模式，还是制造重复？
2. 栈契合度
  • 这是否与现有工具重叠？（例如，在已有 Dragonfly 时再添加 Redis）
  • 它能否与 GitOps 工作流集成？（必须可由 Flux 部署）
  • 它能否在裸金属上运行？（不能是仅限云端的服务）
  • 它是否支持多集群模型？（dev → integration → live）
3. 运维成本
  • 它如何被监控？（必须与 kube-prometheus-stack 集成）
  • 它如何备份？（必须有恢复方案）
  • 它如何处理升级？（必须是声明式的，最好通过 Renovate）
  • 它的故障影响范围是什么？（隔离 > 集群范围）
4. 复杂度预算
  • 这种复杂度是否由学习价值所证明合理？
  • 更简单的现有工具能否解决同一问题？
  • 12 个月内的维护负担是什么？
5. 替代方案分析
  • 现有栈组件中哪些可以解决这个问题？（始终先检查）
  • 生态系统中排名前 2-3 的替代方案是什么？
  • 其他生产级 homelab 使用什么？（kubesearch 研究）
6. 故障模式
  • 当此组件不可用时会发生什么？
  • 它如何与网络策略交互？（默认拒绝）
  • 恢复流程是什么？（必须记录在 runbook 中）
  • 它能否自愈？（强烈偏好自愈）

需要挑战的反模式

反模式为什么不对正确做法
不加监控就"直接跑个容器"故障不可见，无告警必须配备 ServiceMonitor + PrometheusRule
现有工具已足够时仍添加新工具栈膨胀，维护负担先评估现有栈
"暂时"跳过可观测性永远不会偿还的技术债监控是第 1 天的事，不是第 2 天
仅限云端的服务供应商锁定，无法在裸金属上运行优先选择可自托管替代方案
无 HA 方案的单实例单点故障至少记录恢复流程

评论

支持 Markdown