一、认识服务质量的“双重特性”
1.“好服务”的标准该如何界定？
我们该如何衡量服务质量？是看功能多、指标高，还是看客户满意度？答案是：质量不是靠感觉，而是靠特性定义出来的。在ITIL 4框架下，我们明确将服务质量解构为两个层面的属性：固有特性（Inherent Attributes）与指定特性（Specified Attributes），这就是服务交付价值的基础逻辑。
2.为何需要分层理解服务特性？
传统IT服务设计更多关注“技术实现”，往往忽略了“管理表达”。固有特性解决的是“服务做不做得好”，指定特性则关注“做得好是否能被证明、被监督、被协同”。这两类属性构成了ITIL 4中面向价值的服务质量体系的底座。

---

二、固有特性：服务本身的能力与技术特征
1.来自服务本身的“天赋基因”
固有特性是服务在技术架构、功能设计、系统能力等方面的“原生属性”。例如：系统支持的最大并发数、容灾等级、架构开放性、是否支持多租户、是否具备集群与热备功能等。这些不是通过配置改造，而是系统本身所具备的。
2.典型场景识别与表达方式
这些特性多体现于服务设计阶段，写入需求规格说明书（SRS）或系统蓝图中。在服务合同或SLA中，常见的固有特性表述方式如：

• “系统支持每秒1000 TPS的数据写入”；
  
• “服务具备双活部署架构”；
  
• “支持三年版本兼容性”。
  
  

它们是客户进行决策的核心依据，体现服务提供方的交付能力边界。

---

三、指定特性：服务过程中的管理可控性
1.聚焦可管、可控、可持续
指定特性更关注的是“服务怎么被运作”，包括数据的统计频率、指标的监控周期、服务报告的内容与格式、应急响应机制的规范、合规性审核的频率等。
它们体现的是组织如何将服务交付变成“可追溯、可优化”的流程，而非简单输出。例如：SLA达成率是指定特性，支持容错率是固有特性；日报报告周期是指定特性，系统日志自动留存是固有特性。
2.在合同与文档中如何体现？
指定特性通常以管理流程和服务控制参数的形式出现，比如：

• “服务提供方需每月提供一次服务报告，内容包括可用性、性能、工单处理等指标”；
  
• “事件响应时限为15分钟，首次响应需通过邮件和电话双通道确认”；
  
• “系统需符合ISO27001安全审核要求，接受季度第三方评估”。
  
  

这些内容是客户衡量服务“可用性保障”与“治理能力”的重要指标，直接影响服务满意度与信任建设。

---

四、固有与指定特性的契约表达策略
1.将技术能力转化为客户语言
很多时候，我们的系统具备强大的技术能力，但如果无法以客户理解的方式写进SLA，就无法转化为“客户价值”。一个例子：系统具备双活容灾架构，这个固有特性应转化为“RTO<15分钟，RPO=0”的指标条款。
我在课堂上曾举过一个例子：某单位在签约时强调“系统高可靠”，结果服务方提供的是冷热备架构，切换时间15分钟，数据丢失10秒，而客户以为是毫秒级无感知切换。最终因为缺乏契约化表达，双方产生纠纷。这个例子提醒我们，固有特性如果不在合同中明确写清楚其效果及业务影响，就容易出现预期错配。
2.指定特性构建服务“治理闭环”
一个好的服务协议不仅要写“我们能做到什么”，还要写“我们如何证明自己做到了”。指定特性恰恰是将服务运维流程、报告机制、评审制度等管理要素固化进协议体系的工具。例如：

• 服务报告由谁发送、频率多久、格式如何？
  
• 报告中是否包含趋势分析与问题改进？
  
• 达标率如何定义？如何进行季度评审与修订？
  
  

这类条款保障了服务从交付走向优化，从执行走向协同。

---

五、达成共识的策略建议
1.固有特性优先在前期设计中沟通
固有特性涉及系统能力与架构，变更成本高，因此应在需求调研阶段优先达成一致，并写入设计规范与初始合同中。这既保障了后续SLA谈判的底线，也避免了服务交付过程中因系统限制而频繁修订目标。
2.指定特性作为运营中持续协商项
指定特性则具有更强的可变性与协商空间，应纳入服务运营中的评审机制中进行周期性更新。通过持续服务改进（CSI）流程，逐步提升服务的感知价值与交付能力。


ITIL 4大师级课程官方授权讲师长河老师原创，末经许可，不得转载

一、认识服务质量的“双重特性”
1.“好服务”的标准该如何界定？
我们该如何衡量服务质量？是看功能多、指标高，还是看客户满意度？答案是：质量不是靠感觉，而是靠特性定义出来的。在ITIL 4框架下，我们明确将服务质量解构为两个层面的属性：固有特性（Inherent Attributes）与指定特性（Specified Attributes），这就是服务交付价值的基础逻辑。
2.为何需要分层理解服务特性？
传统IT服务设计更多关注“技术实现”，往往忽略了“管理表达”。固有特性解决的是“服务做不做得好”，指定特性则关注“做得好是否能被证明、被监督、被协同”。这两类属性构成了ITIL 4中面向价值的服务质量体系的底座。

---

二、固有特性：服务本身的能力与技术特征
1.来自服务本身的“天赋基因”
固有特性是服务在技术架构、功能设计、系统能力等方面的“原生属性”。例如：系统支持的最大并发数、容灾等级、架构开放性、是否支持多租户、是否具备集群与热备功能等。这些不是通过配置改造，而是系统本身所具备的。
2.典型场景识别与表达方式
这些特性多体现于服务设计阶段，写入需求规格说明书（SRS）或系统蓝图中。在服务合同或SLA中，常见的固有特性表述方式如：

• “系统支持每秒1000 TPS的数据写入”；
  
• “服务具备双活部署架构”；
  
• “支持三年版本兼容性”。
  
  

它们是客户进行决策的核心依据，体现服务提供方的交付能力边界。

---

三、指定特性：服务过程中的管理可控性
1.聚焦可管、可控、可持续
指定特性更关注的是“服务怎么被运作”，包括数据的统计频率、指标的监控周期、服务报告的内容与格式、应急响应机制的规范、合规性审核的频率等。
它们体现的是组织如何将服务交付变成“可追溯、可优化”的流程，而非简单输出。例如：SLA达成率是指定特性，支持容错率是固有特性；日报报告周期是指定特性，系统日志自动留存是固有特性。
2.在合同与文档中如何体现？
指定特性通常以管理流程和服务控制参数的形式出现，比如：

• “服务提供方需每月提供一次服务报告，内容包括可用性、性能、工单处理等指标”；
  
• “事件响应时限为15分钟，首次响应需通过邮件和电话双通道确认”；
  
• “系统需符合ISO27001安全审核要求，接受季度第三方评估”。
  
  

这些内容是客户衡量服务“可用性保障”与“治理能力”的重要指标，直接影响服务满意度与信任建设。

---

四、固有与指定特性的契约表达策略
1.将技术能力转化为客户语言
很多时候，我们的系统具备强大的技术能力，但如果无法以客户理解的方式写进SLA，就无法转化为“客户价值”。一个例子：系统具备双活容灾架构，这个固有特性应转化为“RTO<15分钟，RPO=0”的指标条款。
我在课堂上曾举过一个例子：某单位在签约时强调“系统高可靠”，结果服务方提供的是冷热备架构，切换时间15分钟，数据丢失10秒，而客户以为是毫秒级无感知切换。最终因为缺乏契约化表达，双方产生纠纷。这个例子提醒我们，固有特性如果不在合同中明确写清楚其效果及业务影响，就容易出现预期错配。
2.指定特性构建服务“治理闭环”
一个好的服务协议不仅要写“我们能做到什么”，还要写“我们如何证明自己做到了”。指定特性恰恰是将服务运维流程、报告机制、评审制度等管理要素固化进协议体系的工具。例如：

• 服务报告由谁发送、频率多久、格式如何？
  
• 报告中是否包含趋势分析与问题改进？
  
• 达标率如何定义？如何进行季度评审与修订？
  
  

这类条款保障了服务从交付走向优化，从执行走向协同。

---

五、达成共识的策略建议
1.固有特性优先在前期设计中沟通
固有特性涉及系统能力与架构，变更成本高，因此应在需求调研阶段优先达成一致，并写入设计规范与初始合同中。这既保障了后续SLA谈判的底线，也避免了服务交付过程中因系统限制而频繁修订目标。
2.指定特性作为运营中持续协商项
指定特性则具有更强的可变性与协商空间，应纳入服务运营中的评审机制中进行周期性更新。通过持续服务改进（CSI）流程，逐步提升服务的感知价值与交付能力。


ITIL 4大师级课程官方授权讲师长河老师原创，末经许可，不得转载