Chinaunix首页 | 论坛 | 博客
  • 博客访问: 3597706
  • 博文数量: 1575
  • 博客积分: 19423
  • 博客等级: 上将
  • 技术积分: 16102
  • 用 户 组: 普通用户
  • 注册时间: 2007-06-19 21:36
个人简介

专注专心

文章分类

全部博文(1575)

文章存档

2020年(10)

2018年(7)

2016年(6)

2015年(21)

2014年(32)

2013年(279)

2012年(516)

2011年(309)

2010年(260)

2009年(92)

2008年(15)

2007年(28)

我的朋友

分类: IT职场

2012-08-12 09:28:43

影响系统架构师成长的十一个问题
2012年08月10日19:13 原创 作者:景保玉 编辑: 评论:0

  【IT168专稿】全球系统架构师大会于8月10-12日在深圳万科国际会议中心隆重举行。今天上午的最后一个环节是架构师的能力模型圆桌论坛,主要给大家分享了如何成长为一个合格的架构师。在现场的互动环节中,来自大众点评的架构师王宏通过一系列一针见血的提问,引爆了现场的气氛,也让更多的架构师充分体会到了自己的成长路线,以及成长过程中遇到的各种问题,如何解决这些问题。


  参与本场圆桌讨论的嘉宾主要有:腾讯高级执行副总裁汤道生;去哪儿CTO吴永强;百度技术委员会主席廖若雪;土豆网产品技术副总裁黄冬。


▲系统架构师成功模型圆桌讨论

  以下是所有的精彩问答实录:

  问题1、在社区中讨论非常多、非常热烈,回答各种各样。这个问题是你们现在还写代码吗?你们觉得架构师这个角色应该写代码吗?

  【廖若雪】还写一些。我觉得需要。架构师如果不是持续写代码、不是持续对技术的东西做一些了解,知识会过时,会形成错误的概念、错误的方法论证。

  【黄冬】个人爱好,写点。但是我觉得必须写,而且更重要的是要看一些代码,理解他们怎么工作或者怎么做一些事情,这样才能真正理解自己架构的特性和应用是不是正确的。

  问题2、从两位的回答中,架构师到一定级别,可能没有那么多时间写代码,但是一定要完成的是对自己系统了解、对底层深入的了解,这样在系统运营中有一些情况和问题能够快速解决这些问题,这是架构师最基本的能力。架构师你觉得应该有什么样的最基本能力?

  【汤道生】对于数据的敏感。不管写不写代码,看代码一定要的,很多时候架构一定是框架,框架里面填什么内容、细节怎么实现,其实是非常重要的。但是作为一个架构师,时间分配很多时候经常要了解细节,而且要做出判断,细节的体现很多时候不一定通过代码,需要更客观地去看一些数据,而且要考虑架构不仅仅是程序的架构,可以是网络的架构,可以是设备资源的独特性所带来的对于应用有不同的要求。最终我觉得是要深度了解整个服务体系在关键点上的数据表现充分的抓取分析,这是作为一个架构师非常重要的数据。

  【吴永强】我觉得架构师第一步还是思维能力,重要的难题是鉴定问题。如果问题不清楚,之后所做的工作都是错的。

  第二,基本方法论,需要抽象和简化,比较难,怎么样把抽象的问题变成简单的问题。

  问题3、从几位回答过程中不难看出,架构师要有敏锐的观察力,对系统各个点到面上升到框架结构,之后不同的发展才有不同的路线问题。这些基本素质以外相对已经做到CTO的级别,怎么样发觉一位好的架构师,看到闪亮点,放到合适的问题,这是很多架构师需要了解怎么看人的。

  【黄冬】这个问题问的很尖锐,我觉得有几点很重要:

  第一,如果好的架构师,应该在代码的编写,业务的理解、整个系统的运行以及运行之后整个项目的运营商要充分了解。所以一个好的架构师的基础是在四种工作上有多的经验。如果没有这个基础要素,做事情的时候有些判断更多是夺来品,不是自己思考的。

  第二,要有敏锐的观察力,在这四种工作上或多或少产生好的抽象、好的运行结果。架构师还有一个特性,当一件事情难以解决的时候,承担起一个责任,一个判断、观察,并且勇于承担责任,产生好结果的循环要发现。有了基础的经验、素质外加一些特别事情的表现,是我认为有基础成为架构师的一个判断。当然,还有一个重要的话题是,也许在某一点上有了亮点之后,需要给它在另外几个层面一些培养的机会。我曾经让一个架构师从做开发到学习网络和面对整个系统的运营到业务层面,花了将近四年的时间逐一去经历,慢慢去成长。

  【廖若雪】我再补充两点:第一,基础能力和学习能力。尤其是后期,很难说是去花很多精力补充非常基础的弱点。成功的架构师在自己相关领域的基础能力比较强。学习能力,怎么把握新知识要点的地方。

  第二,架构师面临的问题和所有资源都非常清晰的了解。我们常说,这个事情是不是能够说清楚,说清楚说起来很简单,但是对很多问题的细节、方方面面,抓住问题的关键点都需要提出很高的要求,是不是能够在别人问你问题的时候,尤其是你看到问题,后续怎么补充、补足,使得认识加深,找到资源分配,给到方案。

  第三,对于架构师来说,应该有一些追求。追求就是对架构上面的一种简单或者美的追求。不是把这事做完了能够满足目标就OK了,希望能够做出更好的东西,更美、更简单的东西。这是我的几点感受。

  【吴永强】我只补充一点,我觉得架构上有一个很重要的是能不能应对变化。互联网公司大公司比较稳定,小公司变化非常多,而且系统的性能跟着流量、业务的复杂度发生变化,有没有办法自己突破设定很多结构性的东西,否则没办法跟上公司的发展。

  【汤道生】几位专家把要点都说了,我非常认同学习能力很重要。架构师放在不同场景、不同领域能够很快速的抓到关键点,学习到新的领域,是一个基本的数值。如果在这样的基础下有机会在不同的岗位提炼一些经验、沉淀一些经验。在开发、运营、网络各个方面有机会积累的话,这个人的视野、看问题的广度会有一个更好的基础。

  对于用户需求的了解,架构师的“架构”只是一个命词,是一个手段。架构是用来解决问题的,反过来说是解决问题的能力。我们看到有不少的架构师或者技术人员发展到一定的阶段遇到的瓶颈,是手上架构的能力,对于实际要解决的问题、目的有点远,脱离了。最后不理解用户的需求,或者不够充分的掌握服务要达到什么目的。很难通过架构的设计达到好的结果,我觉得这一点是一个架构师在个人发展过程不断提升的地方。

  问题4、架构师发展而来多数是程序员,以前在做程序员的时候做得是某一个点、某一块的功能开发,要上升到一个前瞻性、系统化。还有一个,一定要有远瞻性。几位都提到一定要了解系统运营中实际的一些问题,要落地、接地气,不单单在技术层面上探讨所谓的深度、复杂性就可以了,一定要了解到自己系统运营的特色,大家如何看?

  【汤道生】落地就是通过不同的岗位上解决、提问题,刚才大家都有提到。

  【吴永强】软件就是为了解决问题,不解决问题就没有价值,每个工程师都应该有这个概念。

  问题5、原来我是作为工程,需求很明确,各方面需求来自设计部门、产品部门、运营部门,跟他们的需求很近。做到架构出现一个问题,我的需求太多、太远,导致试点上有些段,朝着某些方面深入下去,开始脱离了基本的业务需求,脱离业务线。若雪深有体会,请分享一下。

  【廖若雪】我们做架构要解决实际问题,不是解决漂亮的问题。我们需求分析能力非常重要,如何才能把需求看东西,给出一个方案。这里有一个问题有一点感受。很多人说需求看不清楚怎么办。有时候需要根据实际情况,确实要看你的经验。看不到问题的时候,看架构师本身的潜在性能。是不是能够比别人看得更远一点,这就是核心的问题。

  【黄冬】我经历过很多架构,单纯从视频网站的架构,自己经历有三个,土豆网的视频架构截然不同。反过来讲,截然不同的架构由一个架构师设计出来的时候,一定受到很多的挑战。一个优秀的架构师设计这个架构的时候,一定会遵从某一个甚至几个最需要解决的业务需求。但是业务人员也罢、工程师也罢,会不断的挑战。我比较郁闷的是一些架构师会说某某某是怎样做的,我们也这样做,但是一个真正有效的架构师,能够有执行力的架构师,恰巧是把架构尖锐的问题解决好的同时,规避好架构在实际当中用法的问题。

  我认为一个好架构的落地是非常艰辛的,整个系统运行过程中看到的数据,用巧妙的方法在不改变架构,不让大量工作废弃的情况下仍然运行良好。

  问题6、作为架构师能够把架构上升到美的程度。把架构做得简单,所谓简单是系统结构,思维是简单的。新的系统上线要说服使用,成为一个成功的演说点。说难听点是忽悠,忽悠要基本能力的。当别人提到一个问题,怎么解决他们提出的问题,深刻地考验了一个架构师对系统每一个细节的了解。这里延伸出一个问题,作为一个架构师具备这么多的能力,到底在技术深度上做更多的发展,还是广度上发展。我们要了解各种各样的学科还是只是在一门。像腾讯、淘宝对数据库的基本代码很深入的研究下去,也有人做系统的。

  【吴永强】我觉得这个东西跟学习一样的,一个好的人或者比较成功的人一定具备特别好的能力,一个归纳、一个演绎,可以把两点结合起来,广度要有,但是要学会归纳。深度也要有,要学会演绎。里面如果学的很深,基本上其他的软件结构都能演绎出来。我认为架构师的广度和深度都要有,而且要继续加深。

  【黄冬】首先,我认为一个架构师的出发点一定是足够深的深度,如果没有闪光点,没有机会成为一个架构师。所以在一开始的时候一定有深度产生的,也许是一个非常好的DPA,也许是一个非常好的写代码的工程师,也许是对硬件非常精通或者对业务非常精通的人,一定非常深入擅长。但是当他的职业生涯走向架构师,必须放弃往下钻,一定足够广,可以把自己的深度当成业务爱好,不能当成自己的工作。

  作为一个好的架构一定是所有的层面都能有所了解,才能综合和抽象,我觉得是分前后期。

  【吴永强】我觉得跟爱好无关,是工作上的问题。

  【廖若雪】如果不加深深度,广度做不上去,反过来也是一样的。很多是融会贯通的。融会贯通的时候,会发现深度和广度可以转换的。

  【黄冬】如果这么讲,他的深度积累是积累下来的,正是因为有广度才转换的。深度是一个爱好,广度发挥大的价值。

  【汤道生】这两个是相互帮助的。在某个地方可以转深,解决大的问题只有一个领域的知识不够,自然多方面的了解才能解决。单项考虑广度和深度两者是叠加的。很多时候有一个误区,不是说所有的语言都学一遍就很狂,这不是广度,只是在解决问题上面需要用到的工具。所以我觉得真正广度的体现,还是在于解决问题的时候是否考虑足够全面。甚至说,刚才主持人提到程序员原来很明确给我一堆需求,怎么按照这个需求实现就好了,我觉得那个时候也许离目标稍微远的时候,虽然感觉很明确,因为有人帮你过滤了怎么做,而不是真正了解,到底服务业务用户需要什么,视频服务商用户需要流畅、不卡一堆的要求,但经过很多重的翻译下来到一个开发人员的需求可能是播放器加一个断点重播或者其他的功能。这对于你实际的问题理解不足,可以说这是一个很缺乏对于广度在每一层所需要考虑的问题的广泛了解。

  还是要端到端,中间的事情有设备的关系、网络的关系,甚至用户体验的关系,把这些都打通,才是一个架构师所需要的广度。

  问题7、架构师虽然是统称,架构师有分类吗?

  【黄冬】我觉得架构师在我所看到的层面,横向有几个不同层面:

  第一,好的代码。现在知道很多好的框架,本身就是一个良好的架构。在代码、工程师的层面也是有架构设计和一些良好的架构,我们可以看到。

  第二,结合整个系统的运行,会不会有良好的架构。比如(英文)结合系统资源、结合计算机处理能力。

  第三,产品。如何给用户提供好的服务。

  再往上走甚至可以提升到产业链、行业、商业模式的架构。比如说腾讯的开放平台,截然不同的架构,解决什么样的问题、该不该这样做。

  纵向走的话,我认识几个非常资深的信息架构,只是做信息分类,有一个图片做图片库,怎么给图片建立一套体系结构,管这个人叫首席信息架构设计师。包括图书馆的分类也是截然不同的,信息架构是截然不同的东西,还包括硬件的架构,真的体现不同的行业不同的职位。

  【廖若雪】这里有一个核心的问题,定义什么是架构师。从能力上讲,很多架构师很像,他们的侧重点、相对的领域或者在架构层面上解决问题的思路和方法都有不同的地方。

  从计算机领域来看,架构师从分类来看并不是很好的纬度,更多的是侧重点。侧重点是不是分成几类,在我看来并不是这样的,他们之间可以看到很好的作为策略的架构师。他们能力可以转换的。

  问题8、这个问题只是跟上面一个进行呼应。在我看来,架构师的基础能力,最基础的算法,数据与数据结构、网络、TCB的东西,反而是架构师最根本、最需要掌握的知识,之后对这个知识进行总结、归纳,上升到高度之后看到全面才能有一定的深入了解。还要有一定的远瞻性,对公司未来的发展方向都要了解。刚才谈了很多架构师优秀的地方,我比较关心的,比如说我是一个工程,定了这样的方向,如何培养自己的能力?如何一点点向这个方向走?架构师有一个机会的成分给你,公司给你环境,如何寻找这样的环境和抓住这个机会。

  【黄冬】捉所以说横向和纵向都有不同领域,现在作为一名工程师,最需要做的事情就是仔细去琢磨讨论的代码。

  什么叫架构?我自己是这么认为的,一个能够随着时间的变化和业务的变化不去发生改变的稳定的结构,称之为架构。一个架构师一定是对这样的东西加以设计、灵活运用,让这样的结构不轻易改变,能够持久运行做这样的设计来。

  如果自己是一个程序员,每切到一个需求时,往前往左右想一步,看自己的代码能够运行多久,业务和时间的变化都不会产生影响。越能多写这样的代码,就证明在培养这样的能力。

  第二,当自己所做出来东西越来越多的时候,看深度上能不能再深一些的同时,看自己能不能再做一些截然不同的东西。包括系统、运营的东西。

  最后,有没有一个公司、环境多理解业务,能够让自己运用网络、系统代码和业务自己所设计的东西进行运行。这是一个听起来很漫长的过程,是一个有心人自己培养自己的过程。

  问题9、架构师和软件开发主管有时候意见不一致,架构师做交流的时候还是挺困难的。架构师成为独立的架构师也是一个发展方向。对于自己要不要成为软件开发主管兼架构师,还是独立的架构师?发展方向方面有什么建议?

  【汤道生】这是管理问题,不是架构的问题了。程序经理也好、项目经理也好、架构师也好,纯粹说哪个级别或者哪个职位,太不科学了。我原来在不同岗位扮演过不同角色,最健康的合作方式还是拿数据说话,或者对于实际用户的行为能够有好的判断,真的能讲通为什么这个好、为什么不好。为什么这个阶段好,等到下一个阶段采取另外一个策略。

  我记得有一次我们团队在讨论一个facebook的问题,300个好友怎么更新,300人不同的好友,看到的视图不一样。到底存储系统应该怎么设计才合理?有程序经理说,facebook是这样做,把更新发到一个存储来做。架构师说看着别人很稳定的,只是一个系统的设计,不一定是最优的。我们去分析到底用户的行为是怎样的?或者最终存储放什么在、放什么在。放在的信息最好是少量而且是不变的。最后想了另外一种方式,把个人的更新落地到存储,但是能够被内存存起来。这样的话只有更新的人落地,后来发现架构师通过实际用户的行为、实际的资源更准确的判断,用更少的IO,充分利用内存的特征来解决这个问题。最后我们发现我们的设计是跟原来facebook开源的不一样,但是实际的结果更符合我们的需求。那个人抓住重点,充分理解系统资源,最后按照数据来决定。

  问题10、架构师到底需不需要具备人员管理能力?

  【黄冬】手里没枪怎么能抢得了政权呢?

  【廖若雪】跟各个公司的风格和管理相关的,可以不要。

  【吴永强】管理层面太虚幻了,是实际的管理还是对人影响力。

  【汤道生】如果你有能力,自然会得到。

  问题11、性格决定命运,现在又提倡情商比智商更重要。性格方面有什么地方能够比较适合做架构师?

  【汤道生】两个都要。

  【吴永强】智商是必须的,智商如果高到一定程度,情商可以不要了。

  【廖若雪】智商是一个必要条件。情商会更加有助于你成功,任何事情都是这样的,不光是做架构师。

  【黄冬】我认为做架构师的特点就是智商一定要高,作为一个公司的管理必须情商高。

阅读(588) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~