博客园_野男人

基于.NET技术的监控应用分析（二）

2010-09-23T15:35:00Z

在上一篇的基于.NET技术的监控应用分析(一) 中，讲了数据采集和通信技术的分析，其实还有一块也很重要，那就是如何有效的在大量的服务器上进行部署的问题。包邮啦

由于被监控的网络内部存在着多个子网，所以在部署的时候，选择子网的一个网关服务器作为管理其范围内的所有机器。这种方法部署简单，方便统一管理，但对网关服务器的要求比较高。另外一种模式是为每台机器安装一个服务，然后通过网关服务器输送到监控中心，这样网关服务器只起到一个中转的功能，因为只负责数据通讯的功能，所以压力相对较小。这种方法由于部署分散，导致安全、管理上需要集中统一的时候比较复杂。

1、部署架构一

2、部署架构二

3、网络架构

系统网络连通采用跨地域组网方式：

中心网络由数据库服务器、邮件服务器、WEB服务器以及短信发送器组成。

每个地域的网络由代理服务器、以及被监控的服务器设备组成。

代理服务器即是监控中心在本地的监控代理服务器也作为监控代理数据库服务器。

各服务器设备需要开启WMI服务及与此服务对应的135,445端口。

4、系统更新升级

由于服务器分布在异地，系统需要实现自动更新功能，一旦有新版本发布，则通过监控方广播升级消息。代理服务器负责下载新版本程序，子网内的服务器再从代理服务器下载。代理服务器的自动更新模块收到消息后，从发布服务器下载程序，然后关闭系统进程，当更新完成后，由自动更新系统重新启动数据通信服务。

系统更新流程

我们采用的是第二种部署架构。截止目前，该系统经过一年多的运行，很好的做到了对网站服务器上的软件和硬件，特别是针对网站业务的应用系统进行了有效的监控，一旦网站的系统出现异常，运维人员能自动收到预警短信，实现了网站运维监控自动化管理。

本文链接

服务器负载均衡体系结构，I：传输层负载均衡【转载】

2010-09-20T14:01:00Z

服务器农场的可伸缩性和高可用性
Server load balancing architectures, Part 1: Transport-level load balancing
Scalability and high availability for server farms
By Gregor Roth, JavaWorld.com, 10/21/08

原文：http://www.javaworld.com/javaworld/jw-10-2008/jw-10-load-balancing-1.html

进入Internet的门槛是很低的，任何有点想法的人都可以开发一个小应用，然后购买一个域名，架设一些基于PC的服务器就可以处理即将到来的流量了。启动时的投资很小，风险也小。不过随着你的应用的流行，这个廉价的架构很快就会成为问题。一个能处理所有请求的单服务器是不够处理高流量的。这种情况下会进行scale up：通过购买超强的处理器或更多内存的方式升级现有的架构（infracstructure）。

scaling up只是一个短期的解决方案。作用也有限，因为升级服务器的成本与其获得的相应能力不成比例。因此，许多成功的Internet公司使用scale out的方式。应用系统的组件由多个运行在服务器农场（server farms）上的实例来处理，这些服务器农场是基于廉价硬件和操作系统构建的。当访问量（traffic）增加，服务器也相应增加。

服务器农场（server-farm）的方式有它自己的一些要求。对于软件来说，必须设计成能在不同的服务器上以多个实例运行。可以通过将应用划分成更小的能独立部署的组件做到这点。如果这些应用组件是无状态的，这很容易办到。因为组件不必保留任何事务状态，任一组件都能平等的处理同样的请求。如果需要更多的处理能力，只需要加入更多的服务器并安装这些应用组件就行了。

当应用组件是有状态时我们面临更多的挑战。例如，如果应用组件保持购物车数据，一个到来的请求必须被路由到持有此请求者购物车数据的应用组件才行。本文稍后将讨论在一个分布式环境中如何处理此类应用级会话（application session）数据。然而，为了减少复杂性，许多成功的Internet应用系统都试图尽可能的避免有状态的应用组件。

就系统架构来说，处理载荷必须分布到服务器中。这被成为服务器负载均衡（server load balancing）。负载均衡技术也与其它领域相关，例如，网络链接、CPU或硬盘间如何分散工作（spreading work among components such as network links, CPUs, or hard drives. ）本文着重讨论服务器负载均衡（Server load balancing)。

可用性和可伸缩性（Availability and scalability）

服务器负载均衡（Server load balancing)将服务请求分布到一组真实的服务器中，对客户端来说这些服务器看上去就像是一个单独的大服务器。经常一个URL后有数十个真实服务器实现一个单独的虚拟服务（Often dozens of real servers are behind a URL that implements a single virtual service.）。

这是如何工作的？在一种广泛使用的服务器负载均衡架构中，到来的请求直接发给一个专用的负载均衡器，此服务器对客户端来说是透明的。基于某些参数，如可用性或当前服务器载荷等，负载均衡器决定哪个服务器应该处理请求并将请求转发给选中的服务器。为给负载均衡算法提供必要的输入数据，负载均衡器还需要获取服务器的健康和负载情况，以确保它们能处理并及时响应。图1表示传统的负载均衡器架构。

Figure 1. Classic load balancer architecture (load dispatcher)
图1所示的负载调度（load-dispatcher）体系结构（architecture）只是负载均衡方法中的一种。要判断那种负载均衡方法最适合你的架构（infrastructure），必须考虑可用性和可伸缩性。

可用性（availability）由运行时间（uptime）定义，运行时间（uptime）是 the time between failures。（停机时间(downtime）是指检测到错误、修复错误、执行必要的恢复以及重启任务的时间。）运行时间（uptime）内系统必须在预定期限响应每一个请求。如果时间超出，客户端将视为出现服务器故障。基本上，系统中的高可用性就是冗余：如果一个服务器出错，其他服务器将透明的接管出错服务器的载荷。一个单独服务器的错误对客户端来说是不可见的。

可伸缩性（scalability）意味着系统可以为一个客户端提供服务，也能在满足服务质量（例如响应时间）的前提下同时为成千上万的客户端提供服务。随着载荷的不断增长，一个高可伸缩的系统能通过添加硬件资源成线性比例的增加系统的吞吐量（throughput）。

如图1所示，高可伸缩性可以通过将进来的请求分发到服务器上实现。如果载荷增加了，只要负载均衡器不成为瓶颈，可以通过添加更多的服务器解决。要达到高可用性，负载均衡器必须监视服务器以避免将请求转发给过载的或已经死掉的服务器。此外，负载均衡器自己也必须是冗余的，稍后将讨论这点。

服务器负载均衡技术

一般服务器负载均衡解决方案可分为两种主要类型：
* 传输层（transport-level）负载均衡：例如基于DNS方式的、或TCP/IP级的负责均衡，这些都与应用的有效载荷无关；
* 应用层（application-level）负载均衡：使用应用的有效载荷做为负载均衡的依据。

负载均衡解决方案还可以划分为基于软件的负载均衡器和基于硬件的负载均衡器。基于硬件的负载均衡器由专用硬件组成，包括定制的ASIC集成芯片。不需要有通用操作系统，ASIC直接完成网络流量的高速转发。基于硬件的负载均衡器常用于传输层负载均衡。一般而言，基于硬件的负载均衡器要比基于软件的速度更快，缺点是价格更高。

与硬件式负载均衡器相比，基于软件的负载均衡器运行在标准操作系统和标准硬件（例如PC机）上。基于软件的解决方案要么在一个专用于负载均衡器的硬件节点上运行（如图1所示），要么直接在应用中运行。

基于DNS的负载均衡

基于DNS的负载均衡代表了一种早期的服务器负载均衡方法。Internet的域名系统（DNS）将IP地址和一个主机名关联。如果你在浏览器上输入主机名（URL的一部分），浏览器会向DNS服务器发送请求以将主机名解析成IP地址。

基于DNS的方式，是基于DNS能够让多个IP地址（多个真实服务器）被赋给同一个主机名。DNS查找例子如清单1所示：
>nslookup amazon.com
Server: ns.box
Address: 192.168.1.1

Name: amazon.com
Addresses: 72.21.203.1, 72.21.210.11, 72.21.206.5
清单1. DNS查找例子

如果DNS服务器采用了轮询（round-robin）方式，那么DNS每次在对一个主机请求返回响应后，返回IP地址顺序都会发生变化。通常像浏览器这样的客户端会试着连接DNS请求返回的第一个地址。其结构就是对多个客户的响应被分布到服务器中。与图1中的负载均衡体系结构相比，不需要有中间的负载均衡器硬件节点。

对全球范围的服务器负载均衡（这里负载被分布到不同地方的数据中心），DNS是一个有效的解决方案。基于DNS的全球服务器负载均衡经常与数据中心的其它服务器负载均衡解决方案联合使用。

DNS方式虽然容易实现，但是有很严重的缺陷。为了减少DNS请求，客户端倾向于缓存DNS请求的结果。如果一个服务器变得不可用，客户端缓存以及DNS服务器仍然保有不可用的服务器地址。因此，DNS方式对实现高可用性没有太大帮助。

TCP/IP服务器负载均衡

TCP/IP服务器负载均衡器在底层实现交换（switching）。一个流行的基于软件的底层（low-level)服务器负载均衡器是Linux Virtual Server（LVS）。真实的服务器对外部世界表现的就像是一个单独的“虚拟”服务器。一个TCP连接进来的请求被负载均衡器转发给真实的服务器，该负载均衡器运行在一个打了包括IP虚拟服务器（IPVS）Linux内核补丁的系统上。

为确保高可用性，许多情况下需要建立一对负载均衡器节点，其中一个负载均衡器节点是被动模式。如果一个负载均衡器坏了，运行在两个负载均衡器上的心跳程序会激活被动负载均衡器节点，并初始化虚拟IP地址（VIP）的takeover（initiates the takeover of the Virtual IP address(VIP)）。心跳程序负责管理两个负载均衡器的容错，简单的send/expect脚本用来监视所有的真实服务器。

通过使用一个赋给负载均衡器的VIP，客户端实现了透明访问。如果客户端发送一个请求，首先请求主机名被传输给VIP。当收到请求的数据包，负载均衡器将决定应该由哪个真实的服务器处理请求数据包(request packet)。请求数据包（request packet)目标的IP地址被重写成真实服务器的真实IP（Real IP, RIP）。LVS支持好几种分布请求给真实服务器的调度算法。常用的是轮询（round-robin）调度，类似基于DNS的负载均衡。LVS的负载均衡判断是在TCP级（OSI参考模型的第4层）进行。

在收到请求数据包（request packet）后，真实服务器处理请求并返回响应数据包（response packet）。为了强制响应数据包（response packet）通过负载均衡器返回，真实服务器使用VIP作为其缺省响应路由（response route）。如果负载均衡器收到响应数据包，响应数据包的源IP地址被重写成VIP。这种LVS路由模式被成为Network Address Transiation(NAT)路由。图2展示了使用NAT的LVS实现。

Figure 2. LVS implemented with NAT routing

LVS还支持其它路由模式，如直接服务器返回（Direct Server Return），这种情况下响应数据包被真实服务器直接发给客户端。要做到这点，VIP必须也被赋给所有的真实服务器。使服务器的VIP对网络不可解析是非常重要的（It is important to make the server's VIP unresolvable to the network），不然负载均衡器会不可访问（unreachable，不能连线）。如果负载均衡器收到一个请求数据包，请求的MAC地址（OSI模型第2层）被重写，替换成IP地址。真实服务器受到请求数据包并处理之。根据源IP地址，响应数据包将绕过负载均衡器被直接发送给客户端。对于Web流量，这种方式可以大幅度的减少负载均衡器的工作载荷。通常要传输的响应数据包要多过请求数据包。例如，如果请求一个Web页面，通常只有一个IP数据包（IP packet）被发送。如果是一个较大的Web页面请求，请求的页面需要返回好几个响应IP数据包。

缓存机制（Caching）

如果需要支持应用级缓存或者应用会话支持，像LVS这样的底层（low-level）服务器负载均衡解决方案会带来一些限制。如果经常重复的访问相同数据，缓存机制（Caching）提供了一个重要的可伸缩性原则（Caching is an important scalability principle）以避免这种代价高昂的操作。一个缓存是一个临时的存储场所，用于保存一些冗余数据，这些数据是以前进行数据抓取操作的结果。缓存的价值取决于抓取数据的代价vs命中率和缓存大小。

基于负载均衡器调度算法，一个用户会话中的那些请求将被不同的服务器处理。如果服务器端使用了缓存，到处散落的请求会成为一个麻烦。一个解决办法是将缓存放在一个全局空间中。memcached就是一个流行的分布式缓存解决方案，它提供了一个大型的跨多个集群的缓存。它是分区的、分布式缓存，使用了一致性哈希算法（consistent hashing）为一个给定的缓存决定相关的缓存服务器。基于缓存的关键字哈希值，客户端库总能将相同的哈希值映射到同一缓存服务器（daemon）地址上，这些地址将用于存放缓存数据。如图3所示：

Figure 3. Load balancer architecture enhanced by a partitioned, distributed cache

清单2使用了spymemcached，一个Java写的memcached客户端跨多个机器缓存HttpResponse消息。spymemcache库实现了上面描述的逻辑。
以下是spymemcahced的一些实现代码和相关说明（略过）
balabala.....

一致性哈希表的方式具有高可伸缩性，memcached客户端实现了一种支持高可用性的容错策略。但是如果一个缓存服务器（daemon）崩溃了，缓存的数据也就丢失了。这只是一个小麻烦，因为缓存的数据都是冗余的。

一个简单的办法可以使memchach处理这种情况，将缓存数据存放在一个主缓存服务器和一个二级缓存服务器上。如果主缓存服务器当掉，二级缓存服务器可能保留有相关数据，如果没有，请求的（缓存的）数据必须从相关数据源恢复。

应用会话数据支持（Application session data support）

应用会话数据代表用户相关的应用会话状态，例如选中的目录ID，或者购物车中的文章。应用会话数据必须能跨多个请求。传统Web应用中此类会话数据必须在服务器端保持。通过cookie或隐藏域存放在客户端有两个主要缺陷：它暴露了内部会话数据，例如购物车中的价格，导致对客户端的攻击，导致安全问题；由于HTTP cookie消息头的数据量限制以及应用数据从客户端来回传送的开销，这种方法只能保持少量的数据。

与memcached体系结构类似，会话服务器（session server）被用来在服务器端存放应用会话数据。然而与缓存相比，应用会话数据不属于冗余数据，因此如果内存耗尽不能简单的移除应用会话数据以腾出空间。对缓存来说可以根据内存管理的需要随时移除缓存数据。当缓存最大数量到达时，缓存算法一般采用最不常用（Last Recently Used，LRU）的缓存数据先移除。

如果会话服务器崩溃，应用会话数据也就丢失了。与缓存数据相比，应用会话数据大多数情况下是不可恢复的（recoverable）。因此采用支持应用会话数据容错的解决方案非常重要。

客户端关联（client affinity）

缓存及会话服务器的缺点是每个请求导致额外的从服务器到缓存（或会话）服务器的网络调用。多少情况下，调用延时都不会造成什么问题，因为缓存（或会话）服务器和业务服务器都放置在相同的快速网络中。但是当数据量增长时延时可能会带来问题。为避免中业务服务器和缓存（或会话）服务器之间反复的移动较大量的数据，一个客户端的所有请求必须总是转发到相同服务器。这意味着一个用户会话的所有请求被同一服务器实例处理。这种情况下一个本地缓存可以用来替代分布式的memcached服务器架构（infrastructure）。这种方式被称为client affinity，不再需要缓存服务器。
客户端关联（client affinity）总是将客户直接连到”它的“专用服务器上。

以下代码略

LVS通过persistence支持affinity：在一个预定时间内记住最后的连接。它使得一个特定客户端总是连接到相同的真实服务器上。但是如果一个链接是通过代理（proxy）进行的，对同一个session它可能每次都有不同的TCP连接，这种情况下，persistence帮不了什么忙。

总结

基于纯传输层（transport-level）的服务器负载均衡器架构（infrastructures）更为常见。它们简单、灵活并且高效，而且它们对客户端没有限制。此类体系结构（architectures）与分布式缓存或会话服务器组合，可以处理应用级（application-level）缓存和会话数据。然而，如果从缓存（或会话）服务器来回移动数据的开销增长了，此类体系结构会主机变得没有效率。要基于应用级服务器负载均衡器实现用户端关联（client affinity），必须避免在服务器间拷贝大量的数据集。第2部分将讨论系统级负载均衡机制。

本文链接

搜索引擎，你知道我在想什么吗？

2010-03-26T07:40:00Z

搜索是随着信息量的增长而产生的一种信息检索的需求。在信息量少的时候是通过分类、索引、精确匹配，最后到模糊匹配等技术来为用户提供检索服务的。当面对海量的信息时，简单的分类、索引已经完全不能满足人类对信息索取的需求。所以当信息量很大时，如何减少用户的时间成本，让用户更快捷的找到目标信息就是衡量一个搜索是否可用性的主要因素。理想的搜索引擎有自己的神经元和知识库，能完成基本的逻辑推理并理解人的思维，最终满足人类信息检索的高级需求。

下面从用户的搜索行为上分析，归纳一下有哪几种类型的搜索需求。看一下用户搜索的交互过程：

1. 用户输入关键词；

2. 系统分析关键词；

3. 系统根据关键词匹配信息；

4. 系统返回搜索结果。

这里的关键是，系统怎么识别输入的关键词，然后读懂这些词的含义？例如：某用户输入“ABC”关键词。那么搜索引擎是如何对关键词进行“猜测”的呢？

场景1：输入“ABC”，理解为“ABC”。这里系统没有进行任何思考，认为用户输入的关键词，已经可以代表用户最终需要的信息。这样的需求对于用户来说，说明是已经知道自己需要什么，这是一种显性的需求，称为“直接需求”。

场景2：输入“ABC”，初步拆分为“ABC, AB,BC,AC,A,B,C”，然后根据已有的词库进行剔除、提炼和整合，最后系统得出“ABC, AB, A”三种结果。这里系统进行了初步思考，它通过拥有的词库知识，对关键词进行分析推理出用户需要这三种信息；最后通过模糊匹配，它把用户认为最可能要的结果找出来。这是一种相关性的需求，称为“间接需求”。

场景3：输入“ABC”，在场景2的基础上，系统还联想出了“D, E, F”三种与“ABC”有某种内在联系的关键词。这里系统是通过联想后读懂用户的潜在思维，认为用户还可能会需要或者更需要“DEF”这种关键词的信息。这是一种隐性的需求，称为“潜在需求”。

从用户搜索行为的角度看，搜索引擎是一种属于“人工智能”的产品。搜索引擎从精确匹配、模糊匹配到联想匹配所表现出来的就是机器学习从低级到高级的一个过程。通用搜索引擎的处理过程可以分为两步：第一是信息的抓取、加工、处理、组织和存储；第二是关键词的拆分、组合和信息匹配、提炼、排序和呈现。在通用搜索引擎里面，是用一套复杂的数学模型算出一个网页价值大小的数值，即网页的权重。例如：Google的PR算法。

站内搜索与通用搜索引擎最大的区别在于信息内容的类型不同。通用搜索引擎的内容是网页，站内搜索的内容是属于某个特定行业。所以，站内搜索需要有一种有区别于判断网页权重的算法来去衡量特定内容的权重的算法，我称之为“CR算法”（Content Rank）。CR算法的核心还是从多个角度分解内容，抽象出可以表述内容属性的最小单元，即语义或元数据。这个过程就是内容信息结构化的过程。大量的内容经过加工处理后，形成一个多维的内容数据仓库；有了这样的一个仓库，才能达到数据挖掘的目的，最终满足用户的不同维度的信息检索需求，给人一种蒙太奇般的用户体验。

本文链接

一个失败的产品案例

2010-03-16T05:19:00Z

三年前，策划过一个PC与无线结合的产品；实现的功能是从PC发送短视频到手机上；当时3G还没有出来，所以希望手机用户能通过在线录制“视频短信”，然后把“视频短信”发送到亲朋好友的手机上，借此希望能通过这个产品，实现新一代的“手机短信”。想法是美好的，当我第一次听到这个想法时，也为之振奋。想象一下，如果春节期间，部分用文字短信的人改为用“视频短信”给亲友发祝福；那个量会有多大？

产品使用起来很简单：1. 登录网站，录制好视频（系统自动把FLV格式的视频转换成3G格式）; 2. 输入自己的手机号和对方的手机号。3. 点击发送；发送成功后，系统自动从发送方的手机上扣费2元，整个交易结束。从产品功能和技术上来说，问题都不大；很快就开发出来了。产品推出后，选择了“网吧”合作为主的推广发送。挑选了本地10家大型网吧，每个网吧配备两名推广员；她们的工作是辅导用户使用产品，发放宣传单。这样推广了半个月，录制的人不少，但成功发送出去的人寥寥无几（低至4%）；这是一次彻底的失败的推广。为什么说失败呢？首先，在网吧上网的人基本是去看电影，打游戏为主；对这类产品不是很有兴趣，用户来使用完全是冲着那个小赠品去的；其次，跟录制的环境有关系；在公共场合对照摄像头说什么都不知道，即使想说点祝福的话也不太好意思；最后，部分手机支持录制视频功能，他为什么要使用PC录制，而且还要花2块钱去发送呢？普通发送彩信，只需要几毛钱。说到底，还是没有摸准用户的需求，更不符合手机用户的使用习惯。

综合起来，主要表现在以下几个方面：

第一：产品不被市场认可，有多少需求不确定，产品市场调查分析没做好；完全是用“一厢情愿”的思维做产品。

第二：受限于外部基础环境，当时的2G网络无法承载更多的视频内容；

第三：整个运营团队没有明确的战略思维，在没有理解产品意图的情况下，匆忙上阵，只是被动的接受任务。

第四：管理层不务实的考核指标，把人“烤”走了。什么基础底子都没有，一张口就要销售回款3000万。偶的神啊~~~。

就这样折腾了几个月，大家期盼着3G的到来，希望3G是根救命草；结果还没等到那个时候，这个产品就夭折了，部门也随之没落，直到解散。硝烟过后，反思问题到底出在哪里？产品仅仅是想象出来的，或者说是仅以简单的试错思路去做一个产品，没有去认真研究市场；跟管理层的战略部署有关，理想而不务实，希望能通过四面出击（同时成立了四个业务事业部），广种薄收；结果四个鸡蛋全碎，母鸡也差点被炖了。

本文链接

视频网站？电子商务？

2010-03-11T08:39:00Z

从两个不同行业的网站（视频分享、电子商务），看互联网业务平台的特征：

1. 两者的核心都是内容。一个是视频，它的特性是：信息载体、数字化；另一个是商品，它的特性是：功能化，有形化，具体化；视频是给人看的，商品是给人用的。

2. 有内容必有其所有者的主体，只是两者的概念不同。一个是播客，一个是卖家。根据主体的属性，播客又分为：个人播客和机构播客；卖家又分为：大卖家和小卖家；

3. 视频有转载的，也有原创的；商品有自己生产的，也有批发购买的。视频有版权之分，商品有真假之分；

4. 从最终消费者来看：视频网站的用户是不用买单的，电子商务的用户是要掏钱购买商品的；一个是来娱乐，一个是来消费。都是根据内容的属性进行分类并呈现；如：频道、类目、栏目等；

5. 生产者都有自己的经营场所：一个是个人空间，一个是店铺空间。

6. 内容都有一个最终页面；一个是播放页，一个是商品展示页；

7. 视频的监管更容易，按照广电总局的规定执行即可；电子商务平台上的假货很难监管；商品太多，无章可循。

8. 视频网站的推广有内容联盟；电子商务的推广有广告联盟，使用者都是站长。前者是视频推广的需要，后者是商品推广的需要；不过一个是传视频不需要出钱推广，一个是想多卖商品就需要花钱做广告。

9. 视频网站需要想办法把视频卖出去，最好能多卖几次；电子商务不用考虑卖家的商品销售情况，只负责建设商品流通需要的一切基础设施。

10. 如果电子商务平台上的商品都进行人工审核，早就关门了；如果视频网站上内容不审核，也早就关门了。

平台的价值在于打通行业的价值链，把内容生产做成品牌、做成一个模式、做成一个可以输出的、可以长久获利的循环经济。

本文链接

用户体验不是一句空话

2010-03-02T08:20:00Z

每个人都会到餐馆吃饭，我相信每个人都遇到过这种情况：上菜很慢，肚子很饿，急死人了。你会怎么办？要么换一家餐馆，要么不断的催促服务员；直接到厨房抢菜的事情应该很少发生，大部分人通常会选择先催促，后示威，最后再无奈等待（或抬腿走人）。一般催促的场景是这样的：“服务员，我们的菜快点上来，都等很久了，别人后来的都吃上了”。服务员一般这样回答：“马上，马上就上菜”或者“好的，我帮你催一下”；这时你通常会继续耐心等待。（十分钟后……）菜还是没上来，你开始有点发狂了（前肚皮贴后背，喝茶已经不能解决问题了），你马上把服务员叫过来：“到底上不上菜啊？再不上菜我们走了”（开始威胁）；服务员说：“马上，马上就好了”……（十分钟后，你的菜依旧没有上来）

这种用户体验相信每个人都体验过，原因出在哪里呢？服务员肯定不是重点，虽然她每次都说“马上马上”，但她并不能解决上菜慢的问题（路途遥远除外），真正的原因应该出现在后台厨房（厨师少，厨房工作流程不合理，原料资源不够了…）。所以服务员固然重要，但核心基础还是后台支撑能力，有了这个基础再加上训练有素的服务员才能给用户一个良好的用户体验（但如果菜的口味不好，上菜再快也没用）。

坐飞机最怕什么？天气不好，飞机晚点。特别是有急事，那个急啊。恨不得自己有对翅膀，恨不得自己能把大雾吹散，无奈不是孙悟空，只能怪天公不作美。但当天气好转后，眼看别的航班能起飞，自己的航班表还是那个讨厌的“延误”二字，那个心情突然很紧张，马上到服务台问情况去，通常该航空公司的人会说：“飞机还在天上，正从XXX赶过来”。还好，听说30分钟后能起飞，耐心等待中……

过了30分钟，没有看到飞机的任何踪迹，只好又去问航空公司的代表，无奈得到的还是一样的答案。有的乘客开始愤怒了，质问：“飞机为什么还不来？到底什么时候能到？是什么原因延误？”航空公司代表：“我们无法回答具体时间”，原本抱有希望的乘客顷刻彻底失望，所有的愤怒都泼在航空公司的代表身上，但不管你多愤怒，飞机就是不来……

这个航空公司的代表跟餐馆的服务员一样命苦，他们（服务员）解决不了问题，只能转达乘客的愤怒，于事无补。因为该公司的飞机少（拼命提高飞机的执飞率，导致资源紧张）服务员催不出飞机来，只能被动等待……

用户体验不是服务员的工作做得好就OK了，它是一个系统性的工程，前台的表现力取决于后台的支撑能力；所以从以上两个案例中可以看出，用户体验是一个组织的综合能力的体现。

本文链接

我们的目标是什么？没有蛀牙。

2010-02-20T07:23:00Z

新的一年到了，企业都要设定目标，上了规模的企业会形成正式报表，个体户会在老板自己的心里。一般而言，设定目标的流程是这样的：首先由老板提目标，业务部门把目标数字化（大概是这样描述的：实现销售收入X千万，用户数每月X万，流量每天增加X万），然后再把这些目标分解到几个核心部门：如研发部门完成这些目标需要招XX位工程师，市场部门需要XX万业务费......最后财务部门核算一下成本收益，拿出一份年度财务预算报告。与此同时各个部门还会把目标分解细化，把每一个阶段的详细实施步骤罗列出来，然后根据这些目标进行考评，最后大家根据考评结果拿奖金。

每家企业制定工作目标的流程差不多，但结果可是千差万别。有些企业实事求是，遵循事物发展的客观规律，参考市场环境，结合自身条件，最后设定一个可行的目标。但有些企业好高骛远，不认真分析市场环境，不分析自身条件，盲目设定“伟大”的目标。那么宏伟的目标是如何制定出来的呢？大概有这几个方法：

1、做数学题。不是做加法，是做乘法，甚至是指数运算；像一乘十得十，十乘十得百，百乘百得万。恨不得马上把企业弄上 “世界企业500强”排行榜。

2、做填空题。例如：某部门的目标是年底销售回款1500万；（背景：这个部门刚建立，没有几条枪，预算没有，产品处于beta版阶段，当前业务收入有万把块）假如你是这个部门的负责人，怎么分解目标呢？没办法，只好把每个月画成表格，然后把数字拆分往每个月的空格里填好。

3、做解答题。今年的市场份额要上升XX个百分比，进入前三，甚至做中国第一的XXX。大概有这么一个说法，第一名才能让用户记住，排在后面的什么都不是；企业负责人很喜欢这样的论调；他也不把目标分解量化，甚至还没搞清楚拥有多少份额才算是第几名，就像是做一个解答题：我们的目标是什么？没有蛀牙。

制定工作目标是必须的，如果没有目标，事情就会做不好。但如果制定的目标过于“远大”，甚至完全脱离了现实，那么这样的目标还是不要做的好，因为这样不但完不成，还会使团队丧失信心，唯一的好处是达到了管理层的“高瞻远瞩”的战略构想。如果真的拿这样制定出来的目标去考核团队的话，肯定符合“三拍定律”：拍脑袋设目标，拍胸脯保证，拍屁股走人。

本文链接

是做草根，还是做贵族？

2010-01-20T05:36:00Z

视频网站除了做媒体，还能做什么？

视频网站的用户需求

2009-09-15T06:25:00Z

互联网的特征是什么？草根，免费，大众化。所以直接向用户收费的东西很难做，能把视频内容提炼出来收费吗？就像跟电影院一样，看电影收门票。这种方式在互联网上行不通，一定要避免直接收费的方式。即使向用户收费，也要“委婉些”，例如：“增值服务”。

视频网站架构经验

2009-08-21T09:39:00Z

视频网站的架构经验总结。