前两天听了海量用户服务系列课后，收获颇多，快速整理下思路，几个基本点：

一，互联网产品是一个运营的产品，产品的成功很大程度上是运营出来的，而不是开发出来的，从产品的生命周期看，开发环节只是占了其中的一小部分，而产品的生命周期大部分是处于运营状态，因此，在架构设计阶段就必须把产品的可运营性纳入到设计的重要思考点，而绝对不是简单的实现一个功能点就大功告成了。

 

二，什么是可运营的产品？产品的运营是一个动态调整的过程，能够根据用户的需求变化，确保在低成本（可以忍受）的基础上进行快速的迭代，这里必须强调的一个关键点是运营的成本，也许你会说，我的产品是可以动态调整的，但是问题是，你的调整需要付出非常大的代价，不管是机器成本，带宽成本还有人力成本等等，从这个角度上看，这个产品架构设计上就不能算很成功了的。

 

三，针对海量级别的系统设计，我们又根据带宽，存储，单位请求量，用户数和需要的机器数量等的不同分成小胖系统和大胖系统，对这种海量级别的系统，必须坚持两个基本的价值观：有损服务＋柔性可用，动态运营。在这两个基本的价值观去指导系统的设计，才有可能做到大系统，小做。

 

四，在中国的互联网环境中，行业领先者没有太大的动力进行盲目的创新，因此强调快速的跟进变化的能力，在仔细观察行业的趋势，一旦发现新的“绿洲”，马上调度自身有优势的资源快速跟进，实现快速跟进和反超竞争对手。在这种情况下，一个公司，必须有一套能够快速响应的开发流程来保证快速跟进业务的执行能力，以迭代运营来换认识的深度，重点在于快，重点在于运营。

 

五：一旦系统上线，必须有足够的手段来收集用户的反馈，必须有足够的监控来获取用户的行为数据，通过挖掘和分析这里数据，我们才能够真正去认识用户的行为，我们的哪些功能是受用户欢迎的，哪些是用户不怎么使用的，用户在站点的跳转路径是如何的，等等，根据这些反馈来不断快速的调整我们的系统。

 

六：系统的监控是系统架构设计的一个重要方面。一个没有任何监控的系统上线后，我们根本无法知道用户对我们的产品是欢迎还是抵制？哪些是受欢迎的哪些是用户不喜欢的？因此也就缺少了进行产品方向调整的依据，这样的产品设计是完全脱离用户的需求的，是无法倾听到用户的声音的，一切的功能点都只是产品经理喜欢而已，这样的产品是很难成功。

七：对系统进行立体监控，而监控的实施也是一个灰度迭代的过程，根据业务的特点和每个阶段的核心需求点，实施不同的监控点，一个系统的基本监控分为：系统监控和业务监控。其中系统监控是对系统层面进行监控，而业务监控主要是针对业务流程和业务数据进行监控。系统监控可以分成：系统容量监控，系统带宽监控，进程监控，进程端口监控，磁盘空间容量监控，CPU性能监控，cgi响应监控，cgi响应速度监控等。业务监控的点主要根据业务的不同而不同。