夜雨聆风软件为什么会慢慢长成今天这个样子？
最近重新翻了一些以前接触过的企业软件，忽然发现一个以前没有认真想过的问题。
为什么很多完全不同的软件，最后都会长得越来越像？
这里说的不像，并不是界面，而是它们背后的设计。
例如，几乎所有企业软件最后都会出现 Group、Role、Project、Team、Namespace、Owner 这些概念。权限越来越复杂，组织越来越复杂，配置越来越多。很多人觉得这是软件越来越臃肿了，但如果把时间拉长一点，会发现事情可能没有这么简单。
真正发生变化的，也许不是软件，而是软件所面对的世界。
例如最早接触企业目录服务的时候，会觉得 Group 就只是一个功能，方便管理员批量授权而已。后来接触越来越多的平台之后发现，不管是代码平台、容器平台、权限平台，还是各种企业应用，都在不断重复出现类似的设计。
于是开始换一个问题。
为什么企业软件最后几乎都会出现 Group？
如果答案只是”方便管理”，那其实什么都没有解释。
继续往下问。
为什么需要方便管理？
因为人越来越多。
为什么人多了就一定要 Group？
因为人一直在变化。
有人入职，有人离职，有人调岗，有人临时加入项目，有人又退出项目。如果所有权限都直接绑定在人身上，那么每天都会有大量配置发生变化。
软件其实只是选择了一种成本更低的表达方式。
它没有去解决人的变化，而是把变化放到了另一层。
所以，Group 更像是一种对组织变化的适应，而不是一个单纯的软件功能。
继续往下看，又会发现另一个现象。
以前总觉得权限应该绑定到角色。
开发。
测试。
运维。
产品。
后来发现，角色本身也开始越来越不稳定。
现在一个人同时承担几个角色已经很正常。
参与多个项目、负责多个系统、既是 Reviewer，又是 OnCall，还可能兼顾平台建设或者 AI 项目。职位名称越来越多，也越来越容易变化。
如果继续围绕 Role 去设计系统，很快又会遇到新的问题。
于是越来越多的软件开始出现 Policy、Attribute、Relationship 等新的表达方式。
一开始觉得这是权限模型升级了。
后来慢慢发现，也许真正升级的是组织，而不是权限模型。
软件只是被迫跟着一起演化。
类似的现象，其实很多年前就在不同领域反复出现过。
十多年前，监控系统曾经讨论过一个问题：监控对象到底应该按照树状结构组织，还是按照标签组织？
树状结构最大的优点是直观。
机房下面是机柜，机柜下面是服务器，服务器下面是应用，一层一层展开，人很容易理解，也方便浏览。
标签则完全是另一种思路。
同一台机器可以同时拥有多个属性：数据库、生产环境、支付业务、高优先级……查询和组合会更加灵活，也更适合不断变化的系统。
当时很多人认为，标签会逐渐取代树。
但真正实践之后，事情并没有那么简单。
标签最大的难点，并不在技术，而是在语义。
“MySQL”是不是数据库？
“生产”和”线上”是不是同一个概念？
“支付”和”金融”应该是什么关系？
不同的人会给出不同的答案。
标签越自由，维护成本反而越高，最后又不得不制定新的规范。
回过头来看，这并不是树和标签谁更先进的问题。
树擅长表达稳定的层级关系。
标签擅长表达不断增加的新维度。
它们解决的，其实不是同一个问题。
有意思的是，这种现象不仅出现在监控系统。
写博客也是一样。
很多博客系统同时提供”分类”和”标签”。
分类更像一棵树，适合建立稳定的知识结构；标签更像一张网，用来表达文章之间不同维度的联系。
曾经也有人讨论过，是不是只保留标签就足够了，或者只保留分类就可以了。
最后，大多数系统都没有选择其中一种，而是把两者保留了下来。
今天再去看 Kubernetes 的 Label、GitLab 的 Label、Grafana 的 Tag、对象存储的 Metadata，甚至 AI 知识库里的各种 Metadata，会发现它们都在解决同一种问题：如何在稳定结构之外，再表达不断增长的新关系。
类似的现象还有很多。
小时候理解组织架构，总觉得企业就是一棵树。
部门下面是小组，小组下面是员工。
后来参与的平台越来越多，会发现真实世界根本不是这样。
同一个人在不同系统里，拥有完全不同的身份。
在人力系统里属于某个部门。
在代码平台里维护几个仓库。
在项目系统里负责不同产品。
在值班系统里承担 OnCall。
在权限系统里又属于另外几个 Group。
这些关系彼此独立，却又共同描述着同一个人。
这时候再回头看很多软件，会发现越来越多的产品开始弱化”树”，而强化”关系”。
软件并不是突然喜欢图结构了。
而是现实世界本来就越来越像一张不断变化的网络。
想到这里，忽然觉得，以前研究软件时，关注点可能放错了。
以前总是在研究：
为什么 Kubernetes 这样设计？
为什么 GitOps 会流行？
为什么 Platform Engineering 会出现？
这些问题当然值得讨论。
但还有另外一个问题，也许更加值得花时间。
到底是什么发生了变化，才让软件不得不变成今天这样？
如果组织没有变化，很多今天看起来理所当然的软件设计，也许根本不会出现。
如果协作方式没有变化，平台工程可能也不会成为今天的热点。
如果研发规模没有变化，GitOps、值班平台、权限模型，很多东西可能都不会演化到今天这个样子。
这样想之后，再去看软件，好像就多了一个新的角度。
以前研究的是软件。
现在更想研究软件为什么会变化。
软件只是结果。
组织、协作方式、人与人之间关系的变化，可能才是真正的原因。
所以最近开始尝试用另外一种方式看待各种产品。
不是先研究它有哪些功能，而是先观察它解决了什么变化。
不是先比较不同产品的优缺点，而是先思考为什么不同产品最后会收敛到相似的设计。
如果这种观察继续积累下去，也许以后讨论一个产品的时候，可以少问一点”怎么实现”，多问一点”为什么会演化成这样”。
因为真正值得留下来的，也许不是某一个软件的最佳实践。
而是那些在不同产品、不同组织、不同年代里，一直反复出现的规律。
这些规律，不一定只属于 DevOps，也不一定只属于企业软件。
它们可能同样存在于平台工程、AI Agent，甚至未来还没有出现的新系统里。
软件一直在变化。
真正有意思的，也许不是变化本身，而是推动变化的力量。
或许下一次再看到一个新的软件，不妨先别急着研究它的功能。
先问自己一个问题：
它到底在适应什么样的变化？
也许，从这个问题开始，比直接打开产品文档更有意思。