Was sind die Anzeichen für ein unterbesetztes DevOps-Team?

13

Was sind die typischen Anzeichen und Signale dafür, dass ein DevOps-Team unterbesetzt ist? Wie würden Sie eine Anfrage nach einem neuen Mitglied in einem Team begründen / erklären?


Ich würde gerne die generische Frage behalten, aber hier sind einige zusätzliche Informationen:

Wir haben derzeit 2 DevOps-Spezialisten, die als Team zusammenarbeiten, aber die Anforderungen sowie die Menge und Komplexität der Produkte steigen. Wir denken darüber nach, ein neues Mitglied in das Team aufzunehmen, haben aber einige Schwierigkeiten zu erklären und zu beweisen, warum dies eine gute Idee ist.

Alecxe
quelle
Wie viele Entwicklerteams? Wie viele Entwickler hat jedes Team? Die DevOps-Ingenieure sind Teil eines separaten Teams?
030
@ 030 Wir haben wenige Entwicklungsteams mit jeweils etwa 5-10 Mitarbeitern. DevOps ist im Moment ein eigenes "Team", ja. Vielen Dank.
Alecxe

Antworten:

10

Es gibt vier Hauptgründe, warum Sie das Gefühl haben, dass Ihr Team unterbesetzt ist:

  1. Schlechte Organisation und Planung der Arbeit
  2. Arbeiten sollte jemand anderes tun
  3. Arbeiten, die man gar nicht machen sollte
  4. Eigentlich unterbesetzt

Beginnen Sie mit einer Überprüfung der ersten drei Punkte. Lesen Sie im Phoenix-Projekt, wie Sie als Erstes vorgehen können. Fragen Sie sich bei jeder Aufgabe, bei der Sie jemandem helfen, ob sie überhaupt erledigt werden soll und ob Sie es sind, der die Aufgabe erledigen soll oder ob Sie einfach denjenigen ermöglichen sollen, der sie selbst erledigen muss. Auf diese Weise erfahren Sie, warum all Ihre Arbeit notwendig ist.

Überprüfen Sie als nächstes die vier im Phoenix-Projekt erwähnten Arbeitstypen:

  1. Business Projects - was Sie für andere Teams in der Organisation tun
  2. Interne Projekte - was Sie tun, um Ihre Arbeit in Zukunft zu erleichtern
  3. Geplante Wartung - was Sie tun, um die Lichter an zu halten
  4. Ungeplante Unterbrechungen - was Sie tun, weil etwas schief gelaufen ist

Wenn die Arbeit Ihres Teams nachhaltig ist, verbringen Sie ungefähr die gleiche Zeit mit jedem der vier. Wenn die ungeplante Arbeit fast 50% Ihrer Zeit in Anspruch nimmt, ist dies ein Zeichen dafür, dass Sie definitiv unterbesetzt sind.

Sie sollten in der Lage sein, ungefähr eine Person einzustellen, bevor die ungeplante Arbeit 25% Ihrer Zeit erreicht. Andernfalls wird Ihr gesamtes Team von einer Person in einen Tailspin versetzt, von dem Sie sich möglicherweise nie mehr erholen. Überversorgung von Menschen und Technologie hat die gleichen Gründe und Vorteile.

Jiri Klouda
quelle
@alecxe - Warum ist die Antwort mit den meisten Stimmen nicht genug?
Peter
In der bestbewerteten Antwort heißt es im Wesentlichen nur: "Je mehr Arbeit vorhanden ist, desto mehr Menschen werden Sie benötigen. Halten Sie einmal im Monat an, um zu bewerten." Daher gibt es keine konkreten Hinweise zur Durchführung der Bewertung.
Jiri Klouda
8

Hintergrund: Neben der Bereitstellung von Support für unsere aktuelle Infrastruktur und für unsere Entwickler planen wir als DevOps-Team monatlich, was wir erreichen möchten, und helfen Entwicklerteams bei Sprints und neuen Projekten, die gestartet werden. Im Laufe des Monats stellen wir jedoch häufig fest, dass zusätzliche Dinge getan und verbessert werden müssen, die wir dann zu unserem Rückstand hinzufügen. Wir sind auch verantwortlich und helfen bei verschiedenen anderen Dingen, die nicht in unseren Geltungsbereich fallen, aber wir unterstützen das Geschäft, wo wir können :)

Antwort : Sobald Sie bemerken, dass Sie viele Aufgaben, insbesondere die Wartung, nicht erledigen oder verschieben, denke ich, dass dies ein guter Indikator ist (nach dem, was ich erlebt habe). Außerdem, je mehr neue Projekte und Entwicklerteams in die engere Auswahl des DevOps-Teams kommen, desto mehr Leute werden Sie brauchen.

Es ist super einfach, sich in den täglichen Aufgaben zu vertiefen, aber ich glaube, es ist super wichtig (auch einmal im Monat), einen Schritt zurückzutreten und dies zu bewerten.

Kyle Steenkamp
quelle
7
Inoffizielle Antwort. Als Entwickler bei @ kyle bin ich schockiert, dass er tatsächlich hier ist. Zu viel Freizeit? ... mach dich wieder an die Arbeit, Kumpel: P
Rohan Büchner
@ RohanBüchner, also du gehst davon aus, dass man bei der Arbeit keine anderen Fragen beantworten soll?
Oryades
@oryades ja ...
Rohan Büchner
1
@ RohanBüchner dann werden Sie nicht viel Antworten haben, wenn Sie eine suchen ...
Oryades
1
@oryades Ich glaube, du hast den Witz in meinem Kommentar vielleicht verpasst. Bitte lies es noch einmal :) Ich wünsche dir ein frohes neues Jahr.
Rohan Büchner
6

Ich nehme dazu eine Seite aus dem SRE-Handbuch, die ich für sehr relevant halte. DevOps-Spezialitäten sollen nicht horizontal mit einer Organisation wachsen. Wenn Sie jedoch feststellen, dass die Dinge nicht erledigt werden, ist dies ein Signal dafür, dass Sie den Entwicklern nicht die Möglichkeit geben, sich selbst zu bedienen.

Bewerten Sie Ihre Prozesse und überprüfen Sie, ob sie mit den allgemein anerkannten DevOps-Prinzipien übereinstimmen und wie gut Sie die branchenüblichen Best Practices befolgen.

Matt O.
quelle
5
Guter Punkt. Wenn Sie sich unterbesetzt fühlen, bedeutet dies häufig, dass Sie (oder wer auch immer der Manager ist) auf andere Teams zurückgreifen müssen, um Self-Service-Tools zu entwickeln, anstatt Ihrem Team manuelle Arbeit zu leisten.
Boykott SE für Monica Cellio
4

Ich gehe davon aus, dass dieses zweiköpfige Team von Projekt zu Projekt geht und dort DevOps-Inhalte erstellt (CI / CD-Pipelines erstellt, die anderen Entwickler Dockerfiles erstellt oder welche Technologie auch immer Sie verwenden). Mit anderen Worten, geben Sie 3, 4, 5 oder 6 gemäß http://web.devopstopologies.com/ ein .

In diesem Fall ist ein Anzeichen für einen Mangel einfach zu viel Arbeit für diese beiden; zu viele Projekte fordern ihre Dienste an; zu viele Tickets; im Laufe der Zeit; Stress, Burnout. Diese Faktoren sollten Grund genug für eine verantwortungsbewusste Führung sein, mehr Kapazität hinzuzufügen. Ich sehe kein DevOps-spezifisches Zeichen darin, es ist nur eine Funktion, die unterbesetzt ist.

Ein weiteres Zeichen, um etwas zu ändern, ist, wenn Sie genau hinschauen und feststellen, dass Sie ein "DevOps-Silo" erstellen, in dem sich das gesamte DevOps-Know-how auf diese beiden Jungs / Mädels konzentriert und sich alle anderen nur zurücklehnen diese beiden machen "DevOps". Das ist nicht der Punkt von DevOps. Wenn dies der Fall ist, denken Sie über den kulturellen Aspekt nach und modifizieren Sie sie, um mehr Evangelisten / Lehrer / Trainer für die anderen Teams zu sein.

In beiden Fällen sollte dem oberen Management klar sein, warum es sinnvoll ist, DevOps an erster Stelle zu haben (die allgemeinen guten Dinge). Wenn Sie diese Botschaft nicht vermitteln können, verkleinern Sie die Arbeit Ihres Teams, indem Sie sie auf die regulären Entwickler / Operateure verlagern (wie es auch immer der Fall sein sollte).

AnoE
quelle
1

Ich hatte den Eindruck, dass DevSecOps eine Denkweise war, kein Team - wenn Sie ein Dev (Sec) Ops "Team" haben, machen Sie es falsch ... Ich versuche meinen Kopf darum zu wickeln, zwei "DevOps Engineers" einzusetzen zusammen und nenne sie ein "DevOps Team".

Wir haben Entwicklungsteams, SCM, Application Security und Systems Engineers, die gemeinsam an einem schnellen Bereitstellungs- / Freigabemodell arbeiten, um Code- und Konfigurations- / Systemänderungen bis zu einem bestimmten Endpunkt durchzuschieben - entweder für die Bereitstellung oder für die Produktion

Dies hat nichts mit irgendwelchen "devOps" -Ingenieuren als solchen zu tun.

randomNerdboy
quelle
-1

Gruppierung von Aufgaben

Ein Ansatz, den wir in der Vergangenheit in ähnlichen Situationen verwendet haben, besteht darin, die Arbeit eines Teams in vier Hauptgruppen von Aufgaben zu organisieren und das Äquivalent von 2 Vollzeitäquivalenten (FTE) zuzuweisen, um diese Aufgaben zu erledigen (zu versuchen). In unserem Fall handelte es sich um den Betrieb eines SCM-Helpdesks in einer Mainframe-Umgebung, in der etwa 300 Entwickler alle Arten von Hilfe / Interventionen von diesen beiden VZÄ erbeten. Die Aufgabengruppen sind in 4 mögliche Prioritäten gegliedert:

  • Aufgaben der Prioritäten 1 und 2 müssen erledigt sein (keine Ausreden / Verhandlungen möglich)
  • Aufgaben der Priorität 3 sind " sobald es die Zeit erlaubt" zu erledigen .
  • Aufgaben der Priorität 4 sind " wenn es die Zeit erlaubt" zu erledigen .

Lesen Sie weiter, um mehr über die Art der Aufgaben in jeder dieser 4 Gruppen zu erfahren ...

Aufgabenbeschreibungen

Priorität 1 - Betreiben Sie den Helpdesk

  • Von Experten, die leicht zugänglich und immer verfügbar sind.
  • Per Telefon, E-Mail oder Ticketsystem während der Geschäftszeiten.
  • Konform mit vordefinierten SLAs.
  • ITIL-basierte Registrierung aller Helpdesk-Anrufe mit regelmäßigen Berichten aller Anrufe.
  • Anwenden von Notfallanpassungen (Workarounds) für kritische Probleme.

Priorität 2 - Wachdienst

  • 24h / Tag, 7 Tage / Woche Bereitschaft.
  • Konform mit vordefinierten SLAs.
  • Meldung aller Wachdienstanrufe.
  • Eskalation des Managements, wo nötig.

Priorität 3 - Routinewartung

  • Verwaltung.
  • Bewerbung einsteigen.
  • Housekeeping.
  • Leistungsverbesserungen.
  • Raum-Management.
  • Optimierung des Ressourcenverbrauchs.
  • Schlagen Sie Verbesserungen für Anpassungen vor, um die Anzahl der Helpdesk-Anrufe und / oder Überwachungsmaßnahmen zu verringern.

Priorität 4 - Korrekturen und Verbesserungen

  • Erstellen und pflegen Sie Benutzerdokumentationen.
  • QS-Prüfung neuer Anpassungen.
  • Erweiterungswünsche entwickeln und umsetzen.
  • Beteiligen Sie sich an DRP-Tests.

Auswertung

Wenn Sie wie oben beschrieben vorgehen, kann (wird!) Folgendes passieren:

  • Wenn das Team unterbesetzt ist, wird wahrscheinlich die meiste Zeit für die Aufgaben der Prioritäten 1 und 2 aufgewendet, während es eine Weile dauern kann, bis die Aufgaben der Prioritäten 3 erledigt sind diese Aufgaben).
  • Je mehr Zeit zur Verfügung steht, um in Aufgaben der Priorität 4 zu " investieren ", desto mehr Zeit wird für Aufgaben der Prioritäten 1 und 2 benötigt, so dass noch mehr Zeit (des verfügbaren Budgets von 2 Vollzeitäquivalenten) "investiert" werden kann "in priorität 4 aufgaben.
  • Sie werden erstaunt sein, wie nach einer Weile die Anzahl der Aufgaben mit Priorität 1 und 2 sinkt. Und wenn Sie über diese Aufgaben angemessen Bericht erstatten, hört das Management das gerne. In unserem Fall ging diese Zahl von ca. 300 / Monat auf unter 100 / Monat zurück ...
  • Wenn jedoch die 2 VZÄ scheinbar nie (oder kaum) Zeit für Aufgaben der Priorität 4 haben, dann haben Sie eine perfekte Erklärung und einen Beweis für Ihr Management ... dass Sie unterbesetzt sind.
Pierre.Vriens
quelle
1
Dies scheint ehrlich gesagt ein Operationsplan zu sein und nur sehr wenig davon lässt sich in DevOps-Philosophien übersetzen. Ich weiß nicht, wie es zu einer Antwort kam.
Matt O.