可扩展性技术组织的角色.PDFVIP

第2 章　可扩展性技术组织的角色 孙子说：将弱不严，教道不明，吏卒无常，陈兵纵横，曰乱。 可扩展性和可用性失败的共同原因是责任不清。本章通过回顾 角色不清，责任不明的两个真实案例，讨论执行人员的角色、组织 的责任以及各种独立贡献者的角色。最后，我们通过引入可以协助 定义责任和有助于减少情感冲突的工具来结束本章。 本章适用于任何规模的公司。对大公司，可以作为一个清单来 确保厘清与扩展性相关的技术和执行人员的角色和责任。对小公司， 帮助开启定义与可扩展性相关角色的过程。对技术新手，可以作为 了解技术组织如何工作的入门读物。对于经验老到的技术专家，可 以帮助大家回顾组织的结构，以确认可以满足扩展性的需求。对所 有的公司，本章清楚地解释了公司里的每个人对扩展性都有自己特 定的作用。 2.1　失败的影响 有时，角色和责任不清意味着有些事情没人去做。比如，公司 第一部分　可扩展性组织的人员配置 没有安排任何人或团队去负责系统的容量规划。在这种情况下，系 统的容量规划是通过比较系统未来的需要和现有的容量，拟定计 划来确保系统有足够的容量来达到甚至超过需要，这包括申请购 买服务器、软件调优或者增加持续层的数据存储，比如，数据库或 NoSQL 服务器。 在这种情况下，缺乏团队或者个人来负责系统的容量规划，对 一个快速增长的公司是灾难性的。然而这种情况引起的失败却经常 发生，特别是在那些新公司里面。即使公司指定了负责系统容量规 划的人或者组织，往往因为系统过去没有数据积累而无法规划。 “无人负责”问题的另一个极端是有多个组织或人被赋予了同样 的目标。请注意，这和“共享一个目标”并不是同一件事情。共享 目标是好的，因为“共享”内含合作之意。我们这里描述的是目标 有几个主人，而且彼此之间没有清楚地说明谁该去做什么，以达成 什么目标，有时候，他们并不知道其他的人或团队在做着相同的事 情。在小公司里，这种问题看起来好像有些好笑，因为每个人都知 道其他人在做什么。不幸的是，这种问题存在于很多大公司中，而 且当它发生时，不仅浪费金钱，而且还破坏股东的价值，同时在组 织之间产生长期的怨恨，降低员工的士气。造成团队士气低落的最 大的原因，莫过于某个团队对某项任务负全责，因为团队成员以为 其他人在负责某个部分而没有去做，结果造成整个任务的失败。多 人负责的问题是本书第 1 章所描述的基于情感冲突的核心问题所在。 作为一个案例，我们假设一个组织分成工程和运维两个部门， 工程部门负责研发软件，运维部门负责搭建、配置和运行数据库、 系统及网络。进一步，我们假设经验不足的CTO 最近读了一本讨论 • 18 • 第2 章　可扩展性技术组织的角色 共享目标的书，所以决定把平台可扩展性的责任交给两个部门共同 承担。公司的容量规划人员确定，要满足明年业务发展的需要，团 队必须把客户合同管理子系统的处理能力提高一倍。 工程和运维部门的架构师们读过本书的技术部分，他们决定分 割客户合同管理子系统的数据库。这两个部门的架构师们都相信他 们已经得到足够的授权进行独立决策，他们没有意识到同样的责任 已经被赋予了几个人，并且没有人通知他们去一起工作。工程部门 的架构师认为以交易为功能进行分割最有效（这是网站的功能，比 如在电子商务平台上买一个产品和看一个产品是两个不同的功能）， 相反，运维的架构师认为按照客户的边界来分割数据库效果是最好 的，这样把不同组别的客户分在不同的数据库里。两组架构师都做 好了分割的初步计划，组建好了团队，然后分别请求对方团队来做 一些协助工作。 听上去这个例子可能有点儿荒谬可笑，但是却经常发生。在最 好的情况下，两个团队会停下来解决纠纷，损失的只是两组架构师 的宝贵时间。不幸的是，通常情况下，团队会变得极端化，甚至会 在政治斗争上浪费更多的时间。如果把这个项目在一开始就交给单 个人或团队来承担，同时听取另一个团队的建议，解决方案的效果 可能会更好。 2.2　定义角色 这个部分将以实例来讲解如何通过清楚地定义角色来解决基于 责任的冲突。案例讲述了在典型的技术组织结构内，如何定义公司 • 19 • 第一部分　可扩展性组织的人员配置 高管团队和独立贡献者