《The Art of Scalability》的原文摘录
-
我们假设经理应负的基本职责包括以下三点：确保给工程师分配了项目，无论是自己分配的，还是根据管理层指示分配的；确保执行了行政工作，如解决了薪资问题或者传达了人事信息等；以及接收项目的状态更新信息，以便报告给高级管理层。考虑到这种基础水平的管理职责，一个新近从工程师升到管理层的初级经理可能会发现，即使只管理 6 个人的团队，行政工作和项目管理的工作都会耗费她一整天的时间。... 比起那些做过一遍又一遍的工作来说，新工作通常需要花费更多时间，而且要求更加专注。在决定一个团队的最佳规模时，经验水平是一个要考虑的关键因素。 一般来说，业务责任人和产品经理都想建立更多更大的面向客户的项目，这样他们才能不停地击败竞争对手，扩大收益来源，拓展客户基础。这时团队规模过小会带来两个主要问题。首先，根据所采用的产品开发生命周期方法不同，较大的项目需要更多的迭代或更长的开发时间。... 其次，如果增加了工程师数量，那么支持人员的数量也随之增加，包括经理的人数。 工程师天生会对自己能够完成的工作保持过分乐观的态度，如果他们推脱过去能够完成的工作量，这会是一个明显的信号，说明他们自觉生产力下降了。 比这个难得多的是在团队规模过大时，拆分团队。如果团队拆分不当，会造成可怕的后果，如代码的所有权不清楚、更难以沟通、重新适应新经理而工作压力增大。... 首先需要关注的是代码或工作，我们将在第三部分详细地讨论故障域这个概念，这些域通过隔离服务，从而限制了故障的影响范围，也许拆分团队是个把代码拆分到故障域的好机会。 (查看原文) —— 引自章节：团队规模 -
现代的云概念在2001年10月被IBM在“自主计算宣言”中得到延伸，这篇论文的实质是说信息技术基础设施变得过于复杂，如果不能实现自动化管理，它可能会被自己的重量所压垮。 (查看原文) —— 引自第520页 -
组织设计和架构中的另一个要点是，一旦确定了组织或团队的边界，组织或团队的冲突就会随之而来。 (查看原文) —— 引自章节：为什么要考虑组织 -
JAD （联合架构设计）流程的最后一步是决定是否需要把功能提交给 ARB（架构评审委员会），进行最后的审查和批准。... 如果该功能满足下列任何一项，就应该提交给 ARB。 1) 与架构设计原则不符。 2) 就设计达不成共识。 3) 做过重大的权衡决策。 4) 高风险的功能。 (查看原文) —— 引自章节：联合架构设计 -
集群（Cluster）和群组（Pools）有时交替使用，特别是当有一个共享的回话或状态概念时，但有时用来指主备配置的高可用性解决方案。群组（Pools）最经常被引用指一组执行类似任务的服务器。 (查看原文) —— 引自第370页 -
原子性是数据库管理系统的一个特性，它保证执行交易的所有任务，否则回滚整个任务，不会因为硬件或软件的故障而造成交易部分完成。 一致性是保证交易前后数据库状态稳定的特性。如果事务处理成功，数据库将会从一个状态转移到另一个状态，并保持规则一致。 隔离性是当数据正在被一个事务处理的过程中，防止另外的事务同时访问它的属性。大多数的数据库管理系统使用锁来保证隔离。 耐久性是在系统标记记录的状态为成功后，继续维持这个状态而不被回滚的特性。所有的一致性检查必须在事务被认为完成之前通过相应的验证。 (查看原文) —— 引自第459页 -
如果你不能有效地管理危机中的各部分力量，你就要尽可能少用人。 问题管理者……我们需要这个人内在有令人难以置信的平静，而外在有说服力。 工程领导……既能管理团队也能回答高层危机管理团队提出的技术问题……并负责帮助高级团队审查消息、澄清思路、排列不同假设的优先级。 独立贡献者……对可能引发事故的潜在问题进行头脑风暴，相互交流从而形成各种假设，并快速验证这些假设。 (查看原文) —— 引自章节：9.4 混乱中的秩序 …… 195 -
造成团队士气低落的最大原因，莫过于某个团队对某项工作负全责，团队成员以为其他人在负责这个部分而没有去做，结果造成整个任务的失败。 组织的设计中要包括全部的责任，不仅要清楚地定义谁是决策者，还要搞清楚谁负责为决策者提供信息 作为一个领导者你至少应该清除在自己的组织内，每个团队的责任和期望的产出。 接受你权利下放的个人或团队最多承担连带的责任，必须清楚自己要对最终的结果负全责。 (查看原文) —— 引自章节：第2章 可扩展性技术组织的角色 …… 17 -
总结AKF最常用的15个架构原则如下： 1.N+1设计。永远不少于两个，通常为三个。 2.回滚设计。确保系统可以回滚到以前发布过的任何版本。 3.禁用设计。能够关闭任何发布的功能。 4.监控设计。在设计阶段就必须要考虑监控，而不是在实施完成之后补充。 5.设计多活数据中心。不要被一个数据中心的解决方案把自己限制住。 6.使用成熟的技术。只用确实好用的技术。 7.异步设计。只有在绝对必须的时候才进行同步调用。 8.无状态系统。只有当业务确实需要的时候，才使用状态。 9.水平扩展非垂直升级。永远不要依赖更大、更快的系统。 10.设计至少要有两个步骤的前瞻性。在扩展性问题发生前考虑好下一步的行动计划。 11.非核心则购买。如果不是你最擅长的，也提供不了差异化的竞争优势则直接购买。 12.使用商品化硬件。在大多数情况下，便宜的是最好的。 13.小构建，小发布，快试错。全部研发要小构建，不断迭代，让系统不断成长。 14.隔离故障。实现故障隔离设计，通过断路保护和避免故障传播和交叉影响。 15.自动化。设计和构建自动化的过程。如果机器可以做，就不要依赖人。 (查看原文) —— 引自章节：第12章 确立架构原则 …… 248 -
不要开始从这个斜坡上下滑，高标准要求准入和批准，毫不动摇，毫无例外。 (查看原文) —— 引自章节：13.3 JAD的准入和退出标准 …… 271 -
200毫秒真的在客户体验上有很大的不同吗？ (查看原文) —— 引自章节：第15章 聚焦核心竞争力：自建与外购 …… 296 -
好的领导本能地明白这个道理，他们总是把赞扬留给团队，承认失败并公开地承担责任。相反，差的领导在失败时找替罪羊，在成功时抢功。 (查看原文) —— 引自章节：2.2 定义角色 …… 19
作者: Martin L. Abbott, Michael T. Fisher
副标题: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise
isbn: 0137030428
书名: The Art of Scalability
页数: 592
定价: JPY 980
出版社: Addison-Wesley Professional
装帧: Paperback
出版年: 2009