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。

总结一下创新，犯错，与创新的条件：

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