《架构即未来》读书心得

发表于 更新于 分类于

【中心思想】
本书从人员、组织、流程、技术等方面进行扩展性的讨论，有别于通常从技术的考虑。另外，全书贯穿了对股东利益的重视！

确实，像康威定律说的，产品就是组织架构的缩影。所以，人员、组织、流程对产品扩展性的影响不逊于技术带来的影响。做一个类比，一个球队要获得成功，必须要好的队员（人员）、好的阵型（组织）、好的战术（流程）。
简单的说，要达到可扩展，需要做如下两件事：建立敏捷性团队，使用可扩展性的架构原则（具体见下文）。
技术团队需要明白，实现股东价值是第一要义，所以要经常思考用什么指标来衡量IT工作对业务的意义。技术团队能够理解业务所面临的挑战、风险、障碍和策略。
技术高管理解赚钱的业务手段、收入的驱动力、目前的财务现实、竞争格局和当年的财务目标非常关键，只有具备这种知识和能力的CTO才能制定出合理的技术战略来实现企业的目标。

敏捷团队的定义：我们把跨职能同时符合服务架构的组织，标示为敏捷性组织。
见下图：


敏捷型组织专业技能的提高问题：

目标树：通过目标树的方法，可以很容易把一个组织的目标和公司的大目标结合起来。

变更的管理：经验告诉我们，生产环境中发生的事故，有很大一部分是有软件和硬件的变更引起或触发的。

架构原则

外购或自建：
聚焦成本策略：聚焦成本策略的主要弱点是不能专注于战略或差异化竞争；如果只注重成本可能就会导致之间系统的决策。
聚焦战略策略：我们是否是相关技术里最好的（前两名或者三名）供应商或开发商？研发或提供相关技术是否有助于可持续的差异化竞争。

风险模型：把故障隔离架构比喻成泳道，记住，泳道之间不要进行任何同步通信！

AKF扩展立方体：


NOSQL数据库

组织内的两种基本冲突类型：情感型、认知型； 情感型通常是不好的冲突，常常带有责任推诿的冲突，例如部门间的冲突；认知型通常是好的冲突，类似头脑风暴类的。

文章摘要

  • 随着资源的逐渐枯竭，企业更倾向于哪些面向客户的短期的功能研发，而不是长期的扩展性项目。结果是满足了短期的目标，却牺牲了平台长远的活力。
  • 中国还缺少架构师，特别是有领导力的架构师。
    架构师的责任是确保系统的设计和架构可以随着业务的发展而扩展。...架构是也负责制定代码设计和系统实施的技术标准。
  • DevOps通常负责配置、运行和监控生产系统。
  • 管理工具能减低沟通成本；沟通成本 = n(n-1)/2 n代表人数；
  • 亚马逊的“两张披萨饼团队”规则：任何一个团队的规模不能大过两张披萨所能喂饱的人数。
  • 管理是与“推”（pushing）相关的活动，而领导是与“拉”（pulling）相关的活动。领导设定目的地和通往目的地的路线图。管理设法达到目的地。...风格代表着个人对领导或管理任务的理解。如果一个人聚焦在事务处理方面，那么他就是一个经理，如果一个人更具有远见卓识，那他就是一个领导。...如果管理是推动组织爬坡，那么领导就是选择山头，鼓励员工一起努力翻越山头。...好的领导创造文化，聚焦打造具有高可扩展性的组织、流程和产品而取得成功。这种文化靠激励体系来确保公司能够在成本可控的情况下扩展，同时不影响用户体验和出现扩展性问题。
  • 组织的架构很少有对或错之分，任何的结构都有利有弊。
  • 很多成功的领导者都具备“高管盘问”（executive interrogation)这个关键的能力。比尔盖茨版本的盘问技能叫“比尔·盖茨审查”。懂得什么时候去调查、去哪里调查，知道找出满意的答案。
  • 组织的两个关键属性：规模和结构。团队规模的下限是6人，上限是15人。
  • 一个不注重代码、文档、规范和配置标准的制定、发布和应用的组织，研发效率和质量必然低下，生产中出现严重问题的风险很大。
  • 功能点和场景点是度量功能的两个不同的标准化方法。功能点从用户角度出发，而场景点从工程师的角度出发。工程师在本性上对他们认为能够完成的任务过于乐观。
  • 技术人员开始思考如何做一个好的服务者而不是软件开发者。 产品思维！！
  • 关系良好，差异大的团队可以更早的发现项目中的障碍和问题。
  • 领导力：影响一个组织或者个人达成某个特定目标的行为的力量。
  • 最好的领导在为股东争取利益方面大公无私。
  • 如果愿景是描述你要到哪里，而使命是一个指引你怎么到那里的大方向（个人觉得使命应该是告诉你为什么到那里），那么目标就是旅行中确保我们走在正确道路上的路路标或者里程碑。
  • 长期的实践让我们领悟到，对表现差的人要尽早淘汰。（不要尝试改变一个人的道理）
  • 技术和业务建立信任的唯一途径就是通过共同的成功。
  • 好的过程产生好的结果。...过程有助于增加组织的产出和规范重复性或不明确的任务，但太多的过程会拖累组织并增加成本。
  • 造成过程不适应或不匹配的最大问题是文化冲突。
  • 当危机发生时，我们要在最短时间内解决问题，而不考虑资源的回报和效率。
    浪费危机是一件可怕的事情，这句格言支出了一个强烈的愿望，要通过事后处理、分析尽最大可能从危机中学习，以此改善我们的人员、过程、技术和架构。
  • 危机中，需要领导者内在有令人难以置信的平静。 （胸有惊雷而面如平湖）
    最有效的领导人在危机中保持冷静，在整个危机管理的过程中能有力地维护秩序。他们必须有敏锐的业务头脑和技术经验，可以承受压力。
  • 工程团队有一种自然的倾向，他们相信自己能在没有外界或者管理团队的帮助下解决问题。这可能做得到，但仅仅解决是不够的，更需要快速和有效地解决问题。这通常超过工程团队能够掌握的，尤其是设计第三方供应商的时候。
  • 承认错误，明确计划，确保不再发生。
  • 商业在本质上是一种冒险的尝试。
  • 如质量专家所熟知的，即使是中度复杂程度的系统，要确保软件无缺陷，在数学上也是不可能的。
  • 最好的负载是那些从真实的用户流量中复制出来的。有时，可以从应用或负载均衡器的日志里收集取得。
  • 疏于度量注定你永远不会改进，疏于管理注定你迷失目标和愿景。
  • 网站平台和后台系统的数据库模式不兼容是不能实施回滚过程最常见的原因。 通常的做法是，在早期的版本中修改应用（保持数据库不变），在稍后的版本中修改数据库。
  • 数据库同步
    复制数据库在同一数据中心一般在5秒内同步完毕，跨区域的一般在10秒内同步完毕。
  • 很多数据库的复制技术支持以表为单位的复制！
  • 缓存是可扩展性工具箱中最好的工具之一
  • 对象几乎都被处理或压缩成序列化格式，以最大限度地减少内存占用。Memcached是当今最流行的缓存方法之一。这是一个高性能，分布式的内存对象缓存系统。
  • 对许多系统而言，随着时间的推移，数据的价值在逐渐降低。虽然旧的客户联系信息可能还有价值，但却不如最新联系信息的价值高。
  • 大数据的定义：大数据是指一个数据的集合，这个数据的集合如此庞大和复杂以致很难用传统的数据处理技术处理。
  • 是架构而不是技术要为产品的可扩展能力负责。
  • 虚拟化的概念是云计算背后真正的核心架构原则。
  • 云和网格是不同的目的，云计算允许你扩大和缩小架构，网格将工作分解成许多并行的单位。
  • 技术人员仍然要对其应用的可扩展性和可用性负责。云端只是可以用来实现高可用性和可扩展性的另一种技术或架构，但它不能保证应用的可用性或可扩展性。
  • 数据中心通常考虑的因素：带宽的情况、电力成本、人力成本。
  • 监控必须监控业务数据方面的变化，这个才是反映股东价值的东西，而不是仅仅从技术层面来考虑监控指标！