【為什麼我們要挑選這篇文章】Github就是工程師的好朋友，但是大家只曉得怎麼用，卻不知道它的背景來源。不覺得，把一件事從頭到尾摸透透也是一種性感嗎？（責任編輯鄒昀倢）
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 代表了未來互聯網公司的運作方式，他可以適應性地把服務器等基礎設施以及分佈於世界各地的員工緊密連接到一起，人與機器之間無障礙交流溝通，解決了許多傳統企業未能解決的問題。
（本文經合作夥伴愛範兒授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為〈Github：誕生於Ruby，60%的員工遠程工作〉。）