回忆我当架构师的日子(二)

举报
皮皮 发表于 2019/02/21 14:41:13 2019/02/21
【摘要】 5 平衡的艺术架构师是整个产品或者项目方向的把控者,必须要有全局的视野,不能只把精力放在某一个方面,这样很容易忽略其他。从某种意义上讲,架构工作有重要的一部分是平衡的艺术,或者说取舍,规划与现状的平衡,范围与人员投入的平衡,紧迫程度与交付时间的平衡。规划太过超前,短期内就很难产品化,所以要尽可能的分步交付。所谓船小好调头,前期交付发现的种种问题,对于后期技术有非常重要的参考价值,针...

5      平衡的艺术

架构师是整个产品或者项目方向的把控者,必须要有全局的视野,不能只把精力放在某一个方面,这样很容易忽略其他。从某种意义上讲,架构工作有重要的一部分是平衡的艺术,或者说取舍,规划与现状的平衡,范围与人员投入的平衡,紧迫程度与交付时间的平衡。

规划太过超前,短期内就很难产品化,所以要尽可能的分步交付。所谓船小好调头,前期交付发现的种种问题,对于后期技术有非常重要的参考价值,针对这些及时调整方向,才能稳步向前进。这就和开车是一个道理,车在行进过程中,司机总是在微调方向盘,不然车肯定会走偏。我认为小步快跑要比迈大步扯着dan要好一些。

那怎么取舍,我认为这个没有一个特别明确或者说特别靠谱的标准,完全要靠架构师或者架构团队的洞察力,绝对不是技术牛逼的点就搞。当前产品的TOP问题、客户的潜在需求、业界的技术动态和发展方向、各种论文/专利,这些都可以成为取舍的参考点。

细心地读者可能发现了,我上面的叙述把架构师和架构团队分开了,架构师不就是架构团队的成员么,为啥要特意分开呢。一些时候,真理往往掌握在少数人手中,这个的确是真理。所以,确信自己掌握真理的少数人一定要坚持!少数服从多数有时是致命的。当然我说的坚持真理,不能是盲目的,切忌“yiyin”!坚持真理并不代表你以为你以为的就是你以为的,原谅我皮了一下,哈哈。

我总结了我确定真理的一个大致准则:第一,在做或不做中挣扎的时候,不讲要技术,不要讲实现这个功能是困难还是容易,想象一下如果我是用户,我能不能接受这个结果。第二、还是不要讲技术,从逻辑上推断,如果结论是正向的,那就坚持。下面我讲个事情说明一下这两个准则。

6      “独断专行”

独断专行是个贬义词,但有时候在所有人都迷茫,甚至反对你的时候,你要坚持。再强调一下,是要坚持真理。有时候,真的是孤独的。。。

在服务器领域,如果一个PCI设备损坏,有很大的几率引起整个服务器重启。如果损坏或者故障,PCI链路可能会给系统发个fatal信号,CPU收到这个信号以后会重置服务器,也就是直接冷重启。我之前交流过的几乎所有硬件专家都表示,设备损坏,服务器下电或者重启这很正常,这个应该算是硬件领域的一个标准处理流程了。但是,显然我要说的是接受不了。

GPU服务器为例,现在GPU服务器的密度都很高,一台服务器上8GPU甚至16GPU已经成了标配。按照上面所说,如果一个GPU故障,整个服务器都要重启。如果8GPU上分别跑了8个渲染任务,即使是一个GPU坏了,最起码其他7个渲染任务还是正常的。如果重启服务器,那这8个渲染任务都会中断。显然保持其他7个业务能够正常运行是非常有价值的。所以我认为无论从用户,还是从逻辑上看,传统的这种对硬件故障的处理非常不合理,必须改变。于是我定了一个目标:硬件故障尽可能不重启物理服务器。

这个功能当然现在华为云的异构计算云服务器已经有了,并且其中的技术原理也用在另一个重点技术项目中。但是沟通的过程是痛苦的,我不是搞硬件的,但我要说服各种硬件专家,各种沟通、评审不下10次。。让我欣慰的是,这个特性成为当时的可靠性重点工作。硬件、OS、调度等各领域的兄弟姐妹们一起把这个问题搞定了。


【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。