Ein praktischer Weg zur DevOps-Reife

Jede agile Methodik ist ohne echte DevOps-Praktiken sinnlos. Das Schlagwort wurde in vielen Organisationen missbraucht. Wenn Sie sagen, dass Sie agile Teams gereift sind und einen DevOps-Ingenieur oder ein DevOps-Team haben, gehen Sie wahrscheinlich nicht in die richtige Richtung. DevOps ist eher eine Kultur als ein Teamname oder eine Bezeichnung. In Anlehnung an das CMM (Capability Maturity Model) soll dieser Versuch einem Unternehmen helfen, zu wissen, wo es auf einer DevOps-Reise steht und wie es weitergeht. Mit einem Brainstorming zwischen Entwicklungs- und Ops-Teams kann dies erweitert und an die Bedürfnisse der Organisation angepasst werden.

Keine Zahl ist schlecht, da sie einer Person oder Organisation hilft, zu wachsen.

Zufriedener Kunde

Im Gegensatz zu CMM ist dies kein Modell, das Sie einer Zertifizierungsorganisation nachweisen müssen. Das einzige Zertifikat, das Sie erhalten, ist von Ihren zufriedenen Kunden oder Geschäftspartnern. Es ist ein Modell, um sich selbst zu reflektieren und dem Geschäft zu helfen, zu wachsen. Der eigentliche Zweck eines jeden IT-Teams ist es, durch nachhaltige, vorhersehbare Lieferung mit Qualität Wert zu schaffen.

Dies ist ein einfaches Modell, das vom Entwickler bis zum CxO verstanden und in Beziehung gesetzt werden kann.

Bevor ich über das Modell diskutiere. Wir müssen die Notwendigkeit dieses Modells verstehen. Vor vielen Jahren, Melvin Conway in seinem Papier „Wie erfinden Ausschüsse?“ kam mit These, die als Conway-Gesetz berühmt wurde.

Jede Organisation, die ein System entwirft (allgemein definiert), erstellt ein Design, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.

Das Gesetz basiert auf der Überlegung, dass mehrere Personen häufig miteinander kommunizieren müssen, damit die Softwaremodule funktionieren. Daher spiegelt die Softwareschnittstellenstruktur eines Systems die sozialen Grenzen der Organisation (en) wider, die es produziert haben, über die die Kommunikation schwieriger ist.

Schauen wir uns an, wie dies in der Softwareentwicklung mit einem realen Szenario funktioniert. Radha erstellt einen Front-End-Bildschirm, der detaillierte Attribute eines Produkts anzeigt. Angenommen, dieses Produkt ist ein Mobiltelefon. Wenige allgemeine Produktdetails sind Farbe, Preis, Maße, Bewertungen etc. Eine neue Regelung kam SAR-Wert des Mobilteils anzuzeigen. Der von ihr entworfene Bildschirm funktioniert mit Micro Service Call. Sie sprach mit Sunil, der im Datenteam arbeitet. Er sagte, sie können nur Daten in flachen Dateien senden. Es gibt eine klare Trennung zwischen zwei Modulen. Dies ist ein Szenario, auf das jedes IT-Team stößt, wenn nicht alle 100% -Zeiten, aber die meisten Male. Dies ist nur ein Designproblem. Das Problem ist breiter. Was ist, wenn die Prioritäten des anderen Teams sehr unterschiedlich sind von dem, was Ihr Team tut? Ihre Anforderungen haben für sie möglicherweise die niedrigste Priorität, während Ihre Stakeholder hinter Ihnen laufen.

Der erste Schritt zur erfolgreichen DevOps-Implementierung besteht darin, offen für Organisationsänderungen zu sein.

Organisationsänderungen

Lassen Sie mich 5 Reifegrade besprechen:

  1. Initial: In dieser Phase arbeiten Teams in Silos und es gibt nur eine bedarfsorientierte Zusammenarbeit. Wenn Sie in einem Meeting mit allen Teams fragen, wem das „Produkt“ gehört, werden Sie keine Hände heben. Die Markteinführungszeit ist in der Regel länger und beträgt Monate und manchmal Jahre. Prioritäten werden auf Teamebene gesetzt, aber nicht auf Produktebene. Dies führt dazu, dass jedes Team seine eigenen Prioritäten hat. Da es keinen definierten Prozess gibt, ist jeder Versuch wie das Rad neu zu erfinden. Dies führt zu Qualitätsproblemen und längeren Zeitplänen. Das Team führt meistens manuelle Bereitstellungen und manuelle Eingriffe durch. Gut.. dies ist kein schlechter Zustand. So würde der größte Teil der Entwicklung beginnen.

2. Wiederholbar: Teams arbeiten immer noch in Silos. Es gibt ein gewisses Maß an Automatisierung innerhalb des Teams. Wenn eine Krise eintritt, definiert das Team seinen eigenen Prozess und folgt ihm, bis die Krise endet. Die einzige gute Nachricht ist, dass einige davon zu wiederholbaren Prozessen werden können, wenn die Krise erneut eintritt.

3. Definiert: Dies ist ein guter Ausgangspunkt, um die DevOps-Kultur mit einem zentralisierten Team zu fördern. Dieses Team versteht verschiedene Technologien, die Entwicklungsteams verwenden, und die Werkzeuge basieren auf dem aktuellen Bedarf. Als zentralisiertes Team ist es nicht einfach zu überwachen, was jedes Team tut, und so bleiben einige Entscheidungen den Teams überlassen, um zu experimentieren. Das zentrale Team besteht normalerweise aus Experten und Entwicklerteams haben einige Leute mit grundlegendem Verständnis und Wissen.

4. Verwaltet: Da das zentrale DevOps-Team die Tooling-Landschaft der Organisation versteht, werden mehrere Umgebungen und Tools getestet. Konsistente und wiederholbare Prozesse werden von mehreren Teams verfolgt. Die Auswahl der Toolkette basiert eher auf Anwendungsfällen als auf persönlichen Entscheidungen. Überwachungstools für alle Prozesse werden eingeführt und von Teams stark genutzt, um Entscheidungen zu treffen.

5. Optimierte:

Der Erfolg eines guten Führers wird dadurch definiert, dass er keine Anhänger hat, sondern durch die Fähigkeit, großartige Führer zu schaffen.

Die letzte Stufe der DevOps-Reife besteht darin, das DevOps-Team verschwinden zu lassen. Dies könnte wie kontraintuitiv aussehen. Zu diesem Zeitpunkt ist DevOps eher Teil des Produktentwicklungsteams als eine separate Einheit. Infrastruktur als Code, Container, Orchestrierung etc. nutzen. zero Touch Deployment wird erreicht. Wenn Sie nun alle anrufen, die an einem Produkt arbeiten, und fragen, wem das Produkt gehört, werden Sie ohne zu zögern einige selbstbewusste Hände heben. Daten aus Überwachungstools werden verwendet, um neue Tools auszuwählen (einschließlich Infrastruktur, Programmiersprachen, Techniken). Entscheidungen basieren eher auf Daten als auf persönlichen Vorlieben. Das Produktteam ist bereit, Code an jedem Tag und zu jeder Zeit bereitzustellen. Sie lieben den „Geschäftswert“ und behandeln ihn als Haustier. Alles andere wird wie Vieh behandelt.

DevOps-Reifegradmodell.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.