基于产品化的概念运维跨校认证服务

2015-12-02冯骐

华东师范大学学报（自然科学版） 2015年1期

冯骐

（华东师范大学信息化办公室，上海 20062）

0 引言

校际间的数字化资源共享已经成为必然趋势，例如无线接入服务的跨域漫游认证，教学资源的跨校共享等，基于这些应用需求，形成了多个跨校认证联盟，例如上海市教育系统跨校身份认证联盟（31所高校和区县），由华东师范大学、新疆师范大学、山西师范大学等组成的跨校联盟试点等．随着Shibboleth的版本不断更新和跨校联盟的进一步扩大，工作的重心主要集中在跨校认证体系架构的管理上，如何优化管理、提高效率，成为眼下工作的重点．

1 跨校认证技术组成

现有的这一套跨校认证系统基于开源的Shibboleth技术构建．

Shibboleth主要由三个部分组成：

（1）IDP（Identity Provider，身份提供者）

身份提供端：主要作用是向资源提供者提供用户的属性，以便使资源服务器根据其属性对其访问操作进行授权和响应．

（2）SP（Service Provider，资源提供者）

资源服务提供端，主要作用是响应用户的资源请求，并向该用户所在的IDP查询用户的属性，然后根据属性作出允许或拒绝访问资源的决策．

（3）WAYF（Where Are You From，认证中心．Shibboleth 2．0之后更名为DS，即DiscoveryService，但是习惯上依然称呼为WAYF）

图1展示了目前跨校认证系统的逻辑架构．

图1 跨校认证逻辑图

2 服务产品化对跨校认证运维的借鉴

2006年，在IBM服务部门成立10周年的时候，IBM提出全面转型“服务产品化”．经过IBM多年的实践，服务产品化概念已经影响到服务行业的各个方面．服务产品化是通过改变服务的生产方式，把服务的生产过程变得像产品制造一样，把服务的内容分解，实现标准化，然后按照传统产品市场的原则，把服务产品交付给客户．服务产品化让服务有标准，能够被评估，改变了目前服务行业里一些过去无法解决的效率、成本、标准、定价以及评估等难题．

2．1 跨校认证服务所面临的困境

现有的上海市教育跨校认证系统，其实质上源于早年的一个科研项目．在不断推广并获得用户的好评后，如今的跨校认证已经成为覆盖31所高校／区县，提供10余种服务的跨校认证共享，日访问量近万的庞然大物．而对这个庞然大物的服务支持，却没有跟上它增长的步伐．如今面临以下若干问题．

2．1．1 跨校认证系统部署不标准

跨校认证系统是基于开源组件Shibboleth进行构建．其关键的IDP组件需要部署每个加盟的高校节点中，用于和高校自身的统一认证系统对接．传统的服务模式下，IDP组件的部署质量取决于的实际部署的技术人员自身．不同的技术人员所部署的组件，所使用的服务器、操作系统、java环境、IDP组件的版本等都可能不同．部分情况下还可能针对某些高校的特殊情况进行二次开发，而在技术人员发生流动后，这些二次开发的系统又缺乏针对性的维护．这些不标准的组件节点随着整个跨校认证系统的扩大，极大的降低了运维的效率．

2．1．2 跨校认证运维工作效率低

跨校认证系统实质上是连接用户所在高校和用户所访问的业务系统的一个中间件．因此当用户发生登陆异常时，其面临的一个困境即是：“我应该向哪里报修？”．其所在高校的信息办无法直接处理，其所访问的业务系统亦无法直接处理．而跨校认证系统本身并没有直接面向用户的服务窗口．因此一个用户的故障通常需要层层转交，最后到达技术支持者的手中，其服务效率显然是很低的．

那如果用户能够直接面对技术人员呢？为了提高跨校认证的服务质量，在2014年新的跨校认证的DS界面上，增加了技术支持者的邮箱．以便用户在发送跨校认证故障时能直接反馈到技术人员处．然后事实上技术人员收到的大量邮件均为与业务系统相关的咨询，例如成绩查询、选课咨询，等等，真正跨校认证故障产生的报修却少之又少．因此增加了大量的工作量的同时，反而在这些问题上，降低处理的效率（因为同样需要转交咨询到具体的业务系统负责任人）．

2．1．3 跨校认证运维人员负荷高

跨校认证近年了推广的力度在不断加大．2013年一年间，所覆盖的院校从23所增加到31所，所支持的业务系统也从4～5个增加到现在的将近10个．业务量的大幅度增加带来的了更多的维护负担．由于跨校认证系统存在一定的技术门槛，因此这些负担被集中到了少数几个技术人员身上，有时甚至集中在1个人身上．事实上，负责维护的高校技术人员通常并非全职负责跨校认证的工作，往往还要负责学校内的其他工作，并且这些工作的优先级在有些时候，往往还会排在跨校认证之前．

跨校认证系统还将面临不断的扩容，面临新的节点部署，新的业务系统对接支持．这些都会产生较高的工作量，与技术人员学校内其他的工作量叠加后，最终产生了很高的工作负荷．

2．1．4 跨校认证运维成效难评估

尽管跨校认证已经得到了极大的推广，用户体量已经非常庞大，并且在许多应用上已经广泛在使用．例如上海市的教育无线通，每天通过跨校认证进行无线跨校认证的用户数达三四千人．但这些统计数据都是孤立于每个业务系统自身，缺乏一个整体的针对跨校认证系统的使用情况数据．难以对整个跨校认证系统的使用现状进行一个评估和分析．

跨校认证的运维中，每一次故障的保修，每一个新节点的申请和加入，每一个业务系统的跨校认证对接，均没有形成相应的固定流程，亦没有专门的记录和文档．因此虽然跨校认证的运维负担很高，却无法对运维人员的工作量进行量化的统计和评估，这无疑打击了运维者的工作积极性．

2．2 跨校认证服务的产品化

上文已经描述，目前跨校认证服务的困扰最大来源即是缺乏标准和由于不标准带来的额外成本，以及缺乏评估．而这些都是服务产品化所擅长解决的问题．

跨校认证服务的产品化，即是将目前的跨校认证服务进行规范和整合，打包为若干个标准化的产品，形成一套多个产品组合的跨校认证解决方案，从而大幅度地提高跨校认证的服务质量和运维效率．

从跨校认证的部署，运维和评估3个角度入手，我们组成以下3个跨校认证产品．

· 跨校认证接入组件（IDP）

· 跨校认证监控与分析平台

下文将详细描述这3个产品的具体组成和其中部分产品的应用现状．

3 跨校认证产品

3．1 跨校认证接入组件（IDP）

传统的部署过程中，需要服务方和用户方共同配合了完成整个系统的构建．图2展示了传统部署模式下的工作流．

图2 工作流图

从图2可见，大量的流程和时间，其实都消耗在了部署安装前的协调准备上．而打包后的产品——跨校认证接入组件（IDP）则将解决这一问题．

基于标准产品的跨校认证接入组件部署的工作流图3所示．

昨天，唐小果跟爸妈去“唐家大院”拍摄一期关于古代大门的视频。当他们拍摄到一半的时候，遇到了一个卖糖人的老爷爷，他拿着一坨糖浆，一捏一揉，然后轻轻吹几下，一拉一扯，一个惟妙惟肖的孙悟空糖人就做好了。

产品由表组成．

产品化的IDP组件带来了以下3个优点：

（1）产品内容标准化

基于虚拟化的方式统一制作的模板，在正式打包进产品前都经过了严格的测试．因此无论在安全性、兼容性和稳定性上都得到了保障，从而为所有的接入用户均提供统一的标准化产品．

（2）产品响应快速化

打包整合后的产品，使得服务方在接受到请求之后，即可直接向用户提供产品，而无需协调用户准备一些底层环境．同时打包整合后的产品，使得技术人员只需要做极小的改动，即可完成部署．从而极大的提高了服务的相应速度．

表1 跨校认证接入组件组成

图3 产品化后的工作流

（3）产品部署简单化

由于打包的产品已经完成基本的安装和调试，最终的服务人员只需要针对具体不同的学校做少量的修改（例如修改域名、修改logo之类）．因此所需的技术门槛也大大地降低．较为繁琐和重复的部署服务，可以有一般的技术人员完成，甚至可以外包．而核心技术人员只需要对产品进行升级调优，并发布新的版本即可．从而降低了IDP的部署难度和门槛，提高了工作效率．

在上海市跨校认证最近新增的一些节点中，已经使用了标准化IDP组件的部署方式，使得IDP组件的部署时间从过去的1周左右，下降至半天，效率提高了14倍．

3．2 跨校认证运维服务

跨校认证的运维，实质上也是一种IT服务运维．因此很自然想到，要将其产品化和标准化，必须要应用ITIL流程化的运维体系．

跨校认证系统涉及几十所高校和多个业务系统．在这样松散的结构里实现严格的ITIL流程显然不现实．但是一些基本的流程和结构需要确立，一些基本的角色层级需要形成．

服务层：面向用户的服务窗口，接受所有请求（加盟申请，故障报修等），提供一线的支持；生成对应的工单，协调二线的技术人员；跟踪工单以了解事件的处理进程；回访用户获取确认并终止事件；生成事件的报告．

技术层：根据一线提交的工单，提供二线的技术服务支持；

决策层：根据运维的运行状况进行作为决策依据和参考．对一些重大事件（节点加盟申请，重大故障事故等）进行处理和协调工作．

图4展示了基于ITIL流程下的跨校认证事件处理流程图．

在基于ITIL流程化的服务产品中，很容易就跨校认证的运维工作量和工作效率进行精确到人的评估和分析，形成对应的奖惩机制，从而调动服务人员的积极性．通过对工单的追踪和分析，能够精确的了解跨校认证目前的用户体验，从而为决策提供依据．

3．3 跨校认证监控与分析平台

跨校认证系统是一个分布式的松散结构，因此在日志处理和系统监控上先天存在不足．一方面，每个IDP服务器的日志都只保存在服务器本地，既有本地服务器空间存满的风险，也有日志存储分散、日志仅能以文本方式展示、不易查询分析等缺点．另一方面，传统的系统监控仅能监控服务器的运作正常与否，无法检测系统内的IDP服务是否正常工作，无法第一时间感知到跨校认证故障的发生．因此需要一个产品来对整个跨校联盟内的IDP服务进行日志收集分析，实时监控和告警，即“跨校认证监控和分析平台”．

图4 事务处理流程

该产品应该能实现以下功能：

统一日志收集：系统要求能够将分布在各地的idp服务器的log，进行实时的收集储存．

实时监控和告警：系统要求能够实时监控idp服务的运行状态，并对影响跨校认证的异常错误给出及时的告警（通过系统web提示和告警邮件的两种方式）．

数据分析和挖掘：对跨校认证采集的日志数据进行提取分析处理，将其录入数据库．同时可对数据库进行分析和挖掘，提供跨校认证系统使用情况的趋势分析报告．

图5为系统的结构逻辑图．

该产品的开发已经完成demo版本．目前已经在试运行中，并已经得到了一些相当有趣的数据．图6展示了目前跨校认证系统中不同业务系统的流量占比．

可以看到shec－wc－test2这个SP，即上海市教育无线通的流量占了绝大多数的比率．．

针对无线通的使用情况做进一步的分析，能够得到一些更有趣的信息

图7从左至右分别展示华东师范大学、上海对外经贸大学、上海交通大学医学院、复旦大学的无线通流量．

图8从左至右分别展示上海师范大学、上海大学、上海外国语大学的无线通流量．

可以看到，上海师范大学、上海大学和上海外国语大学的流量周期性非常明显，而华东师范大学、上海对外贸易大学、上海交通大学医学院和复旦大学的流量周期性则不太显著．

图5 系统逻辑图

图6 流量拼图

为何用户的跨校无线通的流量会在周末出现高峰，这是一个很值得研究的话题．一个可能的解释是学生们在周末参加其他学校跨校辅修上课，但这又不足以解释为何复旦的流量周期性不那么显著．

总之，整合了日志数据后的跨校认证监控与分析平台，能够给与越来越多的数据供挖掘分析，从而不仅仅对跨校认证的决策产生影响，甚至能够对高校的教学合作等方面的决策提供帮助．

4 总结与展望

基于Shibboleth的跨校认证技术为数字化资源的共享提供了技术平台，形成了由多所高校所共同组成的跨校联盟．随着跨校联盟规模和范围的扩大，认证系统的维护负担也随之增大．为了从根本上提高跨校认证服务的运维质量，本文提出了以产品化的概念来运维跨校认证服务，并提出了3个跨校认证产品，从产品的理念，技术组成和部分的应用的情况都给予了介绍．在运维的标准和评估上，提供了充分的支持．

然而产品化的3大特点标准，定价，评估中，定价亦是其至关重要的一环．在商业的服务产品化中，甚至能够产生准确合理的定价才是其将服务产品化的最主要原因．产品本身就指的是能够提供给市场，被人们使用和消费，并能够满足人们某种需求的东西．但是在现有的体制框架下，却很难以市场化的方式对产品进行定价，更难以将产品的价值转换成合理的报酬，直接回馈给这些产品的生产团队．

本文所提供的3个跨校认证产品中，跨校认证接入组件（IDP）已经正式运行，并取得了极好的效果．跨校认证监控和分析平台正在试运行demo，也收到了一定的成效．跨校认证运维服务，其基于ITIL的运维理念，已经在笔者所在学校的信息化部门运行了2年，收效斐然．但是基于整个跨校认证联盟来组建基于ITIL的服务流程，还需要更多的协调和沟通．