易维帮助台官方BLOG

打造最佳IT服务台，英孚凯尔从未停止过……

★ 统一的技术支持中心和在线客服平台
★ 集中管理、远程控制、自动化系统维护工具
★ ITSM流程与报告

本文档描述EweiVC.exe调用接口协议，第三方应用程序可以通过本接口，启动本地目录下的易维维C程序，发起远程协助请求和执行远程协助会话。 本接口采用windows命令行方式，格式如下： EweiVC.exe –from –via –to From:发起请求的用户的信息，与在系统中配置的用户识别字段对应 VIA:服务请求来源，比如调用者程序名，可根据业务需要自由约定 To：服务请求的目的地，指向系统中已经存在的服务台（们），或者某个具体的工程师 调用时必须传递这三个参数，这三个参数都是必填项，但不区分大小写 命令行参数格式详解： EWeiVC.exe -[from]:[Field0,Field1,Field2,Field3] -[via]:[RequetSource] -[toServiceDesk]/[toEngineer]:[ID] n       -from:[Filed0,Field1,Field2,Field3] Filed0,1,2,3对应着系统配置之4个用户识别字段 由于这4个用户识别字段是可自由定制的，故在传递此项参数的时候也必须与后台配置项保持一致，包括字段数量、字段属性、字段长度和是否必填 Filed0为必填项，Filed1,2,3非必填，但必须以“,”作为参数间隔标识，比如： -from:王小二,,,。 n       -via:[RequestSource] 请求来源（用户自定义服务请求来源），包含一个值，用户可输入自定义值，或是将该值设为null；     如：-via:MyApplication，-via:null n       -toServiceDesk/toEngineer:[ ID] 服务请求目的地，toServiceDesk和toEngineer，分别指向服务台和工程师，但这两个参数只能二选一，不可同时提供，即不可既指向服务台又指向工程师 ID需与在系统中预设的服务台或工程师的自定义编号匹配 toEngineer只允许输入一个ID，toServiceDesk允许多个ID并列，但须以“，”为间隔。比如： -toEngineer:张工 -toServiceDesk:abc,xyz,123 接口参数校验和错误提示 任何调用，立即启动易维维C客户端。 n       参数个数和必填项在主程序启动时进行第一次校验，如校验失败，则立即退出EweiVC主程序； 调用EweiVC成功后，会弹出EweiVC会话窗口进行第二次参数校验，如传入参数无效，则会返回错误信息至会话窗口，并断开服务台连接，由用户自行关闭会话窗口，退出EweiVC主程序。

服务器租用版本的退出推出，消除IT服务商和软件开发商对数据安全的担忧，填补“不放心的纯SaaS”和“难以承受的纯独立服务器版价格”之间的鸿沟。 租用服务器版本在价格方面，专业版起售点提高至10个工程师授权（3000元/年起），企业版起售点提高至500台设备（6800元/年起）。 客户选择租用服务器，可以完全掌控数据的安全性，有机会选择软件升级的时间和节奏，不像纯SaaS那样完全被动地升级。

刚刚得到消息，2012年4月12日10:40分左右，中国电信骨干网发生重大问题，导致香港、日本、美国、韩国、荷兰、澳大利亚、新加波都发生访问网站局部无法访问的情况。检测中，发现了谷歌香港地址在全国访问内很多地区都无法访问。另据网友反馈，中国联通网络用户也有大面积无法访问外网现象。 此次故障，是由于中国骨干线路故障引起。目前只能耐心等待。。。 部分区域的易维帮助台SaaS用户也受到影响，请您谅解！

不管是IT硬件服务商、软件服务商还是企业运维部门，企业内部都有一些重要的应用系统，比如CRM/OA/ERP/EMAIL等等。那么在这些系统中，嵌入英孚凯尔易维远程服务入口后，如何在远程服务中识别求助客户身份呢？

伴随着瘦终端、虚拟化、云计算的演进，IT服务的重心已从硬件维护转向对应用的支持。计算、存储和应用的云端化趋势，与分片式、层级化的技术支持体系之间存在矛盾（一地一个Key man，信息传递失真多，效率低，人员变动将严重影响服务交付的能力和质量）。应用系统越来越多，单个工程师无法支持全部的应用。几乎所有的应用支持都需要外部供应商的参与或者完全提供。

客户是一家国内知名的网购商城，拥有自己的物流机构，在国内有200多个网点和分支机构。由于最近几年公司业务的不断发展和壮大，业务部门对IT技术和自动化系统的依赖越来越大，他们需要IT来支持处理大量业务数据。然而，由于公司缺少一支有组织且结构化的一线IT支持服务团队，雇员们在面对时而发生的IT故障和问题时变得越来越沮丧：他们不知道向谁寻求帮助，在四处求救时浪费了大量的宝贵时间；另外，对于那些重复发生的问题和服务故障，没有一个现成的经验和知识帮他们直接解决问题，使得IT服务人员陷入一遍遍解决同类问题的僵局。当他们处理商品库存调配或其他相关业务时，客户的需求和业务的特性使时间和准确率对他们来说至关重要。他们迫切需要一种最快，最准确的方法保证交易的完美进行。然而，他们却搞不清一旦发生技术故障，他们应该打电话找谁来寻求帮助。甚至即使打了电话，问题也不能得到很好解决，影响业务的进行。这直接导致了这些业务部门的IT最终用户产生如此错觉：IT服务与我们业务部门不是同路人，他并不是一个值得信任的，拥有共同业务目标的好的合作伙伴。这种对IT技术支持团队的错误认识，直接影响了各营业网点及分公司向客户提供服务的能力，降低了客户的满意度。

随着企业业务等越来越广泛地开展，企业IT网络上运行的应用系统不断增多，各项业务系统对信息网络的依赖性越来越高。与此同时，Internet的自由性和先天的不安全性带来的种种隐患、黑客入侵、内部人员的操作失误等问题也相伴而来。如此一来，规避潜在的计算机网络业务风险，保障企业信息平台系统高效的、安全的运行则成为了企业信息所日常工作的重中之重。

07年火爆的市场行情和08年“奥运维稳”使得证券业的IT部门经历了极大的挑战，因系统故障所造成的交易中断事件此起彼伏。甚至在“维稳”期间，市场上仍出现几次重大恶性事故，其中一次还是上交所本身的事故。难道是相关人员不重视？亦或偶发事故？答案显然是否定的。从表面看，这些故障都是由IT系统造成的，但究其深层原因，我们发现相当部分事故实质上都是IT服务管理水平不足所造成的，非纯技术因素。

从上世纪八十年代后期开始，一股由美国刮起的外包之风逐渐蔓延到日本、欧洲，成为全球企业界的一股潮流。产业细分使价值链发生了巨大的变化，企业逐渐把不是自己强项的业务外包出去。
据统计，2005年，全球运维外包服务市场整体规模已达到726.37亿美元，市场增长率为9.5%。

今天的IT服务行业最热门的话题，毫无疑问就是“ITIL”和“ITSM”了。ITSM起源于ITIL，他们的目标是保证更高的运营效率和更好的服务管理，但不管是ITIL最佳实践框架还是ITSM有效管理的方法伦，都让多数IT人恐惧。几乎所有的IT管理者在实施ITIL/ITSM的过程中都会遭遇重重阻力。
幸运的是，现在已经有了可行的IT服务管理解决方案，英孚凯尔公司推出的易维帮助台（www.infocare.cn），使得IT部门利用现有能力实施ITIL流程成为可能。。。