「盘家底。」

「梳理资产。」

「摸排现状。」

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

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

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

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

什么是手感

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

举个例子： 团队和你汇报一个系统改造方案，说要花 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，可以马上做？哪些需要长期规划？哪些需要跨团队协作？

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

建立监控体系

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

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

形成资产管理文化

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

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

最后

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

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

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

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

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

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

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