infrastructure

核心用法

Infrastructure 是一个纯文档型的架构指导 Skill，专注于云基础设施的设计与编排——即如何将服务器、网络、服务等组件有机整合。它不涉及具体组件的配置细节（如 Nginx 调优、Dockerfile 编写），而是提供高层次的决策框架：何时扩展服务器、如何规划多服务通信、怎样选择云服务商等。文档采用模块化结构，主入口 SKILL.md 界定范围，providers.md、patterns.md、backups.md 等子文档深入特定主题。

用户可通过决策矩阵快速判断问题归属：涉及架构结构、跨服务连接、成本分析时启用本 Skill；具体技术实现则路由至 server、docker、ci-cd 等专项 Skill。文档还按用户规模（MVP <1K / Growth 1K-50K / Scale 50K+）给出渐进式架构演进建议，并对比 Hetzner、AWS、DigitalOcean 等主流云商的 CLI 命令与功能差异。

显著优点

决策框架清晰：通过「问题-技能」对照表和阶段化架构模式，大幅降低技术选型的心智负担，避免过度设计或架构债务。

云商中立性：不绑定单一供应商，提供多平台命令速查与成本对比，便于团队根据预算和合规需求灵活迁移。

安全实践内建：网络章节强调默认拒绝防火墙策略，备份策略区分数据类型与频率，成本优化提醒关注隐性流量费用，体现生产级运维意识。

零依赖零权限：纯 Markdown 文档，无需安装、无需 API 密钥、不触发任何系统调用，可在隔离环境中安全查阅。

潜在缺点与局限性

命令示例需人工验证：文档中的 CLI 命令（如 hcloud server create、、aws ec2 run-instances`）仅为参考模板，实际执行前必须核对参数、权限及版本兼容性，存在误操作风险。

动态信息滞后：云服务商定价、功能迭代频繁，文档中的成本优化建议（如预留实例折扣比例）可能随时间失效，需结合官方文档交叉验证。

深度不足：作为「编排层」指南，对具体技术栈（如 Kubernetes 网络策略、Terraform 状态管理）仅点到为止，复杂场景仍需专项知识补充。

社区维护属性：T2 来源意味着更新节奏依赖志愿者贡献，关键安全公告（如新型攻击向量）可能响应不及官方文档及时。

适合的目标群体

• 技术负责人/架构师：规划新项目基础设施或评估现有架构扩展路径
• DevOps 工程师：制定多云策略、备份方案及成本优化路线图
• 初创团队：在资源受限条件下选择性价比最高的 MVP 架构
• 云迁移项目组：对比不同云商功能差异，设计平滑迁移方案

使用风险

性能风险：无（纯文档，无运行时开销）

依赖风险：无（零第三方依赖）

操作风险：中等——用户可能直接复制文档中的命令示例执行，若未根据实际环境调整（如区域、实例类型、防火墙规则），可能导致资源误创建、安全组开放过度或意外费用产生。建议在沙箱环境验证所有命令，并对生产操作启用二次确认机制。

信息时效风险：云商 CLI 语法、定价模型可能变更，长期项目应建立文档版本与官方变更日志的同步检查机制。