5月3日劳动节日期间,Fireman团队遇到了原因不明的系统崩溃,应用系统每隔约30分钟崩溃一次。由于应用只部署在了一台机器上,挂掉的时候为了不影响用户使用,不能做现场的内存和程序分析,只能立刻重启应用。当天实在不得已,试着把应用从windows迁移到了linux,同时加上了tengine做负载均衡(负载均衡后面挂这个应用的2个实例),以便在一个应用实例挂掉的时候可以保留现场,进行分析;奇迹的是,迁移以后问题立马不再出现。之前团队有计划逐步迁移到tengine和linux,由于存在一些风险,一直没动。

这是一个在情况糟糕到极点,引入新技术,并且成功的例子。 记忆中有不少这样的例子。

大约2012年,在点评的时候,我们用F5硬件做负载均衡,用了已经大约7年时间。但由于并发量,用户量的增加,加上F5里面URL Rewrite的规则越来越多,负载的流量转发服务偶尔不稳定,而且F5是商业的系统,出现问题难以定位和自己解决。有一天流量上来,很多系统瘫痪不可用。经过运维分析定位,找到原因出在F5上。 原先内部就有很多人建议迁移到软负载,一直没开始做。 这一次,很多系统瘫痪,整个网站访问不了。 运维团队当机立断,立即把负载均衡从硬件的F5改成用 HA Proxy,当时我们的手心为运维团队捏了一把汗,结果是迁移以后系统平稳运行。后来我们所有的系统全部平稳迁移到了软负载,抛弃了一台几十万的硬负载设备。

这两个事情有显著的共同点,在情况糟糕到极点(坏到不能再坏)的时候,人们迫不得已,尝试新技术,新工具,因为不用担心会有更糟糕的情况发生,也不用承担采用新技术,新工具所带来的风险。于是就有了创新,带来了变革。

不怕犯错,才能够创新;这是为什么往往在事情糟糕到极点的时候,创新容易发生的原因(人们不用为创新可能引起的错误承担责任)。

为什么人们平时不敢使用新技术,新方法?一个方面由于新技术/方法可能导致出错(出错是否可以不产生问题?对于出错的风险没有去深入思考,找出规避风险的措施,于是不敢冒险);另外一个方面也是对于学习新技术/方法的成本估计过高,不敢迈步(事情糟糕到极点时,实在没有办法,不得不逼自己一试)。

那么创新的条件是怎么样的?

再举一个例子,4月26日晚上的时候,我们的3台服务器全挂了。由于30分钟有2000w的流量,系统没有缓存,也没有事先得到消息当天会有广告投放引流,于是当时广告投放方紧急停止广告,延到4月28日投放另外2个小时的广告。按照预估,我们要在27日1天之内,完成系统的性能优化,增加缓存,增加CDN,把服务器数量从3台加到10台,出现问题时能够瞬间切换10台服务器到备份方案。之前的3台服务器,每次都是手工发布的,把asp.net的应用程序拷贝到一台台服务器上,然后重启IIS,整个手工操作过程容易出错,重复、枯燥,缓慢。

结果不得已,我们研发的同学1天之内评估了多个商业和开源的自动化发布系统,选用了octopus这款自动化发布工具,完美支持了.net应用的自动化批量发布,也能够在出现问题时瞬间把10台服务器切换到备份方案。

以往我们一直喊自动化发布,喊了半年没用起来。这次花了一天时间就把自动化发布部署起来,也用了起来。 这一创新的条件是,服务器增多,时间紧迫(条件受限),不得不使用使用工具来做。

从组织的角度,创新的一个条件是,所在的组织鼓励创新,允许犯错,在这里,每一个人都有犯错的权利,我们鼓励每一个人去尝试新技术,新方法,新工具,新思想。

如何促进自己的创新能力,学习新技术的能力:敢于面对困难(困难都是一个个的约束条件),不断尝试新方法,过程中把握系统性的风险(减少犯错的影响,想清楚万一不成功的Backup plan)。有一句话讲“Fail fast, fail better”,有很多技术会失败,有很多的商业方案会失败,如果能够更快地促成失败的发生,这是Fail Fast,过程中确保失败是可承受的,是有事先准备的,并且汲取经验不断成长,那么离成功就越来越近,这是Fail Better。

总结一下创新,犯错,与创新的条件:

  • 不怕犯错,才能够创新;这是为什么往往在事情糟糕到极点的时候,创新容易发生的原因(人们不用为创新可能引起的错误承担责任)。
  • 每个人都有犯错的权利
  • 平时不敢使用新技术,新方法的原因:一个方面由于新技术/方法可能导致出错(出错是否可以不产生问题?对于出错的风险没有去深入思考,找出规避风险的措施,于是不敢冒险);另外一个方面也是对于学习新技术/方法的成本估计过高,不敢迈步(事情糟糕到极点时,实在没有办法,不得不逼自己一试)。
  • 创新的条件:新的问题的出现,新的约束条件的出现,容易促进创新的产生;参与者敢于冒险,胆大信心,能够控制创新的风险;所在的组织鼓励创新,允许犯错;