欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

如何保证IT服务的质量?

作者:易隐者 发布于:2013-2-5 21:29 Tuesday 分类:IT 服务

       IT服务涵盖的范围非常广,其可以是一个具体产品的售后服务,如给用户提供一台设备后的安装与实施,也可以是一个专门的IT服务产品,如各种IT外包服务等。
       IT服务不像那些具有具体、明确交付物的产品,我们可以根据产品的形态、功能、性能等特性来衡量其质量如何,比如我们提供给用户的硬件产品,我们可以通过硬件产品的相应配置和性能指标对其进行比较和衡量,从而得出该产品是否符合用户的要求或需求的结论,这很容易实现,双方也都容易理解。但是IT服务的最终成果往往是无形的并且难以衡量,那么针对这些IT服务,我们如何保证这些IT服务的质量是足以让用户满意的?个人总结如下图所示:
 点击查看原图
以用户/客户为中心
       我们提供的IT服务是面向用户/客户的,因此,我们所谓的IT服务质量肯定是以用户/客户的体验和感受为依据,说白了就是用户说你的服务很好,就说明用户认可你的服务,那么服务的目标基本上就达到了,自然就可以认为我们提供的服务质量是令用户满意的。
       用户可以根据其感受对IT服务的质量进行评价,但是用户的感受具有很大的主观性,因此我们首先要做的就是在主观上:围绕客户而做好以下几点:

1, 维护良好的客户/用户关系

       在中国现在的大环境下,一提到“用户关系”,很容易让人想到通过行贿受贿等潜规则换取的交易型用户关系,但我在这里提到的“用户关系”并不是指这种类型的用户关系,而是指通过对用户的尊重、站在用户的角度去考虑问题、积极主动的帮助用户解决问题、成为用户核心业务支撑上的强大后盾等多种方式建立起来的真正意义上的用户关系。这种用户关系建立在真实、平等、互信、互惠互利的基础上,这种更为稳固的用户关系能够大大提高用户主观上对IT服务质量的认可度。当然良性优质用户关系的建立并非一日之功,需要服务团队的每个成员为这种良性关系不断添加正面的积累,通过较长的时间方能逐步建立。

2, 服务态度

       用户关系是长期而持久的,而服务态度则具体至每一次的服务过程。建立、维护用户关系过程中非常重要的一点就是服务态度,对服务态度的要求并非IT服务行业的特例,所有的服务行业基本上都是一样的,具体主要有以下几点基本要求:
       热情:对用户热情,有问必答,不可爱理不理,没精打采,心不在焉
       诚恳:对用户诚恳,坦诚相待,特别是在服务过程中出现失误和损失时
       积极主动:主动帮助用户提供解决问题的方案,多做一些本职工作分外之事,解决用户的问题,满足用户需求。

       在某些技术含量不高的服务工作过程中,态度对服务质量的影响远远超出服务过程本身,举一个简单的例子,在用户不紧急、对用户影响不大的IT环境中,即使提供服务的工程师经验和水平有限,但是在其热情、诚恳端正的服务态度下,用户也不会太责难他,甚至有用户会安慰工程师,给他足够的时间,帮助他协调各种资源来尽快解决遇到的问题,最终虽然解决的时间比预期的长,但用户对服务质量的主观感受也不会很差,这就是良好的服务态度从中起到的作用。当然,在IT服务这个高技术含量的工作中,这个例子不会是一个普遍的现象,但足以说明态度是做好IT服务的第一步,这一步迈不好,所谓的服务质量就无从谈起。

3, 沟通并与用户达成一致

       主要针对验收标准、免责条款达成一致性意见。
       服务的特性决定了其没有直观的、统一的质量验收标准,标准不一是造成验收异议的根源,而一旦用户对服务结果存在异议,对服务质量的影响将不言而喻,严重时,可能会直接导致IT服务不被用户认可,直至整个IT服务工作的失败。另一方面,信息系统的构成是非常复杂的,与用户核心业务系统的正常运转关联的因素非常之多,有时并不是一次性的IT服务就一定能够解决的,可能需要升级其他的IT服务项目或购买相应的设备才能解决,一旦出现这种情况,如果不提前说明清楚并得到用户的认可,事后难免出现分歧。因此,我们应该在提供IT服务之前与用户做全面的沟通和交流,一起就IT服务产品的验收标准和免责条款达成一致意见,并签署相应的IT服务合同。

       考虑到用户只关心最终结果而无须关心具体实现细节以及IT服务的专业性,我们一般主要针对IT服务的实施效果作为IT服务的验收标准,比较常见的衡量指标有服务响应时间、网络恢复时间、业务恢复时间、服务完成时间、一次性问题解决率等等。

       虽然用户的主观感受在衡量IT服务质量的过程中非常重要,但是由于IT服务高技术含量的特性以及信息系统对用户的重要性,IT服务质量的根本还在于我们能够提供的服务能否高效、经济的解决用户的问题,这就要求IT服务提供者在客观上从如下几点做好自己:

1, 专业能力

       IT服务高技术的含量特性要求提供IT服务的人员必须具有一定的专业水准,提供具体服务的工程师的专业技术能力水平决定了我们为用户提供的服务所能达到的效果。

      一般而言,技术能力更强的工程师总能提供更好的IT服务过程、质量保证,更容易达到令用户满意的服务效果,同时技术能力更强的工程师会产生更高的服务成本,考虑到服务的经济性,我们需要将用户的服务类型和工程师能力水平进行合理的划分,以便我们为用户提供低成本、高质量的IT服务。除了服务团队的梯度划分,我们还必须建立一支专家团队作为强大的技术服务后盾,随时应对服务过程中遇到的各种疑难问题和突发事件,以保证绝大部分的服务质量不会受到小概率突发问题的影响。
       IT服务提供者对IT服务团队成员内部的选拔、培训、淘汰、激励等种种制度是保证IT服务团队具备高超专业技术能力的基础。这涉及到整个服务团队的建设问题,是一个大课题,在此就不做过多的阐述了。

无强大的专业技术能力,服务质量无法保证。

2, 标准流程

       这里的标准流程主要指服务的标准流程和内部的工作流程两方面。
       绝大部分的服务的流程都是可标准化的,服务流程标准化的好处是其可以大大减少服务质量的偏差,我们试想一下,如果甲工程师按照其个人的习惯为用户提供某个IT服务,乙工程师也按照自己的一套方式为用户提供IT服务,即使甲乙两人最终都可以完成各自的IT服务过程,但是整个服务质量却会因个人的经验、技术能力、工作习惯等差异的影响而出现较大的偏差,这些都是影响IT服务质量的不可控因素,服务流程标准化之后,提供具体IT服务的人员全部按照标准化的服务流程按部就班的为用户提供IT服务,可以大大减少这些不可控因素对服务质量的影响。经过不断完善的标准化的服务流程还可以大大提高服务的效率,让经验不足的工程师在提供服务的过程中少走弯路。

       另一个标准流程主要指IT服务团队内部的工作流程标准化,包括IT服务请求的受理、服务过程的状态监控、状态通告、服务升级、服务评价、投诉等等。

3, 检验考核

       为用户提供的每个具体的IT服务都应该在经过检验后纳入服务团队内部考核之中。针对服务质量的检验主要指用户检验和内部检验两种,用户检验可包含对服务提供者的服务态度、主动性、专业性等多方面给出评价,内部检验则从用户的反馈、服务的交付物等方面对其服务过程和质量作出检验。

将用户对服务过程的检验反馈和内部对服务质量的检验结果作为团队内部考核的内容之一,这样做的目的是督促具体的IT服务人员,鼓励其主动做好IT服务工作,提高IT服务的质量和用户的满意度。

4, 交付物

       绝大部分的IT服务是无形的,不像有形的IT产品那样,用户可以清清楚楚的看到他的机房里放着一台服务器、交换机、防火墙,因此IT服务作为一个无形的产品,我们需要将服务的成果实体化、具体化,最为常见的形式就是服务文档。我们在每一次提供IT专业服务之前就应该告知服务后会有哪些交付物交给用户,这些交付物大部分都是服务文档,这些文档主要包含所提供的专业服务的完成情况、给用户带来的可评估效果、给用户的改进优化建议、解决方案等等不一而足,一般根据具体的IT服务类型提供不同内容的文档,这个需要结合服务团队的服务目录做专门的文档架构、设计和规划。

       服务文档交付物让用户直观的感受到IT服务的价值,同时也是体现服务专业性的一种方式,另外有些服务文档还可以作为服务团队内部的知识库。在专业的IT服务产品中,交付文档是不可或缺的,我们需要认真细致的对待每一个服务之后递交给用户的交付文档。

总结

       IT服务的质量保证工作应该以用户感受为中心,态度为基本门槛,专业能力为基础,内部管控为根本,外部关系为升华。通过不断的完善与加强,在上述主客观、内外部的因素之间形成良性循环,不断提升IT服务的质量和用户的满意度。

阅读全文>>

标签: 解决方案 交换机 团队 响应时间 团队成员 服务质量保证 交付物 IT服务

评论(2) 引用(0) 浏览(3693)

Netscout 的KFP分析方法论

作者:易隐者 发布于:2012-10-25 9:46 Thursday 分类:网络分析

        Netscout有一个非常知名的应用性能管理的分析理论—— KFP分析方法论

        所谓“KFP”就是“KPI-Flow-Packets”,我在网上搜集诸多关于Netscout的KFP分析方法的资料,下面是我摘录的一些描述KFP的图表: 

点击查看原图

点击查看原图

点击查看原图

点击查看原图

        这些图表将KFP的工作方式做了直观的展示。再加上一段netscout针对KFP的描述:

"The KPI-to-Flow-to-Packet Approach
NetScout’s products leverage deep packet inspection technology to deliver complete visibility into real-time operational intelligence spanning high-level KPIs (Key Performance Indicators) and early warning all the way down to actual packets, enabling IT organizations to reduce MTTR. The nGenius Solution provides  an from key performance indicators (such as response time or errors) to application flow data (such as utilization, conversations or top talkers) and then to packet-level details – if necessary. This “KPI-to-Flow-to-Packet” approach allows you to delve as only deeply as required to effectively manage and troubleshoot your network and application performance. "

        综合这些相关资料的描述,KFP方法论主要利用Netscout系列产品进行核心业务应用性能分析管理的方法:

K:KPI

       其主要确定各种核心业务应用的关键性能指标(根据不同应用的特点,其KPI的选择有所差异),如HTTP应用的KPI主要有:响应时间、响应成功率;VOIP应用的KPI主要有:丢包率、语音质量等。
Netscout产品统计计算出各个应用在交互过程中的KPI值,并且根据这些KPI值制定相应的告警条件,提前预警业务应用的性能问题,反应业务应用的性能情况。

F:Flow

       在Netscout发出告警之后,用户接下来可以利用Flow进行进一步的分析,包括利用率、会话、最差性能等,发现跟告警相关的具体会话、应用、服务等。

P:Packet

        最终站在数据包交互的角度,分析具体数据报文的细节,定位问题根源。

       KFP方法论的思路固然可以通用,但是具体到实现的效果,估计只有Netscout的产品能够完美的体现出来,毕竟这个是Netscout提出来的。

阅读全文>>

标签: Netscout 丢包 响应时间 预警 交互 应用性能 packet KPI Flow KFP VOIP MTTR

评论(0) 引用(0) 浏览(3854)

应用响应时间(ART)

作者:易隐者 发布于:2012-9-13 18:38 Thursday 分类:网络分析

       在实际的业务应用操作中,客户端向服务器的操作主要分为两类,一类为客户端向服务器上传数据,如HTTP应用中的“post”操作,另一类为客户端从服务器取数据,如HTTP应用中的“get”操作。应用程序对这两个操作的处理机制不同,因此有必要把应用响应时间按照客户端的这两类操作进行划分,下面分别针对服务器端的这两种响应时间进行阐述。

“get 操作应用响应时间

      “Get”操作主要是指客户端向服务器端发送取数据的请求。应用程序对“Get”操作的响应时间主要是指服务器收到get请求数据包至服务器响应第一个带有应用层数据的数据包的时间间隔。其响应时间的计算如下图所示: 

点击查看原图

Get操作应用响应时间计算示意图(一)

       应用程序在处理客户端请求的时候会消耗一定的时间,并不一定能够及时响应请求的数据,为了不让客户端等待过长的时间(时间过长,很可能导致客户端重传数据),服务器很可能首先对客户端的TCP数据段进行响应(Delay ACK)。在上面的图示中,第二个包是TCP层的响应,其应用层的数据的长度len=0,第三个包包含有应用层数据,其数据长度len=n,因此,该应用响应时间就是T3-T1。而下图中,应用程序很快的响应了客户端的请求,第二个包中就已经包含有应用层数据,其长度为len=n,其应用响应时间的计算就是从第二个数据包开始,为T2-T1。 

点击查看原图

Get操作应用响应时间计算示意图(二

        我们再看一下实际应用中的get操作应用响应时间的计算。下图为web应用中某“get”操作的数据交互过程: 

点击查看原图

 web应用中GET 操作的交互过程

       在上图中,我们可以看到,当客户端向服务器发送取数据的get请求后,服务器的传输层首先针对客户端的TCP数据段进行了响应,其应用层数据长度为0,接下来第三个数据报是服务器应用程序对客户端get请求的响应,其包含应用数据。在这个过程中,“get”操作应用响应时间就是第三个数据包与第一个数据包的时间间隔,在该例子中为0.08149秒。

“Post”操作应用响应时间

       “post”操作主要是指客户端向服务器上传数据的操作。“Post”操作应用响应时间主要指服务器端接收到客户的post操作数据包与服务端处理完这些数据后对客户端做出相应响应的时间。关于这种应用响应时间计算的方法请参见本博客《关于client push操作应用响应时间的计算方式的讨论》一文。这篇文章较为详细的描述了客户端向服务器递交数据时的服务器应用响应时间测量的方法。

       在实际的应用中,存在两种常见的应用场景,一种是服务器端在收到客户端的数据,应用进程处理完毕后,需要向客户端发送响应数据;另外一种情况是服务器端接收并处理来自客户端的数据,但是应用进程并不会发送响应数据给客户端。下面我们分别针对这两种类型的应用进行描述。

1,有应用层响应数据的

       当客户端向服务器发送“post”操作数据后,应用层如果有应用数据的响应,那么计算应用响应时间的方法与计算“get”操作应用响应时间的方法一致。就是指服务器收到post请求数据包至服务器响应第一个带有应用层数据的数据包的时间间隔。下图展现的就是一个针对客户端的 “post”操作,应用进程产生应用层响应数据的交互过程:

点击查看原图

有应用层响应数据的“post”操作交互过程

       在这个“post”操作数据交互过程中,我们可以分析出应用响应时间为12.847148秒。

2,无应用层响应数据

       在客户端向服务器发送数据时,如果服务器端应用进程没有应用数据响应,那么服务端仅仅只在TCP层面响应客户端数据的ACK,如下图所示的应用层数据交互的过程: 

点击查看原图

无应用响应数据的“post”操作数据交互

       既然无应用数据响应,那么就说明站在网络数据交互的角度,无法测量应用程序的响应时间,即使测量了,也无法真正反映应用程序的响应时间,在实际应用中,我们就没有测量的必要了。

阅读全文>>

标签: 响应时间 应用响应时间 ART get client push delay ack POST

评论(0) 引用(0) 浏览(8358)

传输层的响应时间(系统层响应时间/服务器响应时间)

作者:易隐者 发布于:2012-9-12 21:30 Wednesday 分类:网络分析

       基于TCP的业务应用在交互业务数据之前必须先建立TCP的连接,而系统在接受到TCP连接的请求报文(SYN报文)时,系统将直接对其进行响应而不需要经过应用程序的处理,因此,我们分析传输层的响应时间的意义就在于该时间值可以间接地反映出服务器端的系统性能。如果服务器系统本身性能不足,就很可能导致该时间值较高。我们在分析业务应用慢的时候,要界定清楚是服务器端本身的性能问题导致的还是应用程序本身的处理性能不足导致的。

       传输层的响应时间主要是指在建立TCP连接的三次握手过程中,服务器端响应客户端SYN数据包的间隔时间,如下图所示: 

点击查看原图

TCP响应时间图示
下图是一个实际环境中TCP三次握手数据包交互过程:
 点击查看原图
TCP三次握手过程中服务器端响应客户端SYN包的时间
 
       在该例子中展现的服务器端的传输层响应时间为0.000003秒,这个时间是很小的,说明该服务器端本身的处理性能还不错。

阅读全文>>

标签: TCP SYN 响应时间 三次握手 传输层 服务器响应时间

评论(5) 引用(0) 浏览(86309)

经受时延的确认(Delay ACK)

作者:易隐者 发布于:2012-9-12 21:05 Wednesday 分类:网络分析

       通常TCP在接收到数据时并不立即发送ACK,相反,它推迟发送,以便将ACK与需要沿该方向发送的数据一起发送(有时称这种现象为数据捎带ACK),这样做的目的是尽量减少发往网络的报文,以提高传输的效率,节省网络资源。

经受时延的确认工作过程

      下图清晰的展示了Delay ACK的工作过程:

点击查看原图


       我们一起来看一个实际环境中的Delay ACK实例: 

点击查看原图

 

Delay ACK响应时间

       在实际工作环境下,我们做应用性能分析时,有时会遇到应用程序处理时间较长(一般超过200ms)时,我们经常会看到服务器先向对端发送了TCP ACK报文(无应用层数据),这个确认的报文一般就是TCP的Delay ACK,如下图所示: 

点击查看原图

       我们在遇到此类现象时,千万不能简单的将此处的Delay ACK当成应用响应时间

Delay ACK的可能影响

       另外需要注意的是,Delay ACK虽然能够提高传输效率,节约网络资源,但是在某些情况下,其会给应用带来难以想象的延时问题(假想一下这样的场景:服务器单向向客户端间歇发送一些数据,但是客户端无应用数据需要提交给对方,此时,如果客户端每收到对端包含有应用字段的报文时,都等待200ms才对其进行确认,那么如果服务器与客户端的交互次数为1000的话,那么整个应用交易或应用会话将要持续1000*200=200S,而200秒对于绝大多数的应用来说是不可接受的)。

Delay ACK补充

1,绝大多数实现采用的时延为200ms,也就是说,TCP将以最大200ms的时延等待是否有数据一起发送,但是这个200ms的值并不是必须的,开发者可以根据自己的需要来设定这个数值,因此,我们在实际工作过程如果发现非200ms但是工作机制与Delay ACK一致的TCP交互过程,那基本上就是Delay ACK机制了。

2,如果连续收到对端两个数据段,则一般立即回应ACK数据包,如下图所示:

点击查看原图

阅读全文>>

标签: TCP 应用字段 延时 响应时间 应用响应时间 ART delay ack ACK 捎带ACK 经受时延的确认

评论(0) 引用(0) 浏览(110317)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1