Warum widersetzt sich die Entwicklung dem operativen Geschäft?

Ich bin noch ein Student, aber ich kenne mich mit Operationen nicht aus und mein Englisch ist immer noch schlecht.

Meine Frage ist: Warum widersetzt sich die Entwicklung dem operativen Geschäft ? Wann widerspricht die Entwicklung der Operationen?

Der Punkt von DevOps ist, dass Entwicklung sich nicht gegen Operationen stellen sollte, sondern sich gegenseitig unterstützen sollte.

Aufgrund von Wasserfallbereitstellungen und umfangreichen Aktualisierungen verursachte die Entwicklung bei der Bereitstellung aufgrund unzureichender Tests, wechselnder Serverumgebungen und fortwährender Aktualisierungen eine Reihe von Problemen. Im Wesentlichen waren die Updates zu umfangreich, als dass das Betriebsteam sie effektiv bereitstellen könnte, ohne dass dabei Probleme auftreten. Diese Probleme könnten der Grund sein, warum Sie der Meinung sind, dass die Entwicklung dem operativen Geschäft widerspricht .

Auf der anderen Seite arbeitet DevOps daran, die Aktualisierungsgröße zu verringern, starre Umgebungen zu verkleinern und im Allgemeinen die Übergabe der Anwendung zwischen Entwicklung und Betrieb zu verbessern, indem die Häufigkeit erhöht wird, mit der die Übergabe jedes Jahr erfolgt. Mit der zunehmenden Anzahl von Bereitstellungen sind weniger Kopfschmerzen für den Betrieb verbunden, da sie entweder einen großen Arbeitsaufwand für die Aktualisierung der Produkte automatisiert haben oder die Aktualisierungen besser vorbereiten und vorbereiten.

Tldr: DevOps zielt darauf ab, die Theorie aufzuheben, dass sich die Entwicklung dem Betrieb widersetzt, indem eine Denkweise geschaffen wird, in der Betrieb und Entwicklung zusammenarbeiten, um häufig Produkte rechtzeitig und leicht reproduzierbar bereitzustellen.

Ich denke, Sie haben bereits einige umfassende Antworten erhalten, aber Sie sagten, Ihr Englisch sei nicht so gut, und ich werde versuchen, eine sehr kurze und verständliche Antwort zu geben:

• Das Hauptziel der Entwicklung ist es, Änderungen vorzunehmen.
• Das Hauptziel des Betriebs ist es, die Umwelt stabil zu halten.

Diese beiden Dinge stehen in Konflikt. Davon abgesehen sollten sich Entwicklung und Betrieb nicht widersprechen. Sie sollten zusammenarbeiten, um sicherzustellen, dass beide Ziele erreicht werden können. Dies ist der Zweck von DevOps.

Die Spannung zwischen Entwicklung und Betrieb ist häufig auf eine fehlerhafte Ausrichtung der Anreize und Optimierungsversuche im Team zurückzuführen.

Entwickler werden oft nach der Geschwindigkeit und Menge der Probleme beurteilt, die sie durchlaufen und in das Code-Repository einbinden können, und ihre Belohnung hängt oft nicht davon ab, ob der Code tatsächlich funktioniert oder richtig funktioniert. Viel weniger Skalierung, Leistung und andere Faktoren.

Vorgänge werden häufig anhand der Stabilität der Umgebung und der Funktionsweise des Codes in der Produktion beurteilt, selten jedoch anhand der Qualität des Prozesses, um Änderungen schnell umzusetzen.

Dies führt zu dem Problem, dass Entwickler Anreize erhalten, viel Code zu erstellen und ihn über die Wand an das Betriebsteam zu senden, und dass das Betriebsteam Anreize hat, so wenig Änderungen wie möglich zu akzeptieren, um die Stabilität der Umgebung sicherzustellen.

DevOps ist in gewisser Weise die Lösung für dieses Problem:

• Einige von ihnen können organisatorisch sein, wobei sich die Prozesse und Anreize der Teams ändern können. Wenn zum Beispiel Entwicklerarbeiten nur dann als erledigt markiert werden, wenn sie seit einiger Zeit in der Produktion ausgeführt werden, gab es keine Probleme, und das Betriebsteam erklärt sich damit einverstanden, den Code in Besitz zu nehmen. In ähnlicher Weise können Vorgänge eher anhand der Geschwindigkeit beurteilt werden, mit der der Code akzeptiert wird, während sich die Umgebung noch innerhalb einiger Stabilitätsgrenzen befindet.
• Ein weiterer Teil der Lösung kann Kommunikation und Cross-Polination sein, bei denen Sie Mitarbeiter aus dem Operations-Bereich in das Entwicklungsteam einbinden und umgekehrt. Sie brechen die Mauer zwischen diesen Teams und DevOps-Ingenieure sind oft das Ergebnis dieser Art der Überbrückung.
• Tools, die Prozesse wie Continuous Integration und Continuous Deployment unterstützen, sind ein weiterer Teil der Lösung, mit der sich die Änderungsgeschwindigkeit erhöhen lässt. Gleichzeitig wird eine hohe Qualität und eine schnelle Wiederherstellung der Produktionsumgebung im Falle von Problemen durch Rollback des Codes oder schnellen Fortschritt eines Fix beibehalten in die Produktion.

Die meisten Unternehmen bewältigen die Komplexität, indem sie ihre Organisation in funktionale Teile aufteilen und von jedem Teil verlangen, dass er herausfindet, wie er sich verbessern kann. Dies wird oft als "Silo" -Ansatz bezeichnet.

Es ist wichtig zu verstehen, warum dieser Silo-Ansatz den Erfolg des Unternehmens blockiert und die Organisation als Ganzes oft nicht verbessert. Dies betrifft nicht nur die Entwicklung und den Betrieb, sondern auch alle anderen Funktionssilos innerhalb eines großen Unternehmens, z. B. Qualitätssicherungsteam, Finanzen, Produkt- und Projektmanagement.

Da die Manager der einzelnen Funktionssilos angewiesen werden, durch Kostensenkung oder Geschwindigkeitssteigerung Verbesserungen vorzunehmen, reagieren sie häufig wie folgt:

• Ich bin total überwältigt, Probleme von den letzten Verbesserungsbemühungen zu beheben. Lass mich alleine.
• Was soll ich tun, meine Aufgaben erfüllen oder an Verbesserungsprojekten arbeiten? Ich habe keine Zeit für beides.
• Nicht noch einmal! Hier kommt ein weiteres Programm des Monats.

Bei diesen typischen Reaktionen wird eine Führungskraft, die kleinere Verbesserungsmaßnahmen einleitet, selten mit Begeisterung aufgenommen. Manager stehen im harten Wettbewerb mit anderen Funktionsbereichen um Ressourcen, die für die Durchführung ihrer Verbesserungen benötigt werden. Kein Wunder also, dass der Befehl zur Verbesserung funktionsübergreifende Kämpfe verstärkt!

Selbst wenn ein Manager seinen Teil eines Verbesserungsprojekts abschließt, trifft er andere Funktionsbereiche und andere Organisationen (Lieferanten, Auftragnehmer usw.), die ihre Arbeit nicht erledigt haben. Dies verringert oder negiert die Ergebnisse vollständig.

Diese funktionsübergreifende Spannung ist nicht auf Verbesserungsbemühungen beschränkt. Es steht im Mittelpunkt der täglichen Entscheidungsfindung und der Beurteilung der Wirksamkeit des Managements in einer Organisation. Hier ist ein reales Beispiel:

Einem Finanzmanager wurde gesagt, "verbessern". Er beschloss, die Einstellung von Vertragspartnern zu blockieren, die mehr kosten als der auf dem Markt akzeptierte Nominalpreis. Er setzte die neue Richtlinie um und gab an, in diesem Jahr 1 Million Dollar eingespart zu haben. Da Entwickler und IT-Abteilungen keine Vertragspartner einstellen können, die sie bei der Verwendung von Container und Container-Orchestrierung unterstützen, sind diese Vertragspartner teuer. Der IT-Betriebsleiter derselben Firma errechnete, dass eine nicht verbesserte Infrastruktur die Firma jeden Monat mehr als 100.000 US-Dollar an zusätzlichen Ausgaben kosten würde. Zu diesem Zeitpunkt wurden die jährlichen Einsparungen bei den Lohnunternehmern vor Jahresende aufgezehrt.

Sie können sich vorstellen, dass die Beziehung zwischen diesen beiden Funktionsbereichen nicht gerade verliebt war.

Diese funktionsübergreifenden Konflikte werden durch den Silo-Ansatz ausgelöst, bei dem die Organisation jedes Silo unabhängig voneinander auf Verbesserungen hin misst. Wenn Sie eine Kostenstelle sind, bedeutet Verbesserung natürlich eine höhere Effizienz oder Kostensenkung in Ihrem Silo.

In diesem Referenzrahmen werden die Kosten als der "additiven" Regel entsprechend angesehen. Die Kosten für jedes Silo addieren sich zu den Gesamtkosten der Organisation. Aus diesem Grund sehen Manager jede Kostenreduzierung in ihrem Bereich als "gut" an, da sie eine direkte Umsetzung in Kosteneinsparungen für das gesamte Unternehmen sehen. In diesem Referenzrahmen werden überall Verbesserungsbemühungen unternommen, um Kosten und Verschwendung im gesamten Unternehmen in Angriff zu nehmen.

Ein großartiges Beispiel, wenn die Entwicklerteams anfangen, agil zu arbeiten und Code alle zwei Wochen an QS und Operations weiterzuleiten, anstatt wie früher vierteljährlich. Die Qualitätssicherung und der Betrieb sind nicht bereit für eine solche Änderung und werden beschuldigt, nachgelassen zu haben. Auch dies trägt nicht viel zur Liebe zwischen den Menschen in Entwicklung und Betrieb bei.