一千萬個為什麽

搜索

人員配備不足的DevOps團隊有什麽跡象?



DevOps團隊人員配備不足的典型跡象和信號是什麽?你如何證明/解釋一個團隊新增加的請求?


我很想保持這個問題的通用性,但這裏有一些額外的信息:

我們目前有兩名DevOps專家作為一個團隊一起工作,但產品的需求,數量和復雜性正在不斷增長。我們正在考慮向團隊申請一個新成員,但在解釋和證明為什麽這將是一個好主意時遇到一些困難。

轉載註明原文: 人員配備不足的DevOps團隊有什麽跡象?

一共有 6 個回答:

Background: Besides for providing support to our current infrastructure and to our Developers, we do monthly planning as a DevOps team for what we want to accomplish on top of helping dev teams within sprints and new projects that are launched. However, during the month we often notice extra things that need to be done and improved, which we then add to our backlog. We also are responsible and assist with various other things that fall beyond our scope, but we assist the business were we can :)

Answer: As soon as you notice you are not getting round to or postponing lots of tasks especially maintenance, I think that is a good indicator(from what I have experienced). Also, the more new projects and dev teams that come in the thinner the DevOps team gets spread, the more people you will need.

它的超級簡單只是在日常工作中完成任務,但我相信它的超級重要性(甚至每月一次)退後一步並評估這一點。

有四個主要原因可以讓你感覺你的團隊人手不足:

  1. 組織和工作計劃不佳
  2. 做別人的工作應該是
  3. 完成不應該完成的工作
  4. 實際上人手不足

首先回顧前三點。閱讀鳳凰項目,了解如何做第一個想法。如果你應該完成這項任務,或者你應該簡單地讓任何需要它的人自己來完成任務,那麽就問你自己幫助任何人的每一項任務。這會給你一些文件說明為什麽你所做的所有工作都是必要的。

接下來回顧鳳凰城項目中提到的四類工作:

  1. Business Projects - what you do for other teams in the organization
  2. Internal Projects - what you do to make your work easier in future
  3. Scheduled Maintenance - what you do to keep the lights on
  4. Unplanned Interrupts - what you do because something went wrong

如果你的團隊的工作是可持續的,你將花費大約相同的時間在四個人中的每一個上。如果計劃外工作開始接近50%的時間,這是一個你肯定人手不足的跡象。

你應該可以聘請一個人,在計劃外工作的時間達到你的時間的25%,否則,一個人離開會讓你的整個團隊陷入一個永遠無法恢復的困境。人員和技術的過度配置有相同的原因和好處。

我實際上從SRE手冊中選擇了一頁,我認為這非常相關。 DevOps專業不打算與組織一起水平增長。相反,如果你發現事情沒有完成,那麽這是一個信號,你沒有正確授權開發人員進行自助服務。

評估您的流程並了解它們如何與通用DevOps原則保持一致,以及您遵循行業最佳實踐的情況。

我假設這兩個團隊正在從項目到項目,並在那裏建立DevOps的東西(創建CI/CD管道,支持其他開發人員創建Docker文件或任何您使用的技術)。換句話說,按照 http://web.devopstopologies.com/

在這種情況下,這兩個人的短缺跡象就是太多的工作量。太多的項目要求他們的服務;票太多了;隨著時間的推移;壓力,倦怠。這些因素應該足以讓負責任的領導層增加更多的能力。我沒有看到DevOps特定的標誌,它只是一個功能不足的功能。

另一個改變現象的標誌是,如果你認真對待,並且你註意到你正在創建一個“DevOps筒倉”,其中所有DevOps專有技術都集中在這兩個家夥/這兩個人正在“做DevOps”。這不是DevOps的要點。如果是這樣,請考慮文化方面,並將其修改為其他團隊的更多傳道者/教師/教練。

在這兩種情況下,為什麽首先有DevOps是一件好事(一般好東西)的深層原因應該對高層管理者清楚。如果你不能傳達這個信息,那麽把你的團隊正在做的工作減少到正常的Devs/Ops(反正應該是這樣)。

我的印象是DevSecOps是一個心態,而不是一個團隊 - 如果你有一個Dev(Sec)Ops團隊,“你做錯了......我試圖圍繞著把兩個”DevOps Engineers“並稱他們為“DevOps團隊”。

We have development teams, SCM, Application Security and Systems Engineers all working in tandem for a rapid deployment/release model for pushing code and configuration/system changes through to a given end point - either staging or production

這與任何“devOps”工程師都沒有關系。

任務分組

我們過去在類似情況下使用的方法是,將團隊的工作組織在4個主要任務組中,並分配相當於2個FTE(全職等效)的人員(嘗試)來完成這些任務。在我們的案例中,它涉及在大型機環境中運行SCM幫助臺,大約300名開發人員要求這兩個FTE提供各種幫助/幹預。這些任務分為4個可能的優先事項:

  • 優先級1和2的任務 必須 完成(無任何借口/協商可能)
  • 優先級3任務將盡快完成“ ”。
  • 如果 時間允許“,則優先級4任務將完成” “。

請繼續閱讀關於這四組中每組任務的更多細節......

任務描述

優先級1 - 操作幫助臺

  • 由易於訪問且始終可用的專家提供。
  • 營業時間內通過電話,電子郵件或票務系統。
  • 符合預定義的SLA。
  • 定期報告所有呼叫的所有幫助臺呼叫的基於ITIL的註冊。
  • 針對關鍵問題應用緊急自定義(變通辦法)。

優先級2 - 值班服務

  • 24小時/每天7天/每周隨時可用。
  • 符合預定義的SLA。
  • 報告所有值班電話。
  • 需要時進行管理升級。

優先事項3 - 日常維護

  • 管理。
  • 申請登機。
  • 家政。
  • 性能增強。
  • 空間管理。
  • 調整資源消耗。
  • 建議增強自定義功能,以減少幫助臺呼叫次數和/或監視值勤幹預。

優先級4 - 修復和增強

  • 創建和維護用戶文檔。
  • 新定制的質量檢查。
  • 開發和實施增強請求。
  • 參與DRP測試。

評估

如果您使用上述方法,各種事情可能(將!)開始發生:

  • 如果團隊人手不足,可能大部分時間都將進入優先級1和2任務,而優先級3任務可能需要一段時間...優先級4任務可能會遭受饑餓(似乎永遠不會是時候完成這些任務)。
  • 在優先級4任務中有更多的時間可用於“投資”,優先級1和2任務所需的時間將會減少,以至於更多的時間2個FTE的可用預算)可以被投資於優先級4任務。
  • 一段時間以後,您會驚奇地發現,優先級1和優先級2的任務數量會下降。如果你對這些任務做了充分的報告,這是管理層喜歡聽到的。在我們的案例中,這個數字從大約300個月下降到100個/月以下......
  • 然而,如果2個FTE似乎永遠(或幾乎)沒有時間優先執行4項任務,那麽您對管理層有完美的解釋和證明......您人員配備不足。