Flickr 的「每日部署 10 次以上」演講，終結了開發與維運之間的戰爭

2009 年時，Flickr 這個隸屬於 Yahoo 的照片分享網站持續不斷地更新服務，而業界預設的分工——開發人員推出功能、維運人員維持網站穩定——讓每一次變更都變成一場爭鬥。變更是大多數服務中斷的根本原因，因此那些「最用力保護」網站的團隊，往往也是發布最慢的團隊。

讓變更變得安全，而不是變得罕見：共用工具——功能旗標、一步式部署、共用指標、聊天機器人——再加上不責怪文化，讓每天 10 次以上的部署成為常態。

維運端主管 John Allspaw 與工程端主管 Paul Hammond 以共同承擔責任為核心，重建了整個發布流程：自動化基礎設施、單一共用的版本控制主幹、一步式建置與部署、功能旗標、共用指標儀表板，以及 IRC 聊天機器人——並搭配一份明確的文化清單：尊重、信任、對失敗抱持健康態度，以及避免責怪。

他們在 2009 年 6 月 Velocity 大會的議程，受到的關注超過會議上任何其他演講，而「工具加文化」的框架也成為 DevOps 手冊的核心：幾個月後，這場運動在根特（Ghent）首屆 devopsdays 上為自己命名，而「每日部署次數」則成為業界的基準指標。

到了 2009 年，Flickr 這個隸屬於 Yahoo 的照片網站持續不斷地發布更新：在平常的一天裡，它會對網站進行十次以上的完整正式環境部署。那年 6 月，在聖荷西舉行的 O'Reilly Velocity 大會上，負責管理 Flickr 維運與工程兩端的兩位主管 John Allspaw 與 Paul Hammond，在一場題為「每日部署 10 次以上：Flickr 的開發與維運合作」的演講中說明了做法。Data Center Knowledge 對該大會的報導稱，這是整場活動中引起最多討論的簡報。

他們的論點直指業界預設的組織架構。那種刻板印象——開發人員增加功能，維運人員維持網站穩定與快速——把變更變成敵人，因為變更正是大多數服務中斷的成因。Allspaw 與 Hammond 把它反轉過來：維運的職責是促成業務，而業務需要變更，所以真正的工作是透過工具與文化來降低變更的風險。工具組包括：自動化基礎設施、共用的版本控制主幹、一步式建置與部署、讓程式碼先以隱藏方式上線的功能旗標、共用指標，以及讓任何人都能觀看發布過程的 IRC 機器人。

另一半則是文化：尊重、信任、對失敗抱持健康態度，以及避免責怪——包括消防演練，讓即使是初階工程師也能在真實事故發生前先演練過正式環境事故，因為失敗必然會發生。那年 10 月，Patrick Debois 在比利時根特籌辦了首屆 devopsdays；這場以該活動命名的運動，把 Flickr 演講的框架——由共用工具、不責怪任何人的團隊進行小規模、安全、頻繁的發布——帶進了各地的工程組織。

它點出了真正的限制所在：在網路事業裡，發布列車就是事業本身，而一個能每天安全部署十次的團隊，學習速度就是勝過每月才發布一次的團隊。

共用工具造就了共擔命運——同一個主幹、同一個儀表板、同一個部署按鈕——因此任何一方都無法靠讓對方失敗來取勝。

它把維運從穩定的守護者重新定義為變更的促成者，讓自動化與文化可以用同一個問題來衡量：我們能多常安全地發布？

它把責怪視為工程缺陷，而非人格瑕疵：如果人們隱藏錯誤，風險就會在無聲中累積；消防演練與不責怪的檢討能讓資訊持續流動。

產能來自讓變更變得安全，而不是變得罕見。共用工具造就共擔命運；責怪會教會工程師隱藏風險；維運促成業務，而不是把業務擋在正常運作時間之外。

那場議程的錄影至今仍在網路上，仍被當作 DevOps 的奠基文物展示。那年 10 月，Debois 在根特舉辦的首屆 devopsdays 為這場運動賦予了名稱，而「一天部署幾次？」則同時成為基準與挑戰。Allspaw 把這套做法帶到 Etsy，其衍生做法——不責怪的事故後檢討與持續部署——也在當地打響名號。十五年多之後，部署頻率已是標準的工程指標，而「開發對維運」的對立，如今多半只以這場演講所擊破的稻草人形式存在。