从去年夏末至今，我一直在阅读《架构即未来：现代企业可扩展的Web架构、流程和组织（原书第二版）》这本书。该书从组织、管理和领导，扩展技术平台的过程，技术和架构的可扩展性，云计算等新技术和如何计算常见技术指标等方面，对一个持续成长的公司如何面对系统、组织和流程的扩展性问题进行了有价值的意见指导。全书阐述了经过验证的信息技术扩展方法，对需要掌握的产品和服务的平滑扩展做了详尽的论述。具有一定的参考价值。
本书中文译版厚达六百页，由于期间穿插着阅读了很多例如《深度学习》、《灰度决策》、《SRE Google运维解密》等其他书目，加之此书看待事物的层次已然到达一定层面，因此书到目前为止仅仅看了二三百页，只是将近书的一半。为了不因时间线拉得过长导致书目前后逻辑阻塞，从今天起，我将逐步总结之前所看内容，以飨读者，也以便自己回顾。文章既有摘转录，又有自我理解批注。
本文是该书的第一部分的上半部分，是书中的第一章、第二章，主要介绍了组织中人员的可扩展性配置的理论与实践经验。
目录
人员和领导力对扩展性的影响
1. 人、组织的作用、特质及其重要性
2. 管理和领导的重要性
可扩展性技术组织的角色
1. 角色和责任的无界定与多指定
2. 定义高管团队和独立贡献者角色与执行人员的责任
3. RASCI工具关于权力下放
人员和领导力对扩展性的影响
人、组织的作用、特质及其重要性
产品所带来的价值和出现的责任都是人为的结果。人对扩展性具有重要作用。如果想要确保产品可以扩展，人是最为重要的因素。在扩展性方面，忽略人的因素作用是错误的，这有可能是产品无法满足用户需求的根本原因。
既然人是可扩展性的核心因素，我们就应花大力气去吸引和留住最好的人才。不仅仅是要找到技能最好且付得起工资的人才，更要有合适的人、合适的行为、合适的工作、合适的时间来引领成功。例如，1985年，乔布斯是一个合适的人，但遗憾的是当时他没有合适的行为。在1996年回归时，他就是个合适的人，且有合适的行为，并在合适的时间做了合适的工作。进一步说，合适的行为意味着乔布斯行为的综合结果，对苹果成长的影响基本上是正面的。
但，如果人是系统扩展中最重要的因素，那么如何把人组织起来完成工作也就同样重要。而成功设计组织首先要明确组织的产出是什么。
关于组织是否容易增加人的问题。好的组织支持增加或少或多的额外人手，允许形成新的团队或者把人加到现有团队中去。当公司状况不佳的时候也能灵活地缩小规模。
而有关指标的问题也很重要，因为组织的产出取决于规模和效率（多少人工作和每个人或团队的产出），即“每个人做更多的工作”或者“以相同的规模有更多的产出”。而如果没有关键性的指标来帮助我们度量达成期望的结果，那么我们就不应该去管理它。管理意味着度量，度量失败即管理失败。如果组织很难度量每个人的表现，那么你就无法度量产出。如果你无法度量组织的产出和工作的质量，你就无法应对突然发生和快速发展所带来的问题。
另一方面，拥有足够授权的团队，通常比授权不足的团队有更高的士气、较低的跳槽率和较快的市场响应速度。授权的基础是为达成目标，有可以独立作出必要决策的能力。授权程度最高和对目标拥有度最高的是那些跨职能而且拥有达成目标所需要的全部技能的团队。
组织的内部冲突类型分为情感型和认知性。情感型冲突是以角色或控制为基础的冲突，经常发生在团队之间。而认知性冲突常常是关于“谁”做，或者“怎么”做。认知型冲突扩大了策略的可能性范围，通过结合不同的知识、技能和经验来覆盖那些相互交叉的部分，从而增加了正确决策的概率。
在《人月神话》（The Mythical Man-Month）一书中，弗雷德里克·布鲁克斯曾经指出，在软件项目开发的过程中，有一个时间点，给项目组增加人员实际上会导致项目的进一步延迟，即更晚交付。布鲁克斯指出延迟的原因之一是团队每增加一位新成员都会带来沟通上的额外负担。随着团队规模的增长，增加成员所带来的额外沟通负担呈线性特征。换句话说，人增加的越多，每个成员的单位沟通和协调成本也就越大。
基于上面的认识，亚马逊创始人兼CEO杰夫·贝佐斯的解决办法是建立“两张披萨团队”规则：任何一个团队的规模不能大过两张披萨所能喂饱的人数。这条规则的含义是，沟通主要发生在团队内部，因此额外的沟通负担就大大地减小了。
管理和领导的重要性
管理是与“推”（Pushing）相关的活动，而领导是与“拉”（Pulling）相关的活动。领导设定的目的地和通往目的地的路线图。管理设法到达目的地。一个人的“管理风格”使其更像一个领导或更像一个经理。风格代表着个人对领导或管理任务的理解。
管理这个“推”的活动是把适当的任务分配到人，并且确保这些任务可以在指定的时间内以适当的成本完成。管理与人相关，需要确保合适的人，在合适的时间，以合适的行为，做合适的工作。
领导这个“拉”的活动就是选择山头，鼓励员工一起努力翻越山头。领导激励员工和组织做正确的事并好好做事。好的领导创造文化，聚焦打造具有高可扩展性的组织、流程和产品而取得成功。这种文化靠激励体系来确保公司能够在成本可控的情况下扩展，同时不影响用户体验和出现扩展性问题。
本节所说到的，其实就是人、组织、管理、领导等基本概念的含义、特质、重要性等内容。总结起来就是人是重要且核心的因素，用合适的、可衡量的、可扩展的、能够化解或避免冲突的组织框架，用以选择山头般的拉式领导和恰当分配任务方法的推式管理。
可扩展性技术组织的角色
此内容对大公司，可以作为一个清单确保厘清与扩展性相关的技术和执行人员的角色和责任。对小公司，帮助开启定义与可扩展性相关角色的过程。对技术新手，可以作为了解技术组织如果工作的入门。对于经验老到的技术专家，可以帮助大家回顾组织的结构，以确认可以满足扩展性的需求。
角色和责任的无界定与多指定
定义清晰的角色是领导和经理的责任，不管是独立贡献者还是组织都需要角色的清晰性。而当你加强角色清晰度的时候，要注意避免责任的重叠，这会造成无效的努力和价值损毁的冲突。
要认识到，角色和责任不清意味着有些事情没人去做。例如服务器容量，缺乏团队或者个人来负责系统的容量规划，对一个快速增长的公司是灾难性的。即使公司指定了负责系统容量规划的人或者组织，往往因为系统过去没有数据积累而无法规划。
而相对的，“无人负责”问题的另一个极端是有多个组织或人被赋予了同样的目标。请注意，这和“共享一个目标”并不是同一件事情。“共享”意味着合作，而此问题不是。这种问题存在于很多大公司中，而且当它发生时，不仅浪费金钱，而且还破坏股东的价值，同时在组织之间产生长期的怨恨，降低员工士气。造成团队士气低落的最大原因，莫过于某个团队对某项任务负全责，因为团队成员一位其他人在负责某个部分而没有去做，结果造成整个任务的失败。多人负责的问题是刚刚描述的基于情感冲突的核心问题所在。而且通常情况下，团队会变得极端化，甚至在办公室ZZ斗争上浪费更多的时间。
定义高管团队和独立贡献者角色与执行人员的责任
任何的组织结构决策都有利有弊。重要的是在组织的设计中要包括全部的责任，不仅要清楚地定义谁是决策者，还要搞清楚谁负责为决策提供信息，决策和行动方案都应该通知谁，谁来负责执行决策。尽管我们无法彻底消除冲突，但是合理的组织结构可以帮助我们限制一些因为缺乏清晰度而造成的冲突。
首席执行官
对于扩展性，CEO是最终的决策者和扩展性的仲裁者。一个技术公司，好的CEO需要精通技术，但是这并不意味着他必须是一个技术专家或者主要的技术决策者。CEO的工作就是提出合适的问题，让合适的人参与，并且协调外部的支持或建议来寻求正确答案。在技术世界里，CEO的工作是了解一些基础知识，知道该问什么问题，知道去哪里和在什么时间可以得到帮助。对于没有技术经历的CEO，这里给出如下建议：
- 提出问题并从答案中寻找一致性：你的部分工作就是寻找真相，尽管我们不认为团队会说谎，但是事实经常会有不同的解读。发现事情看起来不太对劲的时候，就要提出质疑。如果你能够战胜自我或战胜骄傲，提出一些看起来容易被忽略掉的问题，那么就会发现不仅学到了很多东西，而且也磨练出了发现真相的重要技能。同时，懂得在什么时候去调查、去哪里调查， 支支招除螨仪的答案也很重要。同时这种技能不仅限于CEO，经历和独立贡献者也应尽早磨炼出这种技能。
- 寻找外部的帮助：在可扩展性方面，要从朋友或者专家那里寻求帮助。建议与技术公司建立专业或个人的关系，依靠这些关系来帮助你提出正确的问题，并且当你要深究的时候，协助你评估答案。
- 加强对可扩展性的理解：列个清单，把你自己在技术方面的弱点都罗列出来，特别是那些有问题的，然后寻求帮助使自己变得更聪明。更好地提出和评估问题。
首席财务官
预算办公室责任中的一个关键任务，就是要确保团队和公司能有足够的资金来扩展平台、产品和系统。因此，适时地采购和部署系统及解决方案会优化公司的净收入和现金流。CFO可能需要问清楚，在制定预算的过程中是否考虑过其他的可扩展性方案，在确定预算方案的时候，做过什么样的权衡安排？因此，比较好的回答是“我们评估了所有的可能性，这个方案用相对较低的成本来水平扩展，为未来的扩展搭好一个框架，使我们可以持续扩展。”
业务部门的负责人、总经理、产品线负责人
这些要对平台、产品和系统的业务增长做好需求预测，需求预测对确定扩展计划至关重要，这可以避免在公司的实际业务没有发生之前，安排过大的预算。这里，需求指的是系统承受用户并发请求的数量。预测或许不准，特别是在公司发展的初期，但是开启这个过程至关重要，预测的准确度会随着时间的推移而逐渐成熟。
首席技术官/首席信息官
CTO/CIO必须要有公司的整体技术愿景，而且这个愿景要包括可扩展性，同时还负责为团队噢配置合适的人员以确保其能完成可扩展性的相关使命，CTO/CIO责任还包括发展可扩展性的企业文化和过程。这里，CTO绝不应该把指定可扩展性发展愿景的权力下放。同时，对初来乍到的CTO同等重要的是赢得技术人员的信任，没有手下的信任，CTO无法有效的领导。
另外，尽管CTO不必是一位资本市场的专家，但最好还是需要理解公司业务运作的基本情况，例如应能分析和理解损益表、资产负债表和现金流表之间的关系。在一个像互联网公司这样的以技术为中心的公司，CTO通常拥有全公司最大的预算。这样一位高管经常负担着非常大的投资任务，所以缺乏对财务计划的了解会给公司带来很大的风险。CTO应有市场营销的基础知识，，只是希望CTO对这些方面有基本的了解，从而为可扩展性做好商业安排，同时可以有效地在商业界沟通。
独立贡献者
架构师：确保系统的设计和架构是可以随着业务的发展而扩展。架构师需要在业务需要发生之前就想好，远在业务部门的预测超过平台的容量之前，就已经对如何扩展系统深思熟虑了。架构师也负责制定代码设计和系统实施的技术标准。架构师负责设计系统并确保其设计能解决任何的扩展问题。架构师也可以负责信息技术的管制、标准和过程。
工程师：工程师是战斗在第一线的，真枪实弹的基层人员。工程师团队是最有可能真正了解系统局限性的仅有的几个团队，他们也是发现未来可用性问题的关键人员。
DevOps：即系统和服务既需要软件也需要硬件，由此软件研发和系统管理混合成DevOps。通常，DevOps的人员负责研发和测试环境，包括研发和配置脚本、监控、日志和其他系统工具。DevOps的人员负责输出报表展示一个阶段可用性的发展趋势，分析出问题的根源并给予纠正，确定各类问题的平均解决时间和平均恢复时间。不管团队的构成情况怎么样，都是DevOps负责监控、报告应用与系统的健康情况和服务质量，在解决可用性问题的时候起着关键性的作用。架构和工程团队严重依赖DevOps来帮他们确定在什么时间解决什么问题。
基础设施工程师：基础设施横跨很多个敏捷团队。有些大企业为了研发端对端解决方案把他们放在敏捷团队，但在大多数中小企业，则集中在基础设施部门来支撑多个工程团队，包括DBA数据库工程师、网络工程师、系统工程师和存储工程师。不论基础设施人员团队的大小，其主要责任都包括设计共性资源的架构，定义全局的存储架构，确定关系型或非关系型数据库的解决方案。
质量保证工程师：理想情况，质量保证工程师主要是指那些负责应用测试，确保测试结果和公司期望的结果一致的工程师，在可扩展性测试过程中也同样起着重要的作用。质量保证一定要聚焦自动化的测试，而不是手工测试。不仅仅生产系统要可以扩展，而且当添加新功能的时候，测试的过程也要可以高效扩展。
系统容量规划师：有系统容量规划责任的人可以在任何团队工作，但是他们需要能够取得最新的系统、产品和平台的性能数据，系统容量规划是高效扩展和成本控制的关键。
RASCI工具
RASCI是一套用来确定责任的表格：
- R：负责（Responsible）对项目或者任务的完成负责的人。
- A：批准（Accountable）项目关键决策的批准人。
- S：支持（Supportive）为项目完成提供资源的人。
- C：咨询（Consulted）为项目提供数据或者信息的人。
- I：知情（Informed）需要了解项目相关情况的人。
RASCI可以用在矩阵当中，每个活动或者任务标在Y轴上，每个独立贡献者或者组织的名字标在X轴上。活动Y轴和组织X轴的交叉将会有R、A、S、C、I中的一个字母。如果交叉处什么都没有，那么相关的独立贡献者或者组织就不是这个任务的一部分。
在理想情况下，一个任务会有一个R和一个A。一种更为吻合的说法是分给几个人负责的项目等于没有人负责。而这并不是说其他的人不允许为项目或者任务提供建议。同时，A在R就方案的正确性咨询所有相关人之前是不应批准的。当然，如果公司文化好，R不仅可以寻求人们的帮助，而且会让那些被咨询的人感到自己有价值，其价值已经被考虑到决策支持的过程中。
只要你愿意加，觉得有价值，或者对完成项目来说是必须的，可以增加多个C、S和I。但是，同时要注意不要过度知会。新的公司往往假设决策应该让每个人都参与或者知会，在这种信息的发布机制是没有可扩展性的，结果是大家花时间读邮件，而不是去做他们应该做的，能为股东产生价值的事情。
下图是一个RASCI矩阵示例：
CTO可扩展性愿景的顾问包括那些需要依赖CTO来实现生产系统可用性或公司运营后台系统的人。CTO的组织（架构、工程、运维、基础服务和质量保证团队）全部都是愿景的支持者，其中一个或几个部门也可能是咨询者。CTO的技术背景越差，就越需要依赖其团队来制定可扩展性的愿景。
最后指出，需要把可扩展性愿景知会董事会。
另外，和矩阵相关的一个要点是我们已经把任务分割以避免R部分的重叠。然而，这样做的结果是组织向纵向条块化发展，与我们长期的发展方向不符。矩阵型的组织团队，不但可以避免团队内部存在的围绕功能或组织的责任而产生的独立心态，而且可以从RASCI中获益。既要有单一责任的组织，又要确保合作。通过C特性的使用来落实RASCI。
有关角色和责任的一点是，不应该有任何一个团队把角色和责任作为无法完成工作的障碍。当员工履行职责时，完成的任务超过了定义好的责任范围。如果能够帮助公司完成实名，那么员工可以，也应该自愿跨越边界去完成工作。重要的是，当这种情况发生时，他们应当和领导一起去找出到底无人负责的地带在哪里，领导应该承诺在未来纠正这些问题。
关于权力下放
权力下放就是授权别人做你该做的事情。你可以下放任何权力，但是必须对其结果承担所有的责任。接受你权力下放的个人或团队最多承担连带责任，虽然你可以解雇、提升、奖励或惩罚团队，但是必须清楚自己要对最终的结果负全责。好的领导本能地明白这个道理，他们总是把赞扬留给团队，承认失败并公开地承担责任。相反，差的领导在失败时找替罪羊，在成功时抢功。
但这并不是说你自己去做所有的决策，事实上，你可能没有资格去做决定。例如，一个不懂技术的CEO或许不应该去做架构的决策，一个200人的工程机构的CTO不应该去写最重要的代码。你必须找到最好的人，然后才有可能把权利下放给他，并对这些人以最高的标准来严格要求。
