主持人：非常机智、幽默、非常睿智的总编五分钟。2008年开始，中央电视台新台址建设工艺项目正式启动，给广播电视行业带来不少的震撼，毫无疑问这是迄今为止全球范围内广播电视业界最大的一个项目，由此带来的新的理念，新技术受到业内的广泛关注。
下面有请中央电视台副总工程师宋宜纯给我们做主题报告。他给我们介绍全台网的技术和管理经验。
宋宜纯：各位来宾，各位同行，早上好！很高兴参加DDMN每年一次的技术行业的盛会。那么借助这个平台，很多来自全国各地的同行和朋友们，可以充分交换意见和看法。作为一个保留节目，每次都找一个话题来说，那么今年想就构建全台统一的社会监测与故障管理系统这个话题谈一些体会。
那么大家都知道中央电视台在构建新台址的技术系统，这个技术系统将在所有的演播、制作和控制这些系统当中，完成全面的监控。同时要在顶层构架一个跨系统的整合的业务监测与故障管理系统。这个恰好与今年的DDMN的主题、业务整合之道的主题的出发点是相同的。
那么我想通过我们现在的系统所存在的问题，那么我们构建这个系统的目标和需求，以及实现的方法来做一些简单地介绍。
首先我们想分析一下目前系统当中所存在的问题。那么从几个方面，一方面安全播出现在提出了更加严格的要求，它在播出的正确率、设备的可用性、以及出现故障的恢复时间等等方面，都提出了远远高于以前的要求。另外随着系统复杂性的提升，那么还有跨系统的任务，就是几个系统联合才能完成的任务，这样有多个环节，大跨度，也增加了很多的不确定因素，使得故障的发现和追踪变得非常困难。那么在设备管理方面，自从从传统的线性直播系统，发展到非线性直播系统，现在出现了种类多，数量大，监控的难度提高了。我们非常希望了解系统的运行状态，它的性能是否发生故障，以及对于维护、采购方面产生了更多的要求。那么在社会管理方面，也涉及到人员、责任和故障处理流程等等的问题。那么我们现有的管理系统、比如说在网络直播系统当中，也有网络管理，也有系统管理，但是它只侧重于解决本系统内的问题，通常一个系统只是关注于IT或者只是关注于AV，比如说在主控里面，主要是AV设备，到了我们直播系统当中，主要的变成IT设备，那么这些问题的提出和存在，使得我们在全台的系统当中，有没有一个解决的办法。那么我们对这个系统的问题进行分析之后，提出一个目标，就是要实现一个全台基于任务的跨系统的一体化设备报告和监测管理，这个系统的目标是要实现基于任务的跨系统的一体化的设备状态报告和故障管理。那么这里面有几个关键词，一个是基于任务，什么是基于任务呢，我们一个任务可能是一个系统完成，但是还有很多任务是多个系统联合完成。举例来说，像直播，演播室包装的直播任务，那么它就要启动主控，演播室，然后再输出到主控出去。那么这样的话就变成了一系列的相关的系统和设备参与到这个任务里面，另外在IT方面，也有这样的情况。比如说一个节目在网络直播环境当中，做出来要入库，那么涉及到在不同的系统当中，比如说节目生产管理，比如说媒体资产管理，在多个系统当中联合作业，这样的话，是一个任务。这样才能构成一个任务。
那么第二个关键词是跨系统。我们刚才提出了基于任务就是一个单子，一个要做的事情。那么跨系统，一个任务可能涉及到多个系统联合作业。这样的话，原来我们的单个系统通常就没有办法监测到整个任务的完成情况。
那么第三个关键字叫一体化，这个一体化我们不是说AV监控AV，IT监控IT传统的模式，我们是试图把AV和IT做成统一的展示。那么比如说AV有编码器，有矩阵，有切换台，有分配等等。那么在IT有服务器，有交换机，有软件，像数据库等等，我们把它放在一个层面展示，这是我们的目标。回头来说，我们说一个全台的整个系统的在监测之内。那么这个需求是什么样的，大致来讲我们需要监测系统和设备的工作状态，要了解完成任务所需要的技术资源的指配，是指定哪些设备来完成这个任务。那么还要有故障的报告与处理，有性能的监测。我们希望这个系统应该是直观的，多维度的以及多视角。那么可以按照不同的要求去展现。比如说按照任务，也可以按照系统，也可以按照部门等等来展现所有的系统或者是设备的运行状态。同时也希望它便于操作。
那么这个解决方案，我们试图构架一个全台的设备状态监测和故障管理系统，简称就是URM，统一的报告与监测系统。那么这里状态报告，就包括实时监测系统和设备的在线、等待、维修等状态。以及是否能健康运行。其次还包括性能报告，这个主要是IT，因为AV的话主要是状态是否良好，有一些指标性的、信号比如说有问题，那么作为性能来讲，主要的还是IT系统，比如说CPU的分辨率，内存的占用率，网络是否拥灾等等。还有故障管理，设备或者系统发生故障的时候，能够展现、记录，并且形成设备故障报告。建立一个统一的URM负责全台的系统监测和故障管理。
这个结构分为两级，两个层。一个层是监控和采集层，那么就是各个系统，比如说一个网络直播系统，你这个系统负责监控你内部的所有的设备和相关的软件服务器等等。那么它要部署到所有的系统，比如说主控，播出，包括在我们新址当中所有演播室里面的AV设备，都是属于被监控的。那么在网络里面，网络中心数据中心里面大量的服务器，交换机等等。
那么第二层是一个顶层的展现层，按照用户的要求统一收集设备的状态、统一的展现。监控层主要解决本系统的问题，它的状态监测承担运行和配置的操作。那么向展现层报告故障和事件，以及响应展现层的查询。我们展现层，一般的URM指的是顶层，组织设备运行状态，故障事件的展示，向设备管理系统报告，形成设备的报告。
大概三层的情况是这样的，最底层是物理设备层，就是最底的设备。监控层负责做参数的调整等等，同时负责采集设备的运行的情况。那么它把设备发生的事件，不光是故障，有可能是状态的变化。向上提交给展现层，展现层根据用户的需求，把它展现出来。那么在底层的物理设备层与监控层之间，通常我们是采用SNMP来作为通信的协议。而这个监控层与展现层，两个都是应用系统，这两个应用系统当中，我们基于MQ、或者JMS来进行信息的交换和传递。
我们再来看URM与其他系统之间的关系，URM为了得到这个任务来组织展现，根据任务来展现。比如说有直播任务，像奥运会的网球比赛，是一个直播任务，必须从管理系统得到任务的单，同时展现的时候，得到的故障报告，就是URM得到的所有的故障报告，传递给我们设备管理系统，注册说某个系统、某个设备发生什么样的故障，在什么时间，由谁来处理的，将来形成维护的记录。那么大致的话，这几层与其他的主要关系是这样的。
那么URM的主要功能，我们已经提到了系统、设备运行状态的检测。这是一个非常主要的功能。其次要实现基于任务的跨系统设备状态，形成报告。第三就是故障事件管理。就是发生故障以后，怎么样来进行处理一个流程。那么状态检测，实际上我们现在的系统当中基本上都有。主要是通过类似于SNMP或者其他的方式来采集设备的数据和状态，最终在各个系统当中形成向上事件的传递。那么基于任务的系统状态怎么形成，我们以后讨论这个问题。
那么我们来介绍URM的主要技术特点。我觉得可以从三个方面来说明。
第一就是统一，这个技术特点的统一，是把AV与IT两个从我们现在完全不同的管辖的方式合成一体来展现。AV包含了所有可监控的AV设备，包括播出、主控、演播室、所有的AV系统。那么像矩阵、编码器、复用器、切换以及周边设备都在监控之内。IT这边包括路由器、交换机、服务器等硬件，软件包括数据库、应用服务器等系统软件，那么两类系统统一的在这里展现和实现统一的故障管理。
第二个技术特点就是全台，就是说我们在企业范围内，要监控所有的设备和系统。而不是单一的一个。那么这里包括所有运行的状态，所有产生的事件，这是全台的。
第三技术特点通过不同的视图，不同的应用和不同的要求可以组成不同的视图。比如说可以是一个层次化的展示。就是说从部门到系统到设备，也可以从系统到设备到参数等等。
那么还有的不同的视图我们可以组织跨系统的实现一个任务的跨系统相关设备的展示。不同的视图看进去。
我觉得这三点是比较主要的技术特点。还有故障管理，因为搜集了全台的故障和状态，可以形成运行的报表和故障的汇总的报表。那么有助于后期对故障和运行状态进行分析，得到大量的运行的数据来指导运行故障处理，乃至设备的采购。
第四个问题简单说一下具体的实现。因为要做的这个系统必须看一下我们到底具备了何种条件，应该说现在实现URM的基本条件已经具备了。首先基本上所有的设备都是可监控的，绝大多数AV和IT设备都具备了监控接口，比如说支持SNMP，当然不要说现在的AV设备里面的大件、矩阵、切换台等等，都提供了监控接口。像有一些品牌的摄像机，扛着走的都带了网管接口的，当然厂家可能有自己的一些考虑，但是确实实际上已经具备了监控的条件。那么有少数设备提供了串口。那么AV设备的监控的话，如果说都满足的话，IT是标准的带监控的能力的。所以基本上可以认为所有的设备基本上都是可以监控的。其次网络已经充分地铺下去了。这一点不是一个问题。
那么第三我们认为这个技术已经相对成熟，没有技术方面的障碍。过去试图打通不同的AV设备的时候，各家都有很多私有的协议，但是经过这么几年的努力，大量的设备已经在协议方面都已经通了。那么也跟厂家对监控实行一个比较开放的态度也有很大的关系。
那么大致我们先来说几个主要的技术环节，实现的环节。一个是状态报告。实现状态报告不是一个很复杂的问题，主要是一个功能的切分。从技术路线角度来讲，我们一个是要在本地做本地的指配和检测，那么所有的资源指配和状态通过底层的监控系统上传到URM。然后我们想提我们希望这个技术路线是变动量上传，不是所有的，只要有一点事就报告，其实这个里面要承担一些过滤，那么减少了数据的处理量。资源的指配，包括根据任务来实施资源的调配。那么完成这个任务，你需要哪些资源，我们需要来做相应的处理。形成一个资源的指配表，这张表传递到URM里面，可以根据它形成我们的信号传输链路的拓扑，或者说可以形成数据的路由的拓扑结构。其次是状态的检测，这个没有技术难度。第三是展示，需要根据用户的不同要求进行展示。形成状态报告，相对来说是比较成熟的。
第二是监测。就是对设备进行采集、设备的状态、参数进行采集。这个技术路线主要是由各个系统里面进行本地的采集，那么顶层URM不直接操控各个系统，是通过询问本地系统获得本地设备的状态，只监不控。这个里面包括巡检、定检、直接方式结合。巡检，通常的时间跨度大一些。定检，就是比如说我们在顶层指定检测某一台设备，报告它的运行参数，那就是说你发出指令以后，指定这个设备进行检测。还有直接状态，因为根据SNMP网络协议，有一个报告的形式，也就是说一旦你监测的设备发生故障的时候，它会直接报告。但是这个问题并不是想象的那样，出了问题就报告，假定这个问题使得你这个机器功能根本不可用了，比如说关了电了，因为我们那个报告建立在要发出数据包，跟它有联络的时候有报告，一下没有电了，所以报不出来了。所以这个直接的形式不能完全取代巡检的模式。那么还有性能监测，通常现在标准由主动的和被动的两种模式。主动的是我们的监测系统主动发出一个事务处理请求。比如说一个直播系统，或者一个媒体资产系统发出一个查询，那么这个查询是一个样例，你打过去以后沿着系统转一圈，会反过来响应时间，这是主动的。还有被动的，不是说我发出请求，是监测用户提交的任务，它的执行时间、它的响应时间是什么。所以这两种方式都是可能的。那么性能监测，需要提出来我们现在应该是一个叫关键性能指标，叫做KPI，可以直接反映主要的性能。比如说ARM是一个标准的开发包，是一个得到多厂家支持的标准，它有一组SDK放在应用服务器上、数据库上，可以提供整个环路处理的响应时间，你拿到这个时间实际上就是得到这个系统的健康状况。那么另外的话由于用户体验。
第三是管控，都是在各个业务系统当中实现。各系统过去都有系统管理，那么还是在这个上面来做。主要是对系统内所有的设备进行监控，进行管理，这个管理包括接收任务单，比如说节目生产管理系统下达的任务，包括我们临时调度等等，根据任务单我分配资源，比如说调动哪个线路，包括事件记录与报告，还有事件处理等等。
第四是比较大的问题，就是用户界面与展现。这个里面我们希望它的显示能够层次化，步进化，精确化。你可以宏观地来看，也可以看到一个点。那么这样的话，可以得到比较完善的用户的不同的视图，那么完全可以自由选择，比如说从系统、任务、设备、参数、事件，多方面的了解状态，这个可以多方面的查询和展示。比如说我看到发生了一个事件，某一个系统产生了一个报警，那么我点这个告警的信息可以查到这个设备，展现设备所有的参数，这样可以实现交叉的查询。
比如说在层次化展现里面，可以从系统级里面点一个系统，查到这个系统基于这个任务，一系列相关的系统共同完成一个任务。那么点其中的系统，我们可以展现出系统里面的设备的拓扑结构。那么如果我们再访问这个拓扑当中的一个设备的时候，它可以展现出这个设备的所有的参数和状态。基于任务跨系统流程展示在技术上实现，由节目生产管理下一个单子，比如说有两个系统共同完成，下了一个同一个任务的ID，在A系统里面比如说我们给它支配了资源和路径，那么到B系统里面也有资源指配和路径，把这个指配的单交给URM，根据这个单可以组合成一个完整的链路，然后接收这个系统上报的事件，可以构成一个基于任务的跨系统流程的展示。那么在IT方面都不是成为问题了。
第五是故障管理，这个技术路线，各子系统处理本系统故障。事件上传到URM，然后汇集报告全台故障，然后统一登记和记录故障，必要的处理流程。根据我们现在了解的情况，还有其他的系统出现的情况，有大量重复报警，其实可能是一个原因，希望在这个里面做过滤。那么形成故障报告，对于故障维护流程，我们通常建议可以参考IT服务管理的经验，比如说ITSM，ITIL，都是非常成熟的IT管理的经验。还有一个大问题，就是规范和协议。一个是采集协议，我们通常采用SNMP来做，一级二级的连接可以通过Web Service来做。我们需要统一的表达资源指配，统一表达资源到底怎么表达。那么还有要把事件统一表达出来。那么实际上要做的有好几个方面的事，比如说标识，就是ID，全局系统标识具有唯一性，全局设备标识具有唯一性，还有事件有标识，还有涉及到管理流程等等。这个实践上我们预期可以得到什么成果，系统范围内，子系统内我们可以有配置，运行状态显示，还有故障告警及处理，还有设备资源指配，还有全台范围，全台系统、设备统一监控等等。
那么最后小结一下，由于数字化网络化导致系统的复杂性显著增加，另外安全播出和科学化管理需要更加准确、统一和基于任务的信息。那么URM试图从技术角度来解决这一问题。主要的设计目标，就是统一的状态显示和事件报告，还有基于任务的跨系统设备状态显示，还有故障报告与故障管理。这是几个主要的目标。重要的还在于协议和规范。具体的实施效果，现在还在规划到实施的过程当中，还有待于实践的检验。
最后非常感谢各位的耐心，谢谢！
