技术运营管理过程是技术运营能力建设的一个过程，它以业务为中心，交付稳定、安全、高效的技术运营服务，构建业界领先的技术运营能力，支撑企业的持续发展和战略成功。技术运营不仅要具备全局的架构视野和运维与监控规划，而且还需要从事件管理、变更管理、容量管理、成本管理和用户体验管理来综合为业务提供技术保障。
技术运营管理过程分为:监控管理、事件与变更管理、配置管理、容量与成本管理、高可用管理、连续性管理、用户体验管理等，如表1所示。
| 技术运营 | ||||||
|---|---|---|---|---|---|---|
| 监控 管理 | 事件与变更管理 | 配置管理 | 容量与成本管理 | 高可用管理 | 连续性 管理 | 用户体验管理 |
| 监控采集 | 事件管理 | 运营配置管理 | 容量管理 | 应用高可用 管理 | 应急管理 | 业务认知管理 |
| 数据管理 | 变更管理 | 成本管理 | 数据高可用 管理 | 风险管理 | 体验管理 | |
| 数据应用 | 危机管理 |
监控管理是技术运营保障服务质量的手段之一，是衡量技术运营能力重要纬度。监控管理从数据流的纬度展开度量成熟度的分级，分别是监控采集、数据管理、数据应用。
监控数据的源头，包括数据的获取方式、兼容性、传输方案等能力的描述。
采集能力服务化，从采集的手段、支持的协议、兼容性、颗粒度、采集端的基础逻辑和扩展逻辑等角度对能力进行量化评估。
采集能力的数据传输能力原子化，从传输数据质量保障、传输的可用性、传输过程中支持的功能特性的纬度来评估成熟度。
| 级别 | 采集服务 | 数据传输 |
|---|---|---|
| 1 | 1、通过系统自带的命令完成监控采集（无agent），如ssh、scp 2、通过开放的通用协议进行数据采集（无agent），如http、syslog、snmp等 | 无 |
| 2 | 1、独立采集服务，逻辑与配置分离 2、支持可扩展、高可用的数据采集架构 3、嵌入sdk/api实现私有协议的数据上报 4、支持系统日志、应用日志等数据格式上报 5、量化管理采集服务在企业应用的覆盖率 | 1、通过agent完成数据采集 2、通过捕获终端标准数据来实现系统输出的数据采集 |
| 3 | 1、提供统一采集服务能力 2、采集服务具备跨平台兼容性的能力 3、提供集中式的采集配置能力，如采集内容、开关等 4、采集端具备实时性管控、发送延迟、数据校验、统计等管理逻辑 5、新增采集逻辑通过插件化扩展，有自定义监控内容的能力 6、提供开放式、自定义的数据上报方案，协议可灵活扩展，有协议机制保障数据的可靠性 7、内置常用排障数据格式的支持，如tcpdump、自定义日志 8、对监控采集有限制、限频等管理办法，确保不影响生产服务 9、数据采集规模（指标、采集对象、实时性）与性能量化的要求 | 1、有高可靠数据传输通道，传输通道有高可用容灾方案 2、支持多种传输方案，如push或pull 3、可定制数据传输的存储节点，单份数据多份传输目标的分发能力 |
| 4 | 1、采集服务支持频率调节 2、采集架构支持平行扩展、数据汇聚、高效传输等特性 3、监控采集支持智能分析和决策，动态调整采集服务，如采集的内容减少、频率降低等 4、支持更细粒度的采集能力的配置 | 1、具备数据传输质量保障的能力，如支持分片、压缩、断点续传等传输特性 2、支持数据加密、解密及校验等 |
| 5 | 1、监控采集能力由固定规则到动态规则，并且与技术运营能力联动 2、可配置的关联运维事件，实现同一运维对象的不同采集内容变化。（如动态识别容量压测事件的采集内容、堆栈分析排障的采集内容） | 同上 |
作为数据处理服务端的数据接收服务，承接数据采集服务传输来的数据，需要拥有良好的吞吐性能和可扩展的架构，并且能却分数据类型和相应处理的功能逻辑。
指的是大数据处理的逻辑，支持逻辑运算、统计方法、机器学习等计算能力，可结合技术运营的场景，灵活实现数据的扩展与关联分析。同时，需考量数据处理的规模、性能及架构的能力。
针对监控数据的存储场景，对存储的方案、架构、存储成本、数据高可用等纬度综合评估能力成熟度。
| 级别 | 数据筛选 | 数据处理 | 数据存储 |
|---|---|---|---|
| 1 | 1、支持较强的数据接收吞吐性能 | 1、能对原始数据源有预处理能力， 2、对异常数据有识别与校对的机制。 | 1、有独立数据存储方案 |
| 2 | 1、支持可扩展的数据接收架构能力 2、支持对原始数据有清洗、校对等识别异常数据的能力与机制 3、支持数据转发、丢弃、复制等数据接收逻辑 4、支持异构数据源的集中数据接收 | 1、支持自定义数据四则运算、统计（分类、聚类）等常用逻辑 2、支持对外支持易用的API数据服务。 3、通用可扩展的ETL，如数据清洗、转换、导入、加载等数据处理特性。 4、支持异构异数据源的处理、关联分析等。 | 1、支持统一的数据存储管理 2、存储架构支持可扩展，如数据类型、容量 3、存储能力支持数据一致性、完整性、可用性等特性 4、支持多种数据类型的存储方案，如时序数据、文本、数值型 |
| 3 | 1、支持分钟级全网数据上报的数据接收架构能力 2、数据接收平台化，可灵活对接不同上报数据源 3、对外提供统一数据上报api服务，满足多协议多格式的数据源，如文本、字符串、加密协议等。 4、支持数据检查，如识别空值、乱码、属性校验等，保证数据质量 | 1、可扩展数据处理架构，区分实时计算与离线统计场景 2、数据处理架构支持平行扩展 3、支持数据处理延时小于1分钟 4、支持结构化与半结构化的数据的处理，如时序数据处理、自定义日志字段解析等 5、支持数据处理阶段的逻辑异常的监控告警能力 6、有数据校正、不丢失、保持数据完整性的能力 | 1、支持高密度的数据存储查询能力 2、按数据使用场景区分冷热数据的存储架构方案 3、支持自定义数据集 4、数据存储的数据安全性，备份、容量等高可用考虑 5、支持时序数据库提供的时序数据的统计功能 |
| 4 | 1、根据数据上报量动态管理数据接收容量与吞吐性能 2、接收服务防雪崩架构 3、支持秒级级全网数据上报的数据接收架构能力 4、数据吞吐的性能与处理规模能满足该公司业务未来一段时间的发展，按照同时在线和指标的规模，推算一个规模值 | 1、数据处理逻辑配置化、可视化，可编排任务。 2、支持插件化扩展新数据处理逻辑或数据模型 3、数据处理配置为引入机器学习模式提供平台能力支持 4、可灵活关联不同数据源，按业务场景组织多源数据 | 1、确保存储成本合理前提，最大化存储原始数据，以支持查询检索和离线计算（按业务场景所需来定义存储时长） 2、并根据已知的数据用途对数据进行有效的预加工和训练 3、支持对外数据接口能力，支持数据统计能力 |
| 5 | 1、支持PB的数据规模的数据筛选能力 | 1、基于机器学习的智能数据分析能力，实现持续进化的发现新的数据特征 2、通过AI能力达到故障预测等数据效果，有业务价值 3、数据处理规模与性能达到PB级，通过架构可扩展性论证。 | 1、存储模型支持机器学习对数据集管理的需求 |
监控数据的用途是衡量监控管理能力的一个重要能力项，应用按场景的不同主要分成三个方向：告警与管控、数据服务、可视化。
监控对异常识别的能力，包括对异常判断逻辑、管控能力、与业务场景的关联等。
指技术运营需具备可开放的数据服务能力，为其他系统整合与关联技术运营的数据提供支持。
可视化是监控数据指导技术运营工作的开展的重要能力项之一，包括了展现灵活性、可定制性、智能化和运维场景结合度的评估。
| 级别 | 告警与管控 | 数据服务 | 可视化管理 |
|---|---|---|---|
| 1 | 1、通过阈值异常识别。 2、有简单的收敛方案，能够多通道发送告警信息。 | 无 | 1、支持在线数据图表展示的功能。 |
| 2 | 1、支持监控对象的分级告警。 2、对重大告警的管控有标准流程指导。 3、存储告警明细记录，支持告警统计数据的系统导出。 4、对告警触达率有统计分析和要求 | 1、数据支持常见统计方案的加工，如max、avg、排序等 2、数据支持按条件数据导出 3、数据支持复制、同步、传输到其他存储介质 4、支持自定义数据接口和内容的数据服务 | 1、可自定义图形或表格 2、大屏展示重点的业务监控指标。 3、支持在线数据查询能力 |
| 3 | 1、支持预警、告警通知等管控能力 2、支持告警关联用户自定义功能/工具，实现事件触发的能力。 3、支持配置化或规则化的告警关联分析或关联收敛。（单对象多事件） 4、告警通知支持自定义升级机制。 5、对基础/标准化的告警有自动化工具实现故障自愈或绕行。 6、有告警风暴管理能力，如抑制、收敛等管控能力 | 1、数据支持在线自定义分析逻辑实现，如在线sql 2、支持自定义离线或异步的大规模数据计算，如批量mapreduce计算 3、以接口化的形式提供数据服务的管理能力（限频、限制来源等等） 4、数据服务提供对业务或技术优化的支撑的数据结论 5、具备数据安全管控能力，如按需分配权限、数据加密或脱敏等。 | 1、提供基于业务拓扑架构或调用关系的数据可视化功能 2、可视化展示能标示监控异常点 3、支持数据的多维维度展开、下钻 4、视图反馈KPI的数据，对监控数据的提炼和加工汇总。 5、支持权限分级管理，支持按需申请视图使用权限 |
| 4 | 1、支持动态阈值的告警能力，效果比传统模式有提升。如降低告警量、准确性提高。（非统计学算法，强调机器学习手段的引入，且突出效果优于传统方案） 2、对多对象多事件的关联、抑制和收敛能力。 3、自动升级语音电话服务，告警通知、升级与组织架构关联。 4、与其他运维事件关联，实现告警触发的快速根因定位与修复能力。 | 1、数据监控链条支持1分钟端到端输出结果的能力 | 1、运维可视化可根据业务场景的需求，可视化的配置方式所需的图表或功能。 2、可体现异常点对全局的影响分析 3、支持多用户角色协作管理 |
| 5 | 1、按业务场景实现业务影响评估、故障自愈、故障智能调度、业务智能止损等告警发现与平台管控的能力。 2、支持故障发现、根因分析、架构优化等技术运营的目的。 | 1、智能数据推荐服务 2、智能分析设备及应用等关联关系，智能分析影响范围，为变更，故障等分析决策过程做数据支撑。 | 1、智能视图的推荐。 2、按业务场景智能生成监控视图。 |
事件和变更管理是技术运营和IT服务过程中两个重要管理手段。前者对影响生产的事故&问题建立预防、高效处理及度量改进。后者则是对IT 基础设施、系统应用、业务产品配置等场景实施变更所进行的审批和控制。
通过事件管理过程的细分，明确了不同阶段事件管理的重点，从快速发现到高效的处理流转再到复盘改善的跟进，建立起事件全生命周期的管理。
事前管理要求在事前对于事件能够做到定义清晰、完备问题发现能力以及预防止损措施。如监控覆盖、信息周知和上升等
事件处理包括应急响应的流程及要求、事件处理团队内外部的协同配合机制。
故障后的学习与改进的能力衡量，通过复盘、不同维度的事件分析等方式保持对事后改善工作的落地。如客户评估、演习验收等手段确认达标。
| 级别 | 事前管理 | 事件处理 | 事后管理 |
|---|---|---|---|
| 1 | 1、没有对事件的分类、分级定义。 2、依赖用户报障，无主动事件发现工具。被动受理和处理系统故障。 | 1、能够执行好事件的应急响应要求，有基本的达标率要求。 如：业务研发、运维、QA响应和反馈要求、重大故障的响应流程、处理时效等。 2、在事件处理过程中，除事件处理和解决团队外，有专门的事件跟进团队，能够对各类事件的处理过程进行追踪跟进、跨部门协调等。 | 1、在事后被动的建立起基本的学习改善机制。 如：事后复盘、case study 2、开展基本的度量考核工作、事件记录，关注事故数、止损时效、解决率等。 |
| 2 | 1、对事件有基本的分类和级别定义。 说明：在级别和故障属性有初步的分类。例如严重程度分类“严重事故”问题类别 “系统bug类” 2、在团队层面定义了基本的发现和受理事件的要求，有明确的处理团队。通过初期的工具和流程收集到事件（被动方式），建立起监控和周知机制。 说明：例如保障监控触达和应急人员的主备信息表等等。 | 1、具备完整的事件管理覆盖，根据完善的事前对事件的分级定义，在出现事件的第一时间完成预定级。 2、对各类型和等级有事件处理的细化流程和准确定级（有基于影响度、紧急度、优先级的判定规则）；对于重大事故、突发事件有高效的流转、升级和决策能力。有效保证各等级事件处理时效性符合服务级别要求。 如：包含多指标的定级依据，整体匹配度和认同度高。决策委员会，无决策断点。 3、通过服务台统一接口，一二三线配合QA团队，确保事件处理过程高效执行、协作默契。事件处理和结单按照等级时效要求。事件管理的度量结合到KPI。 说明：有细化的团队以及个人考核规则，重复事故、严重事故占比、完整事件总数趋势（投诉、缺陷、事故）、结单率、MTTR、可用性、SLA等等。 | 1、事件分析，从不同角度分析统计（如团队、模块、类别、过程、原因）能够阶段性提出统筹改善点，执行优化改进。在事后跟进上事件后期做到改善措施的落地和验证。 说明：完善的质控介入，分为研发的全生命周期（产品需求变更度量），灰度、变更等环节都有覆盖和执行评估。止损意识包含临时修复的意识。 2、基础端和应用端会定期的开展事故模拟演习和压测以检测改善是否达标。度量事后管理的工作质量，对IT团队有对应的考核。 |
| 3 | 1、对于事件有较详细的划分。具备完善的组织和系统支持，确保更主动地先于用户发现事件，根据事件级别有清晰的事件周知和升级机制。 如：区分问题和事故以及各类严重级别和分类（安全类、系统类、用户体验类/事故类、问题类），较为细化的定义。 2、提前建立起应对各类事件场景的预案，定义好各团队的配合职责。有IT服务类平台，事件发现流程和各工具是相互打通的。确保发现事件后的流程是高效顺畅的（主动方式） 例如:预案库完善，团队上一二线的划分职责明确。7*24值守发现力度。建立起IT服务门户关联好流程。如监控发现触发建单、建单后的事件告警通知等等。 在基础和应用层能够建立统一标准的监控系统，同时也具备开放接入自定义监控的能力，并考虑到人员互备和升级。 | 1、事故处理效率提升，通过架构容错能力、智能监控、故障自检自愈等能力手段缩短发现事故、响应事故和处理事故等分阶段提升。规范事件的流程管理模式。 如：升级划分水平和结构性/垂直。大型组织N线（4线以上）的支持划分。事件职能划分（事件经理、流程经理），回顾事件、修改流程、考核（事件处理成本、问题解决的时间、问题总数..）等。 2、在协同配合机制上，在三级基础上。除技术维度以外也要加强与公关、客服的配合。建立好信息同步、对外沟通的预案。在跨团队跨职能的事件处理协作上整体打通。 | 1、遵循事件终止原则，直至改善达成客户满意才可终止。并关联到IT服务管理的整体提升。 如：针对性的故障模拟演习甚至monkey test，也扩展至系统以外的场景；改进措施的客户确认等。 结合到配置管理、发布管理、变更管理等定期的协同改善。 2、事件分析具备更高的分析视角，能够和其他流程的共同完善。如：配置管理数据库在事件管理占据重要的地位，基础设施故障高效排查的核心工具。 一定的智能化分析，通过持续的输入能够分析出一定量和场景的事故问题前兆。 |
| 4 | 1、精细化组织结构建设以及协同能力打造。如：一二三线的划分，角色划分、从工具到平台化的升级。其他IT流程机制上能帮助事件提前发现。如：非常规变更的信息触达，变更管理考虑到风险控制和对事件管理的信息传递机制。前置配置管理的严格执行保障信息的完整，提升发现效率。 2、事件发现平台有深度的建设和智能化的设计，告警收敛和提高准确率、事件合并等等，以降低事件管理的运营成本。和其他IT系统有完整的关联打通。 如：立体监控--完整监控项的覆盖、根因分析、智能收敛、历史基线等 3、问题信息及时录入工单系统和CMDB，为故障发现提效。做到不同组织下的监控和反馈等事件相关信息的打通。 如：关联到一线客服、公关、安全舆情等更多信息源数据的持续完善。 **（举例中的内容，在评审的操作中，是否要求全部满足？建议要提炼出对企业最关键的必备评估项，企业如何证明自己具备该项能力。） | 同上 | 同上 |
| 5 | 1、同上基础上。考虑设备供应商、第三方服务的公司需要考虑让周边合作伙伴也能达到一定的运维标准。 如：合作伙伴也需要达到事件管理的3级。 智能化更高的要求。 | 同上 | 同上 |
对IT 基础设施、系统应用、业务产品配置等场景实施变更所进行的审批和控制。
通过对变更进行评估，从而确保能够在对用户、服务产生最小负面影响的情况下实施这些变更，同时通过在组织内进行有效的协商和沟通，确保所有的变更都具有合理评估和可追溯性。
| 级别 | 事件变更流程管理 |
|---|---|
| 1 | 1、无完善的应急处理流程。和区别常规变更的授权机制。 如：应对突发的被动处理响应 |
| 2 | 1、变更操作有规范和制度要求。如变更文档、变更计划安排、对于研发内部干系方的周知、基本的影响评估、能够在非生产环境验收。 如：有特定的变更窗口、人员要求、变更评估审批要求、中断时间要求、组织层面具备变更规范制度和文档等等 2、达到变更质量基本的度量 如：实施时间、记录、失败率、回滚率等，整体质量较低 3、有更高效的计划外变更能力。 4、组织结构有应急场景有针对性的设计。 如NOC、IT服务台、工作时间外的值班二线等。 如突发事件的止损规则、特殊授权。 |
| 3 | 1、变更管理流程做到进一步细分，覆盖到发布、部署管理流程、配置管理流程集成等分支流程或场景的要求、每次部署活动提供变更范围报告和测试报告、执行后值班留守的要求。建立起变更审批流，整体的流程主要建立在工作流工具体系之上。 说明：变更管理在多方面会更加精细化，一方面的过程覆盖更加完整，另外在维度上更加具体要求。例如会增加审计的要求，变更审批会关联到层级、职能关系、业务关系。变更方案的步骤和量化会动态的更新维护。（测试验收要求、配置管理要求等等） 2、变更前后的工作：建立变更顾问委员会，能够对变更带来的影响详细的评估，定期组织会议对历史变更进行回顾和总结。变更后的信息反馈。 如：CAB组织（变更经理、服务经理、服务台代表、供应商、客户等） 3、变更质量度量：部署失败率整体较低 如发布成功率95%以上，绝大多数的变更是成功的。 4、完善的应急团队和各条线响应要求 说明：同事件管理中的应急要求相类似，团队的多线条划分、职责、协同流程等都会要求。 5、应急变更操作能够按照预案设定，有较高的执行度。链条操作要求自助化高效实现。 如：一线的操作场景圈定，能力处理一般故障（负载均衡层的调度、设备下线、自动策略执行后的确认等） 6、运维人员通过事先的应急自动化工作，做到有脚本/工具支持的高效处理。 |
| 4 | 1、变更管理流程覆盖全面融合到技术运营的平台化实现，打通配置管理、发布管理等后置流程。兼顾变更前后的周期也支持DevOps其它相关流程，覆盖DEV和QA环节的要求。 说明：完整IT支持能力（体系）基础上的变更，如配置管理、发布管理、基础架构等各能力域关联过程的协同达标。 2、变更管理流程有较高的自动化程度（变更前和变更后）。重视变更后的风险控制以及变更工作的分析。如变更次数、变更合理性、变更后的监控&舆情跟进等。 变更的实施完全遵循定义、规划、构建、测试、验收、评估的特定顺序。 3、变更质量度量和要求：部署失败率整体达成率很高，按照模块、团队、应用都能达到99.95%以上，全年无发布升级导致的重大故障。 补充：不同企业的数据口径有差异，单独讨论供参考。 4、在基础和应用端以外的变更风险关注，如工具类变更，持续集成的集成工具替换、签名系统的升级；客户端SDK的替换；流程类变更的风险评估； 5、应急团队的完善同上并匹配和运维开发、算法团队对异常场景的深度分析和策略制定。 |
| 5 | 同上 |
配置管理作为技术运营工作的基础数据，为技术运营的工作的开展提供必要的配置对象管理、录入、关联等功能，各个技术运营系统可以基于此配置数据实现自动化运维、监控管理等功能。
运营配置管理特指与技术运营相关的配置数据，包括配置管理系统的基础功能与扩展能力，配置对象的说明与对象间的关联与应用场景。
配置管理能力由管理方法或系统承载，从配置记录更新的实时性、配置管理的流程机制、系统接口能力、智能化等角度来评估能力的成熟度。
根据技术运营的场景枚举需要纳管的配置对象和对象间的关联关系，主要评估配置对象记录和其属性的数据获取方法、配置的可扩展性、配置数据定义权责，以及基于配置数据可指导开展的运维活动。
| 级别 | 配置管理能力 | 配置对象与关联关系 |
|---|---|---|
| 1 | 1、无系统管理，依靠文档离线记录配置信息。 | 1、支持基础设施记录，且完整记录其属性 |
| 2 | 1、使用统一配置管理系统，对外提供API接口供其他IT系统调用与消费。 2、配置项的变更有流程支持，通过人工维持数据准确性。 3、配置系统能反馈在线运维对象的运行状态。 4、支持配置数据记录变更日志，可回溯可审计。 5、记录配置对象的版本化信息，可与应用生命周期其他阶段的版本信息关联 | 1、支持更多配置项，如业务、应用等记录与其属性。 2、支持配置对象生命周期中，不同阶段的状态和对应的通知管理。 3、支持配置对象目录管理 |
| 3 | 1、系统权限与组织分工关联，有定期的权限更新机制。 2、有定期校对机制保证配置数据的一致性与准确性 3、支持多用户视角的数据统计与展现 | 1、支持配置对象的自动发现，如基础设施、应用程序。 2、支持自定义配置对象模块、支持扩展字段，且支持与通用对象模型间的关联管理。 3、支持运维事件与配置对象变更的关联，如运维告警关联返回码配置 4、全局的配置系统和对象有纳管方案，需要被关联的范围，要按照目前已知的工作需求建立关联关系 5、对核心配置数据确定负责的部门与定义者，其负责数据源准确性的 |
| 4 | 1、配置项的变更有自动化流程支持，统一变更API接口。 2、有自动化的手段保证配置数据一致性，且有对应的数据纠正机制。 3、配置数据变更支持外部系统的通知与回调，能联动其他系统。 | 1、自动关联配置对象间的关系，能与其他IT系统的基础数据进行联动，智能识别内建关联关系。 2、配置数据为运维活动提供支持，如主动巡检、资产核算、配置与监控、容量管理等。 3、配置对象间的关联数据，可辅助绘制业务功能架构的可视化展示。 4、统一的数据标准管理方法/工具，包括数据负责人、定义、来源、依赖、对外提供的服务等 |
| 5 | 1、配置管理系统为运维智能决策提供数据支持。 2、按场景智能组装出配置管理的流程、变量，实时产生适用的规则 | 1、持续扩充与完善配置对象与对象间的关联关系。 |
容量是广义的capacity在负载、性能和业务量的综述，与成本管理组合可量化技术运营的质量和效率管理纬度的能力。
包括三个纬度：硬件负载、吞吐性能、业务量，以及这三个容量管理纬度与运维活动的结合。
容量管理中与IaaS相关的能力项，包括指标纬度、统计方法、可指导的运营活动等。
以业务的视角来组织容量的数据，让容量的指标与业务的实际质量和运维效率结合，指导运维工作开展。
| 级别 | 硬件容量 | 业务容量 |
|---|---|---|
| 1 | 1、支持按硬件集群等维度聚合性能（IaaS、OS层）指标，且支持容量监控与告警。 | 1、支持按业务功能模块或服务等维度聚合性能指标。 2、支持容量监控与告警。 |
| 2 | 1、有反馈业务容量的指标（请求量、成功率、延时），支持多维度的容量统计报表或视图（接口、应用、功能等） 2、支持实时容量查询，并提供容量API服务 3、支持可自定义的容量计算方法（max、avg等） 4、根据不同运维对象的容量特征，多维度的量化管理其容量指标（如访问密度） 5、容量管理与标准硬件管理结合，常态化压测容量基线 6、有容量主动巡检发现机制 | 1、对硬件容量的统计能力，支持多维度的容量统计报表或视图（地域、idc、region、项目） 2、支持实时容量查询，并提供容量API服务 3、支持可自定义的容量计算方法（max、avg等） 4、根据不同运维对象的容量特征，多维度的量化管理其容量指标（如访问密度） 5、容量管理与标准硬件管理结合，常态化压测容量基线 |
| 3 | 1、业务架构有动态容量平衡能力，能够根据业务分布差异，动态调整业务量与容量的配比（如负载均衡、平行扩展等） 2、有容量弹性伸缩方案，并定期演习容量调度能力 3、有容量预测的模型，供运维活动参考开展 4、容量灾备分布，有可调度的容量备份方案（建议放到业务连续性） 5、支持定期容量预警，如CPU>80%、每小时增长斜率>20% | 1、业务层容量指标与硬件的容量指标关联分析， 2、常态化容量压测行为，定期分析线上业务容量水平。 3、业务可以根据容量数据决策调度的能力（如过载保护、防雪崩） 4、业务的柔性服务能力，如有损服务、容量弹性伸缩。（柔性、有损的概念要有名词解释） 5、根据业务运营或发展，对业务容量预测的模型，供运维活动参考开展 6、按业务分布、容灾，有演习调度策略定期演练（建议放在连续性管理） |
| 4 | 1、支持按运维场景的容量管理方案，如母机容量、链路容量、IDC容量 2、为实现容量优化开展对应的运维活动，如故障与容量数据关联 3、扩大容量预测场景，从单集群容量预测到链路容量预测（母机） | 1、支持业务调用链路的容量分析方法、报表、视图 2、能对业务请求链路中的容量/性能瓶颈进行分析及展开技术优化 3、容量指标为其他运维活动提供数据支撑与关联分析，如故障与容量数据的关联 4、基于链路的容量预测，指导保障业务连续性的容量分布活动 |
| 5 | 1、硬件容量、性能、损耗的智能化预测分析与高准确率 | 1、硬件层与业务层的容量管理实现智能调度、智能决策 |
量化管理运维对象生命周期的运营成本，以及必要的成本管理活动，包括合理性分析、架构优化、容灾规划等等。
对运营成本的主动分析，与容量数据、配置管理数据的结合，并指导运维优化活动的开展，推动架构优化、自动化等能力的建设。
成本管理的一个重要环节，建议成本与业务的关联，并根据业务的发展有计划的申请资源，并定期核对资源的使用合理性与必要性，寻求质量与效率的最优组合。
| 级别 | 成本合理性 | 预算与核算 |
|---|---|---|
| 1 | 1、支持硬件生命周期管理，能标示和记录硬件的不同状态。2、支持软件生命周期管理，有规则流程指导软件的立项、上线、变更、下线等生命周期中不同阶段的对应管理。 3、成本管理涉及的数据记录，须保证与生产环境的实际状态一致。 | 1、有预算能力，有流程支持预算申请。 2、核算能力，有资产配置表，包括硬件、软件资产的记录管理。 |
| 2 | 1、支持丰富成本管理的内容，包括软硬件、云资源、带宽等资源的成本结构和分析，并按需组织多维度成本数据。（云资源指的CPU核数、存储量要有成本换算的方法） 2、成本数据与容量数据关联，对于生产容量、容量扩缩容等运维活动的合理性，能输出成本管理角度的分析和建议。更细粒度的成本管理，从单机到单核的精细化成本使用和管理。 3、有主动的成本优化动作，如库存分析、库存预警、硬件损耗预测、预算预测等（合并：资源的精细化利用方案，离线计算、混布） 4、有例行化的成本管理活动，如架构评审、架构成本合理性分析等。 | 1、预算管理，过期机制、更新机制，主动成本分析流程机制（支持软件与硬件）。 2、有规则流程指导硬件的采购、使用、淘汰等生命周期中不同阶段的对应管理行为。 3、核算纳管所有环境（开发、测试、生产等） |
| 3 | 1、有面向业务场景的成本管理活动，如带宽的削峰填谷、离线计算的应用等。 2、结合业务架构与容量数据，智能分析出业务的容量水位线、容量模型，提供优化建议。 3、成本管理策略与容量管理、吞吐性能关联分析，并指导运维活动的开展。 | 1、利用云服务和技术让成本控制更灵活（如缩短采购周期、弹性伸缩） 2、例行化的成本分析与预测，并系统化支持输出统计图表 3、常态化成本核算的数据校对，有生产数据与设备记录的定期核算机制与流程 |
| 4 | 1、根据成本管理的目标智能调度、智能决策，自动化各个环节的活动。 | 1、建立业务架构与成本的关联，成本数据为技术选型提供辅助决策信息 2、支持业务预算与核算的模型，并且与业务指标建立关联，实现按指标与预算联动（给出模型的推算过程） 3、业务成本预算需要有成本合理性分析与说明来支撑决策。举例，要上线一个新功能，要从架构角度说明成本的消耗分布，结合成本管理的历史数据，要求做到最优。 4、自动化完成核算工作，供业务商业化参考。 |
| 5 | 同上 | 1、根据业务指标智能完成预算的一系列运营操作与活动。 |
高可用管理包括应用高可用管理和数据高可用管理。
可用是指系统无中断地执行其功能的能力，代表系统的可用性程度。
目的：应用层包含了系统应用的业务处理逻辑，可以分为接入层，应用层和服务层，因为业务处理逻辑复杂，应用数量往往较多，需要在具备弹性可扩展能力的同时还需要具有很好的柔性容错能力。
应用节点可以快速横向扩展并更新应用至最新状态上线承载流量，甚至可以根据监控性能指标或按计划进行应用的动态扩容伸缩。相关说明如下：
支持多种负载均衡算法，根据后端性能灵活的分配一定比例的流量给后端服务器，具备流量切换的能力。如Nginx，Zuul，Kong
1）服务节点自动注册，自动发现，自动路由到新发现节点；2）服务节点宕机自动下线，节点异常自动下线与隔离；3）注册中心本身高可用；4）举例，如Zookeeper，Eureka，Consol，Etcd。
有完备的应用服务间调用关系治理的平台，具备完善的应用服务级别的监控报警。通过管理平台，可以对所有服务消费者和服务提供者进行管理，如上线下线，权重调整，调用统计等操作。
1）灰度发布：分批发布，逐步扩大至整个集群全部完成；
2）结合流量切换操作：每批发布的机器在操作前都摘除流量再更新操作，更新完毕后切回流量。
失效转移与重试
当部分应用节点故障或者性能严重下降时，应有机制实现自动将该故障节点从在线服务列表中去掉，以避免仍对生产产生影响。应用调用有重试机制，以保证在网络不好或其他原因导致调用失败情况下还可以重试保证尽量调用成功。
限流管理
当访问流量超过能承载的能力时，有能力对流量进行主动限制，以避免流量过载导致后端服务崩溃。
业务降级管理
划分核心功能和非核心功能，当出现故障或资源瓶颈时，在不能立即恢复业务的情况下，优先把资源留给核心功能，主动降级部分非核心功能，以保障核心功能正常运行，技术上可以把降级做成后台管控的开关以便快速降级及恢复操作。
分布式消息
消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。
具备集中式的运行与维护管理平台，监控具备从主机监控到端口监控，到业务层面的立体的监控，结合配置管理系统实时更新状态信息，集中展现，信息全面准确。引入智能化的技术，智能预测业务增长、故障预警，动态止损、智能调度。
| 级别 | 弹性能力 | 柔性能力 | 运行与维护管理 |
|---|---|---|---|
| 1 | 1.应用系统散乱，难以理清服务间的调用关系，扩展能力差，扩容时间久，依赖手工操作。 | 1.系统健壮性差，硬件故障等问题极易造成业务中断。 | 运行存在风险，依赖人工监控、报障，维护困难 |
| 2 | 1.有较好的应用系统规划，能够结合经验进行应用服务间调用关系的梳理，容量瓶颈需要较长时间才能完成扩容。 2.负载均衡支持多种负载均衡算法，根据后端性能灵活的分配一定比例的流量给后端服务器，具备流量切换的能力。应用发布或数据库变更易造成业务中断或者抖动。 | 1.系统健壮性有提高，但在硬件故障等情况下仍有可能出现业务上的长时间中断或异常，容量瓶颈需要较长时间才能完成扩容。 | 具备主机监控、进程端口等监控，信息不易查看，排障时间长。 |
| 3 | 1.有良好的应用系统规划，有准确的应用服务间调用关系的梳理及监控报警。 2.应用节点可以快速横向扩展并更新应用至最新状态上线承载流量，甚至可以根据监控性能指标或按计划进行应用的动态扩容伸缩 3.有完备的应用服务间调用关系治理的平台，具备完善的应用服务级别的监控报警（体现业务监控的APM或NPM） 4.应用发布支持分批发布，能够从一台开始逐步扩大至整个集群全部完成，每批发布的机器在操作前都摘除流量再更新操作，更新完毕后切回流量，以避免对生产的影响。 | 1.系统健壮性强，没有单点，在硬件故障等情况下不易出现业务上的中断或异常，通过人工介入可以快速完成应用的扩容上线。 2.具备失效转移的能力，当部分应用节点故障或者性能严重下降时，应有机制实现自动将该故障节点从在线服务列表中去掉，以避免仍对生产产生影响。 3.具备限流能力，当访问流量超过能承载的能力时，有能力对流量进行主动限制，以避免流量过载导致后端服务崩溃。 4.具备业务主动降级能力，划分核心功能和非核心功能，当出现故障或资源瓶颈时，在不能立即恢复业务的情况下，优先把资源留给核心功能，主动降级部分非核心功能，以保障核心功能正常运行，技术上可以把降级做成后台管控的开关以便快速降级及恢复操作。 5.使用分布式消息组件，对业务应用间进行解耦，并对请求进行削峰填谷，缓冲的作用。 | 除基础监控外，具备反应业务层面运行状况的监控，易于查看业务请求的调度情况和性能，能够快速定位故障。 |
| 4 | 1.在三级的基础上，具备根据监控性能指标或按计划进行应用的自动化动态扩容的能力，以应对因访问激增导致的性能瓶颈问题，容量问题能做到无人值守自动扩容缩容。 | 1.除三级要求外，通过多机房部署等方式，在硬件故障网络故障等情况下可以尽可能避免业务中断或异常。 | 结合配置管理系统实时更新状态信息，集中展现，信息全面准确。 |
| 5 | 1.除四级要求外，还能够综合成本因素，通过智能化手段分析应用特性，采用池化混用，分时调整等策略，自动调整应用容量，在保障生产稳定的同时兼顾最优化成本。 智能调度与动态路由，能够根据一定的调度策略完成服务的调度，如根据容量、成本、请求量等指标来决定请求的路由 | 1.除四级要求外，还具备多机房多活或异地多活的能力，满足数据的一致性要求，在光缆中断等重大故障发生时能够保障核心业务不受影响或快速恢复运行。 | 智能预测业务增长、故障预警，动态止损、智能调度。 |
主从同步
主从同步可以让数据库中的数据复制到另一台或多台独立的服务器上，在主库发生问题无法快速恢复时可以把从库修改为主库对外提供服务，主库与从库之间同步的延迟确定了从库切换为主库时可能丢失的数据的时间。
读写分离
数据库做了主从同步以后，从库即可以作为备库，也可以作为日常的读库，提高日常的读能力，缓解主库的压力
分表分库
为解决单节点数据库服务器的 能力限制，将数据库水平扩展到不同的物理节点上，每个节点都能提供相应的读写能力，以满足数据库高性能的要求。
数据一致性
数据写入的数据一致性一般通过事务性来解决。事务分为传统事务和分布式事务。传统事务一般通过数据库本身完成，分布式事务因为涉及跨多个数据库，故需要在应用层解决，如使用XA等2PC的方式，但2PC的方式会产出锁的占用，影响性能，故后续又出现了补偿型柔性事务的方式，如、TCC，ServiceComb-Saga等。
能够使用缓存对热点数据进行加速，对缓存有持久化保存，有缓存的备份节点，主备节点保持实时数据同步。缓存节点宕机可以自动切换至备份节点，并保证数据一致。
| 级别 | 数据库高可用 | 缓存高可用 |
|---|---|---|
| 1 | 单机运行，数据库备份不及时，不满足高可用条件 | 无缓存使用 |
| 2 | 数据库有主库和备库，主库备库实时同步，具备主从切换和读写分离的能力。使用数据库本地事务保证一致性，但不具备扩展能力。 | 使用缓存对热点数据进行加速，缓存无备份，数据易丢失 |
| 3 | 数据库具备主从切换和读写分离的能力，可以分表分库横向扩展。因为做了分表分库，本地事务不能满足一致性需求，引入XA等跨库事务的处理能力。 | 使用缓存对热点数据进行加速，对缓存有持久化保存，有缓存的备份节点，主备节点保持实时数据同步。 |
| 4 | 数据库具备主从切换和可扩展的能力，可以分表分库横向扩展，扩展过程不对业务正在读写的数据产生影响。使用柔性事务的方式，在满足一致性要求的同时，降低数据库锁的占用，提高性能。 数据库可以按照RPO要求恢复至10分钟内的数据点。数据库变更操作不影响业务正常运行。 | 使用缓存对热点数据进行加速，对缓存有持久化保存，有缓存的备份节点，主备节点保持实时数据同步。缓存节点宕机可以自动切换至备份节点，并保证数据一致。 |
| 5 | 除四级要求外，还具备多机房多活或异地多活的能力。 在光缆中断等重大故障发生时能够不受影响或快速恢复运行。 | 除四级要求外，还应该考虑成本因素，将缓存中的访问频率很少的数据根据智能化的策略持久化到硬盘存储，以降低运行成本。 |
识别对组织的潜在威胁以及这些威胁一旦发生可能对业务运行带来的影响的一整套管理过程。
该过程为组织建立有效应对威胁的自我恢复能力提供了框架，以保护关键相关方的利益、声誉、品牌和创造价值的活动。
目的：发现潜在的威胁，找到应对的机制
RTO 是一个服务级别目标，是指在灾难发生后达到所需运行能力所需的时间。
RPO 是一个业务连续性目标，规定灾难恢复过程复原所有可恢复系统后达到的业务状态或业务状况。
目标：根据关键业务板块定级，制定衡量方法，有准确的衡量办法和自动化监控的工具能够真实的衡量运行状态。
如应用系统变更前能够分析到是否是核心应用，是否被核心应用依赖，变更失败会影响到哪些业务场景。网络变更操作前，能够提前了解到变更设备关联的服务器，关联的应用及数据库，并推算业务影响范围。数据库变更能够提前预估可能影响哪些应用，变更是否会引起数据库锁表，性能下降等问题。
目标：根据对关键业务的梳理，预估可能的故障对业务带来的影响。
风险分析：
有从技术架构，数据，安全等多种视角的风险分析评估，有技术专家参与，对一直风险和未知风险分类，并对已知风险有改进计划。对变更操作充分评估风险，控制到最小。能够充分考虑法律和监管风险。充分考虑外部威胁和外部舆情和客服等渠道的风险。对网络中断，IDC环境灾难等风险有评估和应对办法。
目的：对目前存在的运行风险有周期性分析的计划，风险评估，并对风险有持续的改进计划和方案。
| 级别 | RTO和RPO的衡量 | 业务影响分析 | 风险分析 |
|---|---|---|---|
| 1 | 无准确的RTO/RPO标准 | 1.无业务影响分析或与真实情况严重不符。 | 1.缺少风险分析，存在安全运行的隐患。 |
| 2 | 1.有RTO/RPO标准，不具备准确的衡量办法和自动化监控工具 2.整体RTO低于99.95 3.没有异地数据备份，同城跨机房RPO大于15分钟 | 1.有较好的业务影响和风险评估，基本能够反映真实情况。 | 1.对运行风险有周期性分析和评估，但仍存在较大的安全运行的隐患长时间未解决。 |
| 3 | 1.有清晰的RTO/RPO标准，有准确的衡量办法和自动化监控的工具 2.整体RTO达到99.95以上（一年260分钟） 3.数据库备份有同城多机房的数据备份，同城RPO小于15分钟 | 有很好的业务影响和风险评估，能够结合业务变化及时更新业务影响和风险评估。变更操作能够提前评估好变更风险和影响，提前预防。 | 1.没有严重的影响安全运行的隐患。有结合容量水位分析运行风险评估， 容量能够满足业务的增长需要。针对法律和监管风险充分评估和预防。 |
| 4 | 1.有清晰的RTO/RPO标准，有准确的衡量办法和自动化监控的工具 2.整体RTO达到99.99以上（一年52分钟） 3.有异地的数据备份，同城和异地的RPO都能小于10分钟 | 有很好的业务影响和风险评估，能够结合业务变化及时更新业务影响和风险评估。变更操作能够提前评估好变更风险和影响，提前预防。 | 1.在三级基础上，能够对外部舆情及客服等信息进行分析，能够主动发现舆情风险和用户体验的问题。 |
| 5 | 1.有清晰的RTO/RPO标准，有准确的衡量办法和自动化监控的工具。 2.整体RTO达到99.999以上（一年5分钟） 3.有异地的数据备份，同城和异地的RPO都能小于5分钟 | 运用智能化手段对计划操作的变更提前评估和预测业务的影响范围和影响大小。 | 1.在四级基础上，对运行风险有周期性智能化的分析和评估，能够覆盖所有业务，没有影响安全运行的隐患，对可能发生的外部风险能够做到智能的故障自愈和止损。 |
目的：应对已经发生的威胁，涉及需要鉴定、评估、理解和如何应对危机
有危机管理组织，负责在重大风险或危机发生时，综合业务影响，用户损失影响，财产损失风险，社会舆论影响，法律风险等问题，进行评估及决策，通过规范的方式对客户及社会公众及时发布信息及处理情况，如果有国家监管部门应按照及时上报监管部门。
不同于应急小组，该组织在重大危机事件发生后启动危机处理流程，尽可能快速评估风险，决策是否启动灾备应急计划，统一公关口径对外披露信息。
该小组一般需要业务负责人，IT技术部门负责人，法律顾问，公共关系发言人，管理层。
根据业务的重要程度和连续性要求，制定数据灾备，业务灾备，业务多活等灾备方案
具备定期灾备测试和演练的计划和执行记录
在灾难发生后，经过分析决策及时启动灾难恢复计划，快速恢复生产。
| 级别 | 重大风险与风险管理机制 | 灾备管理能力 |
|---|---|---|
| 1 | 1.无明确的危机处理计划或不能满足实际需要 | 1.无灾备计划或计划严重不符合生产预期。 |
| 2 | 1.有危机管理组织体系，但可能缺少部分角色。 | 1.有较好的灾备计划 2.做过灾备测试演练但是间隔比较久，可能存在灾备不能按照预期时间完成恢复或者恢复失败的风险。 |
| 3 | 1.有完备的危机管理组织体系，各部分角色都能理解自己的职责，高级管理层重视且参与。充分结合业务分析制定危机应对预案，能够按照预案严格执行危机处理规范。 | 1.有很好的灾备计划 2.定期进行灾备测试演练，演练结果能保证在预期时间完成且结果正确。 |
| 4 | 1.在三级基础上，能够通过技术手段模拟危机事件进行演练，如光纤中断，数据库服务器宕机等，以验证危机预案的可行。 | 1.有详细的灾备计划 2.定期进行灾备测试演练，演练结果能保证在预期时间完成且结果正确。 3.灾备方案上充分考虑外部因素影响，有多机房架构，能够做到短时间快速切换且最小化对业务产生影响。 |
| 5 | 1.无 | 1.有详细的灾备计划 2.定期进行灾备测试演练，演练结果能保证在预期时间完成且结果正确。 3.灾备方案上充分考虑外部因素影响，有多机房架构且分别承载生产业务，各机房能够独立运行业务，即具备完备的数据及应用，能够做到常态化切换并对业务没有影响 |
目的:在突发或重大IT事件发生后，对IT技术和业务进行快速恢复，最大限度地减少事件造成的危害。
良好的应急预案计划应该能够及时更新，集中管理应急响应预案的版本和发布，支持快速检索相关预案内容以便及时执行。
有完整的定期执行的演练计划，历史执行的演练计划可以查询到并符合实际情况。技术上通过模拟真实情况主动注入故障的方式能够提前演练验证系统的健壮性和对故障的处理机制和处理时间。
1.有定期更新的应急管理组织架构，包括具备技术能力的IT部门代表，研发部门代表，业务部门代表，高级管理层代表
2.应急响应及处理能力，监控系统及时准确，通过引入智能化的技术，结合知识库和应急预案，迅速准确的分析出应急事件的原因，甚至结合应急预案的操作步骤进行自动化的止损操作
| 级别 | 应急预案计划 | 应急演练计划与执行 | 应急管理组织架构 |
|---|---|---|---|
| 1 | 1.无应急计划或并不能满足实际需要 | 无 | |
| 2 | 1.有应急响应预案，但是存在更新不及时或者不方便检索等问题。 | 1.应急演练不足以反应组织的应急响应能力。 | 有应急管理组织架构，但部分角色或人员不全。 |
| 3 | 1.有详尽的应急响应预案，准确说明什么条件下启用，操作人和操作步骤。 | 1.有定期的应急演练，能够反应组织的应急响应能力。 2.监控系统及时准确，具备反映业务运行状况的监控报警，具备报警升级机制。 | 有及时更新的应急管理组织架构，角色完备。充分考虑外部舆情和客服的信息反馈。 |
| 4 | 1.在三级基础上，有集中管理且及时更新的应急响应预案，方便检索。 | 1.能够模拟真实情况主动注入故障，执行人员快速排查定位问题并解决，充分反应组织的高效的应急响应能力。 | 有及时更新的应急管理组织架构，角色完备。具备专人7*24监控应急能力，对故障基本能做到通过告警主动发现，1分钟快速响应，5分钟找到原因和启动预案。 |
| 5 | 1.在四级基础上，通过引入智能化的技术，能够分析运行数据，推荐适合采用的应急预案，甚至结合应急预案的操作步骤进行自动化的止损操作。 | 1.除四级的能力外，还能通过引入智能化的技术，结合知识库和应急预案， 迅速准确的分析出应急事件的原因，甚至结合应急预案的操作步骤进行自动化的止损操作。 | 在四级基础上，通过引入智能化的技术，结合知识库和应急预案，迅速准确的分析出应急事件的原因，甚至结合应急预案的操作步骤进行自动化的止损操作 |
用户体验是技术运营的核心增值能力，通过对所属业务的用户&产品体验的管理优化，提升业务的访问速度、减少异常中断达到终止提升产品核心竞争力的目标。
技术人员除了技术以外也需要加强多业务的学习和使用以达到更好的技术端支持。这里从业务学习和知识考核两方面做了要求。
从业务熟悉程度从低到高的要求学习能力，最终以业务结合技术梳理成文档化、细化报告为目标。
业务学习为主同时也需要通过建立必要的考核机制以检验达到的业务熟悉阶段。最终也会结合更细节的度量方法。
| 级别 | 业务学习管理 | 业务知识考核机制 |
|---|---|---|
| 1 | 1、业务理解要求：了解负责业务的基本流程。 如：运维人员熟悉产品的主流程和核心功能点的使用、报错排障 2、管理机制：具备基本的业务培训，让研发人员对负责产品有一定理解。定期体验自己负责的产品业务。 如：运维上岗人员的业务必修课培训要求、需要参加培训的基本要求 | 无 |
| 2 | 1、业务理解要求：了解完成的业务模式和产品功能。 如：了解宏观的业务数据、各模块的迭代计划、参与重要版本或功能的上线计划等。 2、管理机制：除定期业务必须参加的培训外、额外的业务培训考试、运维上岗资质等 | 管理机制，除定期业务必须参加的培训外、额外的业务培训考试、运维上岗资质等 |
| 3 | 1、 业务理解要求：了解不同版本、不同终端的产品、关注和关联重点业务以及竞品的数据。 如：理解不同版本的功能差异、定制核心产品的PV/UV、活跃用户量、用户反馈数据、竞品技术调研等 2、管理机制：团队内部建立结合业务的知识管理、与技术文档结合业务关联。 如：XX功能\版本的上线文档、需求分析文档、新接口文档、压测报告等 技术操作文档对业务端数据的观测细化 | 同上基础上，细分业务线和产品线上岗模块；并结合一定的IPD、KPI等要求。 |
| 4 | 1、资源、性能的变化关联后台团队的体现 | 同上 |
| 5 | 同上 | 同上 |
将直观的用户体验指标分类和量化，分阶段从不同的维度（技术、产品、交互设计）设立计划，逐步提升数据，引导直观感受的提升。
通过分类细化体验指标，建立数据能力及意识帮助量化体验。包括数据梳理、上报、可视化及平台化的建设。
在业务理解和体验数据可视的基础上，通过对产品流程、交互过程、功能等过程采用技术、流程优化等综合化的手段提升体验项和指标。
| 级别 | 体验数据管理 | 体验优化 |
|---|---|---|
| 1 | 1、数据意识：具备用户体验、用户数据的意识，建立初步的监控数据上报并申请对应的数据权限。 如：业务类Log异常分析上报、用户投诉上报渠道的建立、客服端用户投诉数据的申请等 | 1、利用简单的监控类工找到并解决简单的用户体验问题。 如：部页面加载耗时、下载失败率高、崩溃率固定系统偶现等 |
| 2 | 1、数据意识：建立面向业务较为完善的数据能力。利用工具形成管理机制。 如：用户监控完整覆盖性能、速度、可用性、各类异常上报以及完整的用户投诉、建议等数据。 2、数据采集有基本要求。如：频率 加密 压缩 可配置等 3、通过工具建立度量机制，分析问题。 | 1、在用户体验端继续细化体验项，有较全面的监控工具、数据能力，团队专人跟进重要的用户体验指标。 例如关注隐私泄露、产品体验建议等专项体验问题。数据意识加强，关注功能模块的投诉量、优化建议跟进。用户端直观感受的故障缺陷或亚健康问题的处理要求、流程、考核。 2、展示性能指标和用户体验的细则报告 |
| 3 | 1、通过完善的用户数据管理能力，提前和及时解决用户问题。量化用户体验和质量管理。 如：能够量化不同团队不同模块的用户体验能力。 2、打通产品、质量、UED、客服等团队的用户数据以及舆情信息安全的case渠道。建立起统一的用户数据标准。 说明，统一指内部一致的理解或公司不同职能部门间一致的理解 | 1、有专用的用户体验管理体系，在工具、体验改善、用户数据建设方向上有跟进要求和持续改善的主动能力。 竞品分析和行业优秀功能体验或技术升级的引入机制，持续优化。 如与客服、UED、产品行程体验优化团队落实各类能够改善或解决用户问题提升体验项目的落地。 要有主动引入和分析，得到实施提升的案例。 |
| 4 | 1、统一的数据标准具化 2、用户隐私数据 | 同上 |
| 5 | 同上 | 同上 |