Github:诞生于Ruby,60%的员工远程工作
Github诞生于2008年,现在已经是全球最大的代码托管平台。然而鲜为人知的是,他们使用的技术栈非常简易,Ruby、Shell和C。并且6成员工远程工作,通过Hubot协作。
Sam Lambert 在 2013 年加入 Github 公司,当时的身份是公司的第一名数据库管理员,现在已经是 Github 的技术总监。在去年他曾接受 Derrick Harris 的采访,解释作为一家全球性网站,是如何通过简单便捷的技术栈,成功支撑起超过 1000 万用户,超过 2500 万项目的。
他还谈到 Github 大型的远程工作团队,大概有 60% 的员工通过远程工作,利用一个叫做 Hubot 的自动化工具协作。
SAM LAMBERT 介绍,在内部开发产品和各种服务时,Github 特别推崇 Unix 哲学,采用最简单的技术,实现众多基础性功能,对于复杂臃肿的过度工程化深恶痛绝。对于技术和项目的选择,更讲究实用主义。
很久以来,网站许多关键基础设施,都用的是 Shell 脚本,它们很有效,多年来用着很顺利。
网站创建于 2008 年,至今已经 8 年,最初网站使用 Ruby on Rails 构建,最初的版本是由创始人自己写的,当然 Git 部分用的是 C 语言,处理 Git 请求,数据合并等事项。
当初所有的数据都通过 MySQL 存储,对于临时性质的数据,也会采用 Redis 或者是 memcache 做缓存。
Github 刚成立时,技术栈就这么简单:C,Shell,以及 Ruby。并且在做新项目地时候,也不会盲目尝试新的工具和语言。
随着网站规模的壮大,Github 的开发团队成功吸引到多名 Ruby 的核心开发者,在日后的开发过程中,继续保持技术栈的精简和实用。
对于新技术的态度,LAMBERT 表示其实工程师在工作中的自由度很高,可以试用各种新技术,只不过在实施项目时偏保守。
有趣的是,虽然全世界一半的新项目都由 Github 托管,但事实上 Github 仅采用了为数不多的几个技术栈。
随着时间的积累,Github 的用户量爆炸性增长,后面的技术上也面临诸多挑战。其中最复杂的是要处理 Git 的海量请求,LAMBERT 没有细说具体的技术细节,但表示依然是最简原则,不要重新发明轮子。
一直以来,性能都是工程师不懈的追求,Github 技术团队也是。除非这个功能足够快,否则就不要部署。
对于硬件奢设施,Github 没有使用任何云服务,而是自建数据中心,当然,为了满足庞大的使用量,Github 相当于构建了自己的私有云平台,Github 拥有自己的基础设施团队,人数不多,但可以保障 Github 的正常运行。
随着用户量的增长,团队规模也随着扩大。和众多创业公司一样,Github 也面临招聘新员工的挑战,既要具备足够的能力,而且要认同 Github 的文化和发展方向,为了招聘到满足需要的人手,Github 允许员工远程工作,这样可以招聘到其他国家和地区的员工。
在 Github,大概 60% 的员工远程工作,比如 LAMBERT 就曾经周游世界,在不同的地方工作,Github 推崇的正是分布式远程工作的文化。
为了让世界各地的员工分工协作,Github 使用 Hubot 工具。比如可以通过聊天的方式,询问 Hubot 现在在哪里,Hubot 可自动回复某成员当前在世界的哪个城市,或者在办公楼的哪一层。
Hubot 支持好几十个命令,可以查询 MySQL 状态,可以做故障切换,可以删除数据库表,可以备份文件,可以复制转移,可以做几乎所有和运维相关的事。
除了查询其他同事的状态,Hubot 还能实现监控功能,比如当某个服务器出现故障,Hubot 可以自动报警。
LAMBERT 认为,Hubot 代表了未来互联网公司的运作方式,他可以适应性地把服务器等基础设施以及分布于世界各地的员工紧密连接到一起,人与机器之间无障碍交流沟通,解决了许多传统企业未能解决的问题。
本文文字及图片出自 tech2ipo.com
你也许感兴趣的:
- GitHub 删除代码等于“任何人均可永久访问”!微软回应:我们有意为之
- 【外评】”GitHub “开始让人感觉像传统软件
- 编码20年,现在的我想放弃GitHub!
- GitHub 变 Twitter?强“喂”新推荐算法引公愤,开发者从“编程乌托邦”被驱赶到了信息茧房
- 让部署更快更安全,GitHub 无密码部署现已上线
- 开发者危机!微软GitHub启动裁员:印度工程师团队几乎整体裁撤
- 因使用 GitHub ,我们被取消了参赛资格
- 告别SVN,Git成“独苗”:GitHub 在 13 年后宣布淘汰Subversion支持
- GitHub被起诉,版权问题再引热议,网友类比谷歌图书:毕竟谷歌没拿用户内容写小说
- GitHub 前 CTO:全面微服务是最大的架构错误!网友:这不是刚改完 GitHub 吗
你对本文的反应是: