`
ronghao
  • 浏览: 455988 次
  • 性别: Icon_minigender_1
  • 来自: 北京
博客专栏
E9473dd5-1985-3883-ac98-962354ca10b3
张小庆,在路上
浏览量:8779
社区版块
存档分类
最新评论

三个人的2012-工作篇

阅读更多

 

初六的早晨,刚从老家回来,坐在出租屋的阳台上,阳光灿烂,竟然是北京难得的好天气。距离上次写年终总结已经过去好久,打开博客,发现上次写年终总结已经是四年前的事情。上次写总结的时候还是在东直门温暖的办公室里,随着年龄的增长,觉得时间过得越来越快,四年时间,发生了太多太多的事情:有小孩了,换工作了,最重要的,是三十了。三十,意味着很多事情,古人说,三十而立,对我来说,更重要的是有了更多的责任,不仅仅是家庭,工作也如是。

 

年初负责的第一个项目是配置管理组的运维自动化项目,简单的说就是将之前手工管理的20多台机器使用puppet管理起来。想一想,命运真是讽刺,就在一年前,在上一家公司,自己还对持续集成工具不太感冒,不愿去学,甚至认为有些太难:机器环境的管理、构建工具、jenkinspuppet/chefshell,觉得这些东西太琐碎,一心只想写代码。换了工作,阴差阳错,先到配置管理组工作一段时间,必须学习这些东西,过程就不多说了,只有一个感悟:很多时候,你觉得太难,只是因为你不了解它。用了两周时间,将整个puppet环境搭建起来,一切皆SVN,一切皆代码。

 

接下来的第二个项目是负责调研搜索新架构的自动化发布方案,这是跨部门的合作项目,大大小小跨越20多个项目组,这其中还包括了运维同事、测试同事和云计算基础服务的同事,调研一礼拜,实际上事前准备了很长时间,仅仅那一周的调研计划就修改了四版,系统整理了整个新架构的架构方式,和对方领导达成一致,取得他们的支持,了解大家的期望:开发同事希望能够更快更有效率的发布代码,测试同事希望测试的代码与发布的代码同源,运维同事希望发布过程能够遵从规范可控,当大家对共同的目标达成一致时,方案就顺理成章了:持续集成服务器负责一键编译测试打包上传到包服务器,包服务器保存所有的预发布包,预发布包经过测试后才转为发布包,发布包透过发布系统一键推送到Torca集群调度系统,Torca完成最终集群的发布调度。相比老架构,感觉新架构最明显的提升是:下载、索引和检索三大模块被分离成各自独立的服务,独立演进;统一的数据管理平台,以前追踪badcase很难判定是哪个模块处理数据出了问题,现在透过数据管理平台,数据处理过程被可视化可追踪;统一的脚本执行系统,所有脚本以及执行过程透明可视化;云计算平台,XFS文件系统、Xcube数据库、Torca集群调度、mapreduce并行计算,这些服务大大简化了上层应用的开发。越来越体会到架构的本质:随着系统的演进,我们需要不断进行系统的分解,做到服务的独立演化。当然当时也有困惑:当所有的希望都被压在新架构身上,毕其功于一役,现网老架构停止开发运营时,项目的风险可想而知。做完这个项目,感悟有两个:一是机会只青睐有准备的人;二是跨部门沟通一定要找到共同的利益点,一定要多换位思考。

 

4月份,准备调回项目管理组,去云计算基础架构部做项目经理。在配置管理组的最后一个项目是Jenkins的报表系统,只有一周半时间,最开始准备使用scala,考虑到后续维护最后使用了java,好久没有编码了,找回久违的感觉:打印出IDE的快捷键,搭建开发环境、测试环境和产品环境,jenkins一键自动部署,数据库版本管理,TDD,一周半的时间就上线第一个版本,最后还不得不赞一下jenkinsrest api。感悟是:感谢一期开发时间只有一周半,这使得我们不断思考到底我们要做些什么,哪些是我们最紧急最需要的,哪些是锦上添花的,一期上线后,唯一也是最大的好处就是:我们再也不用手动统计和发送构建周报了,每个礼拜一再也不用那么忙碌了。时间盒,很重要。

 

终于转回了项目经理,去云计算,牛人聚集的地方。首先仍旧是补课:计算机原理、Linux系统编程、C++ primer,一个都不能少。去了没多久,出现了一起事故:搜索模块对云计算SDK的依赖是源代码依赖,云计算有5个产品,但是一个产品单独发布时与之前的SDK不兼容,一发布就直接导致了大量搜索模块的无法编译。正好由我负责来推动解决这个问题,立了一个发布流程规范化项目:通过规范化发布流程、增加自动化集成测试,减少云计算平台的发布风险。所有SDK统一打基线发布,发布前必须进行自动化集成测试,server发布时也要与所有SDK版本进行兼容性测试。随着项目的进行,逐渐融入了这个部门:这是一个工程师文化非常强烈的部门,所有人都在技术上追求卓越,加班到10点以后是非常常见的事情,单元测试覆盖率令人惊讶的全部达到85%,但是很多同事一听到规范和流程就头疼,项目计划也是比较随意,延期比较常见,另外因为之前发布版本升级比较随意,也会经常受到上游兄弟部门的投诉,有很多次出现问题,兄弟部门抱怨云计算平台不稳定,而仔细检查后发现很多时候是使用的方式不对,比如查找文件时使用了遍历。逐渐意识到,部门最大的问题其实是缺少产品运营,大家的关注点全部集中在产品本身上(吞吐量、最大存放文件数、强一致性),或多或少的忽略了用户。5月下旬,风神项目启动,项目目标是搭建台风统一的监控平台和自动化部署框架,打造一站式的台风服务。开始在项目中引入项目管理的实践,WBS是最基本的了,迭代计划找到开发节奏、回顾、每个迭代结束后都努力向线上发布版本,实现持续交付,工程上则将开发环境与线上环境进行了隔离。效果都还不错,但思考更多的还是,我们还应该做些什么。产品发布规范化,必须通过自动兼容性测试和周知用户;集群环境的修改必须可被审计,暂时不能自动化,那么先必须周知部门内同事或结对操作;监控有风神项目,但集群运营、用户数据、可用率日报也需要发送;开发、测试和线上环境互相隔离;定期和用户进行主动沟通,了解他们的问题。这段经历的感悟很简单:产品的核心在于运营,作为服务部门,我们交付的一定是用户满意度而不是产品。

 

紧跟着,新架构还未上线,组织结构调整来了,喜欢ls的直率:我现在的任务很简单,就是看到哪里有山头就把它给平了,所有人都必须听我的,所有人的思路必须一致。

 

在敏捷中国大会发表了演讲《百年历史看管理》,这个session足足准备了2个月时间,重新思考了流程、组织结构和人之间的关系。从20世纪初到40年代,管理科学完成了从无到有的第一个阶段发展,这个阶段最重要的成就就是将管理作为一门科学建立起来,发现了管理的三要素:工作流程、组织结构和人,并振聋发聩的告诉所有人:管理是可以学习的。我们可以看到,所谓管理,都不过是在流程、组织结构和人这三者之中进行权衡调节,管理没有固定模式,只有不同企业根据不同情况在这三者间权衡裁剪罢了。如果说管理科学的第一个阶段是在探讨如何正确的做事,如何提高工作的效率,那么5060年代这二十年管理科学的第二个阶段则是在探讨如何做正确的事:以顾客为中心、做事之前一定要想清楚做事的目的。管理至此也终于有了一个完整的定义:做正确的事、正确的做事。从70年代开始,管理科学进入第三个发展阶段,在这个阶段,首先提出的思想就是没有银弹,管理是一门艺术需要柔性,接下来就是流程的内涵开始延伸,不再是单纯的工作流程,而是面向顾客,强调端到端满足顾客需求的整个过程,这个过程在全球化背景下越来越强调企业之间的协调、强调整个面向交付生态系统的协调,业务流程的概念被提出。进入新世纪,不管是更合理组织结构的思考(扁平化),还是对人的推崇(乔布斯、创新)抑或是业务流程效率的竞争(供应链),都明白无误的告诉我们:管理只有恒久的问题,没有终结的答案

 

9月份调整到新的部门:搜搜问问。先负责的是后台组的项目管理。新团队,老人只有一个,士气低下,缺少文档,上百个服务,光维护就非常困难,重写计划。从回顾会议开始,持续改进。这段时间的感悟是:提升团队士气的最好方式就是帮助大家成功,任何一点成绩都值得鼓励。我们引入了持续集成和自动化发布,鼓励同事做总结和分享;引入了自动化测试,鼓励同事做汇报,帮助review ppt;积极的让大家做有态度的程序员,对产品进行思考和反馈,把团队精神传递到部门经理,让部门经理进行鼓励。可以自豪的说,后台组是现在问问最有战斗力的团队。还有一点最重要的感悟是:一定是团队leader决定团队是否给力,幸运的是,我们有一个非常优秀的leader

 

12月份开始负责部门的社区化运营项目。这和今年工作的感悟是一致的,产品的核心在于运营,这正是我想做的。项目立项一定要有一个NB的名字,我们就叫黑暗骑士。这个项目同样面对很多的挑战,目前最大的挑战还是在于人,团队的信心目前还没有建立,年后可能还会有人提出离职,而招人又是如此的困难,所以,上班第二天的第一件事是回顾会议。团队年前第一个版本发的很有挫折感,需求反复修改,开发人员都心灰意冷,所以,感悟是:一份优秀的需求文档是一切合理计划的起点

 

1月份组织了技术中心的部门年会节目,我们原创的小品《非问勿扰》获得了二等奖。把新人都变为主角,这也算团队建设的一部分。

 

依然在不停思考,对问问来说,我们还应该做些什么。传统问答模式作为搜索引擎的补充是否已经走到了尽头?SNS的问答模式是否值得探索?与微博是否有更深的整合方式,或者,它们本身就是一种产品的两种展现方式?新浪微什么的探索是否还不够大胆?在移动端,独立的app没有前景,如何和微信更有力的结合。

 

终于到了可以结尾的段落,还有一件事情似乎忘了总结,那就是我们写了长达四年的那本书《流程的永恒之道-一个工作流和BPM项目的实战》,什么也不说了,一个例子来说明为什么值得期待:当我们把房管局及各委办局的数据和流程用BPM全部打通后,客户却依旧坚持要手动盖章走人工流程,BPM实施技术根本就不是瓶颈,瓶颈依旧是人啊。今年上半年一定出版。之所以写了四年,是因为写着写着总觉得知道的越来越不够,不断读书和补充内容,真是,那时年少,无知者无畏,唉。

 

2013,黑暗骑士崛起!

 

12
3
分享到:
评论
8 楼 ronghao 2013-02-20  
perzer 写道
想问下,楼主做的自动化发布方案中使用的是开源项目,还是自己做的?谢谢。

jenkins,其他是自己开发
7 楼 perzer 2013-02-19  
想问下,楼主做的自动化发布方案中使用的是开源项目,还是自己做的?谢谢。
6 楼 dilantaya 2013-02-18  
lz的文章给了我很大的帮助,有人说过你能走多久在于你与谁同行,总有强者在你前面,谢谢!
5 楼 jiji87432 2013-02-17  
很受用,我自己也写了一下年终总结,逝去的2012,崭新的2013值得学习的一年,希望楼主指导指导。
4 楼 北一王 2013-02-17  
受教颇深。感谢。2013需要学习的一年,看到这篇文章,是个好的开始,加油。
3 楼 jacking124 2013-02-16  
你的经历很多的,应该给新人的成长,做点指导呀!
2 楼 ronghao 2013-02-16  
panshisong 写道
楼主很给力。相信楼主走了这么多的路,能给我们新人点什么好的学习心态,方法,或者理念吗!我看到很多前辈们都说要学习的业务思维模式,但是对于这个概念我又很懵懂,不知道楼主能给简单解释下吗?十分感谢!

多问产品经理为什么要做这个功能,不做这个功能有什么影响。
1 楼 panshisong 2013-02-16  
楼主很给力。相信楼主走了这么多的路,能给我们新人点什么好的学习心态,方法,或者理念吗!我看到很多前辈们都说要学习的业务思维模式,但是对于这个概念我又很懵懂,不知道楼主能给简单解释下吗?十分感谢!

相关推荐

Global site tag (gtag.js) - Google Analytics