一千萬個為什麽

搜索

DevOps部署前指標面臨挑戰



TL; DR,你如何證明devops,特別是部署自動化,提高了更改失敗率?

我們都試圖使用 current (主要是手動)方法來捕獲有關“部署失敗”的指標。不幸的是,“失敗”很少發生,對吧?因為當出現問題時,團隊會聚集在一起(通常用英雄)來解決問題(通常是權限,錯過配置,您知道鉆取)。所以......當我們問到部署如何進行時,答案就是“它有效”。

但是,直覺上我們都知道這並不好。 2017年devops報告顯示,大約有31-45%的“更改失敗率”。“雖然這聽起來很正確,但他們是否被視為事件?羅。因為他們很快得到修復,通常在驗證過程中。實際回滾部署更為罕見。

所以,需要準確地報告失敗率。我們被這樣報告,因為我們希望事情能夠發揮作用,並且我們會盡一切努力實現目標。

那麽,您如何證明devops,特別是部署自動化,可以改善更改失敗率?

(PS試圖用“#devops-capability-model”來標記)

轉載註明原文: DevOps部署前指標面臨挑戰

一共有 2 個回答:

我們過去在類似情況下使用的技術是獲得“管理承諾”,將這些規則強加給每個團隊成員:

  1. 對目標部署區域(即生產)執行更新的權限僅限於選定的自動化系統,它們對其管理的區域進行任何類型的更新都有適當的審計跟蹤(=記錄)。

  2. 無論出於何種原因,手動更新目標部署區域不再允許典型的團隊成員(用戶id)過去可以(授權)執行這些更新。相反,將會創建新的(額外的)用戶ID,其將具有所有必要的權限(仍然)在需要時執行這種手動更新。但要真正能夠使用這些新的用戶ID(=與他們一起登錄),想要使用這種新用戶ID執行登錄的團隊成員必須執行“一些”額外步驟才能訪問密碼這樣的新用戶ID。理想情況下,這個額外的步驟也是自動化的(使用你自己的想象力應該是什麽樣子),但如果其他任何事情都失敗了:只需聯系(=電子郵件,電話等)所需密碼的守門員,包括“他們有哪些問題得到解決“(類似於你的問題)。
  3. 讓這樣的守門員到位並不是一件容易的事。最大的阻力來自......團隊成員(出於種種原因)。因此,這些新用戶ID的變體(如前一步驟)是每個團隊成員獲得一個額外的用戶ID(用他們自己決定的密碼),但是附加了一個額外的字符串:它們只允許執行如果他們真的有充分的理由這樣做,則使用該(額外)用戶ID登錄。每次他們執行此類登錄時,他們都需要提交一些關於“他們修復了哪個問題”的報告(類似於您的問題)。

有了這些程序,所有剩下要做的就是定期檢查每個報告/為什麽需要使用這種特殊用戶ID的原因,並提出問題“有什麽可以做的,以進一步自動化這是為了進一步減少這種特殊登錄的需求嗎?“。

2017年devops報告顯示,大約有31-45%的“更換失敗率”。雖然這聽起來很正確,但他們是否被視為事件?羅。因為他們很快得到修復,通常在驗證過程中。

一個快速修復的問題仍然是一個問題。如果你不這樣報告,那就是一個問題。

所以,需要準確地報告失敗率。我們因此被禁止舉報,因為我們希望事情能夠發揮作用,並且我們會盡一切努力實現目標。

如果你的目標實際上是讓事情發揮作用,那麽你需要誠實地對待失敗,以便將來可以阻止它們。這聽起來像是這裏的團隊對失敗說謊(或許是對自己,對管理層而言),因為他們的目標是讓事情顯得有效。

這些是不同的事情。例如,拿QA產生bug的老笑話說:“我的代碼在QA獲得所有權之前就沒有問題了,然後他們制造了所有這些bug!”。這些錯誤一直存在,但開發人員對他們一無所知。運營團隊的目標應該是實際的可靠性,並且他們需要通過他們的管理來激勵他們。這意味著,如果他們進行更多的監控,導致發現新問題,他們應該得到獎勵,而不是因隨後的可靠性指標下降而受到懲罰。


TL,DR,你如何證明devops,特別是部署自動化,提高了更改失敗率?

如果你試圖激勵你的組織變革,那麽你不應該試圖證明什麽,而是提供其他組織對自己轉變的看法。如果您試圖測量已經存在的流程並證明其持續存在,那麽您應該跟蹤標準可靠性指標,如平均修復時間(MTTR)。

但是,devops的原則不僅僅是提高可靠性。即使現場可靠性工程不僅僅是提高可靠性。相反,您希望達到適當的可靠性水平 - 這對業務有益但不妨礙開發。這就為devops帶來了真正的動力,這是授權改變。您希望允許業務部門更快地響應市場刺激,這通過降低開發人員的摩擦,提高部署速度,自動化手動流程等來實現,同時保持在可接受的可接受範圍內。這意味著你需要測量可靠性,但你也需要測量速度,因為你的目標是增加後者的速度,同時保持前者相對靜止。