分类目录归档:架构和远方

为什么90%的空降技术管理者都在做同一件事?

最近和几个做技术管理的朋友小聚,聊到曾经各自入职后的第一个月在干什么,答案出奇的一致。

「盘家底。」

「梳理资产。」

「摸排现状。」

说法不同,但干的都是同一件事——技术资产盘点。

这些朋友有从大厂跳到创业公司的,有从创业公司到大厂的,有接手十几人团队的,也有管上百号人的。按理说,不同规模、不同阶段的公司,管理重点应该不一样吧?

但为什么大家不约而同都在做技术资产盘点?

这事儿其实跟公司大小没关系,跟一个更本质的东西有关——手感。

什么是手感

做技术管理,手感是个很玄妙的东西。

举个例子: 团队和你汇报一个系统改造方案,说要花 3 个月,投入 10 个人。你如果此时心里犯嘀咕:这个时间是长还是短?人力是多还是少?如果你没有手感,你大概率会说:”方案不错,但能不能再优化一下时间?”

如果团队回复:”已经是最优方案了。”

然后呢?然后就只能批准了。或者再想其它办法来核实,但心里始终不踏实或者耗费时间。

这就是没有手感的典型表现。

手感是什么?是一种基于深度理解的直觉判断力。

有手感的状态大概这样的:

  • 听到「数据库 CPU 占用 80%」,马上能判断是 SQL 问题还是数据量问题
  • 看到「服务器 500 台」,立刻知道是不是合理规模
  • 团队说「这个需求要一个月」,心里有数是真需要还是在放水
  • 出现故障时,能快速圈定问题范围,而不是干着急

而没有手感的管理者呢?就像在迷雾中开车,处处都是未知,步步都要小心。

有手感的管理者,心里有地图,走到哪里都知道车怎么开。

当一个技术团队的管理者没有手感,你的每一个决策都依赖下属的汇报,而你提不出实质性的意见,这样,你的管理权威就会一点点流失,团队也就不好带了。

这也就是为什么空降管理者都急着做技术资产盘点——不是为了显得自己在做事,而是真的需要通过这个过程快速建立手感

没有手感,你就不是在管理,而是在被管理

手感从哪里来

手感不是天上掉下来的,也不是靠看几本书、听几次汇报就能有的。

我曾经见过太多空降管理者犯同一个错误:急于证明自己。

刚到一个新环境,看到这也不合理,那也不规范,马上就想大刀阔斧地改革。结果呢?不是改革受阻,就是改出更大的问题。

为什么会这样?因为我们所看到的「不合理」可能是合理的。

听说过一个案例。一个朋友刚接手一个团队时,发现新团队的部署流程特别繁琐,一个简单的上线要过五六道关卡。他当时就想,这也太低效了,必须优化。

还好当时忍住了,先做了技术资产盘点。这一盘点才发现,这个「繁琐」的流程背后是血的教训——两年前因为上线流程太简单,出过一次重大故障,损失上千万。从那之后,团队宁可效率低一点,也要确保稳定性。

如果当时贸然「优化」,很可能会重蹈覆梯,当然,也可能不会,至少不要那么急着做事,先缓一缓,看清局势。

手感这个东西,来自于对系统的深度理解。而这种理解,对于一个新接手的管理者来说,可以通过技术资产盘点一点点建立起来。

技术资产盘点就像考古,我们得一层层挖掘:

  • 这个服务为什么会存在?解决什么问题?
  • 这个架构为什么这么设计?有什么历史原因?
  • 这个配置为什么是这个值?踩过什么坑?
  • 这些技术债是怎么欠下的?为什么一直没还?

每个不合理的背后,都可能有一个合理的故事。每个奇怪的设计,都可能是特定时期的最优解。

只有当我们了解了这些前因后果,才能真正理解这个系统,才能培养出那种「一眼就能看出问题」的手感。

这就是为什么技术资产盘点如此重要——它不仅仅是在清点家底,更是在建立我们对整个技术体系的认知地图。有了这张地图,我们才知道哪里能动,哪里不能动;哪里需要改进,哪里需要保持。

手感,就是这样一点一点积累起来的。

掌控感是管理的基础

做管理,最重要的是什么?是掌控感。

什么是掌控?不是说我们要事事插手,而是当出现问题时,能快速定位;当需要决策时,有充分的信息;当团队需要支持时,知道资源在哪里。

没有掌控感的管理者是什么样的?

  • 技术评审时,只能听团队汇报,提不出实质性意见
  • 出现故障时,只能在旁边干着急,帮不上忙
  • 做预算时,不知道哪些该花哪些不该花
  • 定目标时,不知道什么是合理的预期

这样的管理者,很难获得团队的信任和尊重。

而手感,正是掌控感的基础。

有了手感,才能在关键时刻做出正确判断。有了手感,管理才不是空中楼阁,而是脚踏实地。

这就回到了我们的核心问题:为什么空降管理者都要做技术资产盘点?

因为这是建立手感的最快途径,是获得掌控感的必经之路。我们可以慢慢熟悉团队,慢慢了解业务,但技术资产是实实在在摆在那里的,是可以快速盘点和掌握的。

当我们知道每一分钱花在哪里,每一个系统如何运转,每一个瓶颈在什么地方,我们就有了管理的抓手,有了改进的方向,有了说话的底气。

这,才是技术资产盘点的真正价值。

技术资产到底包括什么

很多人以为技术资产就是服务器、数据库这些硬件资源。其实远不止于此。

我把技术资产分为几个层次:

入口层:掌控用户的入口

域名是最容易被忽视的资产。

以今年 6 月初的阿里核心域名 aliyuncs.com 故障为例:6 月 6 日凌晨,阿里云核心域名 aliyuncs.com 遭遇罕见的域名劫持事件,导致其对象存储服务(OSS)、内容分发网络(CDN)以及云解析 DNS 等多项核心云服务出现大范围故障,波及众多依赖阿里云服务的网站和应用。

除此之外,各企业网站、学校网站等等都出现过域名导致的线上故障。

还有 SSL 证书,很多公司的证书管理一团糟,快过期了才想起来续,结果用户访问时浏览器报警,体验极差。

为什么要盘点入口?因为这是用户接触我们的第一步。域名解析慢了,用户可能就走了;证书有问题,用户可能就不信任了。这些看似小事,实则关乎生死。

接入层:了解流量的来龙去脉

负载均衡怎么配的?有没有做 DDoS 防护?WAF 有没有?规则合不合理?

我在上一家公司,一个月 CDN 账单接近百万,我在做技术成本优化的时候发现,是其接入策略有问题,使用的是 OSS 的流量计费,并且当月受到一些图床攻击。这种浪费,比比皆是。不盘不知道,一盘吓一跳。

还有一些业务上线了,基本的安全策略都没有,直接服务器裸奔在线上,最终被黑客侵入,变成「肉鸡」或矿机。

计算层:服务器不只是数量

“我们有 500 台服务器”——这个信息对管理者来说几乎没有价值。

真正有价值的是:

  • 这些服务器的利用率如何?
  • 是否存在资源闲置?
  • 扩缩容策略是否合理?
  • 有没有僵尸服务器在白白烧钱?

我曾经做技术资产盘点发现 30% 的服务器 CPU 利用率不到 10%。为什么?因为之前为了应对突发流量,扩容后就没缩回去。这一项优化,一年就省了上百万。多说一句,大家还真都是草台班子。

中间件层:那些看不见的成本大户

消息队列、搜索引擎、大数据组件……这些中间件往往是成本大户。

比如消息队列,很多团队的使用方式是「能用队列的地方都用队列」,结果消息堆积严重,不仅成本高,还影响性能。盘点时你会发现,有些场景用简单的异步调用就够了,根本不需要引入消息队列。

甚至,连异步调用都不需要,同步调用就能解决问题,当时只是为了考虑扩展性,才做的甚至队列的最终一致性。然而业务一直用不上。

再比如搜索,Elasticsearch 集群动不动就是几十个节点,但真的需要这么多吗?数据的冷热分离做了吗?索引优化了吗?

存储层:数据是核心资产

数据库的盘点要细到什么程度?要细到表、甚至字段级别。

为什么?因为:

  • 得知道核心数据在哪里
  • 得了解数据的流转路径
  • 得评估存储成本是否合理
  • 得发现那些该清理的垃圾数据

曾做过一次数据库盘点,发现数据库中有超过 20 个 copy 表,还有几个超大的日志表,占数据库 80% 的空间,而这些表根本没有人在用,只是当时备份一下。

盘点存储,本质上是在梳理数据链路。

当我们能在脑海中清晰地描绘出「用户在界面上的一个操作,数据是如何流转并最终存储的」,我们才算真正理解了这个系统。

代码资产:不只是代码仓库

代码资产包括:

  • 有多少代码仓库?活跃度如何?
  • 技术栈是否统一?有没有历史包袱?
  • 代码质量如何?技术债务有多少?
  • 文档完善吗?新人能快速上手吗?

很多团队的代码仓库就像仓库一样,堆满了各种「以后可能用得上」的东西。结果就是,真正在维护的可能只有一半,另一半都是历史遗留。

流程资产:效率的关键

CI/CD 流程顺畅吗?从代码提交到上线要多久?

我接手过一个团队,上线一个小改动要两天。为什么?因为 CI/CD 流程设计得太「完美」了,各种检查、各种审批,结果效率极低。

盘点流程,我们会发现很多「以前合理现在不合理」的设计。比如,创业初期为了快速迭代,可能没有代码审查;规模大了之后,可能审查流程又过于繁琐。

在制品管理:别让半成品成为负担

什么是在制品?就是那些做了一半的项目、POC 了但没上线的系统、试验性的功能……

这些在制品是隐形的成本黑洞:

  • 占用服务器资源
  • 消耗维护精力
  • 增加系统复杂度
  • 埋下安全隐患

盘点时会惊讶地发现,可能有 30% 的资源被这些”半成品”占用着。

制品管理:那些容易被遗忘的二进制资产

什么是制品?简单说,就是我们的代码编译打包后生成的那些可执行文件——jar 包、docker 镜像、npm 包等等。这些东西看起来不起眼,但管理不当会成为大麻烦。

我见过最混乱的场景是什么样的?一个团队,所有的jar包都扔在一个共享文件夹里,文件名是这样的:

  • app-1.0.jar
  • app-1.0-final.jar
  • app-1.0-final-final.jar
  • app-1.0-final-真的final.jar

你猜哪个是生产环境在用的?没人知道。

为什么要盘点制品?因为制品管理的混乱会带来一连串问题:

版本追踪的噩梦:出了问题要回滚,找不到上个版本的包在哪。或者找到了,不确定是不是真的上个版本。

存储成本失控:没有清理机制,历史版本堆积如山。我见过一个团队,三年积累了2TB的jar包,其中90%是没用的历史版本。

安全隐患重重:制品里可能包含敏感配置、硬编码的密码。如果管理不当,这些信息很容易泄露。

部署效率低下:每次部署都要到处找包,或者重新编译。本来 10 分钟能完成的部署,硬是搞成了 1 小时。

盘点制品资产时,我们需要搞清楚:

  • 制品存在哪里?是 FTP、还是专业的制品仓库?
  • 版本管理策略是什么?保留多少个历史版本?
  • 制品的构建和发布流程是否标准化?
  • 有没有制品安全扫描?
  • 制品的访问权限管理是否合理?

建立规范的制品管理体系,看似是个小事,但对提升研发效率、保障系统安全都有重要作用。这也是为什么现代化的研发团队都会使用专业的制品仓库,而不是简单粗暴地用文件夹管理。

盘点的过程就是发现问题的过程

技术资产盘点最大的价值,不是得到一份资产清单,而是在这个过程中发现的问题。这些问题,往往就是我们这些空降的技术管理者的破局点。

比如:

  • 为什么同样的功能,A 团队用 10 台服务器,B 团队要用 50 台?
  • 为什么数据库连接数经常爆满,但 QPS 并不高?
  • 为什么 CDN 流量忽高忽低,找不到规律?
  • 为什么某个服务的日志特别多,一天就是几个 T?

这些问题的答案,可能是架构不合理,可能是代码有 bug,可能是产品设计有问题,也可能只是配置错误。但不管是什么原因,都是改进的机会。

如何做好技术资产盘点

说了这么多为什么,该说说怎么做了。

1. 不要贪大求全

很多人一上来就想把所有东西都盘点清楚,结果战线拉得太长,什么都没做好。

正确的做法是:先盘点最重要的,最花钱的,最容易出问题的。比如先看数据库和服务器,这通常占技术成本的大头。如果是内容业务,还有存储,如果是 AI 业务。还有算力或者外部大模型 API 等等。

2. 不要只看数字

“我们有 100 个 API”——这是数字 “我们有 100 个API,其中 30 个是僵尸接口,20 个性能有问题,10 个存在安全隐患”——这是洞察

盘点不是为了得到一个数字,而是为了理解现状,发现问题。

3. 要深入但不要钻牛角尖

盘点数据库要不要细到每个字段?大部分情况下不需要。但核心业务的核心表,我们必须了如指掌。

把握好粒度,既要有全局视角,又要有局部洞察。

4. 借助工具但不依赖工具

市面上有很多资产管理工具,可以自动发现服务器、统计资源使用率等。这些工具很有用,但不要完全依赖它们。

真正的理解来自于和团队的深入交流,来自于对业务的理解,来自于对历史的了解。工具只能告诉我们「是什么」,但只有人才能告诉你「为什么」。

5. 让团队参与进来

技术资产盘点不是管理者一个人的事。让团队参与进来,既能获得更准确的信息,又能让大家都有「当家」的感觉。

可以让每个小组负责盘点自己的模块,然后一起 review。这个过程中,我们会发现很多有意思的事情,比如 A 组和 B 组对同一个服务的理解完全不同。

盘点之后呢

完成技术资产盘点只是开始。真正的价值在于基于盘点结果的行动。

建立资产台账

别让盘点结果躺在Excel里吃灰。建立一个活的资产台账,定期更新,让它成为团队的知识库。

新人入职,先看资产台账;技术决策,先查资产台账;故障排查,资产台账能帮大忙。

制定优化计划

基于盘点发现的问题,制定优化计划。哪些是quick win,可以马上做?哪些需要长期规划?哪些需要跨团队协作?

记住,罗马不是一天建成的,技术债也不是一天能还清的。有节奏地推进,比急于求成更重要。

建立监控体系

光盘点不够,还要建立监控体系。资源使用率、成本趋势、性能指标……这些都要持续监控。

很多问题都是慢慢积累的。如果没有监控,等我们发现时可能已经很严重了。

形成资产管理文化

最高境界是形成资产管理的文化。让每个人都有成本意识,都知道自己用的资源值多少钱,都会主动优化。

这需要时间,需要机制,更需要管理者的坚持。

最后

技术管理空降,最难的不是推新技术、搞创新,而是先把现有的东西搞清楚。这就像医生看病,不把脉、不验血,上来就开药,那是江湖郎中。

技术资产盘点,就是给技术体系做一次全面体检。只有知道了哪里健康、哪里有病,才能对症下药。

这个过程可能很枯燥,可能会发现很多历史遗留问题让人头疼,但这是建立手感、获得掌控、赢得信任的必经之路。

记住,管理的本质是通过他人完成工作。而要想通过他人完成工作,我们首先得知道工作是什么、资源在哪里、问题在哪里。

技术资产盘点,就是回答这些问题的第一步。

不要急着证明自己,先把家底摸清楚。当我们真正理解了这个技术体系,知道了每一分钱花在哪里、每一个系统为什么存在、每一个问题因何而生,我们的管理才能真正落地。

毕竟,空降兵最重要的不是会打仗,而是先活下来。而活下来的第一步,就是搞清楚自己降落在哪里。

做了 10 年SaaS 产品后,我总结的权限设计避坑指南

做 SaaS 产品这么多年,我发现权限控制是个特别有意思的话题。说它简单吧,很多团队都做得奇奇怪怪;说它复杂吧,掌握了核心原理后其实也就那么回事。

如果你是产品经理、技术负责人,或者正在做 B 端产品的创业者,这篇文章可能会对你有一些帮助。今天咱们就聊聊 SaaS 产品里的权限控制,怎么设计、怎么实施、怎么避坑。

1 为什么权限控制这么重要

说个数据:2022 年 SaaS 安全报告显示,43% 的企业因为权限配置错误导致过数据泄露。而业内人士都知道,实际比例可能高达63%——很多公司出了事都选择悄悄处理,不对外声张(也能理解的)。

再看一下 2020 年,微盟删库事件,一个运维人员因为跟公司有矛盾,趁着自己还有生产环境的管理员权限,直接把核心数据库给删了。

300 万商家的店铺全部瘫痪,整整 7 天无法营业。正值疫情期间,很多商家本来就靠线上维持生计,这一下彻底断了收入来源。最后微盟赔偿了1.5亿,股价暴跌,品牌信誉更是一落千丈。

事后复盘发现问题出在哪?

  • 一个人就能删除生产数据库,没有任何审批流程
  • 删除操作没有双人复核机制
  • 权限过度集中,运维人员的权限大到离谱

以此作为警示:对 SaaS 行业来说,权限管理不是技术问题,是生死问题。

为什么说权限问题往往比较致命?

做了这么多年 ToB 产品,我发现权限问题有几个特点:

1. 爆发性强:不像性能问题是逐渐恶化,权限问题是突然爆发。今天还好好的,明天就可能因为一个配置错误,导致全部客户数据泄露。

2. 影响面广:一个权限漏洞,可能影响所有客户。特别是多租户架构,一个 bug 就能让所有租户的数据混在一起(如果在多租户逻辑中使用的是字段隔离,而且大部分 SaaS 产品是这样做的)。

3. 修复成本高:早期设计不好,后期改造就是噩梦。

4. 信任难恢复:客户把核心数据放在你的系统里,是基于信任。一旦出现权限问题,这种信任很难恢复。哪怕你后来改得再好,客户心里也会有阴影。

权限控制是基础,这就像盖房子,地基不牢,楼盖得越高越危险。

2 权限控制的核心概念

在深入讨论之前,咱们先把几个基本概念理清楚。

2.1 权限的本质是什么

说白了,权限就是回答一个问题:谁能对什么做什么操作?

  • 谁:用户、角色、部门
  • 什么:功能模块、数据对象、页面按钮
  • 操作:查看、创建、编辑、删除、审批

这三个要素组合起来,就构成了权限控制的基础。比如「财务主管可以查看所有部门的报销单」,这就是一条权限规则。

2.2 功能权限和数据权限

很多人容易把这俩混在一起,其实它们解决的是不同维度的问题。

功能权限控制的是「能不能用这个功能」。比如普通员工看不到薪资管理模块,这就是功能权限。实现起来相对简单,一般在前端控制菜单显示,后端做接口校验就行。

数据权限控制的是「能看到哪些数据」。同样是查看订单列表,销售 A 只能看自己的订单,销售主管能看整个团队的订单,老板能看全公司的订单。这就是数据权限,实现起来要复杂得多。

有一个典型案例:某 CRM 系统,销售经理发现自己看不到下属的客户数据,一查才发现只做了功能权限,忘了做数据权限。结果所有销售经理都只能看到自己作为销售时录入的客户,管理功能形同虚设。

2.3 权限的安全边界

做权限控制,安全永远是第一位的。我总结了几个容易踩坑的地方:

前端权限不可信:永远不要只在前端做权限判断,哪怕把按钮隐藏了,懂技术的人照样能通过开发者工具发请求。所有权限判断必须在后端再做一遍。

默认拒绝原则:权限设计应该是「没有明确允许的都是禁止的」,而不是「没有明确禁止的都是允许的」。这个原则能避免很多安全漏洞。

最小权限原则:给用户的权限应该刚好够用就行,不要为了方便给过多权限。特别是生产环境的管理员权限,能不给就不给,给了也要有审计日志。

3 三种主流权限模型

聊完基础概念,咱们来看看业界常用的几种权限模型。每种模型都有自己的适用场景,没有绝对的好坏。

3.1 ACL

ACL,访问控制列表,是最直观的权限模型,直接定义「用户-资源-权限」的对应关系。比如:

  • 张三可以编辑文档 A
  • 李四可以查看文件夹 B
  • 王五可以删除报表 C

优点是简单直接,实现容易。早期的文件系统、简单的内容管理系统多用这种模型。

缺点也很明显:用户一多就没法管理了。假设你有 1000 个用户,100 个资源,每个资源有 5 种操作权限,理论上你需要维护 50 万条权限记录。更要命的是,新员工入职你得一个个配置权限,员工离职你得一个个回收权限,运维成本极高。

所以 ACL 一般只适合用户量少、权限关系简单的场景。如果你的 SaaS 产品用户量大,还是趁早换其他模型。

3.2 RBAC

RBAC,基于角色的访问控制,是目前最主流的权限模型,核心思想是引入「角色」这个中间层。用户不直接拥有权限,而是通过角色来获得权限。

比如定义几个角色:

  • 销售员:可以查看和编辑自己的客户、订单
  • 销售主管:可以查看和编辑本部门所有客户、订单,可以查看销售报表
  • 财务人员:可以查看所有订单,可以开具发票,可以查看财务报表

新员工入职,只需要给他分配对应角色就行了。角色的权限变了,所有该角色的用户权限自动更新。

RBAC 还可以细分为四种类型,实际应用中按需选择:

RBAC0(基本模型):最简单的实现,用户-角色-权限三层结构。大部分中小型 SaaS 产品用这个就够了。

RBAC1(角色分层模型):角色可以继承。比如「销售主管」自动继承「销售员」的所有权限,再加上管理权限。这样可以减少重复配置。

RBAC2(角色限制模型):增加了约束条件。比如「角色互斥」(一个用户不能既是采购员又是审批员),「角色数量限制」(一个用户最多只能有 3 个角色)等。

RBAC3(统一模型):集成了 RBAC1 和 RBAC2 的所有特性,最完整但也最复杂。

我的建议是从 RBAC0 开始,随着业务发展再考虑升级。过度设计只会增加系统复杂度。

3.3 ABAC

ABAC,基于属性的访问控制,是相对较新的模型,通过属性组合来判断权限。这些属性可以来自:

  • 用户属性:部门、职级、工龄、地域
  • 资源属性:类型、创建者、敏感度、标签
  • 环境属性:时间、地点、设备类型

举个例子:”华东区的销售经理在工作时间可以查看本区域高价值客户的信息”。这条规则涉及了用户的地域属性、角色属性,资源的地域属性、价值属性,以及时间这个环境属性。

ABAC 的优势是灵活性极高,可以实现非常精细的权限控制。缺点是实现复杂,性能开销大,权限规则难以理解和调试。

一般来说,如果你的业务场景确实需要这么复杂的权限控制(比如医疗、金融等强监管行业),可以考虑 ABAC。否则 RBAC 就足够了。

4 SaaS 产品的特殊挑战

相比传统的企业内部系统,SaaS 产品在权限控制上面临一些独特的挑战。

4.1 多租户隔离

这是 SaaS 最核心的需求。同一套系统里住着几百上千家企业,必须保证数据完全隔离。A 公司的员工绝对不能看到 B 公司的任何数据。

常见的隔离方案有三种:

独立数据库:每个租户一个数据库。隔离性最好,但成本高,难以维护。适合大客户少量部署的场景。

共享数据库、独立 Schema:每个租户一个 Schema。隔离性不错,成本适中。适合中等规模的 SaaS 产品。

共享数据库、共享表:所有租户的数据都在同一张表里,通过 tenant_id 字段区分。成本最低,但要特别小心 SQL 注入和权限泄露。这是大部分 SaaS 产品的选择。

如果采用第三种方案,一定要在所有 SQL 查询中强制加上 tenant_id 条件。我见过的好做法是在 ORM 层面做全局过滤器,或者在数据库层面用行级安全策略(Row Level Security)。

4.2 组织架构的映射

企业客户通常都有复杂的组织架构,我们的权限系统必须能够映射这种结构。常见的需求包括:

  • 树形部门结构,支持多层级
  • 一个人可能属于多个部门(兼职、虚拟团队)
  • 临时授权(代理、请假)
  • 按项目组、按地域等多维度的权限控制
  • 集团,公公司等逻辑

我的经验是,组织架构不要做得太复杂,够用就行。很多企业其实就是简单的部门层级 + 角色,硬要上矩阵式组织、事业部制这些复杂结构,反而增加了使用成本。

4.3 权限的动态性

SaaS 产品的权限需求经常变化:

  • 新功能上线,需要新的权限点
  • 客户要求定制化的权限规则
  • 不同行业、不同规模的客户,权限需求差异很大

所以权限系统必须设计得足够灵活。我推荐的做法是:

权限点动态化:不要把权限点写死在代码里,而是存在数据库里,通过配置来管理。

规则引擎:对于复杂的权限判断逻辑,可以引入规则引擎,让权限规则可以通过配置来调整。

权限模板:为不同类型的客户准备权限模板,新客户注册时可以快速初始化。

4.4 性能优化

权限判断是高频操作,一个页面可能要判断几十上百个权限点。如果每次都查数据库,性能肯定扛不住。

常用的优化手段:

缓存:用户登录时把权限信息缓存到 Redis,设置合理的过期时间。权限变更时主动刷新缓存。

权限位图:把权限用位图来表示,一个 long 型变量可以表示 64 个权限点,判断权限只需要位运算。

懒加载:不要一次性加载所有权限,而是按需加载。比如用户进入某个模块才加载该模块的权限。

预计算:对于数据权限,可以预先计算好用户能访问的数据 ID 列表,查询时直接用 IN 条件。

5 设计一个权限系统

说了这么多理论,咱们来点实际的。假设你要为一个 SaaS CRM 系统设计权限控制,应该怎么做?

5.1 需求分析

首先要搞清楚业务需求:

  • 系统有哪些功能模块?客户管理、订单管理、报表分析等
  • 有哪些角色?销售员、销售主管、客服、财务、管理员等
  • 数据权限如何划分?按部门、按区域、按客户等级等
  • 有哪些特殊需求?审批流程、临时授权、数据导出限制等

5.2 模型选择

对于 CRM 这种相对标准的业务系统,RBAC 是首选。具体用 RBAC0 还是 RBAC1,看企业规模:

  • 中小企业:RBAC0 足够,角色数量有限,权限关系简单
  • 大型企业:考虑 RBAC1,利用角色继承减少配置工作

5.3 数据库设计

核心表结构:

-- 用户表
CREATETABLEusers (
    idBIGINT PRIMARY KEY,
    tenant_id BIGINTNOTNULL,
    username VARCHAR(50NOTNULL,
    -- 其他字段...
    INDEX idx_tenant (tenant_id)
);

-- 角色表
CREATETABLEroles (
    idBIGINT PRIMARY KEY,
    tenant_id BIGINTNOTNULL,
    role_name VARCHAR(50NOTNULL,
    parent_id BIGINT-- 用于角色继承
    -- 其他字段...
    INDEX idx_tenant (tenant_id)
);

-- 权限表
CREATETABLE permissions (
    idBIGINT PRIMARY KEY,
    permission_code VARCHAR(100NOTNULL-- 如 'customer.view'
    permission_name VARCHAR(100NOTNULL,
    moduleVARCHAR(50), -- 所属模块
    -- 其他字段...
    UNIQUEKEY uk_code (permission_code)
);

-- 用户-角色关联表
CREATETABLE user_roles (
    user_id BIGINTNOTNULL,
    role_id BIGINTNOTNULL,
    PRIMARY KEY (user_id, role_id)
);

-- 角色-权限关联表
CREATETABLE role_permissions (
    role_id BIGINTNOTNULL,
    permission_id BIGINTNOTNULL,
    PRIMARY KEY (role_id, permission_id)
);

-- 数据权限规则表
CREATETABLE data_permissions (
    idBIGINT PRIMARY KEY,
    role_id BIGINTNOTNULL,
    resource_type VARCHAR(50), -- 如 'customer', 'order'
    rule_type VARCHAR(50), -- 如 'self', 'department', 'all'
    rule_value TEXT-- 具体规则,可以是 JSON
    INDEX idx_role (role_id)
);

6 避坑指南

做了这么多项目,我总结了一些常见的坑,希望你能避开:

6.1 过度设计

最常见的错误就是一上来就想做一个「完美」的权限系统。支持 ABAC、支持动态规则、支持工作流集成… 结果做了半年还没上线,业务等不及了。

记住,权限系统是为业务服务的,不是为了秀技术。先满足基本需求,再逐步迭代。

6.2 忽视性能

另一个常见问题是只关注功能,不关注性能。权限判断是高频操作,如果每次都要查十几张表,系统很快就会崩溃。

一定要做好缓存,关键接口要做压测。我的经验是,权限判断的响应时间应该控制在 10ms 以内。

6.3 权限配置过于复杂

有些系统的权限配置界面,复杂得连开发人员都搞不清楚。这样的系统,客户是不会用的。

权限配置要尽量简化,提供合理的默认值和模板。最好能提供权限检查工具,让管理员可以模拟某个用户的权限,看看到底能访问哪些功能和数据。

6.4 缺少审计日志

权限系统必须有完善的审计日志,记录谁在什么时候做了什么操作。特别是权限的授予和回收,必须有据可查。

这不仅是安全需要,很多行业还有合规要求。审计日志最好是独立存储,防止被篡改。

6.5 数据权限的 N+1 问题

实现数据权限时,很容易出现 N+1 查询问题。比如查询订单列表,每个订单都要判断一次是否有权限查看,结果一个列表页产生了上百次数据库查询。

解决方案是在列表查询时就加入权限过滤条件,而不是查出来再过滤。这需要在 SQL 层面就考虑权限问题。

7 其它一些变化

权限控制这个领域,这几年也有一些新的发展趋势:

7.1 Zero Trust 模型

Zero Trust 模型就是我们常说的零信任模型。

传统的权限模型是「城堡式」的:进了城门(登录系统)就基本畅通无阻。Zero Trust 模型要求每次访问都要验证权限,不管你是内部用户还是外部用户。

这对 SaaS 产品来说特别重要,因为用户可能从任何地方、任何设备访问系统。

7.2 AI 辅助的权限管理

利用机器学习来优化权限配置,比如:

  • 根据用户行为自动推荐合适的角色
  • 检测异常的权限使用,可能是账号被盗用
  • 自动发现权限配置中的冲突和冗余

7.3 细粒度的数据权限

不仅控制能不能看某条数据,还要控制能看到数据的哪些字段。比如普通销售能看到客户的基本信息,但看不到信用额度;财务能看到信用额度,但看不到跟进记录。

这需要在字段级别做权限控制,实现起来更复杂,但确实是一些行业的刚需。

8 写在最后

权限控制是 SaaS 产品的基础设施,做好了用户感知不到,做不好用户骂声一片。它不是一个能带来直接收益的功能,但却是产品能否长期发展的关键。

我的建议是:

  1. 不要等到出问题才重视权限,一开始就要规划好
  2. 选择适合自己业务的权限模型,不要过度设计
  3. 功能权限和数据权限要分开考虑,都很重要
  4. 做好性能优化和安全防护,这是基本要求
  5. 保持系统的灵活性,因为需求一定会变

技术是为业务服务的。不要为了炫技而把简单问题复杂化,也不要为了省事而在安全问题上偷懒。在这两者之间找到平衡,才是一个成熟的技术方案。

以上。

AI 编程的真相:一个老程序员的冷静观察

如果你是一名程序员,最近一两年肯定被各种 AI 编程工具刷屏了。从 GitHub Copilot 到 Cursor,到今年国内出的 Trae,以及最近发布的为提升 AI 编程效率而生的 Claude Code,还有国内的通义灵码等等,简直让人眼花缭乱。

身边不少同事和朋友都已经用上了,有人说效率翻倍,有人说就是个高级的代码补全。在网上也看到许多争论,如程序员会不会被 AI 取代等等话题。

作为一个在一线写了十多年代码的人,我想聊聊自己的观察和思考。这篇文章不是要唱衰 AI,也不是要贩卖焦虑,而是想分析一下当前 AI 编程的真实情况。

今天主要聊两块:LLM 的固有局限、这些局限在编程领域的具体表现,应对策略我们下一篇文章再聊。

1. LLM 的天生缺陷

要理解 AI 编程的问题,得先搞清楚底层的大语言模型(LLM)有哪些局限。这些局限不是某个产品的 bug,而是当前技术架构的固有特性。

1.1 概率预测的本质

LLM 说到底是个概率模型。它的工作原理是根据上下文,预测下一个最可能出现的词。注意,是「最可能」,不是「最正确」。

这就像一个特别会察言观色的人,能根据前面的对话猜出你想听什么,但他并不真正理解你们在聊什么。大部分时候猜得挺准,偶尔也会离谱到家。

在写作、聊天这种场景下,这种「猜测」问题不大,甚至还能带来一些创意。但在编程这种需要 100% 精确的领域,问题就来了,这就是我们所说的 LLM 的幻觉。

以编程为例,AI 可能会「发明」一个当前环境中并不存在的库函数,或者一本正经地告诉你某个框架有某种你从未听说过的特性。例如,你让它用一个小型库 mini-lib 写个功能,它可能会自信地写下 mini-lib.complex_function(),而这个函数实际上只存在于它通过模式匹配「幻想」出的世界里。这种随机性在创意写作中是火花,但在编程中就是地雷。一个分号、一个等号、一个大于号的随机错误,都可能导致程序编译失败、运行崩溃或产生灾难性的计算错误。

LLM 的本质是一个概率预测引擎,而不是一个事实检索数据库。它的核心任务是基于海量训练数据,「猜」下一个 token 是什么最合理,而不是「下一个 token 是什么最真实」。它的训练数据中包含了海量的代码和文档,当它发现很多库都有 .complex_function() 这种模式时,它就会推断 mini-lib 可能也有,从而生成一个语法通顺但功能无效的代码。它追求的是「看起来对」,而不是「真的对」。

1.2 知识的时间窗口

训练一个大模型需要几个月时间和巨额成本,所以模型的知识总是滞后的。比如 Claude 的知识截止到 2025 年 1 月,那么 2 月份发布的新框架、新 API,它就完全不知道。

对于技术更新速度极快的编程领域,这是个大问题。React 19 出了新特性,Node.js 又发布了新版本,某个常用库爆出了安全漏洞……这些信息,AI 都无法及时获取。

虽然可以通过 RAG/Agent 等技术缓解,但这更像是在给一个旧大脑外挂一个「实时信息提示器」,而非大脑本身的更新。

对于技术迭代比翻书还快的软件开发领域,依赖一个「活在过去」的工具,无异于拿着旧地图在新世界航行。更危险的是,它可能会自信地推荐一个已经停止维护、或者已知存在 CVE 的第三方依赖库,从而出现安全隐患。

1.3 上下文窗口限制

这个问题就像人的短期记忆一样。当我们和 AI 聊天聊久了,它会忘记开头说了什么。目前最好的模型,上下文窗口能达到百万级 token,能解决部分问题,但是也不够用。

对于动辄几十万、上百万行代码的现代开发项目,AI 就像一个只能通过门缝看房间的访客。它能看到门缝里的景象,但对整个房间的布局、风格和功能一无所知。开发者们常常抱怨 AI 编程工具「用着用着就变笨了」,根本原因就在于此。

1.4 缺乏真正的理解

这是最根本的问题。LLM 不理解代码的含义,它只是在模式匹配。

举个例子,当我们让 AI 写一个排序算法,它能写出完美的快排代码。但这不是因为它理解了「分治」的思想,而是因为训练数据里有大量类似的代码,它学会了这个模式。

一旦遇到需要真正理解业务逻辑、需要创新思维的场景,AI 就可能搞不定了。

2. 编程领域的具体挑战

上面这些通用局限,在编程领域会被急剧放大,产生一些特有的问题。

2.1 错误的放大效应

我们知道人是有容错能力的,如这张图,汉字顺序错了,我们也能读懂。

写文章错个字,读者能看懂。但代码里少个分号、多个逗号,程序直接跑不起来。更要命的是逻辑错误,比如边界条件判断错了,可能测试都能通过,上线后才爆雷。

我见过 AI 生成的代码,把 < 写成 <=,导致数组越界。还有在金融计算中使用浮点数,精度问题累积后造成账目对不上。这些都是看起来微小,实际后果严重的错误。

2.2 安全漏洞

这个问题相当严重。研究显示,AI 生成的代码中,包含安全漏洞的比例明显高于人工编写的代码。

原因很简单:

  • 训练数据本身就包含大量有漏洞的代码
  • AI 不理解什么是「安全」,只知道完成功能
  • 很多老旧的、不安全的编码模式被 AI 学习并复现

最常见的问题包括 SQL 注入、XSS、路径遍历等。AI 可能会直接把用户输入拼接到 SQL 语句里,或者在处理文件上传时不做任何验证。除非特别要求。

我们在实际写代码过程中,正向逻辑往往并不是花时间最多的,最复杂的就是边界,异常和特殊情况

2.3 项目上下文的缺失

真实的项目开发不是写独立的函数,而是在一个复杂的系统中工作。每个项目都有自己的:

  • 代码规范和风格
  • 架构设计和模式
  • 业务领域知识
  • 自定义的工具类和框架

AI 看不到这些全貌,经常会:

  • 重复造轮子(明明有现成的工具类不用)
  • 违背架构原则(在该用依赖注入的地方直接 new 对象)
  • 误用内部 API(不理解接口的设计意图)

2.4 代码质量和可维护性

AI 生成的代码往往追求「能跑就行」,但忽略了可读性和可维护性。常见问题包括:

  • 过度复杂的嵌套和链式调用
  • 缺乏有意义的变量名和注释
  • 不符合团队的编码规范
  • 没有考虑扩展性和重用性

当我们习惯了 AI 写代码,可能会不想去看代码(自信点,就是不想看),如果这样过度依赖 AI,可能会失去对代码的深度理解。当需要调试或优化时,面对一堆自己没真正理解的代码,问题就会比较大,甚至出了问题还需要现场看代码来定位问题。

小结

写了这么多,核心观点其实很简单 :AI 编程工具是很强大,但也有明显的局限性。我们需要清醒地认识这些局限,合理地使用工具,同时不断提升自己的核心能力。

代码是我们与机器对话的语言,但写代码的意义,永远是为了解决人的问题。无论工具如何进化,这一点不会变。

所以,继续写代码吧,带着思考去写,带着责任去写。让 AI 成为你的助手,而不是你的拐杖。

毕竟,最好的代码,永远是有灵魂的代码,在写代码中注入心流。

以上。