在Flickr的開發與運維合做（筆記）

##要點

1. 自動化基礎
   • 角色／配置管理
   • 系統鏡像？
2. 統一版本控制方式
   • 運維人員也需
   • 讓全部人都知道該幹什麼
3. 一步編譯／部署
   • 一個操做解決
   • 工具自動記錄時間／任務／事情
   • 小而頻繁地更改
4. 特徵標記（分支）
   • 能夠開發不少功能，完成以前不對外開放
   • 不一樣開發語言都有？
   • 水桶測試

設想把編程當作是轉動曲柄從井裏提一桶水上來的過程。若是水桶比較小，那麼僅需一個能自由轉動的曲柄就能夠了。若是水桶比較大並且裝滿水，那麼還沒等水桶所有被提上來你就會很累了。你須要一個防倒轉的裝置，以保證每轉一次能夠休息一下子。水桶越重，防倒轉的棘齒相距越近。 測試驅動開發中的測試程序就是防倒轉裝置上的棘齒。一旦咱們的某個測試程序能工做了，你就知道，它從如今開始而且之後永遠均可以工做了。相比於測試程序沒有經過，你距離讓全部的測試程序都工做又近了一步。如今咱們的工做是讓下一個測試程序工做，而後再下一個，就這樣一直進行。分析代表，要編程解決的問題越難，每次測試所覆蓋的範圍就應該越小。

- [Dark Lauches](http://changelog.ca/log/2012/07/19/dark_launching_software_features)

簡單說，就是開發新功能是要能使之方便地開啓／關閉，能夠很好應對突發事故。

5. 統一的度量標準

   • 開發人員能夠看到運維狀況（CPU/網絡等狀況）

6. 即時聊天工具／機器人

   • 遠程辦公
   • 開發／運維／機器人能夠進行有情景地溝通，更好傳達信息

文化

• 不要有偏見
• 尊重他人的工做／觀點／技能
• 別隱藏東西

開發對運維說對代碼的影響：

• 什麼標註（CPU/網絡...）會更改，怎麼改？
• 風險是什麼？
• 事情變糟糕的跡象時啥？
• 突發事件時啥？

信任

• 運維應該信任開發，邀其討論需求
• 開發應該信任運維，與之討論基礎變動
• 每一個人都應該相信其餘人都在爲工做努力

正確面對失敗

若是你認爲你能夠避免失敗，你就失去了鍛鍊應對失敗的能力。