statsdpython

⑴ python-statsd怎麼安裝

使用槐改猛statsd發送的數據，例如上面的變數hello是在stats 和stats_count路徑下面。
假殲掘如你定義了local.random.diceroll這樣一個變數，並且不使用statsd發送，那麼它會鉛橋產生再根目錄下。echo "local.random.diceroll 4 `date +%s`" | nc ${SERVER} ${PORT};

⑵ 如何打造團隊的工程師文化

打造團隊的工程師文化需要做好10件事：
1. 優化迭代速度。快速迭代的速度提高了工作積極性和興奮度。一些工程師在面試時對他們為什麼要離開公司列舉了最常見的令人沮喪的原因是基礎設施和繁冗流程阻礙他們部署代碼或者上線功能。在組織上，快速迭代意味著給工程師和設計師的靈活性和不設限自主做日常決策。我在谷歌，任何用戶可見的搜索結果改變，即使是低流量的實驗，需要瑪麗莎梅耶在 每周 UI 審查批准。雖然這允許谷歌保護它的搜索的品牌，但它明顯阻礙創新。優化迭代速度也意味著，有明確定義的流程推出產品，而不會說花了大量時間投入後意外發 生。

優化迭代速度意味著建立持續部署以快速驗證，提高測試覆蓋率，減少構建和網站當機次數，快速單元測試，並鼓勵大家來運行，快速增量編譯 和重新載入，以縮短開斗滑滲發時間。持續部署，提交馬上到線上特別重要。 迭代速度至少在小工程隊利大於弊（線上出錯的風險）。人們更興奮看到功能和修復 Bug 是因為很快看到實時流量變化。這要比超過一周或成批的代碼提交，要更容易推斷和精確定位錯誤源的位置。
團隊智慧，快速迭代的速度意 味著有強有力的領導者，幫助協調和推動團隊的工作。在決定關鍵點上負責人需要有效地作出決定，並承諾他們的選擇。借用比爾 · 沃爾什，一個領導 49 人隊 3 次進超級碗的空脊一句話，強有力的領導者需要 「承諾，引爆，恢復」，這意味著承諾攻擊計劃，執行它，然後看反應結果。優柔寡斷團隊只會導致個人努力白費。
2. 盡量自動化。
在技術講座 「規模化 Instagram」，Instagram 的聯合創始人邁克 · 克里格引 「優化最少的操作負擔」 作為一個重要的教訓，領導他的 13 人團隊用戶增長到幾千萬。 產品的增長意味每工程師的操作負擔加重，如用戶跟工程師或者特定功能跟工程師的比率。 像 Facebook 號稱每個工程師支持超過 100 萬的用戶比例指標。
自動化解決方案和腳本去重復執行任務很重要，因為它們解放工程團隊，讓他們為實際產品工作。確保如有失敗服務自動重啟和方便快捷在流量高峰期替代是在管理大而復雜產品的明智方案。在短期內可以對應用做快速修復，而長期還是要依賴自動化測試，這需要權衡。
Etsy 的的座右銘 「衡量所有，衡量一切」。支持像開源監控和制圖工具 graphite 和 statsd 突出自動化 – 即自動化必須由數據和監控驅動。如果沒有監控和日誌你怎麼知道什麼事情錯了，為什麼錯。自動化是困難的。一個後續的座右銘是 「衡量所有，衡量一切，並盡可能自動化。」
3. 建立合理的軟體抽象。
我的麻省理工學院教授和本科生研究顧問丹尼爾 · 傑克遜說的軟體抽象的重要性：
「選擇正確的方式，程序化自然而然地設計; 模塊化就是有小而簡單的界面; 新功能在不影響全局的情況下產生。要是搞錯的話，程序將是一系列的討厭的坑：介面很笨拙因為他們無法適應一些意料之外的交互，即使是最簡單的改動將是很讓碼難維護 「。
是什麼在谷歌讓數千名工程師建立可擴展的系統，是因為他們有非常聰明的工程師像傑夫 · 迪恩和桑傑 · 格瑪沃特創建了簡單，但豐富的抽象，如 MapRece 的，SSTable，Protocol Buffer 等。是什麼讓 Facebook 工程這么支持大規模，是因為專注於核心，同樣喜歡抽象和簡單，Thrift, Scribe, Hive。是什麼讓設計人員能夠有效構建產品，Webnode，Livenode 也是基於同樣的理解。
保持核心抽象的簡單和減少自定義解 決方案，並增加團隊熟悉度和對專業知識的抽象。日益普及系統像 Memcached，Redis，MongoDB 等系統都是降低建立定製存儲和緩存系統的必要。團隊重點轉移到少數核心抽象，而不是分裂在很多臨時解決方案，讓公共庫更穩健，監控更智能，性能更易理解， 測試更全面。所有這一切都有助於搭建一個簡單的系統，降低操作負擔。
4. 注重代碼審查，編寫高代碼質量。
維持高品質的代碼庫增加了整個工程團隊的工作效率。清潔代碼更容易便捷發展和維護，更適應變化，不容易引入錯誤。健康的代碼審查過程使之成為可能。
建立及時代碼審查流程，不管是預提交或提交後，能有幾種方法的提高代碼質量。首先，知道有人會檢查你的代碼，提交寫得不好的代碼可能會辜負你的隊友。那些難以維護，或未經測試的代碼是一種壓力。第二，代碼審查也提供了評審和相互學習編寫更好代碼的機會。
代碼審查更容易接觸到其他工程團隊成員，評論也帶動了 a）增進一段時間內審查代碼的責任感 b）允許團隊成員 – 特別新手 – 觀摩別人的好代碼，c）加快最佳編碼實踐的傳播。
有種說法，靈活的團隊沒多少時間花費在代碼審查而忽視了技術債務，可以很容易地從寫得不好的代碼積累。 在創業早期就為了完成盡可能多的功能而忽略代碼審查; 其結果是，雖然最初的產品更迅速地擁有了市場，但代碼變得修改痛苦，我們花了一年多時間僅僅是改寫脆弱的代碼，以償還技術債務。
谷歌預先進 行審查所有的代碼，但規模較小的團隊並不需要那麼全面和嚴格，因為不是所有的代碼需要使用相同的標准審查。 公司後來採用後提交的評論通過電子郵件通知核心處危險的變化。我們用 Phabricator 對所有的代碼審查，大多後提交，並採用了不同的標准模型，比如控制器代碼和視圖代碼; 對於敏感的代碼或新工程師的代碼，我們要麼做預提交的評論或試圖在幾個小時被提交的代碼中查看它們。
5. 保持一個尊重的工作環境。
同事之間的尊重構成開放交流的基礎。靠譜的想法獲得往往通過大家辯論，這種挑戰也是感覺很舒服的方式。人們不爽的是重要反饋沒有及時回應。
1948 年，亞歷克斯 · 奧斯本概述了在過去的幾十年中在工作環境中流行方法，參與者走到一起，拋開批評和負面的反饋，共同凝聚在一起不用擔心被評判，頭腦風暴會議。最近的心理學 研究已經開始推翻奧斯本的做法，表明在頭腦風暴會議，鼓勵辯論實際上避免群體思維並產生更有效的思路。鑒於這一研究，一個尊重環境變得更加重要使得攻擊僅 僅是觀點而不是個人。
工程往往跨越廣泛的領域（系統，機器學習，產品等），而不是每個人都有相同的專業知識在每個領域。其實是一個強大的團 隊應該具備，在某些領域都有能乾的牛人，即使他們最終會被替代。這有時很麻煩，讓一個系統工程師來評估產品工程師的能力，但在一個健康的工程師文化中尊重 這些差異很重要，並不是完全根據自己的優勢來判斷。
6. 建立共享代碼所有權。
雖然有些人自然就成為精通代碼庫或基礎設施的各個部分，但沒有一個人應該覺得他們擁有或任何一件的唯一維護者。雖然有個人一年以上能在一些領域成為專家，在短期內有成效，這種做法最終傷害長期利益。
在組織上，共享的代碼所有權提供了三個好處。首先，保持因子 8 大於 1 可以減輕壓力和降低團隊維護者離開的風險。這也使人很難在休息時間無憂。我清楚記得，當我夏威夷火山上徒步旅行度假時候，得到報警，因為我是公司的日誌處理器的唯一維護者。
其次，共享所有權讓工程師不限制在特定區域，以促進新的見解。它讓工程師們從他們被困在某些項目上離開，並鼓勵他在多樣性項目上工作，這有助於保持工作有趣性，並提升員工學習積極性。從長遠來看，它降低組織風險，一些工程師感到停滯就會決定離開。
第三，共享所有權還設置了有多個團隊成員（從敏捷開發的一種技術）一起在一個高優先順序的問題，必要時更迅速地完成戰略目標奠定了基礎。而孤立的所有權，負擔通常落在一兩個人。
很多工程組織犯的錯誤是為時過早將整個團隊分成子團隊。子團隊會形成責任的阻礙，並很難去打破所有權的牆，因為個人可能會被其子團隊的目標進行評估。 有很多小團隊，我很珍惜與一些其他團隊的工作機會; 他們使用敏捷開發，重心放在共享代碼所有權，使得工作幸福感和生產力更佳。 初期我喜歡的一個方面是更強調項目而不是團隊，讓我有機會合作的項目從用戶增長，機器學習，工具，推薦，分析，網站的速度，和垃圾檢測。
7. 投資自動化測試。
單元測試和集成測試覆蓋率是管理一個大的代碼庫與一大群人沒有不斷被破壞構建或產品的唯一可擴展的方式。自動化測試提供了對提高代碼質量的大規模重構的信心 和也進行有意義的保護。缺乏嚴格的自動化測試，需要手動測試無論是對工程團隊或外包測試團隊，是容易令人害怕的，很容易陷入恐懼改善代碼的文化，只是因為 它有可能破壞以前的。
在實踐中，自動化測試是對持續部署工作團隊成長的要求。代碼庫規模隨著時間的推移增長，但熟悉的代碼庫多少會隨團隊成 員新人加入而減少。測試和驗證是最容易被原代碼作者完成，因為在他們腦子里還是清晰的，而不是被稍後幾個月或幾年嘗試修改代碼的人。鼓勵單元測試是讓作者 為自己工作責任。
8. 分配 20％的時間。
Gmail 是保羅 · 布赫海特的 20％的項目，第一個版本在一天搞定。 谷歌新聞，谷歌公交，和谷歌建議也是推出的 20％的項目。我用 20％的時間，而在谷歌寫一個 Python 框架，使得它更容易建立搜索頁面演示。而谷歌的 20％的時間在創業初期可能降低生產力，讓工程師們花 20％的時間做某件事情而不是他們的產品規劃上，仍然是小型工程組織的創新搖籃。
Ooyala 公司沒有正式 20％的時間，我們花了一些時間寫了一個命令行構建工具 Flex 和 ActionScript，加快了團隊構建時間。正當 Adobe 的 Flex Builder 工具降級時候我完成了它，在工程團隊超過兩倍大小時該工具仍然在使用。 Atlassian 公司在嘗試一年後通過 20％的時間。Facebook 後來又增加了一個 20% 時間的變化是周期性的黑客比賽 – 一晚上的事件，規則是，你可以做任何東西，除了你的正常項目的工作。
自上而下的方法對產品的規劃，對公司的總體方向是重要的，不能指望從工程師中冒出很多的想法。只要工程師對他們 20％的時間和專注於什麼可以有很大影響的負責，這些項目可能會導致很大的向前發展。沒有官方的 20％的時間，它仍然是可能的，對工程師和設計師可能更難去嘗試瘋狂的想法 – 基本上都找周末或假期做。
9. 建立學習和持續改進的文化。
學習和得到充分得到挑戰是心理學教授米哈里 · 米哈伊稱之為 「流」，一個人是如此的完全集中在他們做的事情，他們甚至忘了時間。 直接即時的反饋能夠適應更快的迭代周期。
每周技術會議給工程師分享他們的設計或者正工作的項目，創造了一個機會，工程師們為他們工作感到自豪，並學到更多工作以外的范疇。內部文檔記錄電子郵件服務的工作原理或如何讓排名改變搜索服務，讓工程師學習和探索新的東西，也很好地補充了 20％的時間。
建設學習文化的一個辦法是注重指導和培訓，以確保每個人都掌握基本的演算法，系統和產品成功所必需的技能。工程組織的成長，花在招聘（尤其是高校招聘）越多， 更多的努力需要投入到指導和培訓。一個導師每天花一個小時為一個新員工的前 4 周工作上似乎是很大負擔，但投資是總時間的新員工將在一年內花費不到 1％，並能幫助到此人是否真正成功。
10. 招最好的人。
僱傭最好的人是許多其他列出的 基礎。如果你認為自己是一個 B 級工程師很難有人尊重。如果你不信任他們開發產品能力，很難給別人自主權去開發產品。如果沒有足夠的工程經驗，很難識別正確的抽象去構建系統。這很容易陷 入構建復雜結構的陷阱，又沒有其他聰明人來挑戰你的想法和推動你走向簡單正確的道路。
在矽谷的史蒂夫 · 喬布斯說，「A 等人聘請 A 等隊員。 B 等人聘請 C 等人。「關注招聘和僱傭合適的人很難，但這對工程組織有效增長很關鍵。黃易山，是前 Facebook 一個工程經理和總監，認為招聘必須是工程組織的首要任務，不只是管理者，工程師也如此。 他也正確地指出 「僱傭最好的」 和 「僱用你面試過的最佳人選」 的區別
在初期，我們在客戶工作上不堪重負，我們很想降低我們的招聘門檻，這樣我們可以聘請足夠的人來做大量工作。我很高興我們沒有，因為低質量的代碼和較弱的工程師團隊積累技術債對團隊和產品的傷害是很大的。
建立一個良好的工程文化無疑是一個大量的工作，但由此產生的工作環境是值得的。