DevOps ist weder eine Methode noch ein Werkzeug, es ist eine Kultur



DevOps ist die Praxis von Betriebs- und Entwicklungsingenieuren, die gemeinsam am gesamten Lebenszyklus vom Entwurf über den Entwicklungsprozess bis zur Produktionsunterstützung teilnehmen. Agilität in das System zu bringen, kann als DevOps-Kultur angesehen werden.

Kultur wird oft ignoriert und missverstanden, ist jedoch ein Schlüsselfaktor für die Leistung eines Unternehmens. Wenn wir unsere Kultur nicht verwalten, werden wir am Ende falsche Praktiken anwenden, die sich letztendlich auf unsere Geschäftsziele auswirken.

Die aktuelle Kultur einer Organisation verstehen

Kultur erzählt uns von den Werten und Normen innerhalb einer Gruppe oder eines Unternehmens. Es identifiziert, was wichtig ist und wie Menschen miteinander umgehen und arbeiten.





CULTURE = „Wie Dinge für den Erfolg intelligent gemacht werden können“

Nehmen wir das Beispiel eines Kundenserviceteams. Die Kultur dieses Teams sollte so sein, dass 97-98% der Kundenzufriedenheit erreicht werden.



Um die Freude der Kunden im Auge zu behalten, müssen sie zunächst höflich sein, auch in schwierigen Situationen müssen sie gut zuhören, um Verwirrung zu vermeiden, und sie müssen die Arbeit nach Bedarf priorisieren.

Lassen Sie uns einen Moment innehalten und uns ein paar Fragen stellen:

  • Was ist die Kultur meines Unternehmens jetzt?
  • Wie gut passt diese Kultur zu meinen Geschäftszielen oder KRAs?
  • Welche Probleme kann ich aufgrund einer Fehlausrichtung erwarten?

Für jede Organisation spielen die 4Cs eine wichtige Rolle



4C der Organisation

Lassen Sie uns nun einen Blick auf die Kultur einer Softwareentwicklungsorganisation werfen. Es sind viele Teams beteiligt, um eine einzelne Softwareeinheit aufzubauen und zu warten. Alle diese Teams haben unterschiedliche Ziele und eine eigene Kultur.

Dieser Prozess beginnt, nachdem die Anforderungen vom Kunden bestätigt wurden.

Entwickler befolgen die von ihrer Organisation festgelegten Codierungsrichtlinien, und zum Generieren des Codes werden Programmierwerkzeuge wie Compiler, Interpreter, Debugger usw. verwendet. Für die Codierung werden verschiedene Programmiersprachen auf hoher Ebene wie C, C ++, Pascal, Java und PHP verwendet.

Sie teilen das gesamte Paket in kleine Ordner auf und entwickeln dann entsprechend kleine Codes.

Bühne 1 : Diese kleinen Codeeinheiten werden dann zu einer großen Einheit zusammengeschlagen. Während der Integration der kleineren Chips muss ein Test auf Projektebene durchgeführt werden, der als Integrationstest bezeichnet wird.

Stufe 2 : Nach der erfolgreichen Integration wird es in einem Dummy-System bereitgestellt. Dieses Dummy-System hat eine ähnliche Konfiguration wie der Client-Computer oder der Computer, auf dem dieses Projekt endgültig bereitgestellt werden muss.

Stufe 3 : Nachdem alle Funktionen in einem Dummy-System getestet wurden, wird das Projekt auf dem Produktionsserver oder dem Clientcomputer bereitgestellt.

Obwohl dieser Prozess in Worten sehr reibungslos und einfach zu sein scheint, ist er technisch sehr schwer zu erreichen.

Mal sehen, mit welchen Problemen wir konfrontiert sein könnten:

Was ist die beste Java-Idee

Bühne 1 ::

Der Kunde ist immer auf der Suche nach Änderungen, um die Qualität des Produkts zu verbessern. In den meisten Fällen, in denen die erste Iteration durchgeführt wurde, schlägt der Client einige Änderungen vor. Wenn die Entwickler die Änderungen erhalten, beginnen sie, sie zu integrieren, was sich auf die Integration auswirkt und zu fehlerhaften Builds führt.

Stufe 2:

In den meisten Fällen sind sich die Tester oder andere Bediener der neuen Änderungen nicht bewusst. Sobald sie den Code von den Entwicklern erhalten, testen sie sie. Während des Backends nehmen die Entwickler die Änderungen noch vor.

Da sie nicht genügend Zeit haben, um neue Änderungen zu implementieren, entwickeln sie ineffiziente Codes, mit denen andere Netzwerk- und Datenbankprobleme konfrontiert sind, was wiederum ihre Lieferzeit verzögert.

Wenn sie die Codes schließlich an das Betriebsteam liefern, bleibt ihnen nur sehr wenig Zeit, um neue Testfälle zu erstellen und zu implementieren. Daher überspringen sie viele der Testfälle, bei denen sie später feststellen, dass diese von hoher Priorität waren.

Stufe 3:

Obwohl der Build praktisch für die Produktion bereit zu sein scheint, sind die Ergebnisse völlig unerwartet. Der Build schlägt fehl und es treten eine Reihe von Fehlern auf.

Dann müssen sie für jeden aufgetretenen Fehler nachverfolgen, warum dieser aufgetreten ist, wo er aufgetreten ist, welche Änderungen vorgenommen werden müssen, um ihn zu beheben. Werden die Codes anderer geändert, um ihn mit den vorherigen kompatibel zu machen. Schließlich muss für all diese Fehler ein Fehlerbericht erstellt werden.

Der Fehler ist auf Systemfehler zurückzuführen, die auf die Unkenntnis des Datenbankentwicklers in Bezug auf die Effizienz des Codes, die Unkenntnis des Testers in Bezug auf die Anzahl der Testfälle usw. zurückzuführen sind.

Da der Kunde die Fristen immer eng hält, konzentrieren sich die an der Erreichung beteiligten Mitarbeiter nur auf die endgültige Freigabe, selbst wenn sie die Gesamtqualität beeinträchtigen müssen.

Ruby on Rails Arbeitsmarkt

Obwohl dies ein Problem bei der Koordinierung der Arbeit zu sein scheint, Dies ist tatsächlich das Scheitern der angenommenen Kultur.

Dies geschieht aufgrund der großen Abhängigkeit von manuellen Prozessen. Das Hin- und Herlaufen im selben Team aufgrund mangelnder Kenntnisse in verschiedenen Bereichen, mangelnder Zugang oder mangelndes Interesse erhöht unsere eigene Belastung und unseren Schmerz.

Es ist höchste Zeit, dass wir vielseitig sind. Es mag schwierig sein, alle an einem System beteiligten Prozesse zu beherrschen, aber wir können der Alleskönner sein und einen von ihnen beherrschen. Nur dann können wir unser System automatisieren oder intelligent genug machen, um es wiederherzustellen, anstatt es zurückzusetzen.

Jetzt denken Sie vielleicht warum?

Dies liegt daran, dass derjenige, den Sie beherrschen, stark von anderen abhängig ist. Um den Abhängigkeitspunkt zu kennen, müssen wir das gesamte System verstehen.

Überlegen wir uns also einen Prozess zur Veränderung der Kultur. Haben Sie vorher die Antwort auf die folgenden Fragen?

  • Wo versagt Ihre aktuelle Kultur?
  • Warum möchten Sie den Prozess ändern?
  • Haben Sie alle erforderlichen Änderungen eindeutig identifiziert?
  • Haben Sie Feedback und Buy-In von allen betroffenen Stakeholdern erhalten?
  • Haben Sie die Prozessdisziplin, die Daten und das Messsystem für die Änderung erneut validiert?

Wenn wir nun die Antwort auf alle Fragen haben, denken wir an eine Revolution in unserem System. Wie wird diese Revolution stattfinden? Es kann nur erreicht werden, wenn wir töten, was wir jetzt sind. Bei der Migration von Code zwischen den Teams wird viel Zeit verschwendet. Wir müssen den Prozess so gestalten, dass wir eine kontinuierliche Integration und Bereitstellung durchführen können.

Dieser Prozess der kontinuierlichen Integration und Bereitstellung macht es agiler. Diese Beweglichkeit zu bringen, gilt als DevOps-Kultur.

DevOps ist die Praxis von Betriebs- und Entwicklungsingenieuren, die gemeinsam am gesamten Servicelebenszyklus teilnehmen, vom Design über den Entwicklungsprozess bis zur Produktionsunterstützung.

Es ist nicht einfach, das Arbeitssystem im Laufe der Zeit zu ändern. Ein erfolgreicher Übergang besteht darin, das System zu renovieren und nicht neu aufzubauen.

Nun wollen wir sehen, wie wir dies erreichen können. Es gibt zwei Möglichkeiten, sich zu nähern.

1) Von oben nach unten

So finden Sie den Datentyp in Python

2) Von unten nach oben

Wenn wir tiefer in diese Techniken eintauchen, werden wir feststellen, welche für unsere Organisation am besten geeignet ist.

Beim Top-Down-Ansatz können wir uns an das höhere Management wenden und sie bitten, Änderungen in allen Teams vorzunehmen. Wenn das Management dann überzeugt ist, können wir damit beginnen.

Die Wahrscheinlichkeit, die Antwort mit „NEIN“ zu erhalten, ist jedoch recht hoch. Dies liegt daran, dass eine Änderung des Systems die Organisation zu Instabilität führen kann.

Sie müssen sich mit der Organisationsstruktur, dem Umsatz, dem Interesse der Kunden usw. befassen. Der wichtigste Faktor, der sie davon abhält, aus dem alten System auszusteigen, ist jedoch, dass sie das nicht sehen können Gesamtbild dessen, was erreicht werden kann und wie reibungslos es mit dem neueren erreicht werden kann.

In diesem Fall können wir nach dem zweiten Ansatz suchen, um dieses Gesamtbild zu erhalten.

Der Bottom-up-Ansatz erfordert Freiwillige. Hier müssen wir ein kleines Team und eine kleine Aufgabe nehmen und sie im DevOps-Modell ausführen.

Mit Blick auf die technische Seite dieses Modells verfügen wir über verschiedene hochentwickelte Tools, die die Arbeit effizienter und schneller machen. Tools allein sind jedoch nicht in der Lage, eine kollaborative Umgebung zu erstellen, die als DevOps bezeichnet wird.

Um eine solche Umgebung zu erstellen, müssen Sie über den Tellerrand hinaus denken, z. Einschätzung und Neuausrichtung der Einstellung der Mitarbeiter zu ihren Teams, dem Unternehmen und den Kunden.

Das Zusammenstellen neuer Tools ist einfacher als das Ändern der Organisationskultur. Indem wir die asozialen Master-Entwickler fördern, die Integration von ineffizientem Code ermöglichen, nicht ordnungsgemäß getestete Codes bereitstellen, sich gegenseitig die Schuld geben und das Betriebsteam als dumm betrachten, sind dies nicht die Best Practices, die wir befolgen, um das Geschäft zu ermöglichen und Wert für unsere Kunden schaffen.

Es sind nicht die Werkzeuge, sondern die Menschen, die sie verwenden, die den Prozess komplex machen. Auf abstrakter Ebene zu sagen, anstatt Ideen und Verhaltensweisen zu sammeln, führt uns zu einem hellen Weg.

Beginnen wir mit einem Team von 6 Mitgliedern und einer 3-Punkte-Geschichte. Zuerst müssen wir das Team, das wir als Entwickler, Betriebe, Tester usw. bezeichnen, auflösen. Wir betrachten sie alle als eins, sagen wir 'DevOps'. Wenn wir die Anforderungen erhalten, müssen wir die Risikozonen analysieren. Denken Sie an die tieferen Abschnitte des Meeres und der Hölle. Wir beginnen zu segeln.

Jetzt müssen Sie sich überlegen, was der x-Faktor dieser kontinuierlichen Integration und Bereitstellung ist, der die Ausfallwahrscheinlichkeit verringert.

Mit der verbesserten Vision und dem verbesserten Prozess können wir uns an das Management wenden und ein klares Bild der Ergebnisse erstellen, z. B. wie reibungslos der Prozess war, wie das Ausfallrisiko verringert wurde, wie die Aufgabe vor dem Zeitplan erledigt wurde usw.

Jetzt können wir uns klar vorstellen, wie der gesamte Prozess aus technischen und kulturellen Gründen optimiert wurde, indem wir nach jeder Iteration eine Rückschau durchführen.

Edureka hat speziell kuratiert Das hilft Ihnen, Konzepte unter anderem für Puppet, Jenkins, Ansible, SaltStack und Chef zu beherrschen.

Hast du eine Frage an uns? Erwähnen Sie sie im Kommentarbereich und wir werden uns bei Ihnen melden.

Zusammenhängende Posts: