企业架构实践（一）：从企业 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 则用于支持实时通信和服务端消息推送。
这些技术分别承担不同职责。
将它们整理到同一份技术清单中，可以帮助我们了解企业主要采用的应用开发技术。但在后续架构分析中，还需要进一步明确它们分别应用在哪些系统中，以及相关应用之间如何交互。 Continue reading “《TOGAF学习之路》企业架构实践（一）：从日常 IT 工作开始理解企业架构”