|
本视频时长1小时32分，建议在Wifi环境下观看。 我是谁？ 大家好，我是顾伟，普元信息的主任架构师，也是个不折不扣的程序员型架构师。 这些年我一直在做产品研发相关的工作，参与研发的产品方向也比较多，从传统的开发平台、服务总线、应用服务器，到这些年的IaaS、PaaS、CaaS、DevOps等；技术方向也比较杂，从一开始的纯前端，到J2EE，到插件开发，再到openstack，cloudfoundry，docker，k8s等。 每个人都会有一个或多个飞速发展的阶段，这些阶段自己可以感受到，也可能从别人那边感受出来，不敢说是从0到1的那种质变，但必须说这就是技术人的阶段性升级。今天的分享正是结合我这些年的经验和总结，来和大家一起看看作为架构师，应该有哪些认知、以及必须掌握的软技能。 换维思考 每次挫折都是你的机会 每个人的职业生涯都有很多挫折，有人被挫折打倒，有人千辛万苦地爬了出来，我想说的是，要正视挫折，每次挫折都是你的一次小练级。 1.墨菲定律 墨菲定律说的是：只要一件事情存在不同选择，那肯定会有人选择不好的方式，从而导致失败。挫折很多时候其实就是因为这个原因而产生。 对于我们这些技术人，尤其是架构师来说，面临的选择会更多，如何做正确的选择，这是想成为合格架构师不可绕过的一道坎。所谓的条条大路通罗马，在这里反而是不合适的。 选择是有理有据的拍板，要做正确选择，必须要在这个行业、这个领域有足够的积累。自然又回到做什么事都离不开的：知识的积累。所以建议想做架构师的同学，要选定行业沉下来去做，一味的跳来跳去，很容易造成领域的不够深入，最终适得其反。 2.重复的错误要引起高度重视 在职业生涯初期，我遇到了一个非常好的项目，给华为定制一款中间件平台，华为的严格程度，只要大家合作过，肯定都清楚的，当时我就犯了一个错误，而且是两次。如果没有前面的铺垫，这个错误说出来我估计很多人都不以为然：某个图标少了一个像素。在第一次他们提出这个问题时，我真是不以为然的，替换后就重新打版本了，结果不久再次出现了这种问题，当再次被当面提出时，我觉得真的挺难堪的。 在这件事情后，我对自己交付东西有了非常严格的要求，即使一些代码、素材不是我提供的，我也会有意识的去验证，毕竟我参与了最终交付。这个项目总代码在50W左右，项目做到三期时，我已经可以一个人交付包括前端、工具、引擎整个平台。正是怕犯错，使我强迫自己去看所有的代码，熟悉每一个细节，关注每一次变更。 3.要学会利用好每次失败的机会 玩网游的同学都清楚，打怪练级拿经验、获装备。而每一次挫折，都是一个难得的提升经验值的机会，职业生涯要是都很顺，那要么你真的足够天才，要么你真的足够运气。 凡事都有两面性。再说的直白些，关乎实际利益，前些天有同学在谈彼得定律，彼得定律是一个“向上爬”定律，人都是应该接受挑战，直到不能胜任。如果你是一个领导或决策者，一般你会给什么样的人机会，所有人都会喜欢能承担责任，快速解决问题，不断优化的人，但问题、瓶颈不是你说有就有的，正是一次次问题、失败提供了机会，关键还是看谁能抓的住。 人都有认知惯性 但架构师要脱离惯性 1.黑天鹅事件 黑天鹅事件告诉我们，绝对的经验主义，在一些小概率事件发生之后往往会造成不可预估的风险。这个事件用在IT系统上有时更准确，像支付宝电缆被挖、乐视受攻击、三星手机炸了等，当然支付宝、乐视的应对能力都足够出色，说明其架构设计足够优秀，但给我们这些架构师的警示是：架构设计不能只考虑简单的上下游以及数据驱动方式，往往这些边界事件、小概率事件更应值得重视。 2.业务变化驱动认知升级 我在做DevOps平台，这和我以前做的很多中间件不太一样，我就会发现我的很多认知放到这个平台中是不完善的。大家都知道，DevOps平台重点是在既有的流程约束下，打通工具链、优化流程、实现精益。这个平台既会覆盖管理域，比如项目管理、产品管理，也会覆盖开发测试域，比如敏捷开发、自动化测试、代码库管理，还会覆盖运维域，比如自动化部署、多级监控、故障处理等。 大家可以去仔细观察下，这些不同领域的工程师的思维方式、做事方法是有很大区别的，像我之前对于产品和项目管理域的认知就不够，使得平台中对于像需求基线、工作项、过程模板这些设计就容易出问题，所以说，架构师要随着所涉及业务的变化持续学习，提升认知，不能老在自己的眼界范围里做事情。 3.在可控范围中鼓励创新 这两天百度无人驾驶事件闹得沸沸扬扬，究其原因就是逾越了一些底线。一个架构师如果设计了一个自己都无法cover的系统，后果难以想象，这也是设计的底线。最近在做DevOps、容器云、微服务，很多人喜欢问我用了哪些开源技术，我说用了k8s、flannel、springboot、react、Jenkins、nexus、influxdb等，那马上就会有人问有没有试过mesos、springcloud、Prometheus等等。那我会说：其实真的挺想用的，但现在也是真的还cover不住，怕引起技术债还不起。 当然，也不要走到另一个极端，做成技术宅。逐步创新才是架构师的附加价值所在，总吃老本，很快还是会被淘汰，除非你已经是行业的风向标。 架构有方法论 关键是如何运筹帷幄 1.架构的本质是打造骨架结构 架构这个词最早出自建筑，其在建筑行业中的重要性不言而喻。但来到软件行业，很多人会觉得重要性没那么显著了，甚至对架构师这个职称的必要性都有所怀疑。其实出现这个疑问不难理解，因为现在很多架构师已经不再是做技术、业务架构相关的事情了，更偏向于管理协调、团队组织这些事情，其实包括前段时间一直争吵的CTO该不该写代码，也是个类似问题：某个职称的本职工作是什么？ 架构师本质上还是要为系统建立钢混架构，概念模型、数据模型、系统上下游、技术栈、部署设计、MVP，这些都是架构师的职责。尤其是数据模型和MVP，这是很多架构师不太去做的，但却是钢混架构中的钢筋水泥，奠定了下限，也注定了上限。 2.方法论都是特定场景下的沉淀 做架构设计的方法也不少，关键是活学活用，比如4+1，比如togaf，还有DDD，ADMEMS这些。但是无论哪个方法论，都是有其特定的上下文场景的，跳出这个场景，也许就不如其他的合适了，比如DDD，非常适合有着复杂的分层架构与职责划分，对于复用性要求也很高的系统设计，如果只是简单的CRUD，那DDD反而不合适了。 所以切勿硬搬方法论，就像以前我们会习惯性的硬搬设计模式一样，多总结，找到适合自己、适合团队、适合平台的一套方法来做设计，同时切勿把架构设计纯粹做成设计，空谈误国，如何落地才是最重要的，这是架构师在方法论的基础上最需要注意的。 还有一些讲架构的书籍，其实大家也可以多关注，比如《架构之美》，《架构即未来》，《微服务设计》，《领域驱动设计》。 3.除了方法论，还有一些好方式 读代码是个很好的习惯，这10年中，我认为对我架构思路帮助最大的代码有两块，一个是eclipse的源码，eclipse将extension和extension point用到了极致，有着极强的延伸性考虑。另一个是cloudfoundry的源码，虽然最终没有用到产品中，但其在集成维度的抽象考虑，让我受益很多。现在很多同学还会看openstack、docker的源码，都是很好的框架，只是受语言能力限制，现在我们团队还处在怎么用精的阶段。 做验证也是一个好习惯，互联网开源技术很多，不可能所有的你都有机会在项目或产品中用到，但很多技术在使用中会给你很多新的思考。记得之前用Hubot和Slack、WeChat做对接玩，我忽然就理解了一些应用生态的建立模式。所以在闲暇之余，多用一用这些著名的框架，哪怕只是自己玩玩，对自己的认知也是很有帮助的。 勿忘初心 在变与不变中认清自己 1.还记不记得，10年前你为了什么奋斗？ 一些新来的团队成员喜欢问我，在一家公司呆10年是什么感受，尤其还是从毕业开始。其实这个我也没有很好的答案，比起很多我的一些朋友和同行，突然就跳到一些大互联网或创业公司，甚至有做到了CTO，当然也有羡慕，但羡慕之余，我自认为有两个点，会使我更沉下心来向前走： （1） 确实我还远没到那个水平，现在的岗位已经让我隐约感受到了彼得定律所到的那层压力 （2） 这一路以来，我是能不断感受到自己在提升的，而这正是我10年前就在追求的。何况现在的我还处在了一个非常出色的团队中。 2、现在的你适合做什么？ 有人说，到了一定阶段，你在与不在，对于团队、公司就显得没有那么重要了。诚然，我也会觉得我现在的角色和能力，早已有团队成员可替代，所谓的很多公司的高层变动，看似天要塌下来，事实上什么也没发生，像阿里的、丁香园的、中国联通的、包括像锤子的这些高层变动，大家也都看到了，人家照样经营的很好。 所以在特定团队中寻找自己的价值，让自己过的不“心虚”，是我一直的动力。止于至善，细节决定成败，永远把自己看成是最后一班岗，这是我的原则，也是很多公司追求的freedom和responsibility的基础。至于到底最适合干什么，只有努力去做了，才能知道。 |
|
|
