IMHO ist es nicht eine gute Idee, direkt und sofort in der Skalierung der Mannschaft eines Teams Gewinne aus seiner DevOps Transformation gilt nach unten . Bestenfalls verlieren Sie nur die Motivation des Teams, in Zukunft solche Verbesserungen vorzunehmen. Aber höchstwahrscheinlich verlieren Sie das meiste Talent in diesem Team.
Stattdessen:
- Ermöglichen Sie dem Team, die Vorteile der schwierigen Transformation zu schätzen, die es durchlaufen hat, damit es Ihre anderen Teams darüber informiert, die die Transformation durchlaufen müssen (oder bereits damit zu kämpfen haben)
- Konzentrieren Sie sich darauf, Produkte / Dienstleistungen von besserer Qualität schneller und mit demselben Team bereitzustellen. Dies ist jetzt aufgrund der Transformation möglich.
- In vielen Fällen wird Ihr Unternehmen aufgrund des Wandels an Fahrt gewinnen - bald müssen Sie mit größerer Wahrscheinlichkeit Mitarbeiter einstellen -. IMHO ist es besser, die Erfahrung derjenigen zu nutzen, die Sie bereits haben, als neue Mitarbeiter auszubilden
- Lassen Sie freiwillige Abnutzungserscheinungen für Sie arbeiten und sorgen Sie für eine effektive Verkleinerung.
Aber im Allgemeinen sind die DevOps-Transformationen in der Regel nicht schnell genug, um die oben genannten Optionen zu berücksichtigen :)
Nun zum Skalieren / Verkleinern .
Idealerweise sollte die DevOps-Transformation die Vorhersagbarkeit Ihres SW-Entwicklungs- und Bereitstellungsprozesses erheblich verbessert haben. Sie sollten in der Lage sein, die Kapazität Ihres vorhandenen Teams mit einem hohen Maß an Präzision zu bestimmen: Wie viel SW / Services einer bestimmten Qualität kann Ihr aktuelles Team in einer bestimmten Zeit erledigen?
Wenn Sie mehr erledigen müssen oder besser / schneller als die Kapazität des aktuellen Teams, müssen Sie das Team vergrößern / verkleinern. Die genauen Details stammen aus dem Prozess / der Methodik, die Sie für Ihre täglichen Aktivitäten verwenden, wahrscheinlich aus einer agilen Variante (siehe auch Muss meine Organisation Agile Soft. Dev. Vor der Einführung von DevOps übernehmen? ).
Wie - anscheinend einfach: Stellen Sie mehr Leute ein, um die überfüllten Aktivitäten zu bewältigen. Wenn Sie sich Sorgen darüber machen, wie schnell Sie sie an Bord bringen und diese Überlaufarbeiten tatsächlich zu den erwarteten Raten erledigen können: Beginnen Sie früher mit der Einstellung, basierend auf Prognosen.
Die Realität kann jedoch etwas schwieriger sein. Die Skalierung eines Softwareprodukts / -dienstes oder des Entwicklungsprozesses und der unterstützenden Tools ist selbst für eine von DevOps unterstützte Organisation nicht unbedingt einfach.
Eines meiner Lieblingsbeispiele ist das schwächste DevOps-Glied in Bezug auf Skalierbarkeit : Continuous Integration. Wenn der CI-Build fehlschlägt, kann es keine Lieferung / Bereitstellung geben (was den "kontinuierlichen" Begriff im CD-Kontext untergräbt).
Nur weil ein bestimmtes Team CI mit anständigen Ergebnissen gerne verwendet, bedeutet dies nicht, dass dasselbe passiert, wenn sich die Teamgröße verdoppelt. Nein, die Ergebnisse könnten verheerend sein - der Lieferprozess kann (in extremen Fällen) zum Stillstand kommen. Ich versuche dies in Congestion in Traditional CI Systems zu erklären ( Haftungsausschluss: Ich bin der Gründer des Unternehmens, dem die Seite gehört, auf die verwiesen wird, und biete eine Lösung für dieses Problem an).
Ein anderes Beispiel könnte beispielsweise das verwendete Versionskontrollsystem (VCS) sein: Wenn sich die in einem Repository gespeicherte Software weiterentwickelt, ändert sich auch der Änderungsverlauf, wodurch die Grenzen des VCS-Systems manchmal über akzeptable Leistungsniveaus hinausgehen. Der Wechsel zu einem skalierbareren VCS-System oder die Aufteilung der Codebasis in mehrere Repositorys könnte ein Ansatz sein, um das Problem zu beheben.
Die Weiterentwicklung der Entwicklungsprozesse und der sie unterstützenden Tools sowie die Weiterentwicklung der gelieferten Softwareprodukte / -dienste sind im Grunde genau das, was ein ausgereiftes DevOps-Team tut. Sie müssen auch bei der Skalierungs- / Out-Strategie des Teams berücksichtigt werden.
Vor diesem Hintergrund kann das Wie in der Tat auf eine bloße Vergrößerung des Teams reduziert werden, um den zusätzlichen Arbeitsaufwand für die Umsetzung der oben genannten Strategie abzudecken.