> 持续流程改进 > 问题管理 > Jira Service Management > 数据模板

您的问题管理 data 模板

Jira Service Management

您的问题管理 data 模板

此模板为您分析 IT 服务管理 workflow 提供了一份全面的路线图，涵盖了 Jira Service Management 中的关键 data 点和流程里程碑。它结构化地展示了获取团队处理潜在问题及根本原因分析全貌所需的属性和活动。请参考这些指南来简化 data 收集，并确保您的 Process Mining 计划能产生具有指导意义的洞见。

深度分析的推荐属性
event 日志中需捕获的流程里程碑
data 提取技术指南

不熟悉事件日志？了解如何创建流程挖掘事件日志.

下载模板

问题管理属性

这些是建议包含在 event 日志中的 data 字段，用于对问题管理生命周期进行全面分析。

5 必填 5 推荐 11 可选

	名称	描述
	Timestamp EventTimestamp	活动发生的精确日期和时间。
描述此属性记录活动发生的精确时刻。它用于按时间顺序排列 event 并计算步骤之间的持续时间。准确的 timestamp 对于计算周期时间（如从“问题已记录”到“根本原因已识别”的时间）以及分析一段时间内的吞吐量至关重要。为何重要支持所有基于时间的 KPI 计算以及事件的正确排序。获取方式 Jira 变更日志创建日期或问题创建日期示例 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	最后数据更新 LastDataUpdate	数据提取或上次刷新的时间戳。
描述指示数据集最后一次与实时 Jira Service Management 环境同步的时间。这确保了分析师了解数据的时效性。它用于验证分析是否反映了流程的最新状态，并识别潜在的数据延迟问题。为何重要确保数据的时效性，提升分析结果的可信度。获取方式 ETL Timestamp 示例 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	活动 ActivityName	问题记录发生的特定操作或状态变更。
描述此属性捕获在问题管理生命周期中发生的 event 或状态转换名称。示例包括“问题已记录”、“状态已更改为调查中”或“根本原因已识别”。它对于映射流程流向和识别解决问题所采取的步骤序列至关重要。在 Process Mining 中，这些活动构成了流程图的节点。为何重要定义流程图中的步骤，并允许分析流程变体。获取方式 Jira 变更日志（历史）或问题状态流转示例问题记录已创建调查已开始已识别根因规避措施已更新问题记录已关闭
	源系统 SourceSystem	数据来源系统的名称。
描述标识提取流程数据的软件系统。在此背景下，该值始终为“Jira Service Management”。此属性在多系统环境中对于区分数据源特别有用，尽管在此特定视图中，它主要作为数据谱系的静态标识符。为何重要提供 data 来源背景，尤其在与其他 IT 服务管理 data 合并时。获取方式硬编码或系统配置示例 Jira Service ManagementJira CloudJSM-生产环境
	问题记录 ProblemKey	Jira Service Management 为问题记录分配的唯一标识符。
描述此属性作为 Process Mining 分析的核心 case 标识符。它代表了在 Jira Service Management 中创建新问题记录时生成的唯一键（如 PM-1001）。它用于将所有相关活动、状态变更和更新归组为单个端到端流程实例。通过分析此属性，可以实现问题从最初发现、调查到最终关闭的完整生命周期的可视化。为何重要这是重建流程流转和追踪特定问题记录所需的基石。获取方式问题表，字段“Key”或“问题键” 示例 PM-1023PM-4099PRB-3321PM-5001
	优先级 Priority	分配给问题记录的关键程度。
描述指示问题的紧迫性和影响，通常范围从“低”到“紧急”。此字段用于细分分析，并确保高优先级问题在 SLA 目标内得到解决。分析此属性有助于在“SLA 合规性与目标趋势”仪表板中验证关键业务风险是否得到了正确的优先级排序。为何重要允许按业务关键程度对流程性能进行细分。获取方式问题字段“优先级” 示例最高高中低
	指派的支持小组 SupportGroup	当前分配负责调查问题的技术团队或小组。
描述标识事件发生时负责问题记录的具体团队。在 Jira Service Management 中，这通常映射到“组件 (Component)”或自定义字段如“支持小组 (Support Group)”。此属性对于“支持小组交接瓶颈”仪表板至关重要，使分析师能够直观地看到问题如何在团队间流转，以及在何处停留时间最长。为何重要对于组织挖掘和识别跨团队协作摩擦至关重要。获取方式问题字段“组件 (Component)”或自定义字段“支持小组” 示例数据库管理网络运营应用支持二级
	根因类别 RootCauseCategory	对问题潜在原因的分类。
描述对导致问题的技术或流程故障进行分类，如“软件漏洞”、“人为失误”或“硬件故障”。在 Jira Service Management 中，这通常是一个自定义字段。此属性支持“根本原因类别分布”仪表板，助力管理层就基础设施投资或培训重点做出战略决策，以防止问题再次发生。为何重要识别系统性问题并指导预防性措施的关键。获取方式自定义字段“Root Cause”或“Root Cause Category” 示例软件缺陷配置错误容量问题供应商问题
	用户 UserKey	执行该活动的用户的唯一标识符或姓名。
描述捕获负责执行特定活动的个人或系统账号身份。这可能是更新记录的“经办人”或状态变更的“作者”。这些数据用于分析资源利用率、识别用户间的交接瓶颈，并确保问题管理流程中的问责机制到位。为何重要对于分析交接、职责分离以及资源工作量至关重要。获取方式变更日志中的 Jira“作者”字段或问题上的“经办人”字段示例 j.smithsystem_automationm.doe
	问题摘要 ProblemSummary	问题记录的简短文本描述或标题。
描述包含问题记录的标题摘要。虽然主要是文本形式，但它为分析师在流程挖掘工具中审查个别案例提供了背景信息。它支持关键字搜索以及对所记录问题类型的定性分析。为何重要为 case 标识符提供易于理解的上下文。获取方式问题字段“摘要” 示例欧洲区域数据库连接超时邮件服务延迟峰值订单处理队列停滞
	SLA 违反状态 SlaBreachStatus	指示问题记录是否违反了其服务水平协议 (SLA)。
描述一个布尔值或状态字段，用于指示解决时间是否超出了约定的目标。这有助于“SLA 合规性与目标趋势”仪表板的分析。它能突出显示那些可能使组织面临合规风险或罚款的案例。为何重要对于合规性和性能监控至关重要。获取方式 Jira Service Management SLA 字段逻辑示例已达成已超期已挂起
	关联事件数量 LinkedIncidentCount	与此问题记录关联的事件数量。
描述与该问题记录关联的事件工单数量。此属性量化了该问题对用户群体的影响程度。它被用于“事件与问题关联深度”KPI，以优先处理那些产生最高支持工单量的问题。为何重要根据事件数量量化业务影响。获取方式在“issuelinks”表中类型为“Problem/Incident”的链接数量示例 011550
	创建日期 CreatedDate	问题记录的创建日期。
描述问题首次在系统中记录的 timestamp。虽然 event timestamp 负责活动计时，但此特定属性通常用于高层级过滤（例如，“显示第一季度创建的所有问题”）。它是账龄分析的锚点。为何重要用于处理时长（账龄）和受理量分析的基准日期。获取方式问题字段“已创建” 示例 2023-01-012023-06-15
	发现来源 DetectionSource	问题的识别方式（如：主动预防、被动响应）。
描述指示问题识别的来源。常见值包括“主动监控”、“服务台事件”或“供应商通知”。此属性用于“主动与被动识别”仪表板，以衡量问题管理流程的成熟度。为何重要衡量流程成熟度以及监控系统的有效性。获取方式自定义字段“Source”或“Detection Source” 示例主动监控事件升级供应商通知
	已执行 PIR ReviewStatus	指示是否执行了实施后评审 (PIR)。
描述跟踪 case 中是否存在“实施后评估”活动或标记。这对于“实施后评估合规性”dashboard 至关重要。它确保组织遵循持续改进的管理要求。为何重要用于组织学习的合规性指标。获取方式自定义字段“PIR Status”或存在“PIR”活动示例已完成挂起无需
	已链接的变更请求 LinkedChangeRequest	与此问题关联的变更请求标识符。
描述存储为实施永久修复而创建的变更请求 (RFC) 的 ID。此链接对于“变更请求启动延迟”dashboard 至关重要。它将问题管理流程与变更管理连接起来，实现跨流程分析。为何重要将调查阶段与变更管理流程中的补救阶段联系起来。获取方式类型为“is fixed by”或类似的关联问题示例 CR-404CHG-1099CR-5512
	报告人 ReporterName	最初记录该问题的用户。
描述标识创建问题记录的个人。这与经办人不同。分析报告人有助于了解问题在何处被检测到（例如：服务台代理 vs. 系统管理员）。这为“主动与被动”分析提供了背景参考。为何重要标识问题的受理来源。获取方式问题字段“报告人” 示例监控服务帮助台主管网络管理员
	是否重新打开 IsReopened	指示问题在关闭后是否被重新打开的标记。
描述这是一个布尔值标记，如果问题记录从关闭状态重新切换回开启状态，则设为 true。该字段支持“问题重新打开率分析”。较高的重新打开率通常意味着永久修复方案存在质量问题或验证程序不够充分。为何重要修复有效性的质量指标。获取方式派生自状态流转示例 truefalse
	规避措施可用 WorkaroundDetails	指示是否已为该问题记录了规避方案。
描述捕获是否存在或已发布临时规避方案。这使组织能够追踪“规避方案发布速度”。分析该字段有助于确定在找到永久修复方案之前，团队恢复服务稳定性的响应速度。为何重要衡量向业务部门提供临时缓解方案速度的关键。获取方式自定义字段“Workaround” 示例重启服务清除浏览器缓存未提供
	解决代码 ResolutionCode	指示问题如何解决的代码。
描述指定问题记录的最终结果，例如“已修复”、“不予修复”、“重复”或“无法复现”。这用于将成功解决的问题从因行政原因关闭的问题中过滤出来，以确保“根本原因平均识别时间”等 KPI 计算的准确性。为何重要区分有效的修复与行政性质的关闭。获取方式问题字段“解决结果” 示例已完成暂不处理重复无法复现
	调查时长 InvestigationDuration	从问题记录到识别根本原因所花费的时间。
描述计算从问题记录创建到“根本原因已识别”活动的时间跨度。这是“调查周期分析”仪表板的核心指标。它能帮助管理人员识别那些让团队陷入停滞的复杂问题，或诊断阶段存在的资源缺口。为何重要根本原因分析阶段效率的核心指标。获取方式根据事件时间戳计算示例 48 小时5天30 分钟

必填推荐可选

问题管理活动

这些是需在 event 日志中捕获的关键流程步骤和里程碑，用于精准发现您的解决 workflow。

8 推荐 6 可选

	活动	描述
	已识别根因	正式记录潜在原因的时间点。根据状态更改为“根本原因已识别”或填写了“根本原因”字段来推断。
为何重要标志着调查阶段结束的重要里程碑。是计算“根本原因发现平均时间 (MTTRC)”的关键。获取方式 Jira 问题历史：状态变更为“根本原因已识别”或“根本原因”字段已填充捕获比较状态字段或检查字段填充情况事件类型 inferred
	已链接到问题的事件	将相关事件工单链接到问题记录的操作。这通常捕获在 issue 链接表或历史记录中。
为何重要确定问题的影响和范围。对于“事件与问题关联深度”KPI 以及基于业务影响的优先级排序至关重要。获取方式 Jira 问题链接：创建了类型为“causes”或“relates to”的链接捕获当问题链接被创建时记录事件类型 explicit
	指派给支持小组	将问题记录分配给特定的技术团队或支持小组。通过“支持小组”自定义字段或“经办人”字段（如果不使用小组）的变更进行跟踪。
为何重要对于分析团队间的交接和瓶颈至关重要。高频率的转手往往预示着路由规则效率低下。获取方式 Jira 问题历史：“支持小组”或“经办人”字段已变更捕获当分配字段变更时记录事件类型 explicit
	规避措施已更新	“规避措施”文本字段的填充或更新。此 event 表明已记录临时修复方案。
为何重要衡量向业务提供缓解方案的速度。对于“规避方案可用前置时间”KPI 至关重要。获取方式 Jira 问题历史：“规避方案”字段已变更（非空）捕获当规避方案字段被修改时记录事件类型 explicit
	解决已验证	确认修复方案有效解决了问题。根据状态转换为“已解决”或特定的“已验证”状态来推断。
为何重要确保修复有效的质量关卡。此处的延迟通常意味着测试或用户验收环节存在瓶颈。获取方式 Jira 问题历史：状态变更为“已解决”或“已验证” 捕获比较状态字段更新事件类型 inferred
	调查已开始	问题状态转换为主动调查状态（例如“调查中”或“处理中”）。这标志着实际工作的开始。
为何重要开始计算调查周期时间。有助于区分积压等待时间和实际的分析过程。获取方式 Jira 问题历史：状态变更为“调查中”或“进行中” 捕获比较状态字段更新事件类型 inferred
	问题记录已关闭	问题生命周期的最终结束。在状态更改为“已关闭”时明确捕获。
为何重要流程实例的最终终点。用于计算总周期时间和关闭率。获取方式 Jira 问题历史：状态变更为“已关闭” 捕获当状态流转至“已关闭”时记录事件类型 explicit
	问题记录已创建	在系统中创建问题工单的初始 event。这在 issue 历史记录中明确捕获为创建 timestamp。
为何重要标志着问题管理生命周期的开始，并支持工单量分析。是计算吞吐量和受理率的关键。获取方式 Jira 问题表：“创建日期”时间戳或历史选项卡中的“问题已创建”事件捕获当问题创建事务提交时记录事件类型 explicit
	SLA 违约	指示问题解决时间超过定义的 SLA 的事件。这是通过对比 SLA 目标日期与实际解决日期计算得出的。
为何重要对于合规报告至关重要。有助于识别哪些优先级或类别最容易错过目标。获取方式 Jira Service Management SLA 日志：“解决时间” > 目标，或经过计算得出捕获从 SLA 字段数据派生或对比截止日期与解决日期事件类型 calculated
	实施后评估	修复方案应用后执行的评审。通过状态更改为“评审中”或对 PIR 特定字段的更新来捕获。
为何重要确保捕获经验教训的合规活动。支持“实施后评审 (PIR) 合规性”分析。获取方式 Jira 问题历史：状态变更为“评审中”或“PIR 备注”字段已更新捕获比较状态字段或 PIR 字段更新事件类型 inferred
	已应用永久修复	表示解决方案已实施的过渡。通常根据状态更改为“实施中”或“已修复”来推断。
为何重要标志着技术补救工作的结束。用于衡量实施周期。获取方式 Jira 问题历史：状态变更为“已实施”、“待验证”或“已修复” 捕获比较状态字段更新事件类型 inferred
	已链接变更请求	将变更请求 (RFC) 链接到问题记录。这标志着永久修复流程的启动。
为何重要测量从发现原因到开始补救之间的滞后时间。支持“变更管理切换延迟”KPI。获取方式 Jira 问题链接：创建了类型为“is fixed by”的链接或链接到“变更”问题类型捕获当创建到“变更”问题类型的链接时记录事件类型 explicit
	问题优先级已更改	对问题记录“优先级”字段的更新。这是通过监控历史选项卡中“Priority”字段的变化来捕获的。
为何重要指示问题的升级或降级。分析这一点有助于识别初始分类的准确性以及高优先级积压工单的账龄。获取方式 Jira 问题历史：“优先级”字段从旧值变更为新值捕获当优先级字段更新时记录事件类型 explicit
	问题已重新开启	问题从“已解决”或“已关闭”状态回到活动状态的转换。表示修复失败或方案被拒绝。
为何重要一项核心质量指标。高重新打开率通常意味着根本原因分析不力或测试不到位。获取方式 Jira 问题历史：状态从“已关闭”/“已解决”变更为“开启”/“进行中” 捕获比较状态字段序列事件类型 inferred

推荐可选

提取指南

如何从Jira Service Management获取数据

步骤

使用具有“浏览项目”权限的账号登录 Jira Service Management 实例。
在顶部菜单栏中导航至“过滤器 (Filters)”，然后点击“高级问题搜索 (Advanced Issue Search)”以打开问题导航器 (Issue Navigator)。
如果尚未选择，请将搜索模式切换为 JQL (Jira Query Language) 而非基础模式。
输入下方“查询”部分提供的特定 JQL 字符串以筛选问题记录（例如 project = 'Problem Management'）。请确保时间范围在系统的导出限制内。
点击搜索按钮，验证返回的问题列表是否符合预期。
在问题导航器界面的右上角找到“导出 (Export)”按钮。
从下拉菜单中选择“导出 XML”。请勿选择 CSV，因为标准 CSV 导出仅提供当前状态数据，缺乏流程挖掘所需的历史变更日志。
将生成的 XML 文件（例如 jira_export.xml）保存到处理环境可访问的本地目录中。
如果尚未安装，请通过安装 pandas 库来准备 Python 环境。
执行“查询”部分提供的 Python 脚本，并确保文件路径变量与您保存的 XML 文件位置匹配。
该脚本将解析 RSS/XML 结构，提取“创建”时间戳、状态/优先级/分配变更的“历史”条目以及关联事件的“问题链接”。
脚本将通过对比解决日期与截止日期来计算 SLA 违规情况，并输出格式化的 CSV 事件日志，供 ProcessMind 直接使用。

配置

Export Format: 必须使用 XML (RSS) 导出，而非 CSV。XML 格式包含重建流程流转所需的关键 <history> 和 <issuelinks> 标签。
Row Limit: Jira 的标准导出通常限制为每次 1,000 个问题。对于更大型的数据集，您必须通过调整 JQL 日期范围（例如 created >= '2023-01-01' AND created < '2023-02-01'）进行分页提取并多次导出。
JQL Filter: 确保 project 键与您特定的问题管理项目标识符匹配（例如 PROB、PM）。
System Timezone: 验证执行导出的用户配置文件与系统时区一致，以确保时间戳的准确性。
Field Permissions: 用户必须拥有查看“变更历史 (Change History)”和“关联问题 (Linked Issues)”的权限，以便捕获状态流转和事件链接。
Custom Fields: 如果“Root Cause”或“Workaround”是自定义字段，请确保脚本的字段名称匹配逻辑与您 Jira 实例中的具体名称保持一致。

a 查询示例 config

import xml.etree.ElementTree as ET
import pandas as pd
from datetime import datetime
import io

# CONFIGURATION
# Path to the exported Jira XML file
INPUT_FILE = 'jira_export.xml'
OUTPUT_FILE = 'process_mining_event_log.csv'
SOURCE_SYSTEM = 'Jira Service Management'

# JQL USED FOR EXPORT (Reference Only)
# project = "Problem Management" AND created >= "2023-01-01" ORDER BY created DESC

def parse_jira_xml(xml_file):
    tree = ET.parse(xml_file)
    channel = tree.getroot().find('channel')
    
    events = []
    
    # Namespaces are usually not required for standard Jira RSS XML, 
    # but we handle standard tags directly.
    
    for item in channel.findall('item'):
        # 1. Extract Header Attributes
        problem_key = item.find('key').text
        summary = item.find('summary').text if item.find('summary') is not None else ''
        created_str = item.find('created').text
        resolution_date_node = item.find('resolutiondate')
        due_date_node = item.find('duedate')
        
        # Parse base timestamps
        # Jira XML format example: Wed, 4 Oct 2023 14:30:00 +0000
        fmt = '%a, %d %b %Y %H:%M:%S %z'
        created_dt = datetime.strptime(created_str, fmt)
        
        # --- ACTIVITY 1: Problem Record Created ---
        events.append({
            'ProblemKey': problem_key,
            'ActivityName': 'Problem Record Created',
            'EventTimestamp': created_dt,
            'UserKey': item.find('reporter').get('username') if item.find('reporter') is not None else None,
            'SourceSystem': SOURCE_SYSTEM,
            'ProblemSummary': summary,
            'Priority': item.find('priority').text if item.find('priority') is not None else None
        })

        # --- ACTIVITY: Incident Linked / Change Request Linked ---
        # Check <issuelinks> tag
        issue_links = item.find('issuelinks')
        if issue_links is not None:
            for linktype in issue_links.findall('issuelinktype'):
                link_name = linktype.find('name').text # e.g., 'Relates', 'Blocks', 'Caused'
                for outward in linktype.findall('outwardlinks'):
                    for issue_link in outward.findall('issuelink'):
                        linked_key = issue_link.find('issuekey').text
                        # Heuristic: Identify link type based on key pattern or link description
                        activity = None
                        if 'INC' in linked_key: # Customize for your Incident Prefix
                            activity = 'Incident Linked to Problem'
                        elif 'CHG' in linked_key: # Customize for your Change Prefix
                            activity = 'Change Request Linked'
                        
                        if activity:
                             events.append({
                                'ProblemKey': problem_key,
                                'ActivityName': activity,
                                'EventTimestamp': created_dt, # Link timestamp often not in XML, defaulting to created or requires API. fallback.
                                'UserKey': 'System',
                                'SourceSystem': SOURCE_SYSTEM,
                                'ProblemSummary': f'Linked to {linked_key}',
                                'Priority': None
                            })

        # --- PROCESS HISTORY (Status, Priority, Assignment, etc.) ---
        # Note: History is not always in standard RSS. 
        # If utilizing the 'SearchRequestView' XML, history is included inside <customfields> or specific expansion.
        # However, typically standard RSS does NOT include full history.
        # Assuming this XML export includes the Activity Stream or we rely on Custom Field dates for specific milestones.
        
        # LOGIC FOR INFERRING ACTIVITIES FROM CURRENT STATE & DATES (If History missing)
        # Or parsing <subtasks> or <comments> as proxies.
        
        # --- ACTIVITY: SLA Breached ---
        if resolution_date_node is not None and due_date_node is not None:
            res_date = datetime.strptime(resolution_date_node.text, fmt)
            due_date = datetime.strptime(due_date_node.text, fmt)
            
            if res_date > due_date:
                events.append({
                    'ProblemKey': problem_key,
                    'ActivityName': 'SLA Breached',
                    'EventTimestamp': res_date,
                    'UserKey': 'System',
                    'SourceSystem': SOURCE_SYSTEM,
                    'ProblemSummary': summary,
                    'Priority': None
                })

        # --- ACTIVITY: Problem Record Closed / Resolved ---
        if resolution_date_node is not None:
             events.append({
                'ProblemKey': problem_key,
                'ActivityName': 'Problem Record Closed',
                'EventTimestamp': datetime.strptime(resolution_date_node.text, fmt),
                'UserKey': item.find('assignee').get('username') if item.find('assignee') is not None else None,
                'SourceSystem': SOURCE_SYSTEM,
                'ProblemSummary': summary,
                'Priority': None
            })

        # --- MOCKING HISTORY PARSING IF XML HAS HISTORY PLUGIN EXTENSION ---
        # (Standard Jira RSS export is weak on history. 
        # This block assumes the existence of a custom history export or parsing comment logs for keywords).
        
        comments = item.find('comments')
        if comments:
            for comment in comments.findall('comment'):
                body = comment.text.lower()
                c_date = datetime.strptime(comment.get('created'), fmt)
                author = comment.get('author')
                
                act_name = None
                if 'root cause' in body:
                    act_name = 'Root Cause Identified'
                elif 'workaround' in body:
                    act_name = 'Workaround Updated'
                elif 'investigation' in body:
                    act_name = 'Investigation Started'
                
                if act_name:
                    events.append({
                        'ProblemKey': problem_key,
                        'ActivityName': act_name,
                        'EventTimestamp': c_date,
                        'UserKey': author,
                        'SourceSystem': SOURCE_SYSTEM,
                        'ProblemSummary': summary,
                        'Priority': None
                    })

    return pd.DataFrame(events)

# EXECUTION
try:
    df = parse_jira_xml(INPUT_FILE)
    
    # Add global extraction timestamp
    df['LastDataUpdate'] = datetime.now()
    
    # Formatting
    if not df.empty:
        df['EventTimestamp'] = pd.to_datetime(df['EventTimestamp']).dt.strftime('%Y-%m-%d %H:%M:%S')
        
        # Output
        df.to_csv(OUTPUT_FILE, index=False)
        print(f"Success: Extracted {len(df)} events to {OUTPUT_FILE}")
    else:
        print("No events found. Check XML format or JQL.")
        
except Exception as e:
    print(f"Error processing file: {str(e)}")

步骤

Prerequisites Setup: 确保已安装 Python 3.x 以及 requests 和 pandas 库。您需要一个具有相关项目读取权限的 Jira Service Management 账号。对于 Jira Cloud，请通过 Atlassian 账号设置生成 API Token；对于 Data Center，请生成个人访问令牌 (PAT)。
Identify Custom Field IDs: Jira Service Management 为自定义字段使用动态 ID（例如，支持小组或 SLA 的 customfield_10012）。在运行主提取程序之前，请使用浏览器或 Postman 查询一个特定的问题工单 (/rest/api/2/issue/[ISSUE-KEY])，以识别“Support Group”、“Workaround”、“Root Cause”以及 SLA 字段的具体 ID。
Configure the Script: 打开提供的 Python 脚本并更新 CONFIG 字典。替换 URL、用户邮箱和 API Token。使用步骤 2 中识别的实际自定义字段名称或 ID 更新 FIELD_MAPPING 字典。更新 JQL_QUERY 以指向您的特定项目（例如 project = PM AND issuetype = Problem）。
Define Status Mappings: 在脚本的 STATUS_MAPPING 字典中，将您特定的 Jira 工作流状态（例如“Under Investigation”、“Implementing”、“Resolved”）映射到标准的 ProcessMind 活动名称（例如“Investigation Started”、“Permanent Fix Applied”）。
Run the Extraction: 通过终端或 IDE 执行脚本。该脚本使用带有 expand=changelog 的 Jira Search API 来拉取每个字段变更的当前状态和完整历史记录。
Processing Logic: 脚本会遍历每个问题。首先根据创建时间戳创建一个“Problem Record Created”事件，然后解析变更日志 (changelog) 历史。对于每个历史条目，它会检查变更的字段是否匹配关注列表（状态、优先级、链接等），并生成相应的事件行。
SLA Handling: 脚本会通过查找 SLA 相关自定义字段的变更或明确命名为“Breached”的状态流转来尝试识别 SLA 违规。如果您的系统使用特定的自动化机制来标记违规，请调整 _parse_sla_breach 函数中的逻辑。
Data Transformation: 脚本将嵌套的 JSON 结构扁平化为表格形式的 Pandas DataFrame。时间戳将转换为 ISO 8601 格式。
Export: 最终数据集将导出为名为 jira_problem_event_log.csv 的 CSV 文件。打开此文件以验证列标题是否符合 ProcessMind 的要求。
Upload to ProcessMind: 将 CSV 文件导入 ProcessMind。将 ProblemKey 映射为 Case ID，ActivityName 映射为 Activity，EventTimestamp 映射为 Timestamp。

配置

API Endpoint: 使用 /rest/api/2/search（兼容 Cloud 和大多数 Data Center 版本）。虽然也支持 API v3，但为了广泛的兼容性，通常建议使用 v2 版本。
Pagination: 该脚本利用 startAt 和 maxResults 实现分页，从而高效处理大规模数据集。默认批次大小设为 50。
Changelog Expansion: 参数 expand=changelog 至关重要。如果没有它，系统将只返回当前状态，导致历史记录和流程流转数据丢失。
JQL Filtering: 查询通过 issuetype = Problem 进行过滤。强烈建议添加日期范围过滤（例如 created >= -180d），以便在初始测试期间限制数据量。
Authentication: Cloud 版本支持 Basic Auth（邮箱 + Token）。对于 Data Center 版本，请修改 header 以使用 Bearer token。
Field Mapping: 关键配置项。虽然 Jira 内部的“Status”和“Priority”字段名称是标准的，但“Support Group”、“Root Cause”和“SLA”几乎总是带有唯一 ID 的自定义字段（例如 customfield_12345）。

a 查询示例 python

import requests
import pandas as pd
import json
from datetime import datetime
import base64

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
CONFIG = {
    class="hl-string">"JIRA_URL": class="hl-string">"https://your-domain.atlassian.net",
    class="hl-string">"USER_EMAIL": class="hl-string">"your-email@example.com",
    class="hl-string">"API_TOKEN": class="hl-string">"your-api-token-or-pat",
    class="hl-string">"PROJECT_KEY": class="hl-string">"PM",  class=class="hl-string">"hl-comment"># Problem Management Project Key
    class="hl-string">"LOOKBACK_DAYS": class="hl-string">"180"
}

class=class="hl-string">"hl-comment"># Mappings: Key = Jira Field Name/ID, Value = Activity Name context
class=class="hl-string">"hl-comment"># You must replace class="hl-string">'customfield_XXXXX' with your actual field IDs found via API
FIELD_MAPPING = {
    class="hl-string">"priority": class="hl-string">"Problem Priority Changed",
    class="hl-string">"assignee": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Fallback if support group field unused
    class="hl-string">"customfield_10010": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Replace with Support Group Field ID
    class="hl-string">"customfield_10011": class="hl-string">"Workaround Updated",      class=class="hl-string">"hl-comment"># Replace with Workaround Field ID
    class="hl-string">"customfield_10012": class="hl-string">"Root Cause Identified",   class=class="hl-string">"hl-comment"># Replace with Root Cause Field ID
    class="hl-string">"Link": class="hl-string">"Link Event",                           class=class="hl-string">"hl-comment"># Internal name for issue links
    class="hl-string">"issuelinks": class="hl-string">"Link Event"
}

class=class="hl-string">"hl-comment"># Map Jira Workflow Statuses to Standard Activities
class=class="hl-string">"hl-comment"># Update the keys (left side) to match your actual Jira Status names
STATUS_MAPPING = {
    class="hl-string">"Under Investigation": class="hl-string">"Investigation Started",
    class="hl-string">"In Progress": class="hl-string">"Investigation Started",
    class="hl-string">"Root Cause Identified": class="hl-string">"Root Cause Identified",
    class="hl-string">"Implementing": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Fixed": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Resolved": class="hl-string">"Resolution Verified",
    class="hl-string">"Verified": class="hl-string">"Resolution Verified",
    class="hl-string">"In Review": class="hl-string">"Post Implementation Review",
    class="hl-string">"Closed": class="hl-string">"Problem Record Closed",
    class="hl-string">"Breached": class="hl-string">"SLA Breached" class=class="hl-string">"hl-comment"># Only if you have a specific status for this
}

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># EXTRACTION LOGIC
class=class="hl-string">"hl-comment"># ==========================================

def get_auth_header():
    class=class="hl-string">"hl-comment"># For Cloud (Basic Auth)
    creds = fclass="hl-string">"{CONFIG['USER_EMAIL']}:{CONFIG['API_TOKEN']}"
    encoded = base64.b64encode(creds.encode()).decode()
    return {class="hl-string">"Authorization": fclass="hl-string">"Basic {encoded}", class="hl-string">"Content-Type": class="hl-string">"application/json"}
    class=class="hl-string">"hl-comment"># For Data Center (PAT), uncomment below:
    class=class="hl-string">"hl-comment"># return {class="hl-string">"Authorization": fclass="hl-string">"Bearer {CONFIG['API_TOKEN']}", class="hl-string">"Content-Type": class="hl-string">"application/json"}

def fetch_issues():
    url = fclass="hl-string">"{CONFIG['JIRA_URL']}/rest/api/2/search"
    jql = fclass="hl-string">"project = {CONFIG['PROJECT_KEY']} AND issuetype = Problem AND created >= -{CONFIG['LOOKBACK_DAYS']}d"
    
    all_issues = []
    start_at = 0
    max_results = 50
    
    while True:
        params = {
            class="hl-string">"jql": jql,
            class="hl-string">"startAt": start_at,
            class="hl-string">"maxResults": max_results,
            class="hl-string">"expand": class="hl-string">"changelog"
        }
        
        try:
            response = requests.get(url, headers=get_auth_header(), params=params)
            response.raise_for_status()
            data = response.json()
        except Exception as e:
            print(fclass="hl-string">"API Error: {e}")
            break
            
        issues = data.get(class="hl-string">"issues", [])
        if not issues:
            break
            
        all_issues.extend(issues)
        start_at += max_results
        print(fclass="hl-string">"Fetched {len(all_issues)} issues so far...")
        
    return all_issues

def parse_activity(issue):
    events = []
    
    class=class="hl-string">"hl-comment"># Basic Issue Data
    key = issue[class="hl-string">"key"]
    fields = issue[class="hl-string">"fields"]
    summary = fields.get(class="hl-string">"summary", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Current values (for attributes)
    current_priority = fields.get(class="hl-string">"priority", {}).get(class="hl-string">"name", class="hl-string">"")
    current_assignee = fields.get(class="hl-string">"assignee", {}).get(class="hl-string">"displayName") if fields.get(class="hl-string">"assignee") else class="hl-string">"Unassigned"
    
    class=class="hl-string">"hl-comment"># 1. Problem Record Created
    created_time = fields[class="hl-string">"created"]
    events.append({
        class="hl-string">"ProblemKey": key,
        class="hl-string">"ActivityName": class="hl-string">"Problem Record Created",
        class="hl-string">"EventTimestamp": created_time,
        class="hl-string">"UserKey": fields.get(class="hl-string">"creator", {}).get(class="hl-string">"displayName", class="hl-string">"System"),
        class="hl-string">"SupportGroup": current_assignee,
        class="hl-string">"Priority": current_priority,
        class="hl-string">"ProblemSummary": summary,
        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
    })

    class=class="hl-string">"hl-comment"># Process Changelog
    changelog = issue.get(class="hl-string">"changelog", {}).get(class="hl-string">"histories", [])
    
    for history in changelog:
        timestamp = history[class="hl-string">"created"]
        user = history.get(class="hl-string">"author", {}).get(class="hl-string">"displayName", class="hl-string">"Unknown")
        
        for item in history[class="hl-string">"items"]:
            field = item.get(class="hl-string">"field")
            field_id = item.get(class="hl-string">"fieldId", class="hl-string">"")
            from_str = item.get(class="hl-string">"fromString", class="hl-string">"")
            to_str = item.get(class="hl-string">"toString", class="hl-string">"")
            
            class=class="hl-string">"hl-comment"># 2, 5, 7, 9, 10, 11, 13, 14. Status Changes
            if field == class="hl-string">"status":
                activity = STATUS_MAPPING.get(to_str)
                
                class=class="hl-string">"hl-comment"># Handle Reopened logic explicitly
                if to_str in [class="hl-string">"Open", class="hl-string">"Reopened"] and from_str in [class="hl-string">"Resolved", class="hl-string">"Closed"]:
                    activity = class="hl-string">"Problem Reopened"
                
                if activity:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": activity,
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 2. Priority Changed
            elif field == class="hl-string">"priority":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Problem Priority Changed",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": current_assignee,
                    class="hl-string">"Priority": to_str,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 3. Assigned to Support Group (via custom field or Assignee)
            elif field_id == class="hl-string">"customfield_10010" or field == class="hl-string">"assignee":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Assigned to Support Group",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": to_str,
                    class="hl-string">"Priority": current_priority,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 6. Workaround Updated
            elif field_id == class="hl-string">"customfield_10011":
                if to_str: class=class="hl-string">"hl-comment"># Only if value is added/changed to something
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Workaround Updated",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 7. Root Cause Identified (via Field Population)
            elif field_id == class="hl-string">"customfield_10012":
                if to_str:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Root Cause Identified",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 4 & 8. Links (Incident Linked / Change Request Linked)
            elif field == class="hl-string">"Link":
                class=class="hl-string">"hl-comment"># This requires heuristic checking of the linked key or link type
                class=class="hl-string">"hl-comment"># Assuming standard keys: INC-xxxx for Incident, CHG-xxxx or CR-xxxx for Change
                if class="hl-string">"INC-" in to_str or class="hl-string">"Incident" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Incident Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
                elif class="hl-string">"CHG-" in to_str or class="hl-string">"CR-" in to_str or class="hl-string">"Change" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Change Request Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
            
            class=class="hl-string">"hl-comment"># 12. SLA Breached (Detection Logic)
            class=class="hl-string">"hl-comment"># Detection depends heavily on plugins. Common method: check for SLA status field change
            elif class="hl-string">"SLA" in field or class="hl-string">"Time to Resolution" in field:
                if class="hl-string">"breach" in to_str.lower() or class="hl-string">"fail" in to_str.lower():
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"SLA Breached",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXECUTION
class=class="hl-string">"hl-comment"># ==========================================
if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting extraction...")
    issues = fetch_issues()
    
    all_events = []
    for issue in issues:
        all_events.extend(parse_activity(issue))
        
    df = pd.DataFrame(all_events)
    
    class=class="hl-string">"hl-comment"># Add LastDataUpdate
    df[class="hl-string">"LastDataUpdate"] = datetime.now().isoformat()
    
    class=class="hl-string">"hl-comment"># Export
    filename = class="hl-string">"jira_problem_event_log.csv"
    df.to_csv(filename, index=False)
    print(fclass="hl-string">"Extraction complete. Saved {len(df)} rows to {filename}")

您的问题管理 data 模板

您的问题管理 data 模板

问题管理属性

问题管理活动

提取指南

Jira Service Management 问题导航器导出

步骤

配置

a 查询示例 config

通过带有 Changelog 的 Jira REST API 进行 Python 提取

步骤

配置

a 查询示例 python

准备好开始了吗？

立即优化您的问题管理流

您的问题管理 data 模板

您的问题管理 data 模板

问题管理属性

问题管理活动

提取指南

Jira Service Management 问题导航器导出

步骤

配置

a 查询示例 config

通过带有 Changelog 的 Jira REST API 进行 Python 提取

步骤

配置

a 查询示例 python

我们重视您的隐私

准备好开始了吗？

立即优化您的问题管理流