Oct 132012
 

今天看到淘宝的技术写了一篇交流总结。感觉也印证了我的很多想法。

  1. 公司没有测试人员
  2. 直接上线进行压力测试
  3. 所有技术人员需要了解网站全部架构

 

下面转载内容http://blog.csdn.net/cenwenchu79/article/details/6196886

 

也算机缘巧合,一个不能称之为机会的机会让我再次和国外现在炙手可热的T公司(由于也不想过多的说这家公司的名字,因此就用T作为代号了)做了一次技术和公司文化的简单交流,这里做个简单的交流分享,希望能够让更多的朋友能够从中找到自己团队或者公司有帮助的内容。但这里还是丑话说在前头,中国有句成语:东施效颦。国外的月亮多圆我不知道,但是我们需要客观的看待不同环境的差异,看到目标,而不要过多模仿过程。下面的阐述将都分成场景和观点,如何做三部分,场景描述了具体的情况,观点仅仅代表我自己的一些感触和理解,如何做是对问题Action提出自己的想法。

场景1:

         T公司的任何一个小Team(业务上划分或者职能上划分)都需要熟悉整个系统从前到后从上到下的代码实现。例如相册团队,从前端脚本,到业务逻辑,再到底层的Memcached或者图片服务器代码在必要的时候都能自己修改和实现业务需求。UserGroup团队是负责对全球业务的用户做统计分析的,当希望做一些变革能够尝试着提升用户转化率的时候,首先是考虑自己如何动手去修改已有系统的功能,而不是去协调各个团队去做。

观点:

垂直化的开发模式其实挑战了国内很多企业的横向细分化流水线方式的开发模式。从技术的横向细分,到业务的模块化细分,好处是提高企业的生产效率,坏处是对人全方面的培养成为一种制约。最大的问题:对自己上游系统的需求了解不透彻,对自己依赖系统的实现完全不理解。

如何做:

横向切分的方式和纵向的方式都有适应的场景,因此可以考虑在互连网企业中部分部门中实施垂直化开发模式,这些部门人员素质较高,能够从产品层面全局的考虑整体的发展,通过实际的参与各个业务线和各个层次的技术中间件开发,为横向切分的部门工作做出改进和建议。这样在高素质人才发展和网站规模化整体化发展之间找到平衡点,相互促进。

场景2:

         T公司的任何一个技术框架都可以被挑战和替换,只要用数字和测试结果作为有效的证据,大家都抱着对公司负责的态度来对待技术选型。因此在T公司中,技术的发展完全是最原始的优胜劣汰机制。

观点:

这点其实很赞同,首先技术如果不是用数据来说话,采用自上而下的方式来决定选型,那么就是拍脑袋做事情。另一方面,如果技术不持续的按照用户需求来优化和演进,那么一定会烂掉,最好的触动不断发展的方式,就是竞争。有人会担心技术竞争会带来资源消耗,其实烂掉的东西在被使用的过程中一样在消耗。

如何做:

首先当然还是提倡积累,能够在已有的技术基础上不断积累发展是最好的,其次也应该鼓励创新,如果有足够理由证明成熟的技术能够替代现有技术,而现有技术又没有发展的动力时,变革并不是坏事(也许这种压力就会迫使原有技术实现者去更好服务客户),最后就是给每个人都有改变任何一部分代码的能力,因为依赖的不稳定也决定了上层系统的不稳定,作为一个产品来看,每个人是对产品负责,而不是对一个组件负责。

场景3:

没有任何文档。最多写一点wiki。

观点:

设计从简,代码需要更优雅,注释需要更全面。文档是代码的骨架。

如何做:

应该有产品需求文档,理解业务需求。技术文档多半是总体性设计和一些协议描述,多一些代码注释和Demo,更利于学习和阅读。

场景4:

应用都被编译在一个包里,一台机器就运行了诺大一个网站的所有功能,不存在服务器间的应用服务调用,都是本地服务方法调用(服务依赖较少)。

观点:

这和Java类型的应用还有些差别,Java的第三方依赖较多,版本凌乱复杂,导致应用部署在一台机器上很困难。但很多大型网站的系统设计慢慢地就将模块分的很细,结果导致服务调用和依赖特别复杂,自身的可用性和稳定性变得难以估量。

如何做:

需要审视服务粒度的合理性及垂直化设计在不同系统中的应用,需要在可扩展和可用性及效率中差别对待不同系统设计,同时降低服务差异性,减少应用服务器由于应用差异导致无法复用的问题。

场景5:

任何一个应用或者中间件开发完成后,都会有一个监控应用伴随诞生。(有些是直接通过已有工具实现,有些独立实现)

观点:

1:1的透明化开发比unit test来的还要重要,因为运行期的系统透明化是业务分析,系统优化,系统监控告警最基本的要求。

如何做:

最低代价就是将监控数据记录打点,应用或者外部系统对数据进行计算和分析,最终提供结果给外部系统展现和处理。

场景6:

没有测试团队,任何开发都是测试人员,通过工具完成页面,接口,集成测试。

观点:

强大的测试工具框架为开发人员提供了测试的规范性和便利性,同时开发人员自身的责任感增强,也让开发人员在测试过程中总结和思索开发设计的常规性错误,理解边界问题。

如何做:

需要有专人专职来负责测试框架的有效性,当然对于这个人或者这么一个小团队来说要求很高。可以借鉴的是,测试团队应该有更加高效的方式自动化测试,同时应该将测试框架开放给开发人员,增强开发人员对产品质量的责任感。

场景7:

没有线下的压力测试和极限测试,线上引流和部分区域发布来做测试。

观点:

一直认为线下的网络环境,用户数据的仿真度都难以模拟线上,因此很多压力测试和极限测试的数据基本就不能成为依据。在数据透明化体系完成后,线上的任何改变都可以获得数据的支持,这样单独或者对比的结果就是压力测试或者AB测试的结果。

如何做:

系统透明化工作为基础,结合Beta发布或者局部发布的模式来验证和测试不同压力下的新老系统。

场景8:

Hack Day,一个晚上通宵做出原型,第二天在全公司面前展现创意,用技术来说服有兴趣的同事一起去做一些有创意的工作。T公司最典型的视频项目就出自于Hack Day。

观点:

通过自己努力和时间的投入,在公司给的平台上展现,最后取得好的效果。

如何做:

公司给平台,个人挤时间。

场景9:

公司中所有的开发人员都是Engineer,每个人可能不同Level,但是每个人的工作都是自己来考虑,上级M只是替Engineer去协调资源。此时任何Team的人如果有想法和创意,如果要做,也需要资源,只能靠自己去说服同事一起做,而M没有权利否定或者强制Engineer去做任何工作。

观点:

由于考核都是同事之间点到点的评价,因此其实M没有任何实质性的技术管理职能在,任务分配和工作目标也是工程师自己需要去考虑的,主动权掌握在自己手中。工程师需要去考虑自己有限的工作时间中如何做有效的做出最有用的内容。能力越大责任越大,因此原本认为束缚工程师的方式,其实反而给工程师偷懒思考的机会。

如何做:

在工程师技术能力达到一定阶层时,国内的公司可以考虑采用这样的方式去管理他们,同时为他们提供更广阔的技术空间去创新和渗透到他们希望渗透的产品中。

场景10:

对于问题从效率角度去考虑如何解决,而不是简单的从资源角度去考虑。

观点:

公司发展壮大,业务战线不断变长,往往第一就考虑需要资源,往往忽略了如何用技术提升效率。增加资源有时候反而是增加内耗和降低工作效率的诱因。

如何做:

压力带来动力,决策者需要判断和观察。

场景11:

每个新人进来都会进入新兵训练营,每个人选择自己有兴趣加盟的两到三个团队,一个月内完成两到三个团队的一些线上问题修复,在熟悉业务的同时,也锻炼了自己的能力,同时更加明确自己感兴趣的团队究竟是哪一个。

观点:

这种方式可以最直接的让新人了解业务,熟悉将来的方向,同时也是检验一个人能力的最有效的手段。

场景12:

不同Level的错误有不同的通报,产生较大问题时,全公司邮件通报,但考核并不看问题发生次数和严重程度(因为每个人都可以修改各个层次内容,多做多错,少做少错这种事情不应该鼓励)。同时,任何过失需要描述四方面内容:现象,问题原因,解决方法,防范措施。范例:有一个同事修改了底层配置系统的部分代码,结果导致全站系统2小时不可用,全公司通报。遂这个同事花了几天时间全部重写了底层配置系统代码,为了防止别人和他犯一样的错误,后遇人都笑谈他重写代码的事,而不是那次问题。

观点:

首先,大家都抱着乐观的态度去看待犯错,看到别人的总结,也是审视自己的工作。其次,最重要的是问题的解决和预防,这点是透明化问题的关键所在,也是驱动犯错者改进自身不足的动力。

如何做:

倡导这种氛围,提升工程师的责任感。

场景13:

对于所有代码的更新时间有监控,很久没有更新的代码将会被提出来,作为烂掉的代码告警全团队。

观点:

很多时候不是做减法不易,而是没人知道什么时候该减什么。

时间有限,其实也没谈太多技术内部的东西,但是从周边的这些内容聊下来,两点让我感觉和去年自己做的一些工作很类似,也很重要。产品责任感,系统透明化。

不论是业务或者技术的垂直化,测试工作前移,产品设计后移(在另外文章中有提到),技术工作自我定义,其实都是在考验一个工程师对产品的责任感,不简单的约束自己在某一个技术领域,在某一个产品环节,在某一个岗位职责,也许听起来是一个较高Level的工程师(国内叫架构师)所需要考虑的,但其实也只有这样的工程师才会称得上是合格的工程师。

不论是1:1系统设计方式,线上仿真测试,丰富的监控系统,其实就是要求做每一个业务系统或者技术框架一定要做好透明化工作,系统透明化是对当前系统负责,对依赖这个系统的外部系统负责。当一个网站各个零部件都能被外部所观察到的时候,出现问题不为人知,缓慢出现量变病化,业务模式AB结果都将变得一目了然。

Oct 132012
 

这其实是我一直想要实现的目标。不过要搞定这个不是那么容易。

如果只是用cobbler装系统,puppet部署Openstack,这其实还是在我的能力范围,我可以搞定。不过如果希望整合好,那就无法避免需要做些开发, 这我就搞不定了。

一定要相信,假如你的设想是对的,那么就一定有人在做。如果没有人在做,就说明你的设想是错误的。

http://www.slideshare.net/guanxiaohua2k6/dodai-openstack-2012autumn

https://github.com/nii-cloud

这个项目已经开源,看PPT介绍,做了一个web界面管理。值得好好测试。这是日本的NTT Data做的。他在Openstack社区应该是很活跃的。比较难得的这位朋友感觉是华人。

我找时间测试测试,争取和他交流交流

Oct 112012
 

今天在超微的机器安装ubuntu 12.04,结果出现这个错误

快照2

The partitiontable table format in use on your disks normally requieres youto create a separatepartition for boot loader code.This partition should be marked for use as “Reserved BIOSbootarea” and should be at least 1 MB in size. Notethat this is not the same as a partitionmounted on /boot.
If you do not go back to the partitioning menu and correct this error, boot loader installationmay fail later, although it may still be possibleto installthe boot loaderto a partition.

http://hi.baidu.com/vc277/item/83db7b905a0112dd7a7f01dd

这个错误,我以前听sina的朋友提过,看来我也中招。解决的办法,就是在preseed文件增加多一个1M的分区。

照sina朋友给的办法不行,自己去搜索。这个应该是和他以前装centos的时候,采用类似lvm分区导致的。

http://cptyesterday.wordpress.com/2012/07/20/get-expert_recipe-mdraid-lvm-gpt-and-grub2-playing-together-on-ubuntu-lucid-and-debian-squeeze/

搞定,让我很爽。解决了我一大问题。

d-i partman-auto/expert_recipe string                         \
          boot-root ::                          \
             1 1 1 free                          \
                $iflabel{ gpt }                  \
                method{ biosgrub }               \
              .                                               \
              150 150 150 ext4                                 \
                      $primary{ } $bootable{ }                \
                      method{ format } format{ }              \
                      use_filesystem{ } filesystem{ ext4 }    \
                      mountpoint{ /boot }                     \
              .                                               \

在我以前的文件里,增加一段就可以。

             1 1 1 free                          \
                $iflabel{ gpt }                  \
                method{ biosgrub }               \
              .                                               \

这其实也算是解决一个大问题。

http://cptyesterday.wordpress.com/2012/06/17/notes-on-using-expert_recipe-in-debianubuntu-preseed-files/

http://cptyesterday.wordpress.com/2012/07/20/get-expert_recipe-mdraid-lvm-gpt-and-grub2-playing-together-on-ubuntu-lucid-and-debian-squeeze/

Oct 052012
 

我经常要帮别人解决这个问题。不同的软件,需要的工具不一样。我就整理一下。下面这些工具,都是最近

浏览器的密码

http://www.magicaljellybean.com/passwdfinder/

估计工具很多,这个今天刚好测试了一下,我火狐下的账号全部看到。

wifi的密码

http://www.nirsoft.net/utils/wireless_key.html

现在win7下查看wifi的密码,已经比以前麻烦很多,用这个工具就可以,区分32bit和64bit。

密码工具

http://www.nirsoft.net/password_recovery_tools.html

基本应该都可以满足你的需求。包括adsl的密码。

http://www.nirsoft.net/utils/index.html

Oct 032012
 

这次回大同看小孩,也就顺便了解一下老婆的表妹的学习情况,今年初二,说起英语作文,她说她的中国式英语作文,给老师扣掉了7分。

别的不行,辅导别人写英文作文,我还是比较牛逼的。

这位老师批评学生写的是中国式英语,其实如果让这位老师写作文,也肯定是中国式的英语。按照这位老师的教育,学生到高考,估计也不会如何写作文.其实这位老师, 很可能他也不会.

只要是中国人,自己写的英文,基本都是中国式。要避免中国式,就不要自己写,而是直接套用老外的格式。如何套用,那么就要参加曹老师的培训。

后来参加MBA培训,接受的曹其军的教育,以后也就再也不害怕英文作文,我也能指导别人如何写英文的作文。

曹其军给我们举了一个很贴切的例子,作文题:计划生育

拿到这个作文题,学生马上写的第一个句子就是,计划生育是我国的基本国策。基本国策,英文如何写呢?估计基本都写错。最恐怖的是:写完这句,后面写啥呢?

我相信就算英文8级的人,让他用英文对计划生育发表高论,估计都是很难高难度的活。那么这个作文题是考察啥,是考察我们对计划生育的看法还是我们的英文表达能力呢?显然是我们的英文表达能力。

曹老师的作文是大概如下

计划生育现在是一个非常热门的话题,无论的电台,电视,还是校园,大家都激烈讨论。对于计划生育,一部分人的观点是:

另外一部分人观点是

这两个观点,听起来都挺有道理的,不过我的观点是

看看下面这篇,就基本是这个套路完成的。对比作文。例如出国留学,早教,等。基本都是可以这样写。红色标记部分,是重点.

Continue reading »

Oct 012012
 

以前启用过百度的统计,其实感觉还可以,不过一个麻烦的地方就是我每次升级完主题,就需要重新添加一次统计代码,这个比较累。

Suffusion主题,其实内置google统计,你只需要启用,加入代码就可以,主题升级,不影响。

我gmail账号,启用google的分析服务。把代码copy过去就可以。改天熟悉一下google分析.

统计