运维教程-如何成长为一名合格的架构师?

跨零代码为大家提供高品质的解决方案,请大家多多来访,跨零不胜感激,在此谢过。

1架构师平时都做些什么事?

主要当然是跟架构相关的事情吧(好像是废话哎),具体一点就是架构设计,讲解推广,然后再做一些代码方面的工作。说起来,讲解推广可能是很多人不太重视的,但其实它的比重还是比较大的,基本能到三成。

而这三者的比例,5:3:2也是很经常的。也就是说,团队到达一定的规模,架构师可能80%的时间都不在编程而在思考上。想(设计)不好,团队就会走很多弯路。很多时候我们太忙,看起来是事情太多,但其实可能是想得太少。

会写代码么?会写,但是可能并不会是核心代码,这个其实看每个团队的成熟程度,比如早期我会写一些核心代码,但是后来因为团队比较厉害了,如果我不分配足够的精力在某个功能实现上,为了不拖累整体的进度,会倾向于写一些边缘的代码,主要是了解团队的代码质量和实现进度。现在可能更多的写一些试验性的代码,去玩一些新的技术。

这里面还有个很特殊也很重要的工作,就是故障处理。对于一个系统来说,实现出来只是第一步,真正做成高可用的系统,还有相当长的路要走。这个过程中,你会遇到各种各样的情况,遭遇系统宕机、服务崩溃等等。基于故障的改进是架构演化很重要的一种形式。我们经常说,故障是推动技术进步的重要动力,就是这个意思。在处理故障的过程中,才会更容易体会思考当前系统的缺陷,后续改进的方向也会更加明确清晰。

前面这些事情基本都是属于输出型的,是个人对团队的贡献。个人层面,我还是需要不断地输入,学习新的知识,保持对行业、领域内新技术的更新。这里也向大家推荐一下,看论文可以认为是架构修炼的一个捷径,因为很多论文写得比较严谨,也会比较系统,了解一个系统实现的细节甚至是思想都很方便。

再有点时间,可能就是写写文章,最近(一年前)写了一个公众号,大家有兴趣可以关注,名字是「一乐来了」,不过可能还是年更 😛

2分享走过的坑,如何做架构?

我第一反应感觉自己没走过多少坑,但是后来想想,其实这也许是在坑里的表现,因为一般在坑里的人是不知道自己在里面的。

话说回来,我觉得有一个坑是所有工作的人都很容易遇到的,就是要认识到研发类工作遇到的问题,在很多情况下,不仅仅是技术问题,这就意味着并不是解决了技术部分就能解决掉的。

拿我自己举例。刚开始做系统设计的时候,有一些架构改造的点子经常不被认可,跟同事跟领导说起来,大家虽然没有什么意见,却应者寥寥。当时有一种强烈怀才不遇的感觉,甚至一度对团队都产生了怀疑,非常苦恼。

后来忽然有一天想明白了,只要还在一个团队,还是得做些事情说服别人才有意义,保持清高却期待变化是不现实的。想说服大家还是得换个角度,先去思考别人为什么不接受。顺着这个方向,慢慢解开了这个结。一般这种你觉得自己不被人理解的情况,基本都是你因为对技术的兴奋,过低评估了风险,或者没有考虑人的因素(是否充足,投入产出比),或者没有考虑项目的因素(排期进度方面)。

多说一句投入产出比的事情。其实单纯的技术改进很多情况下都没有太大价值,除了个人能练练手以外。技术真正发挥价值的地方,一定是在对用户产生影响的时候。如果做不到这点,一遇到人力紧张的情况这样的技术改造就会被放弃。当然说起来应该也算好事。

至于如何做架构呢?我推荐一个工具iPad Pro,也给大家演示一下像Paper53、Notability这样的应用。这些都是我在平时给大家讲解时会用到的,比单纯的PPT要好很多。因为从一个架构图开始,给大家建立整体的概念,然后细化分析其中的组件,在这个过程中再不断提醒这个组件在整个系统中的位置,对于理解一个系统来讲帮助是非常显著的。

服务从本质上来讲就是数据的处理,而架构设计就是在定义数据流转方式而已。

3对想做架构师的同学的几点建议?

最重要的当然是要像架构师一样思考。今天来看直播的有很多不同阶段的同学,我再说一些稍微具体的建议,当然也结合我看到的很多人容易走进的误区。

对于刚入门的同学,在听到一些新的热的技术时,一定不要只是看热闹,要去看门道。很多人都可以针对架构问题夸夸其谈,但其实对概念并没有了解清楚,表现出来就是好一点也只是知道某个东西是什么,却不知道它的优缺点,也不清楚为什么在一些情况下要用。

慢慢的,当开始懂一些的时候,要找机会开始实践。读再多的文章,不如自己上手实现一次。这种实践不是说完成一个项目就行,而是那些有挑战的项目,因为架构问题只有在解决复杂问题的时候才会出现。说起来我们前几天搞过一次PCC性能挑战赛,目的也是这样。

实践之后,还要记得归纳总结。因为如果要实现一个系统,大多数人都会因为急于编码而疏于思考。通过归纳总结,可以反思遇到的问题,重新思考系统的设计缺陷,不仅有助于以后做同类系统时不再踩坑,也因为没有了实现系统的干扰压力,更有可能举一反三,发现更巧妙的系统设计。

最后对于有一定经验的同学的建议就是,要多到社区交流。这不止是个学习的问题,而是对于一般人来讲,到了这个阶段很容易骄傲甚至自满。这是一个很不好的情况,不仅自己不会再有提高,跟团队的配合都可能出现问题。但你很难避免,部分也是因为人性使然。但是与人交流,特别是参加顶级会议,你会遇到很多跟你一样优秀的人,甚至比你优秀更多的人。你跟他们交流,自然会发现技术领域的广阔无边,也就不会再有那样的情绪了。

 

4程序员在35岁之后如何规划?

提出这个问题,还是因为某大厂特殊对待35岁以上员工的新闻。我必须声明的是我还不到35岁,所以并不能有35岁以上学习发展的经验。

我们有时候确实会在意年龄,你10岁没上小学,大家都说你晚了,你30岁还没有结婚,你就是晚婚了。但是在这学习发展的方面,年龄其实并不是问题,规划才是问题。

前几天聊到人生发财靠康波,说的是经济周期都比较长,规律可能在长波维度(六十年左右)才能看出来。但是考虑到行业发展速度和人生长度,个人规划还是比较适合短周期,比如我就一直在用五年规划。

如果有规划,一方面你可以有条不紊脚踏实地的在某一方面深耕,另一方面,也会帮助你尽早去掉一些没有用的烦恼。

书单就是一个很好的例子。很多人都喜欢跟别人要书单,自己也会买很多书「准备」看。注意是准备,因为大多数人并不会真正看完。我之前在微博上分享过一个自己09年的阅读相关的规划,当时我把自己要看的书,按照书的厚度和每天要看多少来进行分析,当时的几本书看完就要三百多天。也就是说一年不买书都看不完,而它们仅仅是案头的一部分。这也是我现在并不会给人推荐书单的原因,如果一个人没有规划,书单只是一个购物单而已。

但是如果你开始规划,你就会知道自己拼了命也只会看几本书的时候,你就更容易理智对待要看的书,把精力分配到更值得看的书上,而不是撒胡椒面式的随意阅读。值得精读又能做到精读的书还是有限的。

当然也一定要警惕,不要被你的思想所局限。之前我写过一篇文章「做业务系统也可以成为架构师」提过这个事情。人永远不知道自己不知道的东西,规划的时候也不能闭门造车,多找人寻些建议,看看别人眼里的一些事情。

5代码之外,都在玩什么?

介绍里跟大家说过一句,业余时间玩得还比较多。跑步、游(喝)泳(水)、登(爬)山、足球(也是跑步)、骑马(去年只玩了两次),最近拳击也开始玩了。

这些都很有意思,大家可以一起玩玩。但我觉得最值得推荐的,还是跑步。原因就在于程序员因为加班多,很容易得职业病。我个人曾经有严重的肩颈劳损问题,严重到每天工作九小时之后肯定会头疼,因为肌肉劳损影响了头部的血液循环。西医看不出问题来,中医针灸、艾灸、中药、按摩也是多管齐下也不管用,直到后来开始跑步,才解决了这个问题。(一秒化身传销了)

现在我每次基本都跑一万米。很多没跑步的人都觉得难,其实是很简单的事情,正常人不是可以过早放弃的话,都可以做到。我自己原来也不行,大学时候12分钟跑都跑不下来,但这其实是一个健康人很容易达到的程度,只要你坚持练习就行。当然运动到了这个量级,确实也会对身体产生不小的负荷,也很容易有运动损伤,要注意技巧方法的改进,装备该换就得换。

其他的就不多说了,有机会可以详细聊。最后祝大家都能有个运动的爱好,养成这样对人生有益的好习惯,毕竟好身体才是享受工作生活的基础。

作者:一乐

文章来源微信公众号:Infoq

从零到一,创造未来!跨零综合IT问题解决服务站,欢迎你的到来。运维教程 只为你绽放。

本文固定链接: http://kua0.com/2019/01/06/运维教程-如何成长为一名合格的架构师?/

为您推荐

发表评论

电子邮件地址不会被公开。 必填项已用*标注