Etsy 在 DevOps 的改革之旅
視頻
https://vimeo.com/51310058
投影片
https://www.slideshare.net/mcdonnps/continuously-deploying-culture-scaling-culture-at-etsy-14588485
2008 工程脆弱和生活痛苦之年
Etsy 有 35 位員工, 有一半是工程師
在 2 個 datacenter 中有 250 台 servers
部署要花費數個小時, 代碼幾乎不行
開發和運維幾乎沒有溝通
Push 通常會失敗, 重新啟動和回滾是個挑戰
認為組織在進行變革之旅程時, 必須要先做的事是:
(1) 為重要的改進項目留出時間
(2) 保持小批量, 且不做長期計劃(例如,幾周而不是幾個月)
(3) 繼續優先考慮較高的”system of work”, 而不是“doing work”
在2008年離開時抱有以下承諾:
a. 獲得高層和底層, 大家都支持要去改變文化
b. 提高組織內部和公眾的透明度
c. 盡快償還技術債務
2009 DevOps 文化開始的一年
(1) 改變辦公環境
您工作的地方必須適合您的文化
(2) 成立一個DevTools 團隊
利用 open source 自動化持續部署的過程
以最少人, 最少步驟和儀式來部署新修改
(3) 管理階層和前線人員協作
管理人員不再只是下命令而已, 他們會一起合作去解決問題
在 2009 結束後, 他們達成了
a. 找到自己組織中造成最大痛苦的部分,並設法穩定它們
b. 僱用會有所作為的員工
c. 選擇去做會產生影響的項目
d. 完成它, 然後就出貨
2010 標準化的一年
(1) 建立持續集成和交付的團隊
(2) 標準化
減少要支援的基礎建設和配置
將所有事情都切換到 PHP 和 MySQL
讓每個人都可以閱讀,修改, 重寫其他人的代碼
(3) 狀態圖形化
顯示發生什麼
顯示哪裡有問題
顯示哪些事情要先處理
(4) 開發人員 on call 計畫
每三年至少有一週要 on call
確保開發人員有責任感和同理心
讓運維在部署期間有足夠資源
(5) 開始實踐 A/B testing, feature flags
(6) 管理層的態度有以下改變:
可以接受失敗, 但不該降低標準
失敗總是會發生, 但是要讓他被看得到, 被了解, 被當作是通往成功的跳板
相信但是會確認
無責罰的驗屍會議
2010 達成以下項目
a. 以圖形化方式顯示系統和基礎建設狀況
b. 讓開發人員當責
c. 文件和流程的標準化是需要的, 但非一成不變
d. 管理經層持續確認員工是否開心和滿意他們目前的工作
2011 豐收年
(1) 把非標準的技術從公司中移走
更多細節可以參考
Ross Snyder’s Surge 2011 talk, “Scaling Etsy: What Went Wrong and What Went Right”).
https://www.youtube.com/watch?v=eenrfm50mXw
https://www.slideshare.net/beamrider9/scaling-etsy-what-went-wrong-what-went-right
(2) 要求公司員工每年要做以下三件事情的其中一件
* Writing blog posts for fix.etsy.com
* Speaking at conferences.
* Open-source something.
(3) 發動一些改革
從 svn 換到 git
專注於資訊安全
利用 game days 來測試和尋找系統未知的問題
他們明年的計畫如下
a. 任何技術公司的高級管理人員應該要專注於技術
b. 即使只有 2 個 server, 也要做配置管理
c. 不要讓支付卡產業資料安全標準, 影響了公司的文化
svn是什麼 在 嫁給 RD 的 UI Designer Facebook 的精選貼文
學東西的方法。
好,我開始講原理。人很犯賤,做事情他都要問 Why,否則他不想做。然後知道 Why 後,他就會想 What to do 。
幹,這就是最慘的地方。初學東西絕對不要用大腦,要用肌肉,要用肌肉,要用肌肉。
如果你一開始用大腦學,你就慘了。這是一個大陷阱,也是很多人學東西學不起來的原因。
你的肌肉有記憶,只要重複,就會有記憶。你只要一件事情,練五次,他就會有記憶。所以不要問「為什麼」,先做就對了。也不要「想一般做一邊想改成自己要的」。
也就是絕對不能讓「大腦」介入學習你的訓練過程。
也就是絕對不能讓「大腦」介入學習你的訓練過程。
也就是絕對不能讓「大腦」介入學習你的訓練過程。
一旦你有這個念頭,你的大腦就會掉入一個無窮迴圈。
"Why" -> "What" -> "Why" -> "What" -> "Why" -> "What" -> "Why" -> "What"
問題是你完全不懂這門知識,你的大腦就會當機,而且擺脫不了這個迴圈。
不熟悉 What 操作方式,大腦就會慌張,就會問 Why。這時候就毀了。
有些人方法是去背熟 Rule Book,試圖掌握規則。
幹,這就更慘了,因為 1) Rule Book 讓人想睡,學習效率會超低 2) 就算你掌握 Rule book,新手根本無法根據 Rule Book 展開世界觀,因為世界不是 Rule Book 建構的,Rule Book 只是世界的一個「削減到最小,接近邏輯的規則」,但他們不是基礎的「邏輯」。
為什麼台灣人學語文 fail 呢?因為台灣學語文是由 Rule book 開始,所以一堆人八百年學不會。
其實世界上各領域都是這樣的,都是勉強會用,「文法標準」,只能證明你「有教養」「可能是 native」「高等教育」,卻不會說文法不標準,人家「完全聽不懂」。
比如說寫程式也是這樣,你照別人 example 做,一開始會動,但是效率不好,coding style 超噁心。然後你再慢慢學慢慢修,變成漂亮的程式。但人家不會說「你沒照正確 best pratices 寫」,這個功能就不會動。
幹,如果新手一開始花超多時間學語法,而且去找語言 best practices 寫,而且試圖去背 rule book,試圖了解他。讀完整本 design pattern 再學寫 code,幹,包準他什麼鬼都寫不出來。因為他會鬼打牆在 「我不要犯錯」,「怎麼一直保持完美」,「why,why,why」。
好。寫到這裡,你會發現開始有感覺了。好像學的起來的技能,都是這樣學起來的。而且我跟你講一件更可怕的 fact,這些學的起來的東西,你學的時候,要是是傻傻初學者狀態最好。
要是你已有類似領域學習經驗。完蛋了。會學超慢。為什麼呢?
因為第一直覺,你一定是會想要 what,把新東西方法 map 到你的舊技能去,然後你發現不 work,然後你開始問 why。
what -> why 迴圈要開始了。
我舉兩個例子。
當初我們最早一輩人,有 svn 經驗的人學 git 時,學超久。結果不知道什麼是 git 的人,學 git 超快。
因為我們會一直試圖把 svn map 到 git,然後找規則,幹,然後找不到規則。我認識一堆大神剛學 git ,都學得比現在新手慢超多......
然後現在新手學超快,是因為 git 現在有教學 example,照著打就好。不然你真的照 git rule book 來。媽的我跟你說 git command 真是超 nonsense 的。這點還被程式界拿出來恥笑。
學人類新語言還特別嚴重,因為這是一個領域,人人都有一門精熟的技能,但是絕大多數人不知道規則是怎樣的技能。
所以學語言時,下意識你會驚慌,一直想用what 去remap,然後去問 why。於是大腦就卡住鬼打牆了。
That's why。
svn是什麼 在 紀老師程式教學網 Facebook 的最佳貼文
[好文分享] Unix as IDE
寫過程式的朋友大概都用過 IDE (Integrated Development Environment)。那種什麼事情都交給 IDE 處理的感覺,真是方便又美好。但是有一部分的人(比如我,哈哈),對 IDE 大致滿意,但對某部分的功能頗有微辭,希望能「換掉」它,又礙於 IDE 是整個包在一起的,沒辦法抽換「部分功能」。
此時這群人就會傾向「不使用 IDE」,改用在「檔案管理、專案管理、文字編輯、編譯、建構工具、除錯工具、版本控制」各自領域首屈一指的工具,嘗試將它們兜在一起。目前,擁有大量這類「優秀小工具」、又「免費」的環境,大概只有 Unix / Linux 了。所以這類人,最後很容易迷上 Linux 環境(而且還是命令列工具),最後成為該領域的「傳教士」。在各領域常用的工具列表如下:
檔案與專案管理 — ls, find, grep/ack, bash
文字編輯軟體 — vim, awk, sort, column
編譯器或直譯器 — gcc, perl
建構工具 — make
除錯器 — gdb, valgrind, ltrace, lsof, pmap
版本控制軟體 — diff, patch, svn, git
底下這篇,正是一位勇闖 Linux 世界,最後愛上 Command Line 工具的朋友,所寫作的文章。跟他有類似經驗的我,看完此篇後心有戚戚焉。也希望能推薦給朋友,讓更多人能了解用 Linux Command Line Tools 整合以後的美好世界。文章有點長,不過相信喜歡的朋友,會忘卻時間,一直看下去的:
http://blog.sanctum.geek.nz/series/unix-as-ide/