一千萬個為什麽

搜索

我如何說服團隊中的開發人員接受“你創建它,你運行它”?



我如何說服團隊中的開發人員接受“你創建它,你運行它”?因此,我記住了 Werner Vogels的這句話

給開發者的運營責任大大增強   服務質量,無論是來自客戶還是技術   觀點看法。傳統的模式是你把你的軟件帶到   將開發和運營分開的墻壁,並將其扔掉   然後忘掉它。不在亞馬遜。你建立它,你運行它。   這會使開發人員與日常的日常操作聯系起來   他們的軟件。它也使他們與日常的日常接觸   顧客。這個客戶反饋回路對於改善這個問題至關重要   服務的質量。

我特別想到一組開發人員:

  • 被聘用為開發人員角色,很少/沒有提及與操作相關的任務。
  • 傳統上,“將代碼扔在墻上”給操作團隊。
  • 傳統上有9-5個工作日程安排,並且積極敵視“尋呼機責任”的想法,在正常工作時間以外參與災難恢復,編寫死後等,尤其是 。 (註意:我只考慮過非常罕見的中斷事件;我並不建議我們為此團隊的工作量增加非工作時間的客戶支持。)
  • 目前不負責編寫/支持他們的應用程序的監控或提醒。

假設有一個團隊正在快速開發新的雲微服務,其個人資料越來越多,將這些服務交付給運營團隊是次優的,因為他們無法跟上獲得深入的知識有效管理和監控它們所需的服務。 “你建立它,你運行它”對於這個團隊來說會更好,因為任務可以委派給每個負責任的團隊成員。因此,該團隊將開始參與設計基礎設施,監控/提醒服務工具,並且(非常少)響應停機事件。

我特別感興趣的方法,由現實世界的例子支持。這是如何在其他工作場所成功實施的,以及在實施這個過程中是否遵循任何規範步驟?任何可以支持答案的鏈接都是非常有用的。

轉載註明原文: 我如何說服團隊中的開發人員接受“你創建它,你運行它”?

一共有 6 個回答:

我認為最簡單的方法是改變他們的性能目標,以便他們基於可靠性以及交付代碼。如果沒有這兩家公司就無法成功出售它,那麽為什麽開發商只能衡量一個呢?那麽他們實現績效目標的最好方式就是參與運營。

最終,你需要說服他們這是公司取得成功的最好方式,因此也是他們取得成功的最好方式。這很難,你不能指望他們從一開始就在船上。他們也需要以價值出售。

談到影響商業文化,最好的辦法可能是通過著名的“煮青蛙”方法。你必須慢慢向開發人員介紹這些任務,因為我知道我自己(作為開發人員)會不敢馬上承擔所有這些新責任。

首先,引入一個或兩個新任務,僅在正常工作時間執行。他們需要學習如何做devops,這可能是一個(到目前為止)代碼開發的學習過程,可能需要一些監督。他們也可能會對改變他們的工作與生活平衡的想法抱有敵意,因為你提到他們習慣於9-5。此時,將數據記錄在新流程中供以後使用(讓他們編寫此代碼,數據始終有用)。

之後,當您要完成新的devops-y任務(因此第一個,第二個和第四個要點幾乎完成)時,請將您引入的第一個任務作為候選人在標準工作時間之外執行。你可能會在這方面看到一些反應,你甚至可能會看到一些消耗,這取決於你對此有多強烈,以及五年期工作文化的根深蒂固。為了防止這種情況發生,希望您的數據能夠支持超出標準時間的工作很少發生的想法,只有在極端情況下才會發生,並且會對業務和客戶都大有裨益。如果你的數據不支持這一點,那麽你最好準備好處理這個選擇的後果。

即使有了數據,讓開發人員編寫監控/警報代碼(以便他們成為開發工程師,但仍主要是開發人員)仍然可能更容易,並將備用操作團隊保留為一線支持(如還有一些人建議)。就像我說的那樣,小的改變對於避免反彈很重要。將開發人員的工作集成到標準時間以外將是一項挑戰,因為他們可能知道,如果他們不喜歡,他們可以在別處尋找工作,因為現在開發人員的市場很強大,特別是如果他們已經具備開發人員技能。買者自負!

恕我直言你建立它,你運行它不應該從字面上。開始 - 這聽起來像是一種懲罰;)

任何單個人或甚至小型開發人員團隊都不能合理地支持長時間在軟件開發過程中使用的工具或工具集(即在生產中!)。去過也做過 :)

隨著工具(集合)客戶群的增長,支持職責也隨之擴大。如果完全承擔這些責任,開發團隊最終可能會得到大部分支持,很少/沒有時間留在發展中。實際上是一個死胡同 - 有多少開發人員想在這樣的環境中堅持下去?

擁有一支專業的第一線支持團隊對於防止挫折,壓力和其他長期暴露於支持開發人員團隊成員責任的其他影響至關重要。

當然,第一線支持團隊將回退給開發團隊(再次,團隊,而不是單人!),以解決他們無法直接覆蓋的問題。是的,起初可能很困難,但事情會變得更好。它應該是一種協作 - 這是DevOps的一部分。

特別是在DevOps之外,如果您正在討論大型(ish)企業環境,那麽 SAFe 方法有一個很好的方式來鼓勵這種行為。

基本上它歸結為幾個關鍵階段:

  • 項目以發布版本開始。意圖(以及對誰資助它的期望)是它會長期運行。我說了多年,沒有一個“站起來3個月,然後站起來”的業務。

  • 在項目過程中,基於新實現的商業機會以及持續的維護風格工作稅,發布培訓將不可避免地吸引更多的人,因為更多的新項目需求都是基於新實現的商業機會。

  • 我幾乎總能看到列車以第一個增量運行100%項目/變更團隊,第二個增量為運行工作分配一定的時間百分比。第三次增量管理意識到他們即將遇到問題,並開始增加團隊來嘗試和處理Run Run,以便他們現在經驗豐富的開發人員和工程師有時間繼續處理新的需求。

  • 如果項目團隊能夠保持合適的平衡,並且能夠繼續提供項目成果而不會因維護工作而陷入困境,並且新加入火車隊的團隊不會立即預期為100%支持團隊,而是承擔將要處理的變更工作的一小部分,然後您最終得到的交付團隊擁有他們正在默認構建的產品,而不需要立即將它們全部交給他們他們是一個運行團隊,相反,它只是慢慢融入他們的日常活動中。

這種模式明顯存在一些缺陷的地方在於企業的定價。一般而言,我希望為變更資源支付的資金要多於運行資源,通常與主要供應商簽訂的合同是固定價格,意圖是他們通過持續改進賺錢,從而節省成本。

這就是說,要想把變革團隊作為發布培訓的一部分來站穩腳跟,並不是一件難事,而只是為了實現持續的改進。如果他們能夠建立或者做某些事情,這會提高他們關註新項目交付的能力,並且不太關心“一切照常”的工作,那麽就應該積壓並優先考慮誰持有這些資金發布火車。

這最終取決於公司的規模和結構。貴公司真的有三個階段:

  1. 啟動階段(150名工程師以下)。當然,開發人員需要運行自己的軟件。每個人都在創業公司這樣做。你甚至可能沒有開始的操作團隊,但即使你這樣做,它也很小,而且進度非常快,所以沒有辦法將所需的知識足夠快地傳遞給另一個團隊,以便他們取得成功。

  2. 中型企業(超過150名工程師,但只有一個運營團隊)。在這個階段,公司的流失率開始變得過高,建立軟件的工程師們也不一定要堅持來運行它。你不再了解每個人,並且很難有效地與每個人進行交流。它會開始變得混亂。在這個階段,您需要轉向Google模型,每個團隊都必須運行他們的軟件,但不一定要操作它。他們將在一開始就運行它,但構建軟件的一大部分是將運行成本降低到某一點,其中負載足夠小,以便運營團隊可以簽署運行它。只有這樣才算完成。具有多個業務部門的大型企業(每個部門都有自己的運營團隊):在這個階段,您可以轉向亞馬遜模式,每個團隊都必須開發和運營自己的服務。每個業務部門都必須足夠小,以便每個人都可以彼此了解,因此大約有150名工程師和您在實質上作為一家初創公司運營。亞馬遜每個AWS服務都或多或少地分開運行,並且適用於他們。

你必須弄清楚你的公司在哪個階段和/或進入並采取相應行動。沒有“一刀切”的解決方案。

我承認這一點(如果我面對這樣的指責,或者任何你會稱之為的話),就像“ 你會期望什麽?”!?! </強>”。因為,意外:

  • 如果沒有它,我甚至無法生存,並且
  • 我喜歡吃我自己的(狗)食物。

讓我進一步解釋一下......

My business/hobby/passion is , more specifically in environments. And wherever I go (to finetune stuff to fit the customers needs), the very first requirement the I impose (in my contract), is that any tuning done to the system we implement, is via that very same system. And by doing so (true, that takes like a few hours, say half a day at max), we get these benefits from it (incomplete list):

  • 幾乎沒有文件記錄我為了讓系統進行而做的任何事情。如果有任何問題要問,我只需查詢系統(並教導客戶如何在沒有我的幫助的情況下查詢系統)。
  • 如果我在X個月/年內接到電話(升級到新版本?),我想知道(記住)之前做過什麽“我”(我唯一信任的是系統告訴我,又叫我想起)
  • 我只需要問客戶一次關於如何在他們的網站做特定的事情(命名約定很難記住),或者說服他們授予必要的權限給“系統”(而不是我......)
  • 您持續 質量檢查 - 在生產環境中測試您自己的系統。你可能會遇到錯誤,邏輯錯誤或缺少的功能(以及不是)。這些都極其激勵他們盡快解決問題......例如提高工作效率。
  • ...如果您想要,我可以添加其他幾十個理由...

但是,在您自己嘗試在家之前,請註意避免一些缺陷:

  • 你希望 everyone 加入派對(使用系統),因為只有1個“例外”(也就是公司的經理/所有者?)可能會毀掉派對(你會認為你可以信任你的系統,但是有人在沒有詢問/使用系統的情況下做了些什麽)。這些情況可能會花費你幾天的時間來發現......
  • 新用戶可能會抱怨說,通過使用這個(新的)系統,他們需要更長的時間才能完成工作(與以前使用的任何工具相比)。無論哪裏合理,他們都會以此為借口,說明他們為什麽遲遲不能完成工作。在那個時候,你最好有高層管理人員來覆蓋你,否則你的項目/系統可能會受到指責。
  • 確保你知道你自己的系統,以及如何配置它以適應你的需求。作為一個例子(在我的情況下):你想配置系統,以便使用操作環境交付給你的實驗環境,而不是其他方式......我已經看到過去發生的事情......使用(濫用)測試系統交付給高度安全的環境。