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.

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.

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.

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.

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).

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.

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.