235idc.com做IDC这一年，我对技术创业的5个新理解
摘要：从写Java转行做IDC，卖服务器、卖带宽、卖算力。这一年接触了大量创业者和中小企业客户，看到了很多项目从想法到落地的全过程。有些认知跟以前做开发的时候完全不同了。这篇文章聊聊这5个理解，不鸡汤，都是实际遇到的。
相关服务：新加坡云服务器租用
关键词：技术创业、IDC、基础设施、创业认知
分类：创业 / IDC / 随笔
背景
去年从开发转行做IDC。服务器、带宽、IP、GPU算力都做。
一年下来接触了形形色色的客户。有一个人单干的独立开发者，有几十人的创业团队，也有从大厂出来带着明确方向创业的技术leader。
看到了很多项目从零开始搭建的全过程，也看到了不少项目半路熄火。有些认知跟以前做开发的时候差距挺大的。
理解一：基础设施成本比你想的高，比你以为的重要
做开发的时候，我对服务器成本的全部认知就是"云主机一个月几百块"。
做了IDC才知道，基础设施的成本结构远比这复杂。
一台云主机8核16G，月费看着不多。但业务真正跑起来之后：
带宽是大头。特别是有大量数据传输的业务，带宽费用可能是机器费用的好几倍。
数据库不能用最低配的。线上出了性能问题再升级，迁移的痛苦远超多花的钱。
备份、监控、安全这些东西不花钱的时候觉得无所谓，出了事才知道值多少钱。
有个客户做SaaS产品，前半年只算云主机费用，觉得一个月两三千挺省的。半年后用户涨上来了，加上带宽、数据库、CDN、备份，月账单到了一万五。
他的原话是：“以前只算CPU和内存的钱，没想到带宽和数据库才是大头。”
对创业团队来说，基础设施的成本是每个月都在发生的。做预算的时候不能只看机器费用，要把带宽、存储、备份、安全都算进去。
理解二：技术选型的窗口期很短，但技术债务还得慢慢还
做开发的时候，技术选型是"哪个方案更优"的问题。
做IDC之后发现，创业团队的技术选型很多时候是"先跑起来再说"。
这没什么错。创业初期最重要的事情是验证产品能不能跑通，不是追求架构完美。用最快的方案把东西跑出来、让用户试用、拿到反馈，比花三个月做一套完美架构重要得多。
但问题在于，"先跑起来"的技术方案往往会在后面埋雷。
一个典型场景：
创业初期为了省钱，用了一台低配云主机跑所有东西。数据库、应用、缓存全在同一台机器上。用户量小的时候完全没问题。
半年后用户涨了，一台机器撑不住了。要拆分服务、要做数据库读写分离、要加缓存层。但原来所有东西都在一台机器上，拆起来非常痛苦——数据库和应用紧耦合，改一个影响另一个。
如果一开始就做了简单的拆分（数据库单独一台、应用单独一台），后面扩容会轻松很多。但初期确实多花了钱。
这就是技术创业的矛盾：初期要快，但太快了后面要还债。
我现在给客户的建议是：初期可以在架构上简单，但有几件事不要省——数据库和应用分开部署（哪怕各用最低配的机器）、数据要有备份机制、关键数据的存储方案要提前想清楚扩展性。这三件事的成本不高，但能省掉后面很多麻烦。
理解三：很多创业者的瓶颈不是技术，是算不清楚账
这个是做IDC之后最意外的发现。
我本以为来找我的客户都是"知道自己要什么"的。但实际上很多人对成本和资源完全没有概念。
“我要一个能跑10万用户的服务器”——10万用户是什么场景？日活还是注册用户？是读多写少还是写多读少？什么都没说清楚。
“我要最便宜的方案”——便宜到什么程度？为了省200块用了一台连备份都没有的机器，数据丢了损失多少？
“GPU服务器我要8卡A100”——你的模型多大？数据集多大？4卡够不够？8卡的利用率能不能跑满50%？
不只是技术问题，是商业思维的问题。
一个做短视频的创业者，上来就要8卡A100做推理。我帮他算了一下，他的模型用4卡就够了，8卡的利用率不到40%。每月省下来大几千块。
一个做电商SaaS的客户，选了一台高端服务器跑所有东西。拆成两台中端的，一台跑数据库一台跑应用，性能更好还便宜20%。
创业每一分钱都很重要。能算清楚账的人，活下来的概率更大。
理解四：信任是这个行业的硬通货
做开发的时候，我对IDC行业的印象就是"卖机器的"，觉得这行门槛低，谁都能做。
做了才知道，这行门槛确实不高，但做好的门槛很高。
客户把业务放在你的服务器上，意味着把命脉交到了你手里。你推荐的线路如果选错了，他的用户体验差了，用户就跑了。你给的服务器如果硬盘质量不行，数据丢了，他的业务可能直接没了。
有个客户跟我讲过他之前的经历：选了一家很便宜的IDC，用了半年硬盘坏了。供应商说没有备件，让他自己寄硬盘过去换。从发现故障到恢复，总共花了五天。他的电商平台那五天几乎没收入。
从那之后他选IDC的标准完全变了。不看最便宜的，看最靠谱的。他说：“出了问题有人管，比什么都重要。”
我在做IDC的过程中越来越理解这句话。价格可以谈，配置可以选，但出了问题有没有人管、能不能帮你解决，这个没法在产品页面上看到。
所以这行最重要的资产是信任。信任靠的不是话术，是出了问题的时候你怎么处理。一次次把问题解决了，信任就建立起来了。砸了一次，信任就没了。
理解五：技术背景做IDC确实是优势，但不是你想的那种
做开发的人转行做IDC，第一反应是"我懂技术，我能给客户提供更好的方案"。
这没错，但只对了一半。
技术背景的优势不在于你能写脚本、能调内核参数。这些客户自己也能学，或者找运维搞定。
真正的优势是：你知道客户的痛点在哪。
做开发的时候被跨网延迟折磨过，所以推荐线路的时候我会重点考虑客户用户的运营商分布。
做开发的时候被共享带宽坑过，所以客户说"要100M"我会追问独享还是共享。
做开发的时候被CLOSE_WAIT搞过，所以交付服务器的时候会帮客户检查一下连接池配置。
做开发的时候被数据库单点故障吓过，所以有客户把数据库和应用放一台机器上我会建议拆开。
这些不是什么高深的技术能力，就是自己踩过的坑。踩过的坑变成了给客户的建议，这就是技术背景的价值。
但反过来说，技术背景也可能变成劣势。有时候会忍不住"过度设计"——客户只是要一个简单的Web站点，你给他设计了一套微服务架构。不是不行，是现阶段不需要。
创业者的钱和精力都是有限的。够用就好，等规模上来了再迭代。
最后
做IDC这一年最大的感受是：基础设施是所有业务的底座，但很多技术人对这个底座了解得很少。
做开发的时候觉得服务器就是SSH上去写代码的地方。做了IDC才知道，选什么线路、用什么带宽、CPU是什么型号、数据怎么备份，这些底层的东西直接影响着上层应用的表现。
对技术创业者来说，不需要精通基础设施，但至少要了解基本的概念和选型逻辑。不然在最开始的几步就可能走弯路，后面改起来代价很大。
写这个系列的初衷就是把这些基础设施领域的常识讲清楚，帮做技术的人少踩点坑。
踩坑这事我替你们干了不少，能少踩一个是一个。
有问题评论区聊。