项目技术架构文档应该有哪一些

物理架构

物理架构视图着重考虑运行软件的计算机、网络、硬件设施等情况。包含：包括如何将软件包部署到这些基础设施、基础设施的配置情况，比如代码仓库、MySQL，MQ，Redis，Nginx，CI/CD，k8s，监控，负载均衡设备等，以及注意事项。

逻辑架构

逻辑架构关注的是功能，包含用户直接可见的功能，还有系统中隐含的功能。或者更加通俗来描述，逻辑架构更偏向我们日常所理解的功能模块，系统依赖的上下游系统以及联系人；
针对系统、子系统或某个功能模块的设计说明，从技术架构到软件设计，到数据库建模，以及核心技术的介绍，性能分析等，面向对象是相同专业的专业人员。

接口文档

在项目开发中，web项目的前后端分离开发，APP开发，需要由前后端工程师共同定义接口，编写接口文档，之后大家都根据这个接口文档进行开发，到项目结束前都要一直维护。接口文档一般需要包含几个个重要的组成部分，分别是：接口地址，调用方式，接口参数，返回结构，异常情况、接口的数据处理流程，目前的调用方；

需求文档

需求文档对应的是在做一个业务需求开发的时候出的业务需求技术文档，主要针对业务需求出的技术文档，记录这个需求所产生的接口文档、数据库变更、上线待办清单、代码仓库和相应的开发分支，以及一些注意事项，方便需求在开发过程中，以及在测试联调过程中，有很好的文档进行备忘、沟通和回顾。如果有依赖底层或第三方的接口，也应一并补充。若有外部调用方，也应进行登记。
文档格式可以参考：技术文档；

技术文档

技术文档对应的是在做一个技术需求开发或者是技术改进的时候出的技术文档，主要针对技术需求出的技术文档，文档格式可以参考：软件系统设计文档大纲
, 软件设计文档编写指南：从理论到实践

技术分享

文档格式可以参考：如何写好一篇技术分享文章；

故障记录

当出现线上故障时，处理完毕后，应编写故障复盘文档，进行原因分析、思考改进措施、贴出关键的代码、交待故障发生以及处理的历史过程，方便团队进行回顾、学习和避免类似问题再次发生。

系统故障分析排查报告，报告通常应包括以下几个部分：

• 报告标题：简要描述故障的类型和发生时间。
• 故障描述：详细描述故障的现象、影响和背景。
• 故障影响：问题影响面大小，多少用户，多少系统
• 分析过程：简要描述分析故障的步骤和方法。
• 分析结果：详细描述分析的结果，包括故障的原因和解决方案。
• 建议与建议：根据分析结果提出有关改进的建议和建议。
• 结论：总结分析的过程和结果，并提出有关改进的建议。
• 附录：可以包括与故障分析有关的附加信息，例如截图、日志文件等。

常见问题

经常问的问题，其中包含用户（测试、产品、上下游系统）针对特定产品、服务或查询提出的常见问题的答案，如何写一个好的常见问题页面？以下是一些很好的常见问题解答指南，可以在向客户推出时包含在软件或产品中：

• 包括客户正在寻找的关键字。
• 包括竞争对手页面上的内容。
• 以客户会写或问的方式表达您的问题。
• 正确格式化您的常见问题解答

新人文档

为新加入团队成员而编写的新人指引教程，包括系统介绍、应该开通哪些账号、遇到的一些常见问题、入周第一周应该做什么等。