導讀web
本系列文章分爲三個部分，咱們將回顧過去的三年，總結穩定Marathon方面的經驗，與你們分享。編程
首先，在本篇文章我會先從咱們的團隊文化談起，接着會談到咱們的代碼文化和設計。最後，我將描述咱們的測試pipeline，以及回顧和展望。微信
這是咱們過去三年在如何穩定Marathon方面總結的經驗。Marathon是DC/OS中的中央工做負載調度程序。大多數時候，當您在DC/OS上啓動應用程序或服務時，在Apache Mesos上啓動它的是Marathon。Mesos管理計算和存儲資源，Marathon協調工做負載。咱們有時把它稱爲"DC/OS的init.d"。做爲DC/OS不可或缺的一部分，咱們必須確保它能持續運行。請注意，我沒有提到"宕機"。您將在後續的系列文章中瞭解緣由。 網絡
在咱們開始以前，我要感謝團隊成員勤勉工做，感謝咱們的客戶和客戶支持工程師們在Marathon沒有按預期運行時所表現出的耐心。儘管咱們已盡力避免，但在生產中仍然出現了bug。與客戶的電話會議極大的促進了Marathon的穩定性。然而，在本文中，我想探討如何避免出現這些狀況以及如何使它們處理起來更容易。app
關於Marathon穩定的經驗，不得不從咱們的團隊文化談起，接着的文章會談到咱們的代碼文化和設計。第三部分描述的是咱們的測試pipeline。最後，我將以回顧和展望做爲結束。能夠隨意跳過關於團隊和代碼文化的部分。可是，我堅信它們對咱們的技術產生了影響。分佈式
第一部分：團隊文化工具
在過去的幾年中，咱們創建了必定的團隊文化。我想分享四個方面，我認爲這些方面不只影響了咱們的代碼質量，並且幫助咱們成爲卓越的團隊。學習
作最完美的設想測試
咱們始終設想每一個人在工做中都懷着最好的意圖。這種思惟方式避免了沒必要要的衝突，並有助於咱們專一於手頭的技術問題。想一想看。你真的認爲有人故意寫錯代碼嗎，仍是他們或者你故意遺漏了某些信息？咱們經常發現代碼部分或做出變動會在團隊中引發爭議，由於做者、審查員或二者對於咱們想要解決的問題都缺少足夠的信息和理解。認可每一個人都懷着最好的意圖，即想要使產品更好，會打開許多大門。這個想法將我引向了下一個原則。spa
尊重先前的成果
編寫Marathon原始代碼時，個人團隊成員都不在身邊。咱們經常會由於原始代碼出錯和糟糕而想放棄代碼。對咱們來講，深刻研究它並嘗試理解爲何要以這種方式編寫要困可貴多。前一種態度會致使「非我所創綜合症」以及沒必要要的重寫。所以，咱們將重點放在後一種方法上並深刻鑽研。這項艱苦的工做一般會帶來回報，使咱們得到涵蓋原始代碼試圖解決的邊緣狀況的新洞察及代碼改進。
加倍投入，以期成功
前兩個原則讓咱們進一步瞭解Marathon。那咱們如何實現咱們的新洞察？——對它們加倍投入。咱們很早就意思到，發現專一於上次生產失敗或錯過最後期限不只使人沮喪，並且也無助於咱們向前邁進*。正如團隊成員蒂姆（Tim）所說：「這就像去購物時列出了不要購買的東西的清單」。咱們一點也不明智。因此咱們決定把精力集中在有效的東西上，並加倍投入。這個工具幫咱們找到了一個bug？讓咱們改進它並教導支持團隊使用它。這個代碼更改解決了競爭條件？讓咱們花點時間在其餘部分也作些更改。
結對編程和兩個評審員
咱們正在學習，而且咱們加倍投入，以期成功，可是這在平常工做中會是什麼樣子呢？咱們很快發現，創建更多的流程帶來的每每是更大的開銷，因而咱們鼓勵同事們進行結對編程，並強制使用兩個代碼審查員。這是咱們的強制選項，以增長應用咱們所學知識的機會。若是兩個工程師結對解決一個問題，那麼他們已經對代碼更改有了大體的瞭解。審查不過是簡單的籤核。然而，當添加第三方時，他們就會提出問題，例如《童子軍規則》*，他們會指出上週剛剛引入的幫助課程或團隊贊成的模式。我真的很喜歡扮演一個不知情的審查員，並提出一些問題來阻止拉取請求，這讓個人團隊成員很惱火。然而，我堅信個人「爲何」和「如何」有助於改進代碼庫。
*這一原則與Rework中的「Learning from mistakes is overrated（從錯誤中學習）」相似。
*可在馬丁（Martin）的著做《Clean Code》中找到。
點擊「閱讀原文」體驗由穩定的Marathon造就穩定的Mesosphere DC/OS
往期精彩文章
關於D2iQ
點擊「閱讀原文」，體驗Mesosphere DC/OS
本文分享自微信公衆號 - D2iQ（d2iq_apac）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。