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