数据保护背景下,安全团队引入了哪些新技术进行防控升级?点击学习案例 了解详情
写点什么

一个反对“平台团队”的案例

  • 2020 年 9 月 24 日
  • 本文字数:3091 字

    阅读完需:约 10 分钟

一个反对“平台团队”的案例

运营多个专注于各自技术业务领域的平台比运营一个平台团队更好。平台思维是关于促进演进的,而不是关于重用的,而专注于重用会破坏这种机会。将平台思维灌输到所有团队中,给自主领域和平台出现的机会,而不应强加于事。



超过一定规模的大多数技术公司都开始考虑创建一个内部平台团队来构建/管理供多个团队/产品使用的系统。这是一个杠杆率非常高的团队,因为他们可以同时对许多产品产生有益的影响,并为能给组织带来巨大的动力。但是,今天,我想提出一些内部平台团队无法顺利工作的情况,至少我遇到过这样的情况。


TL;DR——运营多个专注于各自技术业务领域的平台比运营一个平台团队更好。平台思维是关于促进演进的,而不是关于重用的,而专注于重用会破坏这种机会。将平台思维灌输到所有团队中,给自主领域和平台出现的机会,而不应强加于事。


这个团队是做什么的?

拥有一个独立的平台团队通常意味着所有水平关注点都会被推到他们身上。最终,这个团队将无法识别它的客户,只能以支持许多有用但互不关联的系统而告终。很难为这样的一家公司设定目标和“北极星”,因为它们“从定义上”就是与最终用户脱钩的。这样团队的唯一目的是在不考虑这些系统的目的和运行这些系统所需的专业知识的情况下,最大限度地重用组织内的这些系统。


更糟糕的情况是,其他团队会毫无顾虑地构建可重用的组件。但是,当涉及到在生产中支持重用、尊重其他团队的 SLO 和 SLA 时,人们会立即开始寻找平台团队来进行操作。其结果是,一个操作繁重的中央小组一直忙于灭火,因为他们对自己所拥有的东西缺乏了解。


随着公司共享用例数量的增加,平台团队将会变成各种无连接的组件的存储库,这些组件的业务用途与这些组件是分离的。最终,我们得到了一个“团队”,但这个团队的成员根本不知道其他人在做什么,因为每个成员最终都只专注于各自的某个部分。我们有技术专家,但他不是对业务影响最大的领域专家。如果业务开始陷入困境,平台团队及其工作通常是第一个被砍掉的。这是因为很难向业务方解释这批“准专家”是如何帮助他们赚钱。


开发人员淘金热

从根本上讲,对于一个组织的技术栈,采用流行的二维视图是不合理的。它会使我们产生偏见,认为底层的事物在本质上更基础或更复杂。当然,底层比上层支持更大的“规模”。所有这些都会导致开发人员急于加入刚刚孵化出来的内部平台团队。在某种程度上,这项工作被视为是对组织来说更具声望或更为核心的。事实上,在本质上讲,它充其量是更技术性的,这样开发人员就不必处理现实世界的混乱,不必面向客户的产品了。


这在很多方面对组织构成了挑战。一个是管理谁来做什么,以及哪些角色被认为很酷(为什么非平台角色不被视为“业务特性”,而是“出色的工程”)。另一部分是管理最终形成团队的期望值,创建团队很容易,但是要让他们保持以业务/客户为中心比预期的要困难。许多平台团队都深陷到了一种混合状态中,即技术傲慢且与客户脱离,这使得他们的实力远远低于他们的能力。


其他团队就不是平台团队?

如果有一个平台团队,那么是否意味着其他团队就不是平台团队了?有了一个“无所不能”的团队,其他团队开始放弃平台思维,开始在产品孤岛中思考。


如果平台化是有价值的,那么它应该是所有团队的心态和策略,而不是单个团队的领域。由于所有业务问题都是由领和组织环境所组成的,因此有理由认为,所有团队都应该生产和运营平台化组件。这些平台可以在其他团队所拥有的平台之上生成。平台或通用产品的目的不仅仅是重用,而且要为集中组织专业知识的领域边界进行建模。平台团队不能在任何出现水平组件的地方都继续使用它们,因为那样他们必须是业务各个方面的专家。拥有底层可重用事物的平台团队的典型定义与组织的工作方式并不兼容。


这导致我们……


所有权范围


一个公司的技术栈可以通过顶层的高阶系统抽象和底层的低阶系统抽象进行可视化。这意味着,操作架构的技能集可以随着你的深入而发生很大的变化。这就证明了较低层与较高层的“不同”,应该以不同的方式进行管理。


当我们看技术栈时,所有权范围应该如何运行?它们应该沿着具有类似抽象级别的组件水平运行,还是应该垂直运行,将系统分组以生成端到端的业务价值?


如果你正在运行一个自主的、跨职能的团队(许多公司都声称要这样做),那么技术栈的深度是否重要?这个团队的基本前提是能够在技术栈的所有级别上工作,并且在每个级别上与其他团队都能保持松散的一致性。在这种情况下,建立一个具有固定水平章程的平台团队的想法是毫无意义的。每个团队都会创建自己需要的平台层,并根据需要与其他团队共享。这样可以保持低开销的对齐流程的运行,因为创建组件不仅仅是为了重用,它首先是为了使用而创建的,然后才是在需要时再进行重用。


这种所有权还解决了孤立组件的问题,每个人都非常依赖这些孤立组件,但又没有一个团队对其进行维护。开源对于编写代码来说是个好主意,但对于操作来说却是个糟糕的主意。软件必须有一个可操作的所有者——一个负责确保软件按预期运行并达到预期基准的团队。自主团队操作他们构建的东西,如果我们可以教会他们如何构建平台,那么我们就不需要明确地创建平台团队了。


话虽如此,但反对自主团队的一大论点是,他们往往最终不得不做一堆重复的工作。这显然是次优的,那么我们如何才能将其最小化呢。


解决重用问题

这个问题可以通过以平台化的方式解决所有问题来最小化,这样,一旦被创建出来,所有团队都可以从出现的系统中获益。在调整发布日期等方面可能存在短期问题,但从长远来看,某个特定功能或实体的所有用例开始集中在一个地方。


然而,这并不意味着构建这个平台的团队不再拥有它。重用并不意味着将所有权与创建分离。一个设计良好的平台旨在将平台团队排除在客户的决策周期之外(外部可编程性),因此,如果一个通知平台是由营销团队构建的,并且它被其他许多人所采用了,那么营销团队可以继续拥有并运营它,这没什么错。


一旦一个可重用的东西找到了 3 个以上的客户(Atwood 定律),那么可能是时候考虑一下这是一个横向的责任,并把它转移到一个单独的团队。我并不是说把它转移到一个通用平台团队,而是转移到一个特定的团队,这个团队可以专攻组件建模领域,并致力于将其发展以使其所有客户都受益。例如, 一个通知系统可以完全启动一个全新的商业领域,它本身就是小一点的 Twilio。或者,它可能只是一种共享的技术能力,如托管 Elasticsearch,可以由存储平台团队/ES 平台团队中的存储/Elasticsearch 专家团队来处理。



上面的例子表明,如果团队最初拥有其工作中的所有抽象级别(也就是全栈团队),那么新的团队和领域可以从每个团队的工作中派生出来,这些团队和领域可以在相同的抽象级别上产生。从某种意义上说,新领域是一个全新的可重用组件。我们通过对组件进行分层来垂直扩展组织,并且这些层是在彼此之上创建可重用组件的。我们还通过添加需要解决的全新问题空间来水平扩展组织,而每一个问题空间反过来又会带来新的深化机会。


这种有机的过程与固定的、共同定位的平台宪章的理念背道而驰。“平台团队”的概念混淆了所有权和重用的概念,正如它混淆了技术栈中平台的“深度”与领域知识的概念一样。我认为最好是从特定领域的团队角度来考虑,每个团队都开发自己的平台,并在发现冗余或重用时跨团队转移并合并。


在我看来,今天唯一的平台团队是基础设施团队(管理硬件设备),也许还有身份验证/授权团队,甚至我认为这些都是业务/技术能力,而不是重用/技术栈深度驱动的团队。所有其他平台都应该来自产品团队内部。想想细胞分裂而不是神之手。


原文链接:


https://kislayverma.com/organizations/a-case-against-platform-teams


2020 年 9 月 24 日 10:451632

评论

发布
暂无评论
发现更多内容

可视化埋点在 React Native 中的实践

Shopee技术团队

大前端 可视化 埋点 React Native

Redis 的事务支持 ACID 么?

码哥字节

redis 事务 ACID 签约计划第二季

Redis 6.X Cluster 集群搭建

码哥字节

redis cluster 签约计划第二季

弹性伸缩 && 多机房

空空

架构设计

安全攻防实战系列MSF

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 安全漏洞

即时通讯(IM)开源项目OpenIM本周版本发布-v1.0.6

OpenIM

【Promise 源码学习】第十三篇 - Promise.allsettled 和 Promise.any 的实现

Brave

源码 Promise 12月日更

ipvs localhost 为何不正常

Geek_f24c45

k8s IPVS kube-proxy

多级缓存 && 分库分表

空空

架构设计

查询分离

空空

架构设计

微服务

空空

架构设计

信也科技 x StarRocks:打造统一销售数据平台

StarRocks

数据库 高并发 StarRocks

Smack库 XMPP Tigase异常SASLErrorException

Changing Lin

12月日更

浅谈Java编译优化之常量折叠技术

码农参上

编译器优化 签约计划第二季

目前市面上堡垒机的品牌有哪些?采购时候需要考虑哪些?

行云管家

网络安全 等保 堡垒机 等级保护

蒙娜丽莎Rap的秘密!这个AI算法绝不能错过!!!

百度开发者中心

AI

vivo 敏感词匹配系统的设计与实践

vivo互联网技术

服务器 内容审核 架构设计实战 文本检测

2021商业评论管理行动力峰会

大咖说

商业 直播

【混合云】部分混合云管理平台大汇总

行云管家

云计算 公有云 混合云 云管平台

单库单应用 && 内容分发

空空

架构设计

编译优化后,for循环中i++和++i究竟哪个效率高?

码农参上

字节码 编译优化 签约计划第二季

热门Scrum敏捷看板工具

Leangoo领歌- Amy

项目管理 Scrum 敏捷开发 研发管理 产品研发

AI模型也需要资产管理,星环科技重磅推出AI运营平台MLOps 星环科技 星环科技

星环科技

AI

架构模式及其应用 | 内部分享

空空

内容合集 签约计划第二季

未来“数”于你 | 墨天轮携手 Vertica 发布技术文章征集令,双重大奖蓄势待“发”

墨天轮

数据库 征文大赛 vertica

网易应用创新开发者大赛成功在杭举办,十强队伍现场比拼

网易云信

人工智能 音视频 直播

偷天换日,用JavaAgent欺骗你的JVM

码农参上

字节码插桩 代理 探针 签约计划第二季

动图图解GC算法 - 让垃圾回收动起来!

码农参上

垃圾回收 垃圾回收算法 签约计划第二季

质量基础设施“一站式”服务信息平台建设,NQI一站式服务平台

电微13828808271

Android C++系列:Linux线程(三)线程属性

轻口味

android 28天写作 12月日更

4k/8k超高清时代,如何利用媒体处理技术加速数字化升级

4k/8k超高清时代,如何利用媒体处理技术加速数字化升级

一个反对“平台团队”的案例_运维_Kislay Verma_InfoQ精选文章