Infrastructure Inventory

• Domain: example.dpdns.org
• IPv4: 192.0.2.10
• IPv6: 2001:db8::10
• Nameserver: ns1.dns-service.example
• Environment: practice only

把责任矩阵与这份清单对应起来：每一行的 Owner 都应该能在这份私有笔记中找到对应的真实联系人，且笔记本身**不进入公开目录**（[如何使用本书](https://gitcode.com/GitHub_Trending/us/US.KG/blob/9c7c54110705760267b07b6e6a6d406d1172a1bf/documents/tutorial/foundations/0.1-how-to-use-this-book.md?utm_source=gitcode_repo_files) 明确要求笔记中不放密码、API 密钥、恢复码与证书私钥）。

## 第五步：定义可用性需求

原文要求问清六个问题：

- 站点是信息型的（informational）还是运营关键的（operationally critical）？
- 可接受的宕机时长是多少？
- 内容必须在多快时间内恢复？
- 邮件是否绑定在同一个域名上？
- 站点是否收集个人数据？
- 是否存在法律或合同要求？

这些答案直接决定后面的技术投入，原文的归纳是：它们影响服务器冗余、监控、备份频率与事故响应方式。对应到本仓库的后续章节：

- 若站点只是信息型的个人/小组织页面，[备份与恢复](https://gitcode.com/GitHub_Trending/us/US.KG/blob/9c7c54110705760267b07b6e6a6d406d1172a1bf/documents/tutorial/operations/5.7-backups-and-restoration.md?utm_source=gitcode_repo_files) 中“定期快照 + 可读取性验证”的最低强度即可满足；
- 若邮件与站点共用域名（MX 记录同域发布），则 DNS 变更的影响面扩大，任何一次记录误操作都可能同时打挂网站与邮件，变更必须“一次只改一条”并直接验证；
- 若收集个人数据或存在合同要求，则需要关注 [安全与策略章节](https://gitcode.com/GitHub_Trending/us/US.KG/blob/9c7c54110705760267b07b6e6a6d406d1172a1bf/documents/tutorial/operations/5.5-security.md?utm_source=gitcode_repo_files) 与 [可接受使用政策](https://gitcode.com/GitHub_Trending/us/US.KG/blob/9c7c54110705760267b07b6e6a6d406d1172a1bf/documents/tutorial/operations/5.6-acceptable-use.md?utm_source=gitcode_repo_files) 中的约束。

一个实用的判断口诀：**先按最低配置回答“多久不能恢复”，再决定监控和备份的频率**。免费域名项目的多数失败不是性能问题，而是“到期未续”和“无人响应安全通知”这类生命周期问题——所以可用性规划的重心应放在生命周期监控上。

## 第六步：画出初始架构

原文给出的第一版架构刻意画得极简：

```text
Visitor
  |
  v
Recursive DNS
  |
  v
Authoritative DNS
  |
  v
Web server on ports 80 and 443
  |
  v
Static website files

每个组件都有明确的后续出处：

• 递归解析器（Recursive DNS）：访客设备上配置的 DNS，负责替客户端完成逐级查询并缓存答案。域名与 DNS 基础 特别澄清：笔记本/路由器上的那个 DNS 地址是递归解析器，不是注册时填写的权威 NS 值——这是新手最常见的概念混淆。
• 权威 DNS（Authoritative DNS）：发布该域名区域记录的外部权威服务。平台章节 中的流程是在外部 DNS 服务商建好 zone、拿到完整的一组 NS 主机名，再提交给注册层做委派。
• 80/443 端口的 Web 服务器：对应 服务器准备 中的防火墙放行与 服务器加固 的基线。
• 静态网站文件：第一版没有数据库层，服务器只是“存文件 + 发文件”。

原文的收尾原则值得原样保留：

Keep the first architecture understandable. Every added component creates another configuration, credential, failure mode, and renewal lifecycle. （保持第一版架构可被理解。每加一个组件，就多出一份配置、一份凭据、一种故障模式、一个续费生命周期。）

这句话是整份规划的架构裁决标准：任何想加入第一版的组件（CDN、数据库、对象存储……），都要先回答它新增的配置、凭据、故障模式与生命周期各是什么。

第七步：写下完成定义（Definition of Done）

原文列出的九条验收标准，是整个规划中最接近“可执行检查单”的部分：

1. 域名已注册且处于 active 状态；
2. 域名服务器委派（nameserver delegation）正确；
3. 根域名与 www 的 DNS 记录都按规划解析；
4. HTTP 重定向到唯一的规范 HTTPS URL；
5. 证书对每个公开主机名都有效；
6. 首页与 About 页在桌面端与移动端都正常；
7. 存在一份能够恢复站点的备份；
8. 域名到期与证书续期都在监控之中；
9. 没有秘密信息或私密注册数据被公开。

这九条与仓库中 清单与模板附录 的三张检查单可以一一映射，建议直接照抄进项目笔记使用：

• 域名注册清单（Domain Registration Checklist）：覆盖第 1 条——提交前核对精确的标签与后缀、完整的分配 NS 集合、政策与费用确认、注册数据准确、结果在 Domain List 中确认、到期日已记录；
• 外部 NS 清单（External Nameserver Checklist）：覆盖第 2 条——zone 拼写与注册域名一致、没有把服务器 IP 当 NS 主机名填写、dig NS 返回预期值、每个外部权威服务器都能回答 SOA；
• 网站部署清单（Website Deployment Checklist）：覆盖第 4、7 条——本地测试通过、备份可读取、目标路径已验证、私密笔记与秘密已排除、nginx -t 与 HTTP/HTTPS 状态均验证。

第 5 条（证书）对应 证书清单：请求的主机名列表已复核、私有密钥受保护、证书名称与有效期已验证、重定向已测试、续期 dry run 成功、且存在独立的到期告警。第 8 条（监控）则对应 监控与事故响应 与 续费与到期。

把“完成定义”写下来的额外好处是：它让每个验收项都有了独立的验证命令或界面信号（dig NS、dig A、curl -I、证书查看器、备份恢复演练），而不是一句“网站上线了”这种无法复验的表述——这正是全书“Verify”环节（用独立检查而非成功的 Save 按钮作为证据）的体现。

第八步：建立风险登记表

原文给出的初始风险登记表（照原样保留）：

Risk	Likelihood	Impact	Mitigation
Account email lost	Medium	High	Protected recovery account and documented owner
DNS typo	Medium	High	Export, one change at a time, direct verification
Server update failure	Low	High	Backup and tested rollback
Certificate renewal failure	Medium	High	Renewal dry run and expiration alert

四条风险恰好对应四条主线，可与仓库章节互相印证：

• 账号邮箱丢失：注册账号是整个域名的控制点。缓解手段“受保护的恢复账号 + 书面所有者”落在 账号与政策章节 与前述责任矩阵上；域名管理 中也强调注册邮箱的可达性。
• DNS 拼写错误：缓解三件套是“先导出、一次只改一条、改完直接验证”。DNS 故障排查 与 TTL 与传播 解释了两点支撑：已缓存的答案不会因权威侧修改而消失（新旧值会短暂共存），所以变更后必须用 dig 直接验证而非凭界面提示；[变更模板](https://gitcode.com/GitHub_Trending/us/US.KG/blob/9c7c54110705760267b07b6e6a6d406d1172a1bf/documents/tutorial/appendices/checklists-and-templates.md?utm_source=gitcode_repo_files)（DNS Change Template）则要求每次变更预先写好 current value、intended value、验证命令与 rollback value。
• 服务器更新失败：缓解是“备份 + 经过测试的回滚”。备份与恢复 的核心要求是备份必须“可读取、可演练”，而不是仅仅“存在”。
• 证书续期失败：缓解是“续期 dry run + 独立到期告警”。启用并验证 HTTPS 中，续期演练与独立告警正是验收项之一。

登记表的维护方法：每月按 月度运维清单（Monthly Operations Checklist）复核一遍“到期日与续费负责人是否仍在位、委派 NS 是否被变更、备份与证书续期是否健康”，风险表就始终与现状同步。

规划练习：产出一页纸

原文布置的练习是写下一页纸，包含六项内容：

1. 受众与目标（Audience and goal）
2. 第一版本的页面（First-version pages）
3. 规范主机名（Canonical hostname）
4. 责任人（Responsible owners）
5. 完成定义（Definition of done）
6. 三大风险（Three major risks）

把前述各节的内容合并进去，可以直接使用下面这份合并模板（沿用本书的虚构值约定，真实值只在你自己的私有笔记中填写）：

# Website One-Page Plan

## 1. Audience & Goal
This website helps [audience] accomplish [specific result].

## 2. First-Version Pages
- Home:
- About:
- Contact method (no unnecessary personal data exposed):
- Navigation: accessible, no database, no login

## 3. Hostnames
- Canonical:  example.dpdns.org
- Alias:      www.example.dpdns.org
- Test:       lab.example.dpdns.org
- Visitors will see: root | www   （二选一，另一个由 Web 服务器重定向）

## 4. Owners
| Responsibility | Owner |
| --- | --- |
| Registration account |
| Renewal (primary + backup) |
| DNS |
| Server updates |
| Website content |
| Security reports |
| Backups |

## 5. Definition of Done
- [ ] Domain registered and active
- [ ] Nameserver delegation correct
- [ ] Root and www resolve intentionally
- [ ] HTTP redirects to one canonical HTTPS URL
- [ ] Certificate valid for every public hostname
- [ ] Home and About work on desktop and mobile
- [ ] A backup can restore the site
- [ ] Expiration and certificate renewal monitored
- [ ] No secrets or private registration data published

## 6. Top Risks
| Risk | Likelihood | Impact | Mitigation |
| --- | --- | --- | --- |
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |