【DEVOPS】Devops關鍵實踐

1.DevOps Team的要求：非臨時構造，對小區域負責，全職，跨職能，小的，多樣化的專家，自組織，搭配，對正在使用的工具負責。

2.可視化工作的優點：

發現已經接收的工作

發現潛在存在容量缺乏的領域

哪里的資源已經或即將耗盡

被阻塞的任務

未完成的任務

如果沒有時間完成本迭代接收的所有工作，其中哪些值得嘗試去完成，以便達到最大化有用的結果

3. Kanban創建可以拉動系統：提升工作流，降低故障停滯時間，降低協調的需求

4.關于LWIP(限制在制品)：在制品數量和批量規模應該被限制

幫助構建，拉動系統；促進前置時間估算，促進可視化限制，促進持續識別，明確并消除限制；降低專業人士的工作被打斷，提升由于切換丟失的生成率。降低工作時間重新規劃，資源利用率的惡化。

批量規模：

提升總體總量；惡化流動節奏，提升前置時間，提升缺些數量，減緩假設評估，惡化，產品質量，提升資源利用率

5.DevOps的運維需求：

Devops擴展了產品負責人PO的角色，在整個IT運維系統中，包括功能性的以及非功能性的需求。

建議摒棄非功能性需求這個傳統名字

最主要的關注點從可靠性轉移到可恢復性

6. 識別處理瓶頸的方法：

采用支持LWIP限制的可視化工具，可用來識別價值流中的瓶頸

在所有瓶頸中，關注造成最大延遲的那個。

理解如何改變短期工作規則，已便于最大化用識別出來的瓶頸點

找到消除瓶頸點的辦法，干掉它

撤銷前面建立的短期規則，并尋找下一個顯著瓶頸點。

7.與傳統實踐的差異占考試分數的12.5%

（1）Devops更頻繁的發布（官方Devops書本上的翻譯是發布是日常活動）

傳統實踐：大尺寸，幾天，幾周發布，很多資源，高付出，備份，文檔，手工，時間表

Devops實踐：小尺寸，每周每日發布，有效自用資源，常規付出，自動化，連續

（2）Devops更多地關注增加業務價值（官方Devops書本上的翻譯是發布是由業務決定的。）

傳統IT:版本發布，發布是一組共同部署到生產環境的更改，發布時間，IT決策

Devops實踐：部署，使用用戶完全或部分可用新功能，通過測試后立即部署，商業決策。

（3）Devops更需要自動化（官方Devops書本上的翻譯是一切都是自動化的）

部署流水線的環境由腳本在流水線控制系統的控制下自動創建

這些環境會在使用后自動銷毀，從而釋放資源

流水線的快速操作需要最大可能的測試自動化

流水線的最后部署和分發，也是自動完成，并對系統和應用程序健康進行必要的調整。

（4）Devops處理解決事件和缺陷的方式（官方Devops書本上的翻譯是缺陷立即被修復的）

如果要追溯的最近的部署，Devops流水線控制系統將自動回滾到之前已知穩定狀態。

Devops仍然需要人工干預來分析變化并對變化進行糾正

Devops流水線所有鏈接都是已知的，包括要解決的問題，客戶，開發人員和測試人員。

（5）Devops需要持續改進和保持Devops（官方Devops書本上的翻譯是流程是持續更新的）

Devops建議應立即消除所有確定的過程缺陷。

與可以推遲問題的傳統做法相反，Devops建議盡可能多的重復有問題的步驟

更好的了解如何改進他們，并相應的挑戰工作

8.Devops團隊的理解：

（1）不是一個臨時的項目團隊，是一個長期存在而組建的。

（2）團隊成員是全職工作在團隊中

（3）是跨職能的，意味著團隊應該有能力完成所負責的領域價值流上的工作。DOD完成的定義，理解的唯一方式

（4）團隊不能太大

DevOps

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。