從歷史上看,運營(運營)和開發人員之間一直存在著自然的緊張關係。 Ops 的使命是保持系統穩定和運行。 對於大多數系統,如果系統沒有變化,它往往會像過去那樣。 然而,開發人員通常被激勵來增加系統的使用,這意味著,無論好壞,更多的功能。 新功能導致系統快速變化,系統引入了某種程度的不穩定性和風險。 這些相反的激勵機制在兩支球隊之間造成了巨大的緊張。這將導致操作刪除對計算機的訪問,從而自由執行任何與操作相關的操作。 這結束了組織內的微服務等新想法,因為始終需要基礎結構來建立新服務,而新基礎結構需要與其他團隊進行深入協作。 這種緊張情緒不好,在工程團隊中造成了一個分裂,導致由於兩個團隊拒絕互相説明而沒有取得任何進展。這不僅會損害工作效率,而且最終會損害員工的幸福,他們將開始離開。 如果我在擔任工程領導者期間學到了什麼,那就是:如果你想讓員工滿意,你必須確保他們富有成效。 快樂意味著與其他工程團隊相處,將文化與創造分裂文化統一起來。

"強大的力量帶來巨大的責任"

作為一個團隊,我們都負責我們投入生產的軟體,而不僅僅是操作或開發人員。 這意味著我們必須創建一個集中結構,為運營和開發人員提供一個共同目標。 Devops對不同的人有很多意義,但對我們 ShareThis 這意味著運營、開發和 QA 的功能領域之間有很高的重疊。 因此,為了讓開發人員獲得對生產進行更改的權力,他們必須對其行為負責。 這就是為什麼我們認為,如果出現問題,開發人員必須進行呼叫輪換。 當開發人員的代碼導致意外問題時,他們應體驗到被提醒的原因。這分擔了在團隊全部下班時間解決問題的責任,而不是僅僅在運營或單個團隊的肩上解決問題。

SLA 與 SLA 津貼

最重要的活動之一是為服務定義 SLA。 這定義了系統中對客戶、開發人員和操作的穩定性的期望。 但目標絕不應該是100%的上線時間,因為這可能意味著你行動太慢,沒有承擔足夠的風險。 初創公司就是承擔計算的風險和快速移動。 至於更可量化的風險,我們使用SLA津貼。 我們可以通過採用 SLA 減去 1 來計算我們的風險承受能力。 因此,如果您有 99.9% 的 SLA Uptime,我們可以按以下 1 = 0.999 = .001 計算 SLA 津貼,這是我們的 SLA 限額。 這意味著在您使用商定的停機時間之前,網站可以有 4300 萬次停機時間。 通過這樣做,開發人員可以根據需要部署,只要他們沒有達到 SLA 允許。 一旦它們完成,就可以部署任何新功能,而團隊應專注於穩定性。 這強調自動測試和監視,以驗證其應用程式不會在生產中引起問題。 這也在速度和風險承受能力之間保持健康平衡,可以事先達成一致。 在整個辦公室中,我們正在構建儀錶板,這些儀錶板可以快速顯示任何異常,以便我們可以在導致 SLA 衝突之前還原任何更改。

結果

自從我們從事"DevOps"文化以來,我們看到了團隊之間協作的顯著提升,以及生產率的提高。 從開發到生產的應用程式的總擁有權已經擴展到整個團隊,我們現在能夠在幾秒鐘內和幾周內啟動伺服器和基礎架構。 對於我們的客戶來說,這意味著新的功能和服務的穩定性。 對於我們的內部利益相關者來說,這意味著可預測的時程表。最重要的是,對於我們的團隊來說,這些變化給他們一種主人翁感和生產力。

如果這種類型的工作環境是您感興趣的,請造訪我們的機會頁面:
https://sharethis.com/careers/