血泪总结！创业公司CTO要避免哪些坑？

对于想做 CTO 的人，或者正在做 CTO 的人，或者做技术管理的人而言，技术的锤炼和知识的提升非常重要。本文作者将向大家讲述创业中踩过的那些坑和他们的血泪总结。

先让我从印象最深的一次宕机讲起。有一天，有一台机器的容器挂了，我对技术人员说，你把机器重启一下吧！然后他就去了。结果没几秒钟，突然收到报警。我问那位同事，你做了什么？他反问，你不是让我重启服务器吗？

当时我简直要崩溃了，我只是让他把服务重启了，没想到他把服务器给重启了！幸亏运气好，重启服务器没有异常，如果重启失败，那意味着所有系统全部挂掉。

所以，作为技术管理者，

运维是企业中非常忙碌的一个职位。事实上，在创业公司，哪里有专门的运维人员？全是技术人员身兼百职。这样的结果往往是一团糟。

我们也是从这样的常态中走出来的。当时没有资金请人专门做运维，什么事情全是自己内部消化。后来，技术团队慢慢用 JKS 做管理，然后线上自己搭建服务器，发布系统，最终实现多线条发布。当我们逐渐将发布系统控制好之后，我们决定成立专门的运维部门和测试部门。

当时有很多同事不理解，我就和他们讲述了上文我所亲身遭遇的那个宕机事件。我告诉他们，当运维对于线上数据中心或者是云端的所有系统，不是全权把握的时候，终有一天你们会后悔，这就和我们后期把服务器重启是一个道理。

我们经常遇到这样一个场景：业务部门的同事反馈用户投诉系统有 Bug，技术部门的同事收到投诉后，开始检查系统，如果有问题，那就赶紧修改，尽快上线。

如今，这个流程已经不能满足监控系统的需求了。

这对前端技术人员提出了挑战，要把所有的业务调整成自动化的脚本，定期地自动运营。具体实现是在前端设立一些机制，每隔一段时间去自动化地进行全路径的测试，把点击、下单、注册这些流程全部都走一遍，每隔一段时间就重复操作一遍，作为一种预防机制，这也能发现一些问题。

谈及架构师，我认为架构师的第一个角色是医生，首要职责是看病。我们可以把业务当成病毒，业务这一病毒会感染系统，那么架构师需要根据病情开药方，

架构师要做的第二件事情是着眼未来，像医生一样不仅要治病，更要预防患者再次生病。所有系统的方向，在满足业务的同时，要稍微往前面走半年到一年的时间，对于创业公司和中小型公司，提前半年的架构已经很好了。

在架构 IT 系统时，我的方法是分配出 20% 的人力，在技术架构上实现超前部署。

苹果应用商店对重应用的审核非常严格，我们提交 APP 之后，一般3天就通过审核。随着业务的发展，我们在 2015 年发布了 14 个升级版本，平均不到一个月就需要升级一次。

为此，我给苹果写了 10 封加急邮件。最后，苹果公司给我发了一封邮件，提醒这样的行为非常不妥，建议我们先自查代码，以后再遇到这样频繁的升级，审核将无法通过。

原因是我们将太多核心的功能放在 APP 中了。现在，我们不再采用这种做法，我们将粗颗粒度的代码写在 API 中，中间设立 ISC 框架进行多元调用，从而帮助 APP 端实现更多的功能。

有需求的开发者通过下单，将数据传输进来，我们在内部做拆分，做数据的聚合，然后再聚合下传、拆分，数据清晰，最后再聚合，再传过去。通过内部的优化，我们可以监控这些数据，实现更好地调用。

关于数据库的经验分享，我要求数据中心的管理人员，每个礼拜的固定时间要进机房巡检，是真的去人为地一台台巡检，并把这件事当做日常的工作之一。

这方面我也是吃亏长见识，公司的数据存储量不大，平均一个小时备份一次，当时出了一次意外，有一小时的数据丢失了，最终找到硬盘公司，花了几万元才把数据恢复出来，重新再合并回去。

慢慢的，公司架构就演变成现在这样。在架构改变的过程中，所有的管理层，所有的技术负责人，对于整个团队的技术方向要有一定把控，要去关注他们用的是什么技术。

“薅羊毛”这个词大家都不陌生，如何抵御“羊毛党”的攻击呢？

• 我们公司是做食品的平台，“羊毛党”的目光都锁定在那些方便流通转卖的商品上，例如五粮液、品牌的大米、油这几类。
  
• 从异常行为中发现端倪，从而阻止“羊毛党”的攻击。
  
• 可以借鉴腾讯和阿里的系统，它分为两个等级，其中第一个等级使用验证码就可以。通过验证码，做一些简单的人工判断、人工学习，例如通过页面拖动的时间、停顿、失误率来判断出这个注册对象是人还是机器。像腾讯、阿里这样的公司，有一套完整的数据库，通过对网站注册用户的一些基本资料的判断，将用户分成三个等级：可信、可疑和严重。然后，根据不同人的行为，做不同的风控体系，例如被归为可疑的用户，会在下单、充值、注册、加购物车、刷新等处设置关卡，每个环节都把风控体系做好。
  
• 我认为风控最后落地的关键不在技术，而是客服。因为客服体系可以根据订单来判断用户是否存在异常。 
  

我曾经亲身体验过，当时团队的一位技术同事做了一个功能，他自己认为开发的非常好，可以大大提高仓库工作人员的效率。我去仓库干了一个礼拜，回来之后，针对他提的功能改了 40 多处。

当客服接到用户投诉，技术要可以实现将一系列的用户行为记录在案，留存证据。

请记住，没有一家公司技术能满足业务需求。如果一家公司宣称技术能满足业务需求，我会认为这个公司前途惨淡。因为

CTO 在管理过程中时刻需要做决策，从管理层角度看问题做判断，一方面是由过去的经验辅助决策，另一方面是从公司整体出发，决策更有全局观。

相信很多时候，技术管理者都会遭遇这样的问题，比如 CEO 一个电话要求 CTO 某项目一个月上线。这是领导做出某项决策，没有给技术人员留出足够的准备时间的情况，属于典型的缺乏沟通意识。

当时我和 CEO 沟通，或许我可以用一个月的时间做出一套系统，但是这套系统是否能让双方满意，是否能达到预期？这都存在风险。我请他以后有新的想法，要提前和技术人员沟通，不要等到已经做出决定了再告诉技术人员，因为这样会让技术人员非常被动，也让项目实施徒增很多困难。

技术团队还会经常听到的话：“这有很难吗？应该几天就可以完成吧？为什么这个这么慢啊，两天时间还搞不定吗”这些话在创业初期不绝于耳，因为你不能要求每一位老板都懂技术，所以你只能妥协，通过团队的努力，尽可能快地实现领导下达的目标。

企业技术体系的构建，绝对不要坚持“技术至上”原则。因为技术的构建离不开业务的发展，

还是用上文中与 CEO 的沟通作为例子，当时只有一个月的时间，我无奈之下做出了一个非常错误的决定：把现有 IT 系统拆分，拷贝了一套出来，在此基础上修改，重建了一条分支。这也意味着，技术内部存在两套系统，各自有独立的服务器、独立的系统、独立的数据监测。

这个解决办法的确满足了业务的需求，但很快更多的问题暴露了出来：无论从财务层面、报告层面还是公司结构层面，都需要将这两套独立系统再度融合在一起。

通过这个惨痛的教训，我想告诉大家：

我曾经看到过非常好的技术，觉得非常好用，结果该技术没有形成生态，没有技术的中文文档，没有论坛支持，连人才都找不到。这时，请一定控制技术的欲望，

在创业发展后期，肯定是用所有语言的所长，用所有工具的所长，去解决技术遇到的问题。我认为，没有最好的语言，只有最适合的语言。但

现在我也在挖掘更多的能力，希望减少人力重复的工作，目的也是为了。这是一个非常现实的问题，因为在公司成本中，往往人力成本是最贵的。从领导角度考虑就会思索，能不能将几千万的工资降低，去做别的更有价值的事情。

在创业的初期阶段，我选择用服务商去为公司招人，做安全测试时，我也决定花钱请外面的公司对我们做渗透测试，之所以这么做，是因为我认为公司初期所有的资源都应该为业务铺路，这是我的做事原则。在当然，盲目去支撑也不对。

我们目前在做私有云，但是我不准备在这件事上花过多的精力，我要用最轻的方法做私有云，让专业的云厂商去实现我们的诉求。

如何帮助业务做得更好？传统上看，工程代码耦合程度相当高，我认为，如旁支的检测、安全检查，但是

我们公司创业最初的系统是外包给供应商做的，可他们做了一件令我觉得不可思议的事情：为了把核心代码加入系统中，他们把所有的逻辑都写在了同一层里面，不管逻辑是否通顺，甚至也不管该不该写在其中，全部一股脑写进去，然后把这个包加密了。

当我把源代码购买来解密了这个包之后，那一瞬间我就想把系统推翻重做！这已经谈不上什么耦合关系了，俨然是打断骨头连着筋的状态，最后没有办法，我们自己一点点做解耦。

在创业初期，如何解决招人的难题？

我的回答是，看论坛中的学生，有没有符合要求的人。还可以让这些人推荐他们身边的好友，不管是毕业的、应届的、没毕业的，只要是人才，通通招进来。

坦白说，我创业初期的成员就是靠这个办法招来的，毕竟在公司初创时期，没有品牌效益，没有资金，前途和“钱途”都无法许诺，只能通过这样的方式去招人。

值得一提的是，通过我这样的方法招来的员工，职场经验如同一张白纸，他们没有见过世面，也并不知道该做什么。大部分人技术都停留在理论知识，写过一些小程序，并不了解什么是开发，什么是资产。这样的结果就是公司的系统质量令人堪忧。

后来，公司业务慢慢有了起色，IT 系统开始跟不上业务的发展节奏。在这样的情况下，我们只能逐步解耦做 SOA，先把框架搭建起来，然后一点点调整。

我的经验是，