收藏!架构师需要掌握的99条铁律

收藏!架构师需要掌握的99条铁律_第1张图片

经常有人问我:我是多少年某某行业工作经验,我现在是去创业公司做技术总监还是去大公司做架构师?我发现我都无法回答这个问题。因为多少年某某行业工作经验,并不能解析为具有怎样的知识结构和掌握的能力数量和深度,很难与相应的职位需求进行匹配对应。

比如,架构师,几乎所有公司的架构师需求都不完全一样。为什么呢?软件架构师是 IT 行业里独一无二的职业,既要精通软件开发技术,又要掌握业务知识,还要周旋于公司不同部门之间,协调各种矛盾。

收藏!架构师需要掌握的99条铁律_第2张图片

以下是有志于成为架构师或已经是软件架构师的应该知道的 99 件事,如果都精通吃透,应用在日常工作中,百万年薪工作不是梦。

1.  多去参加大会沙龙,跟成功的架构师探讨案例、思维模式和前沿技术。

自己摸索和尝试耗费很多时间,有时候需要广交朋友,跟成功的架构师们一起讨论、一起成长。捷径是找到成功的架构师,一起探讨,走成功者走过的路。

2.  简化根本复杂性 ,消除偶发复杂性

根本复杂性指的是问题与生俱来的、无法避免的困难。偶发复杂性是人们解决根本复杂性的过程中衍生的。分析问题好比拨云见月、水落石出。架构师的责任在于解决问题的根本复杂性,同时避免引入偶发复杂性。

3.  关键问题可能不是出在技术上

大多数项目是由人完成的,人才是项目成败与否的基础。学会尊重他人,给予团队成员充分的信任,是聪明的架构师获得成功必须掌握的核心技能。团队同心,其利断金。

4.  以沟通为中心,坚持简明清晰的表达方式和开明的领导风格

沟通应当言简意赅、详略得当,别拖泥 带水。

5.  架构决定性能

种瓜得瓜,种豆得豆,架构设计也是一样道理。它是影响应用性能和可伸缩性的决定因素,性能参数是无法简单地通过更换软件,或者“调优”底层软件架构来改善,必须遵循分布式计算和物理学的基本原理,必须在架构的设计(或重新设计)上投入更多精力。

6.  分析客户需求背后的意义

抽丝剥茧,洞见症结。不要被表面需求迷惑。

7.  起立发言

让沟通事半功倍,起立发言是最简单、有效的方法。

8.  故障终究会发生

系统必然存在不同形式的故障隐患,无论如何都无法彻底消灭,应该提前设计预防措施,限制故障。

9.  我们常常忽略了自己在谈判 

工程师应该适时转换角色,学习谈判的技巧。绝不能在与对方谈判的第一个要求上就妥协让步。

10. 量化需求

没有规矩,不成方圆。在记录需求的过程中,对一些模糊的描述比如“灵活”,“可维护性”,“性能”等通过简单的问题来量化需求,比如“数量多少”,“有多频繁”,“不能超过多长时间”等。如果缺乏客观的标准,就只能任凭挑剔的用户摆布。

11. 一行代码比五百行架构说明更有价值

可工作的代码才是目标,设计只是达成目标手段。摩天大楼的建筑师如果一味追求美观而无视物理定律,迟早会自食其果。

  12. 不存在放之四海皆准的解决方案

  软件世界没有放之四海皆准的解决方案。架构师必须培养和训练情境意识,才能更好地设计架构和解决问题。

  13. 提前关注性能问题

  尽早展开性能测试。尤其是对性能要求苛刻的系统,可以验证架构和设计是否符合实际性能要求。

  14. 架构设计要平衡兼顾多方需求

  平衡兼顾项目的技术需求和相关各方的业务需求。

  15. 草率提交任务是不负责任的行为   ( Niclas Nilsson )

  要设法杜绝开发人员草率提交任务的念头。

  16. 不要在一棵树上吊死   ( Keith Braithwaite )

  为客户提供多样化的解决方案。

  17. 业务目标至上 ( Dave Muirhead )

  技术决策不能脱离业务目标和现实条件的约束。

  18. 先确保解决方案简单可用,再考虑通用性和复用性 

  如果存在多个可实施方案难以取舍,“先简单后通用”原则可以成为最终的评判标准。通过经验提练的简单方案,远胜过不切实际的通用性。

  19. 架构师应该亲历亲为 ( John Davies )

  身先士卒才能赢得同事的信任。

  20. 持续集成 ( David Bartlett )

  持续集成确保当前的开发不会出现意外,借助它可以取得更稳定、更符合要求的开发成果。

  21. 避免进度调整失误 ( Norman Carnovale )

  不惜一切代价拒绝调整项目进度的要求。为提高交付速度而改变计划会带来一系列的问题。

  22. 取舍的艺术 ( Mark Richards )

  架构不可能满足所有需求。鱼和熊掌不可兼得,应牢记瑞典和波兰战争中瑞典瓦萨号(Vasa)战舰的故事。

  23. 打造数据库堡垒 ( Dan Chak )

  一开始就要定义好数据模型。数据模型的设计必须做到能够拒绝无效数据,阻止无意义的关系。

  24. 重视不确定性 ( Kevlin Henney )

  推迟决策,建设性地利用不确定性。推迟决定不是故意拖延,而是强调作出的决定应该基于足够的事实,不能仅凭假定和猜测。

  25. 不要轻易放过不起眼的问题 ( Dave Quick )

  别忘了温水煮青蛙的故事。

  26. 让大家学会复用 ( Jeremy Meyer )

  重复利用已有资源,首先要改变大家的观念。

  27. 架构里没有大写的“I ” ( Dave Quick )

  不要让自己变成自大狂。辩解容易,难的是学会停止辩解,恃才傲物容易,难的是拥有自知之明。

  28. 使用“ 一千英尺高” 的视图 ( Erik Doernenburg )

  选择合适的架构视图。不能太抽象,也不能细节太多,看清整个架构。

  29. 先尝试后决策 ( Erik Doernenburg )

  越晚做出决策,可利用的信息就越多。可先通过尝试,对问题的最佳解决方案有了共识,再组织协调制定决策。

  30. 掌握业务领域知识 ( Mark Richards )

  掌握业务领域知识有助于架构师选择合适的架构模式,更好地制定针对未来的扩展计划,适应不断变化的产业趋势。

  31. 程序设计是一种设计 ( Einar Landre )

  软件开发也分成设计和生产两个阶段。程序设计属于设计范畴,而不是生产范畴,软件的生产则是自动化的,由编译器、构建工具和测试代码共同完成。

  32. 让开发人员自己做主 ( Philip Nelson )

  架构师的工作重点是仔细观察整个系统是怎样组合在一起的,确保系统良好地协调运作,应该给予团队成员足够的自主权,让他们发挥自己的创意和能力。

  33. 时间改变一切 ( Philip Nelson )

  选择值得投入精力的工作,漂亮的解决方案搭配正确的任务,才能经受时间的考验。别跟以前的工作过不去。回顾过去的工作,永远会觉得以前的设计和自己的期望有差距,把这些问题当作今后的工作标准,克制自己回过头去修改的冲动。

  34. 设立软件架构专业为时尚早 ( Barry Hawkins )

  这个自己分析吧!

  35. 控制项目规模 ( Dave Quick )

  分而治之,将大项目分解成独立的小项目,设置优先级,尽快交付,实现最重要的需求,尽快获得客户的反馈,越快越好。

  36. 架构师不是演员,是管家 ( Barry Hawkins )

  架构师的职责和管家相似,承担着管理他人资产的责任,架构师应该尽可能为客户利益着想,计算可用的时间和人力,综合考虑成本和复杂性等因素,设计出折中的解决方案,不能存有私心,卖弄时髦的软件框架和流行的技术词汇,只会把系统变得更复杂,给公司造成损失。

  37. 软件架构的道德责任 ( Michael Nygard )

  架构师的决定会影响许多人,务必慎重。虽然设计必填项从表面上看并无不妥之处,但实际上是架构师在强迫用户接受自己的意图。必填项迫使用户准备更多的信息,这个过程常常会耽搁工作,让人非常沮丧。

  38. 摩天大厦不可伸缩 ( Michael Nygard )

  但软件可以。无论是开发新项目还是替换已有的系统,都应该逐个部署系统组件,一来可以将风险分散到各个时间段,每次砌好“一块砖”,二来迫使我们设计清晰的组件间接口。

  39. 混合开发的时代已经来临 ( Edward Garson )

  混合编程是指在同一套软件系统中同时采用多种核心编程语言。新的技术变革正逐步瓦解我们以往积累的技术成果,架构师应拥抱这种变化,跳出原有的思维模式,充分挖掘软件的多元化特性。

  40. 性能至上 (Craig Russell )

  性能,减少软件响应时间,提高人机交互效率!

  41. 留意架构图里的空白区域 ( Michael Nygard )

  空白区域“充满”了各种软件和“硬件”。隐藏着一系列复杂的事件,应该考虑各种隐藏的细节,才能顺利地解决空白区域里的问题。

  42. 学习软件专业的行话 ( Mark Richards )

  架构师必须掌握基本的架构模式和设计模师,学会识别不同的模式,并借助它们和同行及开发人员进行交流。模式可分类四大类:

  • 企业架构模式定义架构的全局框架结构。

  • 应用架构模式指出了全局架构下的子系统及局部应用的设计方法。

  • 集成模式研究怎样在系统的组件、应用和子系统之间传递信息,共享功能。

  • 设计模式研究架构中每个组件的构造方法。

  43. 具体情境决定一切 ( Edward Garson )

  架构不存在设计理念,具体情境决定一切,根据具体情境设计尽量简单的解决方案。

  44. 侏儒、精灵、巫师和国王 ( Evan Cofsky )

  开发团队不应该同质化。软件架构师好比国王,应该熟悉各种人的性格特点,招聘不同性格的人加入自己的团队,为不同性格的团队成员安排合适的任务,轻构化解各种难。由一帮性格相同的人设计的架构只能吸引同样性格的人加入团队,只能解决一类问题。

  45. 向建筑师学习 ( Keith Braithwaite )

  借鉴建筑行业的经验。架构师应该蕴含适当的艺术成分。

  46. 避免重复 ( Niclas Nilsson )

  两条公认的软件开发的真理:

  (1) 复制是魔鬼。

  (2) 重复性的工作拖累开发进度。

  消灭重复的内容是架构师的责任,为此应该重新研究框架,创造更完善的抽象机制,或者使用代码生成器。

  47. 欢迎来到现实世界 ( Gregor Hohpe )

  现实世界比软件世界复杂。不要抱怨现实世界中用户需求带来的麻烦,不妨从中寻找解决问题的灵感。

  48. 仔细观察,别试图控制一切 ( Gregor Hohpe )

  选择合适的抽象层次能提供有效的信息,也方便用基本的验证规则检查模型,架构师应仔细观察,提取模型,然后检查验证,别妄想掌控一切。

  49. 架构师好比两面神 ( David Bartlett )

  架构师应该像两面神一样,眼观六路、耳听八方。

  50. 架构师应关注边界和接口  ( Einar Landre )

  寻找自然的边界,分而治之。架构师应关注和绘制“有界情境”和“情境地图”,有界情境是用以唯一定义一个模型或概念的区域,通常以一朵云或一个气泡来表示。情境地图则包含了一系列有界情境及它们之间的接口。

  51. 助力开发团队 ( Timothy High )

  优秀团队是成功的保障,要尽量助力开发团队。

  52. 记录决策理由 ( Timothy High )

  记录架构决策背后的理由,长期有用,又无须为之付出过多精力维护,具有极高的投资回报价值。

  53. 挑战假设, 尤其是你自己的 ( Timothy High   )

  臆断是事情搞砸的主要根源。一定要拿出相关的经验证据,仔细验证假设,才能做出最终决策,务必要确保软件基石坚实可靠。

  54. 分享知识和经验 ( Paul W. Homer )

  讨论有助于发现不足,只有能非常容易地做出解释,才表明你真正理解了。只有不断解释和讨论,才能把经验凝聚成知识。帮助周围的人不断改善,他们也会帮助我们发挥出全部的潜力。

  55. 模式病 ( Chad La Vigne )

  不要让一展设计模式功力的欲望,遮蔽了务实的真知。使用模式解决适用的问题才是最重要的。

  56. 不要滥用架构隐喻 ( David Ing )

  不要耽溺于系统隐喻之中,只将之用于探索性的沟通,不要反让它拖了后腿。

  57. 关注应用程序的支持和维护 ( Mncedisi Kasper )

  应用程序的支持和维护,永远都不应该是事后才考虑的事情。由于应用程序超过 80% 的生命周期都是在维护上,在设计时就应该多多关注支持和维护的问题。考虑生产环境修误错误的压力,生产环境中的日志记录级别要比开发环境中的低很多,考虑开发人员与支持人员具有不同的技能等。

  58. 有舍才有得

  珍惜需要权衡的时机,远胜毫无约束和限制。

  59. 原则、公理和类比胜于个人意见和口味 ( Michael Harmer )

  清楚的架构原则,能够使那些不熟悉某项特别技术或组件的人,明白其中的缘由,更透彻地理解他们本不熟悉的技术。

  60. 从“ 可行走骨架” 开始开发应用 ( Clint Shank )

  “可行走骨架”是对系统的最简单实现,它贯穿头尾,将所有主要的架构组件连接起来。从“ 可行走骨架” 开始,增量培育系统成长 。

  61. 数据是核心( Paul W. Homer )

  从“数据是核心”这个角度去认识系统,能大大降低理解复杂度 。

  62. 确保简单问题有简单的解 (Chad La Vigne )

  试图猜测未来的需求时,错的概率是 50%,错得很离谱的概率是 49%。今天只需要解决今天的问题就好。把应用发布出去,从反馈中生成真实的需求。

  63. 架构师首先是开发人员 (Mike Brown )

  碰到麻烦时,架构师可不能只会干吹烟圈却束手无策。获得开发人员信任的最快捷方式:你的代码就是你的资本。作为架构师,主要目标应该是创建可行、可维护的解决方案,当然,也一定要能够解决当前的问题。

  64. 根据投资回报率(ROI )进行决策( George Malamidis )

  在判断每个决策选项是否务实或恰当时,将架构决策视为投资,并将相关的回报率也一并考虑在内。

  65. 一切软件系统都是遗留系统( Dave Anderson )

  软件很快便会过时,修改维护无可避免。需考虑以下几点:

  (1) 清晰性:各个组件和类的角色清晰。

  (2) 可测性:系统易于验证。

  (3) 正确性:结果和设计或期望的一致。

  (4) 可跟踪:能迅速诊断出故障并立马解决问题。

  66. 起码要有两个可选解决方案( Timothy High )

  软件架构是要在所有给定的约束条件下,寻找到解决问题的最佳方案。期望第一个解决方案即满足全部的需求和约束,几乎是不可能的。如果对手头的问题只有一个解决方案,这意味着将没有进行折衷权衡的余地。这个唯一的解决方案可能无法令系统投资方满意。

  67. 理解变化的影响 ( Doug Crawford )

  清楚认识变化类型及其影响。变化有多种不同的表现形式:

  (1) 功能需求的变化

  (2) 可扩展性需求的演进

  (3) 系统的接口被修改

  (4) 团队人员流动等。

  管理变化并非架构师的职责,但架构师要确保变化是可控的,有许多工具和技术可以用以减轻变化的影响。

  (1) 进行小规模的增量渐变。

  (2) 构建可重复运行的测试用例,并经常运行。

  (3) 让测试用例更易编写。

  (4) 跟踪好依赖关系。

  (5) 系统性的行动,根据反馈信息作出进一步反应。

  (6) 自动化重复的任务。

  68. 你不能不了解硬件( Kamal Wickramanayake )

  硬件容量规划,是和软件架构同等重要的事情。水平伸缩能力是关键,可以在需要时才添加硬件,而无须一开始就过量采购。

  69. 现在走捷径,将来需付息( Scot Mcphee )

  及时还清技术债务。可能觉得单元测试并不直接产生价值,于是就让开发人员跳过这些严格的测试工作,这将导致所交付的系统在未来更难修改,而且在修改时信心不足。 除了避免在开发初期走捷径,发现有不当的设计决策时就要尽快修正,搁置越久,为之付出的利息也将越高。

  70. 不要追求“完美”,“足够好”就行( Greg Nyberg )

  避免过度设计。不要屈服于企图使设计或实现达到完美的诱惑。把目的设定在“足够好”就行,当已经达成目标时,就停下来。

  71. 小心“好主意” ( Greg Nyberg )

  “骆驼的鼻子”是 一个隐喻,指一旦允许一些不期望但很小的情况发生,后面就会招致巨大而无法避免的情况发生。“好主意”就如“骆驼的鼻子”,它将导致范围膨胀,复杂度上升,竭力把和业务需求无关的东西塞入应用中,这纯粹是浪费精力。

  72. 内容为王 ( Zubin Wadia )

  内容即网络,即界面。在联系日益紧密的今日世界,内容质量很快成为了成败的关键。优秀的内容指的是其内容之间互相关联,而不是空洞割裂。系统的成功取决于其内容,在设计过程中,要对内容价值的评估给予足够重视。

  73. 对商业方,架构师要避免愤世嫉俗( Chad La Vigne )

  过度自信,会让你在业务领域头破血流。不要让自己成为愤世嫉俗的“天才”,总是以一副自作聪明,居高临下的语调,力求证明公司当前的运营是多么的糟糕不堪,以期触动业务方。成为优秀架构师的秘诀之中有一个关键要素,那就是要对工作满怀激情,但不要是那种带着愤怒和火气的“激情”。

  74. 拉伸关键维度,发现设计中的不足( Stephen Jones )

  单独拉伸每个维度,然后综合起来看待,便可暴露出那些隐藏于最初设计中的潜在限制与不足。架构师可以通过拉伸关键维度,对解决方案进行校核:

  (1) 了解基础设施的规划是否能够应付增长的需求,圈出限制范围。

  (2) 确认在预期的吞吐量下,系统不但能在当天内及时完成全天的任务处理,同时具备峰值储备,才能应

  对“特别忙碌的日子”,才能在停电后“加班补上”.

  (3) 对当前的数据访问方案进行校核,确保其在系统伸缩扩展时依然有效。

  (4) 确保在系统工作负载上升时,(如果需要)能够以增加硬件和转换处理路径的方式进行系统的伸缩扩展。

  (5) 数据量持续上升,导致数据必须在更多的基础设施间进行分割时,要确保应用程序仍然可用。

  75. 架构师要以自己的编程能力为依托( Mike Brown )

  为项目设计架构时,对实现每个设计元素所需的工作量,要做到心中有数;如果以前曾开发过其中某种设计元素,那么估算所需工作量将会容易得多。

  76. 命名要恰如其分( Sam Gardiner )

  弄清楚要做的究竟是什么。设计就是要去实现各种意图,例如,快速、廉价、灵活、而名字便是用来承载和传达这些意图的。

  77. 稳定的问题可以获得高质量的解决方案( Sam Gardiner )

  架构师必须从整体上看待杂乱无章的数据、概念、数据和处理逻辑,架构师要能够将它们作为整体看待,并将它们分解为更小的片段或块。这些问题块必须是稳定的,只要问题是稳定的,就可以创建出一个拥有稳定设计的系统。稳定的设计可以让你集中精力,打造出高质量的应用程序。

  78. 天道酬勤( Brian Hart )

  勤奋体现在很多方面,但归根结底是指具备坚强的毅力,并且对系统的每项任务和每个架构目标,都能投入足够的精力。真正做好那些看似简单的任务,坚守承诺。很多时候,不是能力不足导致项目的失败,而是由于勤奋不够,紧迫感不强。

  79. 对决策负责( Yi Zhou )

  有效的架构决策包含:

  (1) 无论是以敏捷的形式还是传统的形式做出架构决策,都必须对决策过程有充分的认识。

  (2) 要定期对架构决策进行复审;对照检查决策的实际效果和预期效果;

  (3) 要贯彻架构决策,只有全程跟进实施过程,才能够确保最到位地实现其设计意图。

  (4) 并没有所谓的全能技术天才,可以将一些决策委托给相应问题域的专家。

  80. 弃聪明,求质朴( Eben Hewitt )

  别去理会什么流行风潮,只有真正睿智的架构师才懂得如何保持质朴。在质朴的方案中,每个组件只做一件事。

  81. 精心选择有效技术,绝不轻易抛弃( Chad La Vigne )

  架构师工作很大的一部分,是要选择用以攻克难题的合适技术。精心选择熟悉的武器,不到万不得已绝不轻易抛弃它们。同时,以审慎的态度更新你的技术武器库。

  82. 客户的客户才是你的客户!( Eben Hewitt )

  假设你正在编写一个电子商务应用程序,那么该仔细考虑的应当是那些会在那个网站上购物的人的需求。

  83. 事物发展总会出人意料 ( Peter Gillard-Moss )

  设计是在不断变化的世界中持续进行探索试验的过程。无论研究得多么深入透彻,无论设计是如何深思熟虑,事情最后总会变得和你想的不一样,我们会发现通常无法预知的新信息。

  84. 选择彼此间能和谐共处的框架 ( Eric Hawthorne )

  当心“无所不能”型的框架。系统应该由多个相互独立的框架组成,其中每个框架都精专于各自的领域,但同时又非常简洁、包容和灵活。

  85. 着重强调项目的商业价值( Yi Zhou )

  可通过下面五步,成功将架构提案打造为典型的商业项目:

  (1) 形成价值陈述,用以说明组织的业务为何要采用某种特定的软件架构,重点应放在说明其在提高生产力、改进业务效率方面的能力。

  (2) 建立量化的度量标准,量化得越具体越到位,项目也将越具有说服力。

  (3) 回过头来关联传统商业的衡量方式,如果能将技术分析转化为财务数据,则会更为完美。

  (4) 知道该在哪里停止。准备好一张路线图,用以捕获远景目标,清楚地知道每一个里程碑将带来的商业价值。让利益相关者自己决定在何处停止。

  (5) 寻找恰当的时机,如果时机不对,可能仍然无法成功推销你的点子。

  86. 不仅仅只控制代码,也要控制数据 ( Chad La Vigne )

  数据库的变化不应该影响构建活动的连续性。要把数据库也作为一个构建单元包含在内,做到一次性构建整个应用程序。

  87. 偿还技术债务 ( Burkhardt Hufnagel )

  在速度和架构间进行权衡,保持平衡。“脏但快速”的路线也许适合将修改快速纳入产品中,但由于“脏但快速”的修复有隐性成本,记得安排开发人员回头去妥善修复解决,纳入下一个计划发布的版本中。

  88. 不要急于求解( Eben Hewitt )

  不要立即着手去解决摆在面前的问题,而要看看自己是否可以改变问题。

  89. 打造上手的系统( Keith Braithwaite )

  我们构建的系统,用户体验应该是“上手的”,一定要能够帮助人们做事,这是成功的决定性因素。

  90. 找到并留住富有激情的问题解决者 ( Chad La Vigne )

  以正确的方式有效地经营开发团队。应确保团队具有打不垮的首发阵容,而一旦已经拥有“常胜铁军”,就要竭力维持。

  91. 软件并非真实的存在 ( Chad La Vigne )

  需求文档不是蓝图,软件并非真实的存在,虚拟世界中的软件是柔韧可变的。

  92. 学习新语言 ( Burkhardt Hufnagel )

  防止沟通不畅和误解 。架构师要能够以业务人员可理解的术语向业务人员解释其中的问题,以程序员可理解的术语向程序员转述业务上的问题。

  93. 没有永不过时的解决方案( Richard Monson-Haefel )

  今天做出的选择,在未来很大程度上会是错误的,只要选择能满足当前需求的最佳解决方案就行了。

  94. 用户接受度问题( Norman Carnovale )

  减轻用户接受度问题带来的风险。人们并不总是满心欢喜地接受新系统或系统的重大升级,架构师的目标,是要去了解和衡量接受度问题带来的威胁,并朝能减轻这些威胁的方向开展工作。最有效的解决办法,是运用系统设计本身来消解个中忧虑,包括培训、定期安排系统的演示,并分享用户从新系统中将会获得的知识。

  95. 清汤的重要启示 ( Eben Hewitt )

  软件架构设计需要不断的精炼浓缩。反思各种构想,直至可以确定系统中每个需求的本质。

  96. 对最终用户而言,界面就是系统 ( Vinayak Hegde )

  最终用户通过用户界面访问系统,用户交互应和产品健壮性和性能同等重要,好的用户界面能够帮助客户提高生产力,能够帮助人们更加高效,也有利于产品自身的业务收益。

  97. 优秀软件不是构建出来的,而是培育起来的( Bill de hÓra )

  要抵制试图设计出庞大完整的系统来“满足甚或超出”已知需求的特性期望的想法,要有宏伟的远景,

  但不要有庞大的设计。设计尽可能小的系统,帮助成功交付,并推动它向宏伟远景目标不断演化。

  98.    客户需求重于个人简历

  客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉,往往事与愿违。

  99.    多用书面方式总结架构师的思维模式,多讲述和分享,提高沟通能力和影响力

  架构师的沟通能力和影响力很重要,要利用大会和互联网,把自己的思维模式和架构体系整理出来,提炼,并多讲述。这样可以不断提高自己的总结能力,沟通能力和影响力,提高日常跟团队的协作能力。

       本文转自itwriter的“架构师大会:顶级架构师应该知道的99件事”,稍有改动。本文是针对中国架构师大会宣传而写,但是文章不乏很多架构师箴言和经验,值得大家学习和研究。


申明:感谢原创作者的辛勤付出。本号转载的文章均会在文中注明,若遇到版权问题请联系我们处理!

Elasticsearch在线分享直播

收藏!架构师需要掌握的99条铁律_第3张图片

刘征,Elastic 中国技术布道师

《DevOps Handbook》《The Site Reliability Workbook》译者;精通DevOps/SRE/ITSM等理论体系和相关实践等落地实现。致力于通过社区推广开源Elastic Stack技术堆栈的应用,包括运维大数据分析平台、云原生服务治理、APM全链路监控和AIOps等使用场景。

使用 Elastic Stack 监测 COVID-19 疫情爆发网络研讨会2020年4月8日15:00 线上分享

用实际应用场景探索 Kibana 的多种用法 ,构建自己的个性化仪表板,从公共数据源跟踪全球各地的COVID-19疫情状况。在本演示中,您将了解如何轻松地在Elasticsearch中索引任何类型的数据索引,使用采集节点对其进行数据转换,然后使用Kibana 的可视化、仪表板和地图对疫情现状进行分析。

亮点:

Elastic在CNCF云原生交互场景中的位置

在Kubernetes上运行 Elastic Stack

演示:如何使用 ECK 部署、防护和升级 Elasticsearch

Beats 中使用 autodiscover 监测动态工作负载的入门知识

在Kubernetes上掌握可观测经验

报名方式:识别图片二维码或阅读原文报名


想要加入中生代直播群的小伙伴,请添加群助手大白的微信

申请备注(姓名+公司+技术方向)

你可能感兴趣的:(收藏!架构师需要掌握的99条铁律)