随笔:创业这一年那些事(1)

2018年初,那时候“三点钟”群一时之间炒爆了全国,所有人都带着狂热,市场一片欣欣向荣的光景,年轻人们都被“优秀的同龄人”的焦虑所缠绕。。。

Frankie找到我,说希望能加入他们公司一起创业,做汽车互联网。其实对于汽车这个行业我一直不是很了解,虽然作为一个直男,但我是很少了解有了解关注汽车,在影响中好像只知道宝马大众之类的。但那时候已经有换新工作的想法了,毕竟在useease呆了三年多了,而且同期进来的伙伴们也都闯南走北去了,想了大半个月,期间也去过公司简单考察过就答应下来了。其实,最后让下决心是两个因素,一个是Frankie给人感觉还可以,虽然在技术上不是很懂,但也愿意听取意见;一个是自己想出去闯闯,毕竟“外面”闹得这么热腾,而且也想锤炼下自己的全局能力,毕竟在useease管理过团队也研究过技术,但一直没尝试过从产品到研发和运营的一整套打法。

定基调

到公司第一件事,我做了战略框架的梳理,首先向Frankie、Jason两位创始人了解了公司的定位——成为一家类似于埃森哲的集广告与营销于一身的咨询类科技公司。既然定下了基调,那么先确定核心的优势,从哪里重点切入?其实,在当时我们已经跟运营商合作开发了半年多了,这是一块很大的资本,所以,在那时归纳起来就是数据,那么,我把技术基调定位构建一套规模庞大而有用的汽车大数据中心。

战略路径图

小插曲就说到这,后面也做些前期的技术规划和总结。

搭建技术团队及技术选型

第一次以一家创业公司技术负责人身份来思考团队架构和目标。

之前在useease担任研发技术经理,主要是管理项目和制定产品,人员上以小规模团队作战为主,由于业务和目标明确,较少需要思考团队组织架构和资源规划。(由于是内部项目,人员资源不足可以向上面协调和借调,而且像产品、美工、测试公司都是统一使用的,设备也是在统一的集群资源上分配)

首先从设备选型、方案设计、核心算法选择、可靠性、安全性的考虑,以及风险管理进行组织规划。

设备选型

因为前期计划是先做RTB程序化广告系统的,对延迟性和并发有要求,在单机选型上选了 Dell PowerEdge R730, 2U 的机架结构和他那强劲的CPU Xeon E5-2640 v4 象征着力量与实力,内存是4条 16G 的内存条,配备 8TB 硬盘 (后来在数据处理的时候发现硬盘读写存在瓶颈,又加了2TB固态硬盘),在单机性能上还算是过得去了。

硬盘存储方案选择 RAID 5,在数据保障和磁盘利用率之前折中 8TB 硬盘实际变成 6T 多,系统选用了 Centos 7 ,Red Hat 以稳定性著称,也适合线上环境运行。

系统目录结构分配:

/dev/mapper/centos-root        1.2T  4.9G  1.2T    1% /
devtmpfs 32G 0 32G 0% /dev
tmpfs 32G 0 32G 0% /dev/shm
tmpfs 32G 92M 32G 1% /run
tmpfs 32G 0 32G 0% /sys/fs/cgroup
/dev/sda2 94G 231M 93G 1% /boot
/dev/mapper/centos-home 3.2T 2.7G 3.1T 1% /home
/dev/mapper/centos-var 917G 152G 719G 18% /var
/dev/mapper/fastDevice-docker 689G 154G 501G 24% /var/lib/docker
tmpfs 6.3G 4.0K 6.3G 1% /run/user/42
tmpfs 6.3G 48K 6.3G 1% /run/user/1000

fastDevice-docker是后面加入的固态硬盘,主要用于扩充 docker 存储,给程序做读写加速。

方案设计

虚拟化方案

容器化和虚拟化不管对于小团队作战也好,大规模应用开发也好,都是团队不错的选择。对于小团队,特别是服务器资源有限的团队,进行虚拟化可以更方便协调团队资源,划分多环境开发,同时虚拟化也更容易进行风控,更安全。后期随着规模逐步扩大,也可以非常方便地转型成微服务应用,帮忙大团队以小团队的效率进行开发迭代。因此底层采用虚拟化方案将硬件和资源进行分离。

虚拟化方案选择了更轻量的 Docker 代替虚拟机,容器管理选择 Kubernetes,主要经历了 2017 的容器编码大战之后,Kubernetes 项目已经成为了构建容器化平台体系的默认选择,是一个非常优秀的容器应用的部署、扩展和管理的解决方案,也可以作为企业实现原生云(Cloud Native)概念的支持。

数据层

关系型数据库采用MySQL,这里主要采购了腾讯云的MySQL高可用解决方案。

缓存层采用Redis,主要用于缓存用户请求信息。

Hadoop作为底层的分布式数据库,主要用于存储运营商传过来的DPI分析结果数据。每天的规模在2~3G,kafka作为消息中间件。

计算层

计算层主要分为两部分,一部分是对数据做传统的统计分析或者运用传统的机器学习模型进行建模,主要用Spark使用;一部分是基于深度学习框架进行建模,这里分为两个工具,一个是用于算法研发阶段使用的:PyTorch,一个是用于生产环境,成熟稳定的:Tensorflow

应用层

最后一层是应用层。每个应用以容器的形式运行在系统上,与作为中台的计算层进行交互。

风险管控

技术风控上有几点:

  • 第一个是语言选型。前期团队语言选择Python,有几个原因,(1)Python简单,而且我作为技术负责人也是最擅长;(2)便于前期快速迭代开发,招人也相对简单;(3)可以很好的和数据分析、机器学习等进行整合,使用统一的技术栈。前段选用Vue,(1)小团队开发以语言易用,易招聘为根本;(2)Vue作为国人贡献的产品,中文支持力度好。我觉得前期的技术选型,简单易用是技术风控最关键的。
  • 服务器安全管理。要控制好风险,服务器的安全管控和项目上线流程要梳理好,(1)对各级开发者的账号权限的管理,严格控制sudo权限;(2)采用严格的安全策略,禁止远程密码登陆,换ssh端口,对所有对外开启的端口进行记录,数据库限制为只能内网访问,采用keeweb记录密码和管理密钥。

问题

研发人员少,主力工程师研发、运维一把抓

功能增加,复杂性逐渐变高

频繁改动,系统脏、乱、差

团队基础设施搭建

在创业初期,团队的基础工具集搭建是十分重要的,是效率和生产力的保证。
在这里我主要搭建了代码管理平台gitlab、持续集成工具git-runner、部署采用了容器化技术、在后续的架构升级中也引入了容器编排工具kubernetes,项目管理用的腾讯的TAPD

在构思技术选型中重要的是想清楚:
1、在什么阶段,解决的是什么问题
2、有哪些解决方案,为什么选择A而不选择B,取舍的关键是什么
3、突破的创新是什么,如果不做会怎么样,如何平衡创新和业务的关系
4、如何保持持续的维护性和创新性

shikanon wechat
欢迎您扫一扫,订阅我滴↑↑↑的微信公众号!