Archive for the ‘项目管理’ Category

风险投资入门

Saturday, December 1st, 2007

风险投资入门

风险投资呢,就是传说中的“疯投”,以高风险的投资换取高利润。

风险投资是由专门的风险投资基金负责管理的,而这个管理的核心就是一大堆的投资顾问。一般来说,这些人都是经验非常丰富的,在提高利润,降低风险方面手段奇特。不过说实在的,他们其实都挺俗的,不要看作神仙就是了。

风险投资比较感兴趣,并且希望投资的项目都是需要高增长的。一般来说多见于高科技行业,比如最近10年内的互联网。对于传统行业,疯投则比较关注连锁的概念,举个例子国美,或者是麦当劳。高科技行业纵然是依靠几个人的天才,几十个人的补充,就创造出巨额利润的好途径。而连锁概念,则是做好一家店之后快速的复制并成倍的扩大收入。至于传统行业的连锁,我知道的不多,就先谈谈高科技行业里面的互联网的疯投流程。

一般来说呢,一个项目的最开始就是一个人头脑中的想法,想法想要变成行动就成了整个流程最为困难的一步。有的人,安于现状,于是放弃了;有的人,不想离开公司、学校,所以也放弃了。所以最后能真正动手的已经是少数了,有投入必有风险,这个就看每个人对风险的承受能力了。于是,想法要变成行动了。

大多数创业都是以团队的形式,其实所谓团队也就是两三个人为多,大家一起凑点钱,辞了工作,租个小房子,于是开始动手做。这个时间是整个团队最黑暗的时候,不过也是最单纯的时候。大家不分日夜的拼搏,做出理想中的东西。于是在一段时间之后,产品出来了,对于互联网,多半就是一个网站的上线。

这里谈谈创业团队。创业本身是高风险的事情,所以往往是最有毅力,并且聪明的一塌糊涂的人才会愿意参与。当然,创业初期,资金紧缺,大家基本上只是确保生存而已;更不能去招聘其他详细工作的工程师。所以,这个时候,创业团队的成员就需要身兼数职,非超人不能已矣。所以呢,选团队成员时还是谨慎些,仅仅有热情是不够的。这个阶段也不能带希望依靠团队生活的人进来。

在产品面世后,其实都很多团队来说,资金已经开始见底了。这时就需要风险投资了,团队选出一个leader去找风险投资商谈判,出让一部分股份,以换取发展所必需的资金。为了降低风险,很多风险投资项目都不是一家疯投全额投资的,而是三五家疯投共同投资,这个时候就需要挨家去谈。用自己的发展计划和方案来感动投资顾问的口水。

第一轮疯投拿到了之后,团队就可以考虑去注册个公司了,当然这个事情早点做貌似也没什么。公司也会在疯投的沐浴下快速成长。不过,风投基金并不会放心的把钱交给你就算了,而是一般会再派驻一个财务相关的职位给你,甚至是派一个CEO给你。这样的人一般就叫做投资监管,也许会顺便给企业的发展做点贡献。

再之后呢,就是不停的发展,第二轮,第三轮疯投等等。不过注意的几点是,很少有公司去申请第四轮风险投资。再有,并不是每个公司都可以安然的申请到下一轮的疯投,如果公司发展并不顺利,那么疯投可能会对公司的发展失去信心,于是便任由公司关门或收购。对现代企业来说,资金链的重要性怎么形容都不过分。创业企业也有至少99%是死于资金链的断裂。所以,像百度那样,申请到疯投以后也要做好未来可能资金链断裂的准备,尽可能的用这些疯投把公司维持的久一些,是很重要的。

最后呢,当然是IPO了,意思是“首次公开募股”,国内一般叫“上市”。其实也就是到某个证券交易所注册一下,把自己公司的股票再卖出去一部分,以换取下一步发展的资金。而证券交易所也是有各自的学问的,伦敦和纽约证券交易所历史悠久;纳斯达克则主要是做高科技公司的IPO;国内则是上海和深圳两个证券交易所,而香港也有个证券交易所。IPO之后,公司的发展就需要遵守很多制度了,比如财务报表公开等等。因为投资人也需要依赖财务报表来了解公司的运营状况,并对下一步的投资策略作出调整。

关于“天使投资”,名字倒是挺好听的,实际上与风险投资很相像。天使投资就是团队的第一笔投入的资金,有可能是几个团队的成员共同出的,也有可能是找天使投资基金出的。天使投资的风险比风险投资还要高很多,不过一般来说数额都是比较小的。

为什么要用股份制?股份制是一种利益共享,风险共担的公司运行方式。在施行股份制之后,如果公司运行状况转好,各个股东都会受益,当然,创始人的收入肯定不如独资的好;不过如果公司运行状况不好,那么大家也都是一起担着,不至于像独资企业那样可能老板本人都一蹶不振。再有就是公司的某些经营行为是必须要相当的资金投入的,比如互联网行业的购置服务器等,这个时候,往往依靠个人的投资难以实现,所以共同入股以促进公司的运营。再者,就是面对竞争了,一些推广计划中往往遇到竞争对手,这个时候,往往就是比拼双方实力的时候,如果技术不够优秀,就需要用更多的资金投入来袮补不足。最后,就是一个定理的问题了,对于绝大多数行业来说,投入越高,风险越小。无论是一个公司的哪个方向,投入更多的资金也就意味着更大的保险。比如,足够的资金可以聘请来第一流的CEO,可以招到最优秀的CTO,也可以用于更广泛的推广,招更多的工程师等等。

战略与战术。我最常听到想要创业的人说的就是:“等有了钱以后,如何如何”,典型的战略型人才。其实,战略型人才真的是遍地都是,那些根本不去创业的绝大多数人,也知道“有了钱以后”可以如何如何。但是问题难就难在,钱要哪里来?资金可以考虑风险投资,但是你必须要有强悍的发展能力,才可以让风险投资敢于对你投资。也就是说,在天使投资的阶段,就必须要做到最好,在没有拿到风险投资的时候,就已经奠定了成功的基础。

技术必要与否?最早也不知哪一位贤人说了一句:“做事情不能只关心技术”。结果就被一般俗人理解为“做事情不能关心技术”。于是后来俗人便口口相传,到了现在,已经成了流行语了。对于一个要告诉成长,短期内就要达到世界顶尖的公司,风险投资基金关注的事情,在各个阶段是不同的。不过对于一个根本不把技术人员放在眼里的公司,肯定是没戏。在第一轮风险投资的审核阶段,便可以认定一个公司的最初价值,这个时候,基本上产品网站用户寥寥无几。而即便是这个粗陋的产品,也是需要实现的,并不会从一个概念不经过任何技术人员立刻变成产品的。第一轮风险投资往往看中的就是创业团队的技术实力。这个技术实力,并不是技术这么简单,而是要做到顶尖,要巨牛无比的技术。到了第二轮风险投资时,风投基金就开始关注执行能力和未来的计划了。这个时候,最初的天才技术人员已经开始带领一些团队进行继续的产品开发了。第三轮风险投资时则更关注管理能力,包括创业团队每个人的管理能力,还有就是公司在整个行业中的位置。古语云:千里之行始于足下,想做把公司迅速做大,每一步都要走的踏实,不过想要跨过第一步的,往往还等不到第二步的时候也便摔了下去。

第二次互联网的热潮已经显出了降温的趋势,从很多经济的信息也看得出,风险投资基金对互联网的投入比例也在减少。这个时候想要依托风险投资迅速发展的公司更是需要积累足够的实力。不过,至少有一点是肯定的,就是一个优秀的人,无论做什么,都会更成功一些。而风险投资最看重的,一个公司的核心,其实也就是优秀的人。

nagios的插件体系

Tuesday, November 27th, 2007

nagios的插件体系

nagios的插件体系是很方便而友好的,可以允许用任何的程序编写插件,并与nagios很好的协同工作。

nagios的插件实际上就是一个单独的应用程序,所以几乎可以说毫无限制,你可以写一个shell脚本,也可以用汇编写一个内存访问程序,这些都是随便的。当然,需要少许的配置让nagios找到你的这个程序。

传入参数方面,nagios允许使用命令行的那些传入参数,貌似也可以用环境变量来传递。

输出参数方面分为两部分,一个是应用程序调用时的返回代码。一般来说返回码用来标识程序的运行结果,0表示成功。但是nagios却按照这个返回码来显示一个监控参数的危险级别,这是个很好的创意。同样,一个程序运行时的返回码为0则表示这个参数的检测没有出错,如果返回了一个正数,则数字越大表示越危险。在nagios的界面中也会按照不同的颜色来显示。

另外一个输出就是标准输出了,也就是print到屏幕上的内容,nagios会在调用时自动修改重定向以接收这些输出。这些内容nagios并不做分析,而是全部保存,以备了解报警的详细信息。

nagios的插件体系算是我这些年接触的多种插件体系当中最灵活的了,以后也会尽可能的参考他来做。

做大事与项目管理

Thursday, November 1st, 2007

做大事与项目管理

最近听了一位同事的项目管理讲座,实际上主要还是讲Project 2007的使用。软件的使用当然枯燥乏味,转身即忘,不过对Project的管理功能还是有些感触的。

在使用了一些项目管理软件以后,确实可以达到对项目进程和各类资源的精确控制,而这种控制,就是降低风险的好方法。

大学刚毕业时(注:其实刚毕业1年),每每递上简历,都要申明我在某某技术上的熟悉程度,我做过什么样的程序。现在看来与公司真正的最需求的还是有相当的差距。对于一个金字塔状的公司结构来说,一个人的价值在于他可以做多大的事情。如果只是关注于某些技术细节,那么可能控制的范围就比较有限。如果可以从多个方面对公司需要的“事”能够精确的掌控和实现,那就价值很大了。

说到头来,也是这种金字塔形式的层次,实际上对老板来说,他最期望的莫过于什么都不干,只要把投资交给雇员,雇员就可以源源不断的生产出钱来。但是现实世界没有这么理想,所以在整个体系中,有不同的人做着不同的事情。有人可以把一个方面做的精益求精,有些人就善于协调,有些善于交流。当然,从老板的角度讲,还是那句,如果一个雇员可以协调所有资源,并最终创造价值,那么这个雇员的身价也会高很多。

比如某个产品,甚至仅仅是老板说:我想要业绩增长的一句话。一个雇员可以立即提出方案和规划,资源配置,时间安排,那么这个雇员的价值就会立即体现出来。

所以,总的来说么,做老板的大多不懂技术,既然不懂就不必跟老板多说,把他能懂的事情做好,就是本分。当然,这里就涉及到很多其他的事情了,如协调、资源配置等等。但只要把事情做好就是了。

从编程的角度讲,就是提供高层次的封装,隐藏底层细节。至于底层实现就可以有很多学问了,善于协调的可以找别人做,善于实现的可以多受累一些自己做,总之实现了高层次封装和隐藏底层细节就是了。

不过貌似国内有一些很不好的风气,就是鄙视做技术的,而且国内技术人员的待遇也远远无法与管理层相比。也许高层次的协调是一种很稀缺的能力吧,但是却不应该由此形成等级观念。况且世界这么复杂,每个人虽然能力略有差异,但是也不至于就肯定不会某些技能。绝对的做管理和绝对的做技术是不存在的。当然,互相批评的主要目标指的就是这些绝对的人。

总之呢,我以后要学一些关于项目管理的知识了。做技术很享受,但是享受的同时,如果辅以管理,并最终提高生活品质就更好了。

高性能应用程序开发

Monday, October 22nd, 2007

高性能应用程序开发

Author: gashero
Date: 2007-10-22

目录

1 高性能的时代

当你面对汹涌而来的用户时,该怎么做?

产品策划的成功、推广的成功带来了汹涌而来的用户,随之问题开始凸显,曾经运行的很好的服务器,开始极度缓慢;运营经理哭丧着脸看着你显示出他回天无力一般的无奈。在一次成功的推广之后,突然访问量暴增了200%,然后,就在那个能够给你带来划时代推广意义的时候,服务器宕机了。

2 WEB应用的基本结构

一般的WEB应用包含几个基本结构:

  1. WEB应用
  2. 应用服务器
  3. 数据库

这似乎是无可挑剔的简洁,但是问题是当访问量猛增的时候,链条上任何一个结点都可能会成为瓶颈,并且让你欲死不能。

2.1 WEB应用

先进可以做WEB应用的技术很多,比较通用的有PHP、JSP、ASP.net等。一般来说,WEB应用技术本身的性能是无法构成瓶颈的,真正的瓶颈在于这些优雅的框架上编写出的低效的程序。那些经常 select count(*) from xxx 的程序员才是你的恶梦。当然,有一点不得不说,如果一个框架足够难学,那么意味着能够到达这个层次的程序员往往水平也很高,在数据结构、性能优化方面也往往经验丰富,这时候,他所能做的高性能的事情已经不再是一种框架可以制约的了。

PHP本身有着很方便的部署,PHP本身也不太难学,但是一个特点是PHP只有在Linux下才足够地道,导致了相当的学习成本。所以,国内的PHP程序员往往都是经久考验的。

JSP/Servlet本身是优秀的,但是在Java相关技术火热的发展起来之后,程序员队伍的总体素质就堪忧了。其实真正可以从J2SE一路学过来的也倒没什么大碍,关键是怕那些Java WEB速成派。当然从这里也侧面的想到那些IT培训学校所倡导的几个学速成加就业包票的讲法,实在是没的说。也许这个世界上从来都不曾有真正的窍门存在。

至于ASP.net,好用的工具还是要看归什么人用,ASP.net学习成本的低廉造就了一批水平也是相应的程序员。当然,不排除用ASP.net的高手,但是问题是平均水平。

2.2 应用服务器

应用服务器实际上对整个系统性能也有很大的影响,比如resin就比Tomcat性能要高,其他等等不一而足。同时应用服务器的配置也是个艺术。

2.3 数据库

数据库对整体性能影响也是比较大的,同时对于一个不断成长的系统,必须要考虑到未来扩展的可能。

3 高性能WEB应用的一般结构

从前端到后端依次是:

  1. 负载均衡Load Balance
  2. squid
  3. 应用服务器
  4. 中间件/memcache
  5. 数据库服务器

3.1 负载均衡

面对大规模的用户请求,负载均衡是不可或缺的。当然这个东东市场上卖的很贵,可以按照自己的需求来买。最近一段时间流行的第四层交换也可以考虑,产品多多。如果做的不是非常之专业的话,用squid来做目的代理服务器也有相同的功能。

一些软硬件防火墙一般也带有负载均衡的功能,可以利用起来,当然,某种产品中附带的某某功能,肯定是不如专业的好。

负载均衡妙处很多,可以自己慢慢发现,包括好偶面的squid到应用服务器这一层实际上也可以加上负载均衡来确保各个服务器稳定一点。

3.2 squid

用来缓存动态生成的页面,降低服务器的负载。不同的URL有时候需要不同的缓存超时时间。

当然squid在这里的主要用途是降低服务器负载,另外一种技术是网站静态化,达到类似的效果。总的来说加入这样一个缓存层次之后网站的总体负载就可以达到可控的地步了。另外,也可以对squid服务器层进行平行扩展以达到一定范围之内的网站扩容了。

3.3 应用服务器

同上所说,不过既然是在重负载的环境,也就需要好好配置了。

3.4 中间件/memcache

随着网站规模的不同可以选用中间件或memcache,简单一点的网站把数据库的中间查询结果缓存到memcache中即可。不过总体来说,即便是有中间件memcache也是很值得推荐的。

3.5 数据库服务器

巨无霸的Oracle未必就是最好的,多学一些数据库系统原理吧,适应你的需求哪怕是你自己写出来的sqlite集群也会比那些所谓成熟的解决方案好的多。

程序员作为一个以思考来吃饭的职业,如果不去思考,而把一切都寄希望于别人做好的东西可就不好了。不用怀疑,如果上面的那些技术你都用到了,那么说明这个网站已经开始遇到一些前人没有解决的问题了。想办法用你的聪明智慧来解决吧,因为这个时候你已经没法指望别人了。

4 一些基本原理

4.1 数据库连接

数据库的连接计算非常耗时,尽可能避免,如果不可避免那就尽可能减少连接的层次。甚至,你可以为了性能而不遵守各类范式。比如不去做连接,而是把被连接的数据串行化以后存到字段里面。

4.2 数据库统计

数据库的各类统计都是恶梦级别的,包括COUNT()、SUM()等函数调用,和排序操作。有如上面说的,为了性能你可以用尽各类方法,包括不遵守数据库的范式。一些函数的所得数据如果确实很必要,那么就把他们缓存起来。比如一个用户的某个资源数量统计,就可以存入这个用户的一个字段中,并且在每次资源增减时更新这个字段的值。

至于排序,很多时候其实是为了取得某个参数最高的几个,这时大可以在每次更新时把排序字段最高的几个缓存起来。

SUN的某牛曾说,计算机技术历史上最伟大的思想是缓存,用好缓存吧。

4.3 操作流程

每一种操作如果可以按照流程分步骤的话,就可以看清楚很多问题了。因为一个流程的耗时是各个流程耗时的和,这意味着如果可以减少流程,就会提高性能。

当然,与之相悖的是逻辑清晰度,减少划分的层次就会导致一些逻辑合并到了一起。这时如何取舍就是你自己的问题了。想想逻辑清晰的目的。曾经听过一句话:为了用户未必需要的未来的升级而预先做太多的提高灵活性、移植性等等的工作,实际上是违反软件工程师职业道德的体现。

这个事情上推荐去学习一下Tomcat的分层,作为反面典型。

4.4 数据库只是数据库

数据库只是用来存储数据的地方,不要过度依赖SQL语句带来的计算功能,也不要把计算的中间结果也存到数据库里面去。计算并不是数据库的强项,更何况你这样做毫无优化可言。所以当你看到一个很长的SQL语句时应该先仔细考虑他是否有优化的可能。再者,有些人喜欢把计算的每个中间结果都存到数据库里面去,并且把这些结果用于调试。这样做在网站稍微上一点规模的时候就会体现出严重的后果。

不过将数据库用于异构系统之间的数据通信倒是常事。

再就是别把数据库当文件系统,有意义的数据可以存入数据库,但是像用户的头像和上传的其他数据可就别往这东西里面放了。