正文
对于想做 CTO 的人，或者正在做 CTO 的人，或者做技术管理的人而言，技术的锤炼和知识的提升非常重要。本文作者将向大家讲述创业中踩过的那些坑和他们的血泪总结。
先让我从印象最深的一次宕机讲起。有一天，有一台机器的容器挂了，我对技术人员说，你把机器重启一下吧！然后他就去了。结果没几秒钟，突然收到报警。我问那位同事，你做了什么？他反问，你不是让我重启服务器吗？
当时我简直要崩溃了，我只是让他把服务重启了，没想到他把服务器给重启了！幸亏运气好，重启服务器没有异常，如果重启失败，那意味着所有系统全部挂掉。
所以，作为技术管理者，一定要清楚地对下属表达自己的意见，否则，一旦出现操作上的“歧义”，后患无穷。
运维是企业中非常忙碌的一个职位。事实上，在创业公司，哪里有专门的运维人员？全是技术人员身兼百职。这样的结果往往是一团糟。
我们也是从这样的常态中走出来的。当时没有资金请人专门做运维，什么事情全是自己内部消化。后来，技术团队慢慢用 JKS 做管理，然后线上自己搭建服务器，发布系统，最终实现多线条发布。当我们逐渐将发布系统控制好之后，我们决定成立专门的运维部门和测试部门。
当时有很多同事不理解，我就和他们讲述了上文我所亲身遭遇的那个宕机事件。我告诉他们，当运维对于线上数据中心或者是云端的所有系统，不是全权把握的时候，终有一天你们会后悔，这就和我们后期把服务器重启是一个道理。当运维对数据中心哪怕存在一点点失控的细节，那都意味着漏洞的存在。
我们经常遇到这样一个场景：业务部门的同事反馈用户投诉系统有 Bug，技术部门的同事收到投诉后，开始检查系统，如果有问题，那就赶紧修改，尽快上线。
如今，这个流程已经不能满足监控系统的需求了。监控系统的新需求是先于业务，先于客户知道漏洞存在于何处。
这对前端技术人员提出了挑战，要把所有的业务调整成自动化的脚本，定期地自动运营。具体实现是在前端设立一些机制，每隔一段时间去自动化地进行全路径的测试，把点击、下单、注册这些流程全部都走一遍，每隔一段时间就重复操作一遍，作为一种预防机制，这也能发现一些问题。
谈及架构师，我认为架构师的第一个角色是医生，首要职责是看病。我们可以把业务当成病毒，业务这一病毒会感染系统，那么架构师需要根据病情开药方，换一个新的思路去解决问题。
架构师要做的第二件事情是着眼未来，像医生一样不仅要治病，更要预防患者再次生病。不只是架构师，包括所有的管理层都不能只看眼前，要看将来。所有系统的方向，在满足业务的同时，要稍微往前面走半年到一年的时间，对于创业公司和中小型公司，提前半年的架构已经很好了。
在架构 IT 系统时，系统必须要有冗余，架构的冗余、设备的冗余、技术的冗余，包括人力上都要稍微的冗余，而不是所有的技术人员都投入在业务上。我的方法是分配出 20% 的人力，在技术架构上实现超前部署。
苹果应用商店对重应用的审核非常严格，我们提交 APP 之后，一般3天就通过审核。随着业务的发展，我们在 2015 年发布了 14 个升级版本，平均不到一个月就需要升级一次。
为此，我给苹果写了 10 封加急邮件。最后，苹果公司给我发了一封邮件，提醒这样的行为非常不妥，建议我们先自查代码，以后再遇到这样频繁的升级，审核将无法通过。
为什么会出现这样的现象？原因是我们将太多核心的功能放在 APP 中了。现在，我们不再采用这种做法，我们将粗颗粒度的代码写在 API 中，中间设立 ISC 框架进行多元调用，从而帮助 APP 端实现更多的功能。
有需求的开发者通过下单，将数据传输进来，我们在内部做拆分，做数据的聚合，然后再聚合下传、拆分，数据清晰，最后再聚合，再传过去。通过内部的优化，我们可以监控这些数据，实现更好地调用。
关于数据库的经验分享，首先是永远不要忽视数据库的重要性。我要求数据中心的管理人员，每个礼拜的固定时间要进机房巡检，是真的去人为地一台台巡检，并把这件事当做日常的工作之一。
第二点经验之谈是数据库怎么备份都不嫌多。这方面我也是吃亏长见识，公司的数据存储量不大，平均一个小时备份一次，当时出了一次意外，有一小时的数据丢失了，最终找到硬盘公司，花了几万元才把数据恢复出来，重新再合并回去。
慢慢的，公司架构就演变成现在这样。在架构改变的过程中，所有的管理层，所有的技术负责人，对于整个团队的技术方向要有一定把控，要去关注他们用的是什么技术。
“薅羊毛”这个词大家都不陌生，如何抵御“羊毛党”的攻击呢？
首先要设立一套标准的风控体系，对于价格的波动、促销的波动、销量的波动，都有控制手段。我们公司是做食品的平台，“羊毛党”的目光都锁定在那些方便流通转卖的商品上，例如五粮液、品牌的大米、油这几类。
其次，做好业务沟通与货物物流的工作。从异常行为中发现端倪，从而阻止“羊毛党”的攻击。
再次，建起第一道防线——注册。可以借鉴腾讯和阿里的系统，它分为两个等级，其中第一个等级使用验证码就可以。通过验证码，做一些简单的人工判断、人工学习，例如通过页面拖动的时间、停顿、失误率来判断出这个注册对象是人还是机器。
像腾讯、阿里这样的公司，有一套完整的数据库，通过对网站注册用户的一些基本资料的判断，将用户分成三个等级：可信、可疑和严重。然后，根据不同人的行为，做不同的风控体系，例如被归为可疑的用户，会在下单、充值、注册、加购物车、刷新等处设置关卡，每个环节都把风控体系做好。
最后，客服体系也是风控的重要环节。我认为风控最后落地的关键不在技术，而是客服。因为客服体系可以根据订单来判断用户是否存在异常。
我要求产品和技术定期去公司第一线工作。我曾经亲身体验过，当时团队的一位技术同事做了一个功能，他自己认为开发的非常好，可以大大提高仓库工作人员的效率。我去仓库干了一个礼拜，回来之后，针对他提的功能改了 40 多处。
追责也是技术人员必须考虑的一个因素。当客服接到用户投诉，技术要可以实现将一系列的用户行为记录在案，留存证据。其实以上这一切行为的根本目的就是要将产品与技术融入到一线，跟业务打成一片。
请记住，没有一家公司技术能满足业务需求。如果一家公司宣称技术能满足业务需求，我会认为这个公司前途惨淡。因为真的业务永远在发展，技术永远在追随着业务发展的脚步，技术人员如何更好地去帮助业务成长，是首要考虑的事情。
CTO 在管理过程中时刻需要做决策，从管理层角度看问题做判断，一方面是由过去的经验辅助决策，另一方面是从公司整体出发，决策更有全局观。
相信很多时候，技术管理者都会遭遇这样的问题，比如 CEO 一个电话要求 CTO 某项目一个月上线。这是领导做出某项决策，没有给技术人员留出足够的准备时间的情况，属于典型的缺乏沟通意识。
当时我和 CEO 沟通，或许我可以用一个月的时间做出一套系统，但是这套系统是否能让双方满意，是否能达到预期？这都存在风险。我请他以后有新的想法，要提前和技术人员沟通，不要等到已经做出决定了再告诉技术人员，因为这样会让技术人员非常被动，也让项目实施徒增很多困难。
技术团队还会经常听到的话：“这有很难吗？应该几天就可以完成吧？为什么这个这么慢啊，两天时间还搞不定吗”这些话在创业初期不绝于耳，因为你不能要求每一位老板都懂技术，所以你只能妥协，通过团队的努力，尽可能快地实现领导下达的目标。这些都需要技术人员多和领导沟通，了解对方的想法。
企业技术体系的构建，绝对不要坚持“技术至上”原则。因为技术的构建离不开业务的发展，构建的目的也是为了更好地实现业务的升值。
还是用上文中与 CEO 的沟通作为例子，当时只有一个月的时间，我无奈之下做出了一个非常错误的决定：把现有 IT 系统拆分，拷贝了一套出来，在此基础上修改，重建了一条分支。这也意味着，技术内部存在两套系统，各自有独立的服务器、独立的系统、独立的数据监测。
这个解决办法的确满足了业务的需求，但很快更多的问题暴露了出来：无论从财务层面、报告层面还是公司结构层面，都需要将这两套独立系统再度融合在一起。
通过这个惨痛的教训，我想告诉大家：不要追求技术至上，在变动技术架构之前，一定要和业务部门充分沟通，了解他们的需求，这样做出来的系统才能贴合实际需求，而非空中楼阁。
我曾经看到过非常好的技术，觉得非常好用，结果该技术没有形成生态，没有技术的中文文档，没有论坛支持，连人才都找不到。这时，请一定控制技术的欲望，尤其作为管理者，在项目的初期一定要控制技术的求知欲。
在创业发展后期，肯定是用所有语言的所长，用所有工具的所长，去解决技术遇到的问题。我认为，没有最好的语言，只有最适合的语言。但在创业初期，我的建议是尽量统一语言，一方面是方便招人，另一方面也会降低技术运营成本。
现在我也在挖掘更多的能力，希望减少人力重复的工作，目的也是为了减少研发成本。这是一个非常现实的问题，因为在公司成本中，往往人力成本是最贵的。从领导角度考虑就会思索，能不能将几千万的工资降低，去做别的更有价值的事情。
在创业的初期阶段，我选择用服务商去为公司招人，做安全测试时，我也决定花钱请外面的公司对我们做渗透测试，之所以这么做，是因为我认为公司初期所有的资源都应该为业务铺路，这是我的做事原则。在业务没有把技术做崩溃之前，一定要保证业务的前行。当然，盲目去支撑也不对。
我们目前在做私有云，但是我不准备在这件事上花过多的精力，我要用最轻的方法做私有云，让专业的云厂商去实现我们的诉求。
如何帮助业务做得更好？传统上看，工程代码耦合程度相当高，我认为工具性的内容可以通过外包服务实现，如旁支的检测、安全检查，但是系统层面的构建千万不要选择外包服务。
我们公司创业最初的系统是外包给供应商做的，可他们做了一件令我觉得不可思议的事情：为了把核心代码加入系统中，他们把所有的逻辑都写在了同一层里面，不管逻辑是否通顺，甚至也不管该不该写在其中，全部一股脑写进去，然后把这个包加密了。
当我把源代码购买来解密了这个包之后，那一瞬间我就想把系统推翻重做！这已经谈不上什么耦合关系了，俨然是打断骨头连着筋的状态，最后没有办法，我们自己一点点做解耦。
在创业初期，如何解决招人的难题？
我的回答是，去各大学的论坛泡，看论坛中的学生，有没有符合要求的人。还可以让这些人推荐他们身边的好友，不管是毕业的、应届的、没毕业的，只要是人才，通通招进来。
坦白说，我创业初期的成员就是靠这个办法招来的，毕竟在公司初创时期，没有品牌效益，没有资金，前途和“钱途”都无法许诺，只能通过这样的方式去招人。
值得一提的是，通过我这样的方法招来的员工，职场经验如同一张白纸，他们没有见过世面，也并不知道该做什么。大部分人技术都停留在理论知识，写过一些小程序，并不了解什么是开发，什么是资产。这样的结果就是公司的系统质量令人堪忧。
后来，公司业务慢慢有了起色，IT 系统开始跟不上业务的发展节奏。在这样的情况下，我们只能逐步解耦做 SOA，先把框架搭建起来，然后一点点调整。
我的经验是，即便是在初期，也要坚持自己的IT规划和思路，定期地对系统进行抽检，确保跟进业务路线，这是非常重要的事情。
作者：钱荣明
编辑：周雪、孙淑娟
本文选自《CTO说》
钱荣明，曾创办猎头电商推推网，后就职于IBM，2012年加入本来生活，担任产品技术中心副总经理，参与了整个体系的技术搭建，全面负责产品技术工作，包含产品技术运维测试BI等。
