最近和几个做技术管理的朋友小聚,聊到曾经各自入职后的第一个月在干什么,答案出奇的一致。
「盘家底。」
「梳理资产。」
「摸排现状。」
说法不同,但干的都是同一件事——技术资产盘点。
这些朋友有从大厂跳到创业公司的,有从创业公司到大厂的,有接手十几人团队的,也有管上百号人的。按理说,不同规模、不同阶段的公司,管理重点应该不一样吧?
但为什么大家不约而同都在做技术资产盘点?
这事儿其实跟公司大小没关系,跟一个更本质的东西有关——手感。
什么是手感
做技术管理,手感是个很玄妙的东西。
举个例子: 团队和你汇报一个系统改造方案,说要花 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,可以马上做?哪些需要长期规划?哪些需要跨团队协作?
记住,罗马不是一天建成的,技术债也不是一天能还清的。有节奏地推进,比急于求成更重要。
建立监控体系
光盘点不够,还要建立监控体系。资源使用率、成本趋势、性能指标……这些都要持续监控。
很多问题都是慢慢积累的。如果没有监控,等我们发现时可能已经很严重了。
形成资产管理文化
最高境界是形成资产管理的文化。让每个人都有成本意识,都知道自己用的资源值多少钱,都会主动优化。
这需要时间,需要机制,更需要管理者的坚持。
最后
技术管理空降,最难的不是推新技术、搞创新,而是先把现有的东西搞清楚。这就像医生看病,不把脉、不验血,上来就开药,那是江湖郎中。
技术资产盘点,就是给技术体系做一次全面体检。只有知道了哪里健康、哪里有病,才能对症下药。
这个过程可能很枯燥,可能会发现很多历史遗留问题让人头疼,但这是建立手感、获得掌控、赢得信任的必经之路。
记住,管理的本质是通过他人完成工作。而要想通过他人完成工作,我们首先得知道工作是什么、资源在哪里、问题在哪里。
技术资产盘点,就是回答这些问题的第一步。
不要急着证明自己,先把家底摸清楚。当我们真正理解了这个技术体系,知道了每一分钱花在哪里、每一个系统为什么存在、每一个问题因何而生,我们的管理才能真正落地。
毕竟,空降兵最重要的不是会打仗,而是先活下来。而活下来的第一步,就是搞清楚自己降落在哪里。