用户访谈记录 - 管理层（IT总监）
一、基本信息
| 项目 | 内容 |
|---|---|
| 访谈时间 | 2026-03-05 10:30-11:30 |
| 访谈地点 | 公司会议室B |
| 访谈对象 | 李总监 |
| 职位/角色 | IT总监/管理层 |
| 记录人 | 项目经理 |
| 访谈方式 | 面对面 |
二、访谈内容
2.1 现有系统现状
问：公司目前有哪些业务系统？各自使用什么技术栈？
答： 目前公司运行的主要系统有：
核心系统：
- OA系统 - 致远OA，.NET技术栈，2018年上线
- 财务系统 - 用友U8，C/S架构，2016年上线
- HR系统 - 自建系统，Java技术栈，2019年上线
- CRM系统 - Salesforce，云服务，2020年上线
技术栈统计：
- Java系统：3个（HR、官网、商城）
- .NET系统：2个（OA、旧ERP）
- 云服务：2个（CRM、钉钉）
- 数据库：MySQL、SQL Server、Oracle混用
关键发现：
- 系统数量较多，技术栈不统一
- 有老旧系统（2016-2018年上线）
- 云服务与本地部署混合
问：现有系统的用户管理和权限控制是如何实现的？
答： 目前各系统独立管理：
用户管理：
- OA系统：使用AD域账号同步
- HR系统：独立用户表，与OA定期同步
- 财务系统：独立用户管理
- CRM系统：使用Salesforce自带用户管理
权限管理：
- 各系统独立维护权限
- 没有统一的权限模型
- 权限分配依赖各系统管理员
痛点：
- 新员工入职需要在多个系统开通账号
- 权限变更需要在多个系统操作
- 离职员工账号回收容易遗漏
关键发现：
- 各系统用户管理独立
- 没有统一权限模型
- 账号生命周期管理困难
问：目前各系统之间的数据是如何同步的？
答： 目前的数据同步方式：
定时同步：
- HR系统 → OA系统：每晚同步组织架构
- AD域 → OA系统：每小时同步用户信息
手动同步：
- 组织架构变更：人工通知各系统管理员
- 用户信息变更：人工在多个系统修改
问题：
- 同步延迟（最长24小时）
- 数据不一致（部门名称、人员信息）
- 同步失败缺乏监控
关键发现：
- 以定时同步为主
- 存在数据不一致问题
- 缺乏同步监控机制
2.2 技术架构
问：对 System 系统的技术架构有什么要求？
答： 我的技术要求：
技术选型：
- 后端：Java（Spring Boot）或 Node.js
- 前端：Vue.js 或 React
- 数据库：MySQL 8.0
- 缓存：Redis
- 消息队列：RabbitMQ 或 Kafka
架构要求：
- 微服务架构，便于扩展
- RESTful API，便于集成
- 支持容器化部署（Docker/K8s）
- 支持水平扩展
关键发现：
- 倾向Java技术栈
- 要求微服务架构
- 需要支持容器化部署
问：需要支持哪些集成方式（API、SSO、LDAP等）？
答： 需要支持的集成方式：
认证集成：
- SSO - 单点登录（必须）
- OAuth2.0 - 第三方应用接入
- LDAP/AD - 与现有AD域集成
- SAML - 支持SaaS应用
数据集成：
- REST API - 标准接口
- Webhook - 事件通知
- 消息队列 - 异步数据同步
现有系统集成需求：
- OA系统：SSO + API
- HR系统：API + 数据库直连
- 财务系统：API（受限）
- CRM系统：API + Webhook
关键发现：
- 需要多种认证方式（SSO、OAuth2、LDAP）
- 需要标准REST API
- 与4个核心系统集成
问：对系统的扩展性和性能有什么要求？
答： 性能要求：
并发能力：
- 支持500+并发用户
- 峰值1000并发
- 登录响应时间 < 2秒
数据规模：
- 支持5000+用户
- 支持100+部门
- 支持50+角色
扩展性：
- 支持水平扩展
- 数据库读写分离
- 缓存集群
可用性：
- 99.9%可用性
- 故障恢复时间 < 30分钟
- 支持主备切换
关键发现：
- 并发要求500-1000
- 用户规模5000+
- 可用性要求99.9%
2.3 用户与权限管理
问：公司目前的组织架构是怎样的？有多少部门？
答： 组织架构情况：
层级结构：
- 总部（1个）
- 技术中心（1个）
- 研发部、测试部、运维部、产品部
- 营销中心（1个）
- 销售部、市场部、客服部
- 职能中心（1个）
- 人力资源部、财务部、行政部
- 技术中心（1个）
统计数据：
- 一级部门：3个
- 二级部门：10个
- 三级部门：15个
- 虚拟团队：5个（项目组形式）
特点：
- 部门层级最多3级
- 存在虚拟团队（跨部门项目组）
- 组织架构每季度可能调整
关键发现：
- 部门层级最多3级
- 存在虚拟团队需求
- 组织架构调整频繁
问：预计 System 系统需要管理多少用户？
答： 用户规模：
当前用户：
- 正式员工：450人
- 外包人员：80人
- 实习生：30人
- 合作伙伴账号：20人
- 总计：580人
增长预期：
- 2026年底：预计700人
- 2027年底：预计1000人
- 系统需要支持：5000人（预留扩展空间）
用户类型：
- 内部员工：主要用户
- 外部人员：需要受限权限
- 系统账号：服务账号、接口账号
关键发现：
- 当前580人，计划支持5000人
- 包含内部员工和外部人员
- 需要考虑服务账号
问：用户角色和权限如何划分？
答： 角色规划：
系统级角色：
- 超级管理员（2人）- 系统全部权限
- 系统管理员（3人）- 用户、角色管理
- 安全管理员（2人）- 审计、安全策略
部门级角色：
- 部门管理员（每个部门1人）- 本部门用户管理
- 部门主管（每个部门1人）- 本部门数据权限
普通角色：
- 普通员工 - 基本操作权限
- 访客 - 只读权限
- 外部人员 - 受限权限
特殊角色：
- 审批角色 - 各类审批权限
- 报表角色 - 数据查看权限
- 接口角色 - API调用权限
关键发现：
- 三级角色体系（系统级、部门级、普通）
- 需要特殊角色（审批、报表、接口）
- 角色数量预计50+
2.4 安全与合规
问：对密码策略有什么具体要求？
答： 密码策略要求：
复杂度要求：
- 最小长度：8位
- 必须包含：大写、小写、数字、特殊字符
- 不能包含：用户名、连续数字
更换策略：
- 更换周期：90天
- 历史密码：不能与最近5次重复
- 首次登录：必须修改初始密码
锁定策略：
- 失败次数：5次
- 锁定时间：30分钟
- 告警通知：锁定后通知管理员
关键发现：
- 强密码策略要求
- 90天更换周期
- 5次失败锁定
问：是否需要支持多因素认证？
答： 需要支持MFA：
应用场景：
- 超级管理员：强制MFA
- 系统管理员：强制MFA
- 外部访问：强制MFA
- 敏感操作：二次验证
认证方式：
- 手机验证码（SMS）
- 邮箱验证码
- 动态令牌（TOTP）
- 企业微信/钉钉扫码
实现计划：
- 第一阶段：支持手机验证码
- 第二阶段：支持动态令牌
- 第三阶段：支持生物识别
关键发现：
- 管理员强制MFA
- 多种认证方式
- 分阶段实现
问：操作日志需要保留多长时间？
答： 日志保留要求：
保留期限：
- 在线查询：180天
- 归档存储：3年
- 审计用途：永久保留
日志内容：
- 用户登录/登出
- 权限变更
- 敏感数据操作
- 系统配置变更
- 管理员操作
日志要求：
- 不可篡改
- 定期备份
- 支持导出
- 支持审计查询
关键发现：
- 在线查询180天
- 归档3年
- 审计日志永久保留
2.5 运维与支持
问：系统上线后由谁负责运维？
答： 运维分工：
运维团队：
- 运维主管：1人（总体负责）
- 运维工程师：2人（日常运维）
- 数据库管理员：1人（DBA）
职责划分：
- 基础设施：运维团队
- 应用系统：开发团队（前3个月）
- 数据库：DBA
- 安全：安全团队
运维工具：
- 监控：Prometheus + Grafana
- 日志：ELK Stack
- 告警：钉钉/企业微信
关键发现：
- 运维团队4人
- 开发团队前3个月参与
- 已有运维工具链
问：对系统的可用性有什么要求（SLA）？
答： SLA要求：
可用性指标：
- 年度可用性：99.9%
- 月度可用性：99.95%
- 计划停机：每月不超过4小时
响应时间：
- 登录响应：< 2秒
- 查询响应：< 1秒
- 批量操作：< 5秒
故障处理：
- P1故障：15分钟响应，2小时恢复
- P2故障：30分钟响应，4小时恢复
- P3故障：2小时响应，24小时恢复
关键发现：
- 可用性要求99.9%
- 明确的故障分级处理
- 有响应时间要求
问：是否需要提供培训和技术支持？
答： 培训需求：
培训对象：
- 系统管理员：深度培训（2天）
- 部门管理员：操作培训（半天）
- 普通用户：使用培训（1小时）
培训内容：
- 系统功能介绍
- 操作手册
- 常见问题处理
- 应急处理流程
技术支持：
- 上线后1个月：驻场支持
- 上线后3个月：远程支持
- 之后：工单支持
文档要求：
- 用户操作手册
- 管理员手册
- API接口文档
- 运维手册
关键发现：
- 分级培训计划
- 1个月驻场支持
- 需要完整文档
2.6 通用话题补充
问：您目前在工作中使用哪些系统？
答： 作为IT总监，我日常使用的系统：
- 运维监控系统 - Prometheus、Grafana
- 日志系统 - ELK Stack
- 代码仓库 - GitLab
- 项目管理 - Jira
- 知识库 - Confluence
- 办公系统 - OA、邮件
痛点：
- 系统太多，切换频繁
- 各系统账号独立管理
- 权限申请流程繁琐
关键发现：
- IT人员使用系统更多
- 对系统集成度要求高
问：这些系统的用户管理和权限控制是如何实现的？
答： 现状：
- 运维系统：LDAP统一认证
- 开发系统：GitLab自带用户管理
- 办公系统：AD域认证
- 项目管理系统：独立用户管理
问题：
- 没有统一的用户中心
- 权限管理分散
- 离职人员账号回收困难
关键发现：
- 已有LDAP和AD，但不够统一
- 权限管理是痛点
问：您在登录不同系统时遇到过什么问题？
答： 登录问题：
- 浏览器记住的密码经常过期
- 有些系统不支持LDAP，需要单独登录
- 移动端访问体验差
- VPN连接不稳定时无法访问
期望：
- 统一身份认证
- 支持多种认证方式
- 更好的移动端支持
关键发现：
- 认证方式不统一
- 移动办公需求
问：您在用户管理方面遇到的最大困难是什么？
答： 困难：
- 人员变动时，需要在多个系统调整权限
- 权限审计困难，无法统一查看
- 临时权限管理混乱
- 外包人员权限控制不严
期望：
- 统一权限管理平台
- 自动化的权限变更
- 完善的权限审计
关键发现：
- 权限变更是最大痛点
- 需要自动化和审计
问：目前的权限管理存在哪些问题？
答： 问题：
- 权限分散 - 各系统独立管理
- 标准不一 - 没有统一的权限模型
- 回收困难 - 离职人员权限回收不及时
- 审计困难 - 无法统一审计
影响：
- 安全风险
- 合规问题
- 管理效率低
关键发现：
- 权限分散、标准不一、回收困难、审计困难
问：您希望 System 系统首先解决什么问题？
答： 优先级：
- 统一认证 - 单点登录，减少密码管理负担
- 统一权限 - 集中权限管理，简化运维
- 统一组织 - 组织架构一处维护
- 安全合规 - 满足等保要求
关键发现：
- 认证、权限、组织、安全是核心需求
问：您对 System 系统的整体期望是什么？
答： 期望：
- 技术先进 - 采用成熟稳定的技术
- 易于集成 - 标准接口，便于对接
- 可扩展 - 支持业务增长
- 易运维 - 降低运维成本
关键发现：
- 技术、集成、扩展、运维是核心关注点
问：您认为 System 系统上线后会带来哪些改变？
答： 改变：
- 运维效率 - 减少重复工作，提升效率
- 安全水平 - 统一管控，降低风险
- 用户体验 - 单点登录，体验提升
- 合规能力 - 满足审计要求
关键发现：
- 效率、安全、体验、合规四方面提升
问：对系统的界面设计有什么建议？
答： 建议：
- 管理界面要专业、功能完整
- 用户界面要简洁、易用
- 支持主题切换
- 响应式设计，支持移动端
关键发现：
- 区分管理端和用户端设计
问：还有其他建议或补充吗？
答： 建议：
- 充分测试 - 特别是集成测试
- 灰度发布 - 逐步上线，降低风险
- 监控完善 - 上线后要有完善的监控
- 应急预案 - 制定详细的应急预案
关键发现：
- 重视测试、发布、监控、应急
三、关键发现总结
3.1 技术现状
- 系统多且杂 - 7个系统，多种技术栈
- 集成复杂 - 需要与4个核心系统集成
- 数据不一致 - 各系统独立管理，同步延迟
3.2 技术要求
- Java技术栈 - 倾向Spring Boot
- 微服务架构 - 便于扩展和维护
- 容器化部署 - 支持Docker/K8s
3.3 集成需求
- 认证集成 - SSO、OAuth2、LDAP
- 数据集成 - REST API、Webhook、消息队列
- 系统对接 - OA、HR、财务、CRM
3.4 安全合规
- 等保三级 - 必须通过认证
- MFA支持 - 管理员强制多因素认证
- 审计日志 - 180天在线，3年归档
四、待确认事项
- 技术方案 - 需要技术团队评审架构设计
- 集成方案 - 需要与各系统负责人确认集成细节
- 数据迁移 - 需要制定详细的数据迁移计划
- 安全评审 - 需要安全团队参与方案评审
五、后续行动
- 技术方案设计 - 根据访谈结果设计技术架构
- 集成计划制定 - 与各系统负责人制定集成计划
- POC验证 - 对关键技术点进行验证
- 安全方案评审 - 组织安全团队评审
访谈结束时间： 2026-03-05 11:30
访谈时长： 60分钟
记录整理时间： 2026-03-05 13:00