企业架构实践（一）：从企业 IT 系统的建设与管理开始
一、从日常 IT 工作开始
在企业 IT 管理工作中，每天都会接触各种各样的系统。
有负责企业资源管理的 ERP，有管理生产过程的 MES，有支持仓储业务的 WMS，也有 OA、HR 等日常办公系统。为了让这些系统正常运行，还需要数据库、中间件、虚拟化平台、容器平台、监控系统以及各种公共服务。
随着业务发展，系统数量逐渐增加，技术架构也会不断变化。
平时遇到的问题通常比较具体：某个接口为什么调用失败，业务数据为什么没有及时同步，某个服务为什么无法访问，或者一次系统变更会不会影响其他应用。这些问题需要结合具体情况逐一分析和处理。
但在处理这些问题的过程中，也会逐渐发现，很多问题并不完全属于某一个系统。
例如，MES 的数据同步出现异常，原因可能涉及 ERP 接口、集成服务、消息队列或相关业务处理逻辑；文件访问出现问题，除了检查应用本身，还可能需要检查对象存储、网络文件存储以及底层虚拟化环境。
如果只熟悉单个系统，就很难快速了解这些系统之间的联系。
我开始学习 TOGAF Standard 10，也是希望能够在已有的 IT 建设和管理经验之外，进一步学习如何从企业整体的角度看待业务系统、数据、应用和技术基础设施。
当然，日常 IT 管理和企业架构之间还有很大的距离。了解一些架构概念，并不意味着已经具备完整的企业架构能力。
对我来说，一个比较实际的起点，是先把企业现有的 IT 环境梳理清楚，看看目前有哪些系统，它们分别承担什么职责，又是如何联系在一起的。
二、先把现有的 IT 系统梳理清楚
在开始分析企业架构之前，我认为有必要先回答几个基本问题：
- 企业目前有哪些 IT 系统和技术平台？
- 每个系统主要解决什么问题？
- 系统之间通过什么方式交互？
- 系统运行在哪些基础设施上？
- 哪些能力由多个系统共同使用？
- 当前环境中有哪些问题值得进一步分析？
这些问题看起来并不复杂，但实际梳理起来，往往需要结合系统文档、部署信息、接口资料以及日常运维经验。
企业 IT 环境通常不是一次性规划完成的。很多系统是在不同阶段，根据当时的业务需求逐步建设起来的。随着业务变化，一些系统会继续保留，一些系统会被替换，还有一些公共服务会逐渐形成。
因此，第一步不一定是立即设计新的架构，而是先了解现状。
结合目前的实际环境，可以先从以下几个方面整理系统清单。
2.1 业务应用与协同办公
这一类系统直接支持企业的业务活动和日常管理。
| 系统 | 主要用途 |
|---|---|
| 易飞 ERP | 企业原有的资源管理系统 |
| D365 Finance and Operations | 新业务环境使用的企业资源管理系统 |
| MES | 制造执行管理 |
| WMS | 仓储管理 |
| OA | 办公自动化与日常协同 |
| HR | 人力资源管理 |
| Redmine | 项目管理、任务跟踪及相关问题管理 |
需要说明的是，易飞 ERP 和 D365 Finance and Operations 是两套独立运行的 ERP 系统，服务于不同的业务环境，两者之间没有共享业务接口和数据。
从系统名称来看，它们都属于 ERP，但不能因此认为它们使用相同的数据、遵循相同的业务流程，或者彼此之间存在直接的集成关系。
MES 和 WMS 则分别面向生产执行和仓储作业。在实际业务中，它们需要与相关业务系统配合，才能支持从业务计划到生产执行、仓储作业等不同环节。
OA 和 HR 等系统主要服务于办公协同和人力资源管理。它们与 ERP、MES、WMS 的业务重点不同，但同样是企业 IT 环境的一部分。
这里需要注意一个区别：系统清单记录的是企业有哪些系统，而不是企业的全部业务流程。
知道企业使用 MES，并不意味着已经完整理解生产业务；知道企业使用 WMS，也不代表已经梳理清楚库存管理的全部规则。
系统清单只是进一步分析的基础。
2.2 应用集成与公共服务
除了直接面向用户的业务应用，企业还会建设一些公共服务，用于支持系统集成、文档生成、消息发送、文件存储等工作。
| 系统或平台 | 主要用途 |
|---|---|
| ERP Sync Service | 处理 ERP 相关的集成业务，连接 ERP 侧与后续集成环节 |
| RabbitMQ | 为系统之间的异步消息交互提供支持 |
| Document Generator | 提供统一的文档生成能力 |
| Reporting Service | 提供报表相关服务 |
| Message Service | 提供统一的消息发送能力，支持企业微信和 Email |
| MinIO | 保存业务文件、图片等对象数据 |
这些服务的作用，是为多个业务场景提供可复用的技术或业务能力。
例如，不同业务系统可能需要生成 PDF、Excel 或 Word 文件。如果每个系统都自行开发文档生成逻辑，就可能出现重复实现、维护成本增加以及输出格式不一致等问题。
通过 Document Generator，可以提交 JSON 数据和模板代码，生成相应的文档。生成后的文件可以存储在 MinIO 等存储平台中。
Message Service 则提供统一的消息发送能力，支持企业微信和 Email 等渠道。
RabbitMQ 用于支持系统之间的异步消息交互。它与直接进行 HTTP 或 Web Service 调用的方式有所不同，具体适用场景取决于业务流程和集成设计。
ERP Sync Service 则承担相关 ERP 集成业务。在 D365 F&O 与 MES 的集成过程中，它不是一个可以忽略的中间环节，而是实际集成链路中的独立组件。
需要注意的是，公共服务并不意味着它们可以脱离其他系统独立存在。它们本身也需要运行环境、存储、网络和相应的运维保障。
当多个业务系统开始依赖同一个公共服务时，这个服务的可用性和变更管理就可能影响多个业务系统。
这也是为什么在梳理系统清单时，不能只记录业务应用，还需要把公共服务纳入其中。
2.3 身份认证与安全管理
身份认证和安全管理为业务系统提供基础支撑。
| 系统或平台 | 主要用途 |
|---|---|
| 自研 SSO | 基于 OpenID Connect（OIDC）协议提供统一身份认证能力 |
| AD Domain | 提供域环境及相关目录服务 |
| Jump Server | 为受控的运维访问提供统一入口 |
| 防病毒软件 | 提供终端或服务器的恶意软件防护能力 |
公司建设了自研 SSO，采用 OpenID Connect 协议，为业务系统逐步接入统一身份认证提供基础。
统一身份认证不仅涉及登录页面，还涉及身份验证流程、系统接入方式以及与权限管理相关的设计。
从长期来看，逐步统一业务系统的身份认证方式，有助于减少重复建设，并为统一的身份管理提供基础。
不过，系统清单应该反映真实的现状，而不是只记录期望达到的目标。
目前，D365 Finance and Operations 尚未接入公司自研的 SSO。因此，在梳理身份认证架构时，需要将这一现状明确记录下来，而不能简单地认为所有业务系统都已经实现统一认证。
AD Domain、Jump Server 和防病毒软件承担的职责也有所不同。它们可能不直接参与某个业务流程，却会影响系统访问、安全管理和日常运维。
后续如果要进一步分析安全架构，还需要结合实际的账号管理、权限控制、访问路径和安全策略进行梳理。仅凭系统名称，还不足以判断整个环境的安全水平。
2.4 IT 服务管理与开发交付
企业 IT 不仅需要建设和运行系统，还需要管理服务请求、故障、项目以及软件开发和发布过程。
| 系统或平台 | 主要用途 |
|---|---|
| Ticket System | IT 服务请求、故障报修及问题处理 |
| Redmine | 项目管理、任务跟踪及相关问题管理 |
| GitLab + CI/CD | 代码版本管理、自动化构建、测试及部署 |
Ticket System 和 Redmine 都可能涉及问题记录和跟踪，但两者的实际职责边界，需要根据企业内部的使用方式来确定。
例如，可以由 Ticket System 主要承担 IT 服务请求和故障报修，由 Redmine 主要承担项目管理和开发任务跟踪。如果实际使用中存在职责重叠，就需要进一步明确两者的定位。
GitLab 与 CI/CD 可以放在一起理解。
GitLab 用于代码版本管理和协作开发，CI/CD 用于支持自动化构建、测试及部署。两者共同参与软件开发和交付过程。
从企业架构的角度来看，这些系统不直接承担生产、采购或仓储业务，但它们会影响业务应用的开发效率、版本管理和发布过程。
例如，一次应用升级不仅涉及代码修改，还可能涉及构建、测试、部署和变更管理。因此，开发交付平台也是企业 IT 架构中值得关注的一部分。
2.5 数据分析与低代码平台
随着业务系统积累的数据逐渐增加，企业还需要相应的数据处理、分析和应用开发工具。
| 系统或平台 | 主要用途 |
|---|---|
| Dremio | 数据访问、查询及数据分析相关能力 |
| Superset | 数据可视化与分析报表 |
| Kettle | 数据抽取、转换和加载（ETL） |
| Budibase | 低代码应用开发 |
这些平台可以帮助企业更好地利用已有数据，也可以支持部分数据处理和轻量级应用开发需求。
例如，Dremio 和 Superset 可以用于数据查询、分析和可视化；Kettle 可以用于数据抽取、转换和加载；Budibase 则可以用于构建部分低代码应用。
不过，工具能够连接数据，并不意味着不同系统的数据在业务含义上天然一致。
例如，不同系统中的物料、客户或库存数据，可能存在定义、编码和更新频率方面的差异。如果要进一步建设统一的数据分析体系，还需要明确数据来源、数据口径和数据质量要求。
这些内容属于后续数据架构分析需要考虑的问题。
2.6 基础设施与技术平台
业务应用和公共服务都需要运行环境。
如果只梳理应用系统，而不记录它们依赖的操作系统、虚拟化平台、数据库和中间件，就很难完整了解企业 IT 环境。
因此，基础设施和技术平台也需要纳入系统清单。
2.6.1 服务器与虚拟化基础设施
| 系统或平台 | 主要用途 |
|---|---|
| Linux OS | 主要服务器操作系统 |
| VMware vSphere | 提供服务器虚拟化及虚拟机管理能力 |
| VMware vSAN | 提供软件定义存储能力 |
| NFS | 提供网络文件存储访问能力 |
目前，企业服务器环境主要使用 Linux 操作系统。
VMware vSphere 用于虚拟化环境的管理，vSAN 提供软件定义存储能力，NFS 则提供网络文件系统访问能力。
这些技术处于不同的层次，但在实际部署中可能形成依赖关系。
例如，某项应用使用的文件存储服务，可能运行在 Linux 虚拟机上，而虚拟机的虚拟磁盘又依赖底层存储平台。
如果只记录应用连接的存储地址，就无法完整了解其背后的运行环境。
因此，后续还需要逐步把应用部署信息与基础设施信息联系起来。
2.6.2 容器平台、网络入口与运维支撑
| 系统或平台 | 主要用途 |
|---|---|
| Kubernetes | 容器编排与应用运行管理 |
| Nginx | Web 入口、反向代理及流量转发 |
| NTP | 提供网络时间同步 |
| Prometheus + Grafana | 监控指标采集与可视化 |
| ELK | 日志采集、检索与分析 |
| 企业级备份与恢复软件 | 提供数据和系统的备份与恢复能力 |
部分业务服务部署在 Kubernetes 中，例如 MES 和 ERP Sync Service。
Kubernetes 提供容器化应用的部署、调度和运行管理能力，但它并不能替代底层计算、网络和存储基础设施。
Nginx 可以承担 Web 访问入口、反向代理和流量转发等职责。
Prometheus 和 Grafana 分别承担监控指标采集与可视化展示等工作，ELK 则用于日志采集、检索与分析。这些工具可以从不同角度帮助运维人员了解系统运行情况。
备份与恢复软件同样属于基础设施管理的重要组成部分。
需要特别说明的是，系统正常运行，并不意味着数据已经具备充分的恢复保障。备份范围、保留周期、恢复时间以及恢复验证，都需要结合实际业务要求进行评估。
2.6.3 应用开发与实时通信技术
| 技术 | 主要用途 |
|---|---|
| .NET / .NET Core | 应用开发与运行平台 |
| ASP.NET Core Web API | 构建 HTTP API 服务 |
| Vue | 前端应用开发框架 |
| SignalR | 实时双向通信及服务端消息推送 |
在应用开发方面，企业使用 .NET / .NET Core 等技术。
ASP.NET Core Web API 用于构建 HTTP 接口，为前端应用和其他业务系统提供数据访问及业务处理能力。Vue 用于前端开发，SignalR 则用于支持实时通信和服务端消息推送。
这些技术分别承担不同职责。
将它们整理到同一份技术清单中，可以帮助我们了解企业主要采用的应用开发技术。但在后续架构分析中，还需要进一步明确它们分别应用在哪些系统中，以及相关应用之间如何交互。
2.6.4 API 网关、Web 代理与后台任务处理
| 技术 | 主要用途 |
|---|---|
| Ocelot | 基于 .NET 生态的 API 网关 |
| Nginx | Web 反向代理、访问入口及流量转发 |
| Hangfire | .NET 后台任务处理，支持定时、延迟及持久化任务 |
Ocelot 主要用于 .NET 生态中的 API 网关场景，Nginx 则是通用的 Web 服务器和反向代理工具。
两者都可能参与请求转发，但具体职责取决于实际部署方式，不能仅凭技术名称判断它们是否存在功能重叠。
Hangfire 主要用于处理 .NET 应用的后台任务，例如定时任务和延迟执行任务。
它与 RabbitMQ 的定位不同：Hangfire 主要面向后台任务的调度与执行，RabbitMQ 则主要提供消息传递能力。
在实际架构中，理解这些组件的职责边界，有助于避免把不同层次的技术混为一谈。
2.6.5 数据库与数据访问中间件
| 技术组合 | 主要用途 |
|---|---|
| PostgreSQL + Pgpool | PostgreSQL 数据库及相关的连接管理、数据库访问能力 |
| MySQL + ProxySQL | MySQL 数据库及相关的数据库代理、连接管理和查询流量管理 |
企业使用 PostgreSQL 和 MySQL 等关系型数据库。
与单独列出数据库相比，将数据库和相关中间件组合起来，更容易体现实际的技术搭配。
PostgreSQL 与 Pgpool 组合，MySQL 与 ProxySQL 组合，分别构成相应的数据库访问技术栈。
具体的连接管理、流量分配和高可用能力，仍然取决于实际的版本、配置和部署方式。仅凭使用了某个中间件，并不能直接判断数据库已经实现了某种高可用架构。
后续如果要进一步梳理数据库架构，还需要了解数据库与应用之间的连接关系，以及相关的备份、恢复和运行保障方式。
2.6.6 缓存与分布式协调
| 技术 | 主要用途 |
|---|---|
| Redis | 缓存及其他基于内存的数据访问能力 |
| ZooKeeper | 为分布式系统提供协调服务 |
Redis 常用于缓存和临时数据存储等场景。
ZooKeeper 则为分布式系统提供协调能力，具体用途取决于哪些应用或组件使用它。
这些技术通常不会直接出现在最终用户的操作界面中，但可能是某些应用正常运行的重要依赖。
因此，后续绘制系统关系图时，也需要根据实际情况将这些组件纳入分析，而不是只关注用户能够直接访问的业务系统。
2.6.7 文件存储与其他技术服务
| 系统或平台 | 主要用途 |
|---|---|
| MinIO | 对象存储 |
| NFS | 网络文件存储访问 |
| Shlink | 短链接管理服务 |
MinIO 用于保存业务文件、图片及其他对象数据，NFS 提供网络文件系统访问能力。
在当前环境中，MinIO 的持久化存储使用 NFS，NFS 服务运行在 Linux 虚拟机上，相关虚拟磁盘由 VMware vSAN 提供存储支持。
Shlink 则用于短链接管理。
这些服务看起来比较分散，但都可能与业务应用的运行和使用体验有关。
至此，我们可以初步形成一份涵盖业务应用、集成服务、身份认证、开发交付、数据平台以及基础设施的 IT 系统清单。
这份清单不一定一开始就完整，也不需要一次性把所有技术细节都整理出来。随着对系统的了解不断加深，可以逐步补充相关信息。
三、从系统清单进一步了解系统之间的关系
完成系统清单之后，我们可以回答企业有哪些系统、每个系统大致负责什么。
但仅有清单仍然不够。
企业 IT 环境并不是一组互不相关的软件和服务器，而是由业务系统、集成服务、数据库、中间件和基础设施共同组成的整体。
因此，下一步需要了解系统之间的关系。
3.1 D365 F&O 与 MES：通过 ERP Sync Service 和 RabbitMQ 进行集成
目前，D365 Finance and Operations 与 MES 之间并不是直接通过 RabbitMQ 进行交互，而是通过 ERP Sync Service 和 RabbitMQ 等组件共同完成相关集成。
从系统关系来看，可以将这条链路概括为：
D365 F&O ↔ ERP Sync Service ↔ RabbitMQ ↔ MES
这里的箭头表示系统之间存在交互关系，具体的数据流向和处理方向需要结合不同的业务接口进一步确认。
在这条集成链路中，各组件承担不同的职责：
- D365 F&O：负责相关 ERP 业务处理。
- ERP Sync Service：承担 ERP 相关的集成业务，连接 ERP 侧与后续集成环节。
- RabbitMQ：为集成服务与 MES 之间的消息交互提供支持。
- MES：负责相关制造执行业务。
从业务角度看，D365 F&O 与 MES 存在数据交互需求；但从技术实现来看，两者之间还存在 ERP Sync Service 和 RabbitMQ 等中间环节。
这两种视角并不矛盾，只是关注的层次不同。
如果只记录 D365 F&O 与 MES 之间存在数据交互，就容易忽略实际承担集成工作的服务和消息中间件。只有进一步梳理这些组件，才能更准确地理解系统之间的依赖关系。
例如，当 MES 没有收到预期的业务数据时，问题不一定出在 MES 本身。还需要结合实际的数据流向，检查 ERP Sync Service 的处理情况、RabbitMQ 的消息状态，以及相关环节是否出现异常。
这也说明，集成服务本身需要作为独立的应用组件进行管理。它的运行状态、接口处理逻辑和部署方式，都可能影响相关业务流程。
目前，ERP Sync Service 部署在 Kubernetes 中，RabbitMQ 也部署在 Kubernetes 中，但 RabbitMQ 采用单实例部署方式，并不是集群部署。
这属于现有架构中的客观情况。它是否需要调整，需要结合业务重要性、可接受的中断时间、恢复要求和运维能力进行评估。
通过这条链路可以看到，企业应用集成并不一定是两个业务系统之间的直接连接。实际实现中，可能还需要集成服务和消息中间件共同参与。
3.2 ERP 与 WMS：通过 Web Service 进行集成
ERP 与 WMS 通过 Web Service 进行集成，而不是通过消息队列进行交互。
这种集成方式需要重点关注接口调用关系、请求与响应、异常处理，以及系统之间的数据一致性。
与消息队列模式相比，Web Service 的调用过程和错误处理方式可能不同。因此，不能用同一套假设来理解所有系统集成。
进一步梳理时，需要明确接口双方的职责、数据来源、数据流向，以及接口调用失败后如何处理。
这些信息有助于建立比较清晰的接口依赖关系，也能为后续的故障排查和系统变更评估提供参考。
3.3 公共服务也会形成系统依赖
除了业务系统之间的集成，公共服务也会形成依赖关系。
例如：
- 业务系统可能调用 Document Generator 生成文档。
- Message Service 为相关业务场景提供企业微信和 Email 消息发送能力。
- Document Generator 生成的文件可以存储在 MinIO 中。
- MinIO 的持久化存储依赖 NFS。
- NFS 服务运行在 Linux 虚拟机上，相关虚拟磁盘由 VMware vSAN 提供存储支持。
- 业务应用可能依赖 PostgreSQL 或 MySQL 保存业务数据。
- 部署在 Kubernetes 中的应用依赖相应的容器运行环境和底层基础设施。
这些关系需要结合实际部署和调用情况进一步核实，并不是所有系统都必然存在上述全部依赖。
但它们说明了一个问题：系统之间的关系不只有业务接口。
有些是应用调用关系，有些是数据存储关系，有些是运行环境依赖，还有些与身份认证、安全管理和运维保障有关。
如果只画出业务系统之间的接口，就可能忽略文件存储、数据库、中间件和基础设施带来的影响。
因此，在后续梳理中，需要逐步区分不同类型的依赖关系，并根据分析目的选择合适的表达方式。
四、从日常 IT 工作理解 TOGAF 的四大架构领域
学习 TOGAF Standard 10 之后，我开始尝试把平时接触的 IT 工作与企业架构的概念联系起来。
在入门阶段，我认为比较容易理解、也比较适合从现有系统出发进行实践的，是以下四个架构领域。
4.1 业务架构（Business Architecture）
业务架构关注企业的业务能力、业务流程、组织以及业务之间的关系。
以制造企业为例，可以从销售、计划、采购、生产、仓储和财务等业务活动出发，分析企业如何开展业务，以及不同业务活动之间如何衔接。
ERP、MES 和 WMS 都是支持业务活动的系统，但业务架构并不等于系统清单。
一个业务流程可能涉及多个系统，一个系统也可能支持多个业务流程。
因此，梳理业务架构时，需要先理解业务本身，再分析系统如何支持业务。
4.2 数据架构（Data Architecture）
数据架构关注企业数据的组织方式、数据实体、数据流向、数据存储以及数据之间的关系。
例如，物料、客户、供应商、生产订单和库存等数据，可能会在不同系统之间流转。
即使系统之间已经建立接口，也仍然需要进一步明确：
- 数据由哪个系统负责维护？
- 哪个系统是特定数据的权威来源？
- 数据通过什么方式同步？
- 不同系统中的数据定义是否一致？
- 数据出现不一致时如何处理？
这些问题不能仅靠接口清单解决，还需要从数据架构的角度进行分析。
4.3 应用架构（Application Architecture）
应用架构关注企业应用系统的组成、职责、交互关系以及应用之间的协作方式。
易飞 ERP、D365 F&O、MES、WMS、ERP Sync Service、Document Generator 和 Message Service 等，都可以纳入应用架构的分析范围。
通过应用架构，可以逐步回答：
- 哪些应用支持哪些业务能力？
- 应用之间通过什么接口或机制交互？
- 哪些公共服务被多个应用依赖？
- 哪个应用发生变化时，可能影响哪些其他系统？
- 是否存在职责不清晰或重复建设的情况？
前面的系统清单和集成关系梳理，可以为应用架构分析提供基础。
4.4 技术架构（Technology Architecture）
技术架构关注支撑应用运行的技术基础，包括计算资源、网络、存储、操作系统、数据库、中间件、容器平台以及相关技术服务。
例如，Linux、VMware vSphere、vSAN、Kubernetes、PostgreSQL、MySQL、RabbitMQ 和 Nginx 等，都可以从技术架构的角度进行分析。
技术架构不只是记录使用了哪些技术，还需要进一步了解这些技术如何组合，以及它们对应用可用性、性能、安全性和可维护性的影响。
例如，应用部署在 Kubernetes 中，并不意味着它与底层基础设施完全解耦。它仍然可能依赖数据库、文件存储、消息中间件和网络服务。
理解这些依赖关系，有助于分析系统故障、技术风险和架构改进方向。
4.5 四大架构领域之间的联系
这四个领域并不是相互独立的。
业务架构说明企业需要开展哪些业务活动；数据架构关注这些活动所使用的数据；应用架构说明哪些应用系统支持这些业务活动；技术架构则为应用提供运行环境。
例如，一个生产业务流程可能涉及生产订单、MES、ERP Sync Service、RabbitMQ、数据库和 Kubernetes 运行环境。
从业务架构看，这是一个生产业务流程；从数据架构看，需要分析生产订单及相关数据的来源和流转；从应用架构看，需要分析 ERP、集成服务、消息中间件和 MES 之间的关系；从技术架构看，则需要考虑数据库、消息中间件和应用运行平台。
同一个问题可能同时涉及多个架构领域。
这也是我学习企业架构时逐渐认识到的一点：业务、数据、应用和技术不能完全分开看。只有将它们联系起来，才能更完整地理解企业 IT 环境。
五、梳理现状，是为了发现值得进一步分析的问题
建立系统清单、梳理系统关系，并不是为了记录尽可能多的技术名称，也不是为了证明现有架构有多复杂。
我认为，这项工作的实际价值在于帮助我们发现平时容易忽略的问题，并为后续分析提供依据。
5.1 公共服务的影响范围
Document Generator、Message Service 和 MinIO 等公共服务，可能被多个业务系统使用。
如果这些服务出现故障，影响范围可能不止一个应用。
因此，需要进一步了解哪些系统依赖这些服务，以及服务中断会对哪些业务造成影响。
这并不意味着所有公共服务都必须采用相同的高可用方案，而是需要先明确它们的实际用途和业务重要性，再决定相应的保障措施。
5.2 中间件的可用性
RabbitMQ 目前采用 Kubernetes 单实例部署。
对于这种部署方式，需要结合实际业务要求评估其可用性。如果 RabbitMQ 发生故障，可能会影响依赖该中间件的系统集成流程。
进一步分析时，可以关注故障时的业务影响、消息持久化与恢复机制，以及业务能够接受的中断时间。
是否需要调整部署方式，应当结合业务重要性、恢复目标、技术成本和运维能力综合判断，而不是仅凭部署实例数量就直接下结论。
5.3 文件存储与数据保护
MinIO 用于保存业务文件和图片，当前采用多节点部署，持久化存储使用 NFS。NFS 服务运行在 Linux 虚拟机上，相关虚拟磁盘由 VMware vSAN 提供存储支持。
从依赖关系来看，这涉及对象存储、网络文件存储、虚拟机和底层存储等多个层次。
需要注意的是，多节点部署并不等于已经具备独立的数据备份保障。
目前，MinIO 没有独立的备份机制。因此，有必要进一步评估相关数据的保护方案，包括备份范围、保留周期、恢复流程和恢复验证。
随着业务文件持续增长，存储容量和数据恢复也需要纳入长期规划。
5.4 身份认证的统一性
公司自研 SSO 基于 OIDC 协议，为业务系统逐步接入统一身份认证提供基础，但 D365 F&O 目前尚未接入。
这意味着，在分析身份认证架构时，需要区分已经实现的能力与后续需要推进的工作。
后续可以根据实际业务需求，进一步梳理不同系统的登录方式、身份管理边界和权限控制方式，判断是否需要进一步统一。
这里的重点不是简单地追求所有系统采用相同的技术，而是理解现状、明确需求，并在此基础上做出合理的架构决策。
5.5 技术组件的职责边界
企业 IT 环境中往往存在多种技术组件。它们可能在部分能力上有所交集，但实际职责并不完全相同。
例如：
- Ocelot 与 Nginx 都可能参与请求转发，但所处的技术层次和使用场景可能不同。
- Hangfire 主要处理后台任务，RabbitMQ 主要提供消息传递能力。
- PostgreSQL + Pgpool 与 MySQL + ProxySQL 分别属于不同的数据库技术组合。
- GitLab + CI/CD 涉及代码管理和自动化交付，不只是一个代码仓库。
- Kubernetes 负责容器编排，并不能替代底层存储、网络和虚拟化基础设施。
- MinIO 提供对象存储服务，NFS 提供网络文件系统访问能力。
把这些组件整理清楚，有助于后续理解技术依赖和系统边界。
具体功能仍然需要结合实际配置和部署方式判断。不能只凭技术名称，就认定某项能力已经实现。
六、为什么要从企业整体的角度看 IT？
在日常工作中，很多问题最初都是以单点问题的形式出现的。
例如，某个接口异常、业务数据没有及时同步、某个服务无法访问文件，或者一次系统变更影响了其他应用。
如果只从单个系统的角度出发，分析范围可能会不断扩大，却仍然难以快速定位问题。
当系统清单、应用关系和基础设施依赖逐步清晰之后，就可以从更完整的角度分析这些问题。
例如，当应用无法访问文件时，可以沿着实际依赖关系，检查应用服务、对象存储、NFS、虚拟机以及底层存储，而不是一开始就假设问题一定出在应用代码中。
当集成流程出现异常时，也可以根据接口关系和消息处理过程，分析问题发生在哪个环节。
这种方法不仅适用于故障排查，也适用于系统规划和架构改进。
引入新系统之前，可以分析它与现有系统的关系；调整技术组件之前，可以评估可能受到影响的应用；规划基础设施时，可以结合应用的重要性和实际依赖确定优先级。
这些工作听起来并不复杂，但真正做好并不容易。它需要不断积累系统信息、验证实际情况，并与业务人员和技术人员沟通。
对我来说，学习企业架构并不是要用一套新的术语替代原来的 IT 管理工作，而是希望借助相对系统的方法，把原本分散的经验和信息组织起来，让分析问题和规划改进有更清晰的依据。
七、从系统清单开始，逐步理解企业架构
回顾这次梳理，第一步只是整理企业现有的 IT 系统和技术平台。
但在这个过程中，我逐渐认识到，系统清单只是起点。
知道企业有哪些系统，只能回答“有什么”；理解系统之间的关系，才能进一步回答“它们如何协作”；将业务、数据、应用和技术联系起来，才有可能从企业整体的角度理解 IT 环境。
这与 TOGAF Standard 10 所提供的企业架构方法有很多可以相互参照的地方。
不过，一份系统清单还不能称为完整的企业架构。它还需要进一步补充业务能力、业务流程、数据关系、应用交互、技术依赖，以及架构改进的目标和路径。
对于已经运行多年的企业 IT 环境而言，从现有系统入手是一种比较务实的方式。
不需要一开始就建立复杂的模型，也不需要立即改变现有系统。可以先把已有信息整理出来，再根据实际业务需求逐步补充和验证。
这也是我学习和实践企业架构时，现阶段比较认同的一种做法：先了解现状，再分析问题；先把关系梳理清楚，再讨论如何改进。
下一篇，我准备继续围绕系统之间的关系展开，尝试从现有系统清单出发，进一步梳理应用依赖，并区分业务依赖、接口依赖和基础设施依赖。
这只是一个开始。后续还有很多内容需要学习和实践，但至少可以先从熟悉的 IT 环境出发，一步一步把企业架构这件事理解得更清楚。