2. JSM站点与项目架构设计

在Jira Service Management（JSM）中，站点是承载所有用户、项目、权限与配置的顶层容器，而项目则是服务交付的实际工作单元。架构设计的第一步，不是急着创建项目，而是先回答一个更根本的问题：这个站点要同时服务哪些类型的“客户”，他们各自需要什么样的入口、流程和可见范围。JSM把服务项目按服务对象和交付模式划分为三种基本类型：IT服务管理（ITSM）、客户服务（CS）和业务服务（BS）。理解这三者的差异，是后续模板选择、多项目协同与门户策略的前提。

三种服务项目类型的定位与差异

IT服务管理项目面向内部员工，典型场景是IT帮助台、事件管理、变更请求、资产与配置管理。它的核心特征是“内部请求者 + 服务目录 + SLA驱动”，请求者通常通过门户提交工单，由服务台按优先级和SLA响应。客户服务项目面向外部客户，典型场景是产品售后支持、投诉处理、订单咨询。它的核心特征是“外部请求者 + 多渠道接入 + 客户满意度”，往往需要与CRM或订单系统集成，且请求者身份验证方式与内部员工不同。业务服务项目则面向跨部门或特定业务线，例如HR入职服务、财务报销、法务合同审批，它的核心特征是“流程审批 + 跨团队协作 + 业务规则”，通常不强调传统ITIL流程，而更关注表单、审批链和状态流转。

三者的关键差异可以用“请求者来源、服务目录形态、流程重心、SLA要求、门户暴露程度”五个维度来区分。例如，ITSM项目的服务目录通常按ITIL实践组织，SLA按优先级分级；客户服务项目的服务目录更接近产品线，SLA往往与合同等级挂钩；业务服务项目的服务目录则按业务事项组织，SLA可能体现为审批时限而非响应时限。这些差异直接决定了项目模板的选择。

项目模板选择：从模板到可运行项目的关键决策

JSM提供了多种项目模板，但模板只是起点，不是终点。选择模板时，应关注三个层面：第一，模板是否内置了与目标服务类型匹配的工作流和字段；第二，模板的请求类型（Request Type）是否覆盖了主要服务场景；第三，模板的权限方案是否与站点现有用户组兼容。例如，ITSM模板默认包含“事件”“服务请求”“变更”等请求类型，并预置了优先级字段和SLA日历；客户服务模板则更强调“问题”“反馈”等类型，并默认开启客户满意度调查。业务服务模板通常以“审批”为核心，内置多级审批工作流。

实际操作中，建议先创建一个“样板项目”，在样板项目中完成请求类型、字段、工作流、SLA、自动化规则的完整配置，验证通过后再复制为模板项目，供后续同类项目复用。这样做的原因是：JSM的项目配置项之间存在强耦合，例如SLA依赖于优先级字段，自动化规则依赖于状态流转，直接在新项目中逐项配置容易遗漏。样板项目法可以把验证过的配置整体复制，降低出错概率。

多项目协同与门户策略

当站点内存在多个服务项目时，协同的核心是“数据不重复、入口不混乱、权限不越界”。数据不重复，意味着用户目录、组织、客户等基础数据应在站点级别统一维护，而不是每个项目各自导入。入口不混乱，意味着门户应按受众分层：内部员工看到的是ITSM和BS项目的服务目录，外部客户看到的是CS项目的服务目录，两者不应混在同一个门户首页。权限不越界，意味着项目权限方案应基于站点用户组分配，而不是直接给个人授权，否则人员变动时维护成本会急剧上升。

门户策略上，JSM支持“帮助中心”作为统一入口，也支持为不同项目配置独立门户。推荐的做法是：内部服务使用统一帮助中心，按项目分组展示服务目录；外部客户服务使用独立门户，避免内部服务目录对外暴露。如果企业同时有多个品牌或产品线，可以为每个品牌创建独立的客户服务项目，但共享同一个站点，通过组织（Organization）字段区分客户归属，这样既保证了数据隔离，又避免了多站点带来的用户目录同步问题。

一个可参考的站点架构示例

假设某企业有800名内部员工、约2000名外部客户，IT部门需要管理内部IT服务，客服部门需要处理产品售后，HR部门需要办理入职审批。合理的架构是：一个JSM站点，三个项目——ITSM项目（内部员工）、CS项目（外部客户）、BS项目（HR入职）。站点用户目录同步企业AD，外部客户通过邮箱注册并归入对应组织。门户方面，内部帮助中心展示ITSM和BS的服务目录，外部客户门户只展示CS的服务目录。权限方面，IT代理只能访问ITSM项目，客服代理只能访问CS项目，HR专员只能访问BS项目，站点管理员统一管理全局配置。这种架构既满足了服务隔离，又避免了多站点带来的维护复杂度。

需要强调的是，架构设计不是一次性的工作。随着服务范围扩大，可能需要新增项目、调整门户分组或修改权限方案。因此，在初始设计时就应预留扩展空间：项目命名规范统一、请求类型命名统一、自动化规则尽量参数化，这样后续扩展时才能保持一致性。