In diesem Essay haben wir versucht zu zeigen, warum die folgenden Antworten auf die Fragen angemessen sind: Was sollten Sie zwischen SRE und DevOps w\u00e4hlen? Ist SRE nur auf Cloud-Umgebungen anwendbar? Was genau ist die Funktion des DevOps-Teams? Sind SRE und DevOps miteinander kompatibel? Ben\u00f6tigt SRE Codierung? Ist es eine gute Idee, eine Karriere im Bereich DevOps anzustreben? Die Antworten auf all diese Fragen finden Sie auf dieser Seite.<\/p>\r\n\r\n\r\n\r\n
Wenn es um Softwareentwicklung, -ver\u00f6ffentlichung und -produktion geht, k\u00f6nnen Unternehmen entweder SRE oder DevOps w\u00e4hlen. Eine umfassende Analyse der Unterschiede und \u00c4hnlichkeiten zwischen diesen beiden Methoden kann Unternehmen jedoch bei der Auswahl der am besten geeigneten Strategie helfen.<\/p>\r\n\r\n\r\n\r\n
Entwicklung und Betrieb werden in der Praxis zusammengef\u00fchrt, die als \u201eDevOps\u201c bezeichnet wird. Der Zweck von DevOps besteht darin, sicherzustellen, dass dasselbe Team, das f\u00fcr die Entwicklung verantwortlich ist, auch f\u00fcr die Wartung des Codes in der Produktion verantwortlich ist.<\/p>\r\n\r\n\r\n\r\n
Die M\u00f6glichkeit, Anwendungsupgrades vor der Bereitstellung von Software zu bewerten, wird durch kontinuierliche Bereitstellung f\u00fcr Entwickler erm\u00f6glicht. Neben kontinuierlicher Bereitstellung umfasst DevOps die Softwareentwicklung, die Ver\u00f6ffentlichung neuer Versionen, das Testen und Integrieren dieser neuen Versionen, das Konfigurationsmanagement und die Echtzeit\u00fcberwachung.<\/p>\r\n\r\n\r\n\r\n
Site Reliability Engineering ist das, was wir meinen, wenn wir SRE sagen. Software Reliability Engineering (SRE) ist eine Partnerschaft zwischen Softwareentwicklung und Systembetrieb. Eines der Ziele von SRE besteht darin, Probleme zu erkennen und vorbeugende Ma\u00dfnahmen dagegen zu ergreifen, die zu Ausfallzeiten f\u00fchren k\u00f6nnten.<\/p>\r\n\r\n\r\n\r\n
System Reliability Engineering ist eine Verschmelzung von Systembetrieb und Softwareentwicklung.<\/p>\r\n\r\n\r\n\r\n
Software Reliability Engineering (SRE) befasst sich mit Aspekten der Softwareentwicklung wie Geschwindigkeit, Qualit\u00e4t, Design, Agilit\u00e4t und Innovation. Dar\u00fcber hinaus ist SRE f\u00fcr betriebliche Anforderungen wie Wartbarkeit, Verf\u00fcgbarkeit, Wartungsfreundlichkeit und Leistung verantwortlich.<\/p>\r\n\r\n\r\n\r\n
SRE vs. DevOps \u2013 ein organisatorischer Vergleich<\/p>\r\n\r\n\r\n\r\n
In den meisten Unternehmen arbeiten viele Abteilungen an demselben Produkt. Das Produkt kann jedoch nur dann erfolgreich sein, wenn diese Abteilungen zusammenarbeiten.<\/p>\r\n\r\n\r\n\r\n
Die Unterschiede, die zwischen den Teammitgliedern auftreten k\u00f6nnen, k\u00f6nnen mithilfe von DevOps gel\u00f6st werden, das alle unter einem gemeinsamen Ziel n\u00e4her zusammenbringt. Der Zweck der DevOps-Methodik besteht darin, eine effiziente Ressourcenverwaltung in allen Abteilungen einer Organisation zu erm\u00f6glichen.<\/p>\r\n\r\n\r\n\r\n
Die SREs hingegen greifen die Silos nicht direkt an, sondern ermutigen alle zur Diskussion. Aus diesem Grund wird die Verantwortung f\u00fcr ein Produkt gleichm\u00e4\u00dfig auf alle Mitarbeiter der Organisation verteilt, die daran arbeiten.<\/p>\r\n\r\n\r\n\r\n
SRE vs. DevOps: Testfehler<\/p>\r\n\r\n\r\n\r\n
Wenn Software nicht st\u00e4ndig getestet wird, wissen Unternehmen, dass sie irgendwann kaputt gehen wird. DevOps verwendet automatisierte Tests, um Probleme zu entdecken und Risiken zu minimieren. DevOps stellt durch diese Vorgehensweise sicher, dass die Teams nicht dieselben Fehler machen.<\/p>\r\n\r\n\r\n\r\n
Fehler werden von SREs mithilfe von zwei verschiedenen Ans\u00e4tzen untersucht, n\u00e4mlich Service-Level-Indikatoren und Service-Level-Zielen. SLOs stellen den Erfolgsprozentsatz von SLIs dar, der die Anzahl der Fehler quantifiziert, die pro Anfrage im Laufe der Zeit auftreten.<\/p>\r\n\r\n\r\n\r\n
Messung des Fortschritts zwischen SRE und DevOps<\/p>\r\n\r\n\r\n\r\n
Die Effektivit\u00e4t von DevOps wird anhand dieser vier Kennzahlen bewertet. Zu diesen Faktoren geh\u00f6ren die Anzahl der Bereitstellungen, die Zeit, die zur Wiederherstellung des Dienstes ben\u00f6tigt wird, die Zeit, die zur Vorbereitung auf \u00c4nderungen ben\u00f6tigt wird, und der Prozentsatz erfolgreicher \u00c4nderungen.<\/p>\r\n\r\n\r\n\r\n
SREs \u00fcberwachen den Fortschritt anhand von vier Signalen: Verkehr, Latenz, S\u00e4ttigung und Fehler. Bei der Messung m\u00fcssen Entwickler die bestehenden Standards ber\u00fccksichtigen, die jeder Statistik entsprechen.<\/p>\r\n\r\n\r\n\r\n
Teamorganisation in Bezug auf SRE vs. DevOps.<\/p>\r\n\r\n\r\n\r\n
Site Reliability Engineers mit Erfahrung in der Softwareentwicklung und im Betrieb bilden das R\u00fcckgrat von SRE-Teams.<\/p>\r\n\r\n\r\n\r\n
Innerhalb eines DevOps-Teams k\u00f6nnen viele verschiedene Rollen besetzt werden. Einige Beispiele f\u00fcr diese Rollen sind Qualit\u00e4tsanalysten, Softwareentwickler, Release-Manager, Systemadministratoren, Produktbesitzer und System Reliability Engineers.<\/p>\r\n\r\n\r\n\r\n
SRE versus DevOps: Tools<\/p>\r\n\r\n\r\n\r\n
Container, Microservices, kontinuierliche Integration und Bereitstellung, Infrastruktur als Code, Belastbarkeitstests und \u00dcberwachungssysteme sind einige der Technologien, die DevOps und SREs gemeinsam haben. Zu den weiteren Tools geh\u00f6ren Belastbarkeitstests.<\/p>\r\n\r\n\r\n\r\n
SRE versus DevOps: Fokus<\/p>\r\n\r\n\r\n\r\n
Das Hauptziel von SRE ist die Entwicklung von Anwendungen, die sowohl sehr zuverl\u00e4ssig als auch sehr skalierbar sind. Daher konzentrieren sich die Aufgaben eines SRE haupts\u00e4chlich darauf, die Zuverl\u00e4ssigkeit der Anwendung sicherzustellen und aufrechtzuerhalten, anstatt h\u00e4ufige \u00c4nderungen vorzunehmen.<\/p>\r\n\r\n\r\n\r\n
DevOps hingegen befasst sich haupts\u00e4chlich mit der Erstellung von Produktionsumgebungen, in denen Entwickler mehr Kontrolle haben. Das Ziel von DevOps ist die Implementierung von CI\/CD-Pipelines in allen Phasen des Produkts, um eine agile Entwicklung zu erm\u00f6glichen.<\/p>\r\n\r\n\r\n\r\n
SRE vs. DevOps: Unterschiede in der Art und Weise, wie \u00c4nderungen implementiert werden<\/p>\r\n\r\n\r\n\r\n
Anstatt umfangreiche Updates auf einmal f\u00fcr die Softwareanwendung zu ver\u00f6ffentlichen, nimmt DevOps im Laufe der Zeit inkrementelle Anpassungen am Produkt vor. Wenn dies getan wird, gibt es weniger Probleme in DevOps-Apps und sie verf\u00fcgen \u00fcber ein besseres \u00dcberpr\u00fcfungsmanagement.<\/p>\r\n\r\n\r\n\r\n
SREs machen \u00c4nderungen schnell und oft r\u00fcckg\u00e4ngig, um sicherzustellen, dass das Produkt fehlerfrei ist. SREs bewerten Updates mithilfe von Canary Releases, bevor sie \u00c4nderungen in die Produktion einbringen. Dar\u00fcber hinaus muss der SRE ein Gleichgewicht zwischen Zuverl\u00e4ssigkeit und H\u00e4ufigkeit der Updates finden.<\/p>\r\n\r\n\r\n\r\n
SRE zielt darauf ab, langweilige Aufgaben loszuwerden, indem ermittelt wird, welche Aktivit\u00e4ten mehr als f\u00fcnfzig Prozent der Zeit eines Ingenieurs in Anspruch nehmen, und diese Aktivit\u00e4ten dann eliminiert werden. Dar\u00fcber hinaus sind SREs daf\u00fcr verantwortlich, bestimmte Codes f\u00fcr eine Vielzahl von Prozessen vorzubereiten und diese Codes dann einem Playbook hinzuzuf\u00fcgen.<\/p>\r\n\r\n\r\n\r\n
Die automatisierten Strategien von DevOps erm\u00f6glichen die Erstellung von Feedbackschleifen zwischen den Entwicklungs- und Betriebsteams. Der Zweck der von DevOps eingesetzten Automatisierung besteht darin, den Prozess der Einf\u00fchrung inkrementeller \u00c4nderungen an bereits laufenden Anwendungen zu beschleunigen.<\/p>\r\n\r\n\r\n\r\n
Google hat das SRE-Modell mit der Absicht entwickelt, es Entwicklern zu erleichtern, sich auf die Geschwindigkeit zu konzentrieren, mit der neue Funktionen hinzugef\u00fcgt werden, und auf den Einfallsreichtum dieser Funktionen, w\u00e4hrend sich Systembetreiber gleichzeitig auf die Aufrechterhaltung von Konsistenz und Stabilit\u00e4t konzentrieren k\u00f6nnen.<\/p>\r\n\r\n\r\n\r\n
Das Konzept l\u00e4sst sich an jede Organisation anpassen, und in den letzten Jahren gab es ein sp\u00fcrbar steigendes Interesse an seiner Verwendung. Die Unternehmen, die das SRE-Modell implementiert haben, haben faszinierende Anekdoten mit vielen Gemeinsamkeiten zu erz\u00e4hlen, die sich um die Vorteile von SRE drehen und darum, wie sie diese Praktiken in einen greifbaren und positiven Einfluss auf ihr Gesch\u00e4ft umgesetzt haben.<\/p>\r\n\r\n\r\n\r\n
Aus der Sicht eines Entwicklungsteams sind die Vorteile von SRE von Anfang an deutlich erkennbar. In der Vergangenheit lag der Hauptfokus von Entwicklungsteams auf der Anwendungsentwicklung und der F\u00e4higkeit, so schnell wie m\u00f6glich neue Funktionen bereitzustellen.<\/p>\r\n\r\n\r\n\r\n
Offensichtlich ist sich eine moderne und erfahrene Gruppe bewusst, dass dies nur ein Bestandteil der Gleichung ist. Unter anderem tr\u00e4gt die Aufwendung von Zeit und Aufwand f\u00fcr die Entwicklung von Testtechniken, Prozessen f\u00fcr kontinuierliche Integration und Bereitstellung sowie Cloud-Automatisierung zur Gesundheit eines Softwaresystems bei.<\/p>\r\n\r\n\r\n\r\n
Der Ansatz des Software Reliability Engineering (SRE) liefert Teams Prinzipien der Softwareentwicklung, die auf ihre IT-Abl\u00e4ufe angewendet werden k\u00f6nnen. Dies hilft Teams, die Messlatte f\u00fcr operative Exzellenz h\u00f6her zu legen. Dank dieser Prinzipien k\u00f6nnen sie Verbesserungen in verschiedenen Bereichen erzielen, darunter Kapazit\u00e4t, Leistung, Verf\u00fcgbarkeit und Latenz. SRE-Praktiken sind eine Disziplin, die sich darauf konzentriert, den Prozess des Betriebs und der Wartung von Softwarel\u00f6sungen zu verk\u00fcrzen und letztendlich zu vereinfachen.<\/p>\r\n\r\n\r\n\r\n
Diese Praktiken k\u00f6nnen eine Vielzahl von Facetten umfassen, die \u00fcber den gesamten Softwarelebenszyklus hinweg vorhanden sind. Anstatt \u00c4nderungen an ihrer Softwarel\u00f6sung zu vermeiden, verlagert ein Team, das SRE-Praktiken erfolgreich einf\u00fchrt, seine betriebliche Arbeitslast auf die allt\u00e4glichen Entwicklungsaufgaben und ber\u00fccksichtigt die technischen Komplexit\u00e4ten, die mit Skalierung und neuen Funktionen einhergehen. Diese Verlagerung erfolgt aufgrund der Entscheidung des Teams, \u00c4nderungen an seiner Softwarel\u00f6sung nicht zu vermeiden. Einheitliche technische Vision und Koordination zwischen den verschiedenen Teams<\/p>\r\n\r\n\r\n\r\n
Der Ansatz des Software Reliability Engineering (SRE) verleiht dem Unternehmen eine koh\u00e4rente technische Vision, wenn er auf verschiedene Softwareentwicklungsteams angewendet wird. Diese einheitliche technische Vision f\u00f6rdert die Zusammenarbeit, den Informationsaustausch und eine einheitliche Sprache zwischen verschiedenen Teams. Im Gegensatz zur Einf\u00fchrung einer neuen Softwarebibliothek oder eines Bereitstellungstools liegt die effektive Einf\u00fchrung von SRE nicht nur in der Verantwortung des Softwareentwicklungsteams. Das Unternehmen und andere Stakeholder, die nicht technisch orientiert sind, haben erheblichen Einfluss auf die F\u00e4higkeit, eine Kultur zu erm\u00f6glichen und zu pflegen, in der die SRE-Einstellung gedeihen kann. Mit einem Gespr\u00e4ch zwischen allen Stakeholdern dar\u00fcber, was Zuverl\u00e4ssigkeit f\u00fcr das Unternehmen bedeutet, ist es wichtig, eine Kultur zu etablieren, in der sich die Entwicklungsteams psychologisch sicher f\u00fchlen, zu scheitern, und aus ihren Fehlern lernen k\u00f6nnen.<\/p>\r\n\r\n\r\n\r\n
Ein Gespr\u00e4ch zwischen gesch\u00e4ftlichen und technischen Stakeholdern ist die einzige M\u00f6glichkeit, die notwendige Abstimmung herzustellen, um die verschiedenen Servicelevel zu definieren, ein Kernkonzept von SRE, und den Aufwand und die gesch\u00e4ftlichen Auswirkungen zu verstehen, die mit jedem Level verbunden sind. F\u00fcr das SRE-Servicelevel entscheidende Konzepte Im Folgenden sind die wichtigsten SRE-Servicelevel-Konzepte aufgef\u00fchrt: Service Level Indicators (SLIs) sind eine oder mehrere quantitative Zuverl\u00e4ssigkeitsmesswerte der Softwarel\u00f6sung aus der Sicht Ihrer Kunden.<\/p>\r\n\r\n\r\n\r\n
In einem webbasierten System sind die HTTP-Statuscodes und die gesamte End-to-End-Latenz einige n\u00fctzliche Beispiele. Service Level Objectives (oft SLOs genannt) sind ein oder mehrere Ziele, die ein bestimmter SLI innerhalb einer vorgegebenen Zeitspanne erreichen muss. Im Kontext einer Webl\u00f6sung kann dies bedeuten, jeden Monat maximal 1 % HTTP 5xx (Serverfehler) anzustreben oder t\u00e4glich f\u00fcr jede HTTP-Anforderung eine Latenz von weniger als 200 Millisekunden zu erreichen.<\/p>\r\n\r\n\r\n\r\n
Um die Zuverl\u00e4ssigkeit zu berechnen, teilen Sie die Anzahl der erfolgreichen Aktionen (d.\u00a0h., wie oft es ordnungsgem\u00e4\u00df funktioniert hat) durch die Gesamtzahl der Aktionen. So erhalten Sie den Zuverl\u00e4ssigkeitswert. Das Ma\u00df an Unzuverl\u00e4ssigkeit, das die verschiedenen Beteiligten bereit sind zu ertragen, wird als Fehlerbudget bezeichnet. Kurz gesagt kann dies ermittelt werden, indem der Zuverl\u00e4ssigkeitswert von 100 % des Gesamtwerts abgezogen wird.<\/p>\r\n\r\n\r\n\r\n
Die SRE-Servicelevel-Konzepte und die damit verbundenen Zuverl\u00e4ssigkeits- und Fehlerbudgetwerte sind \u00e4u\u00dferst hilfreich, um diese gemeinsame Sprache in der gesamten Organisation zu etablieren. Dadurch entsteht ein gemeinsames Verst\u00e4ndnis zwischen Unternehmen, Entwicklern und SRE-Ingenieuren hinsichtlich der Definition von Erwartungen und Verantwortlichkeiten. Auch wenn sie leicht zu verstehen sind, sind die SRE-Servicelevel-Konzepte und die damit verbundenen Zuverl\u00e4ssigkeits- und Fehlerbudgetwerte von Vorteil. Ebenso wichtig ist, dass die Festlegung eines Ziels von 100 % Zuverl\u00e4ssigkeit sowohl romantisch als auch falsch ist, da dies das Team an Innovationen hindert, das Team daran hindert, aus seinen Fehlern zu lernen, und die Geschwindigkeit verlangsamt, mit der neue Funktionen ver\u00f6ffentlicht werden.<\/p>\r\n\r\n\r\n\r\n
Das Unternehmen selbst als Quelle der Wertsch\u00f6pfung<\/p>\r\n\r\n\r\n\r\n
Das SRE-Paradigma f\u00fchrte zu einer grundlegenden Ver\u00e4nderung der Denkweise von F\u00fchrungskr\u00e4ften in Unternehmen \u00fcber die operativen Aufgaben und Praktiken der Softwareentwicklung. In der Vergangenheit hielten die Gesch\u00e4ftspartner nur die Entwicklung neuer Softwareentwicklungsfunktionen f\u00fcr lohnenswert. Andererseits wurden zugrunde liegende IT-Operationen und andere Aktivit\u00e4ten als l\u00e4stige Ausgaben betrachtet. Aufgekl\u00e4rte Organisationsf\u00fchrer in der modernen Softwareentwicklung von heute wissen, dass man der Entwicklung und Feinabstimmung eines gro\u00dfartigen Motors mehr Wert beimessen muss, wenn man ihn in ein altes, rostiges Chassis stecken will.<\/p>\r\n\r\n\r\n\r\n
Sie sind sich dieser Tatsache bewusst, weil man der Entwicklung eines gro\u00dfartigen Motors mehr Wert beimessen muss. Daher ist es notwendig, die gesamte Softwarel\u00f6sung in den verschiedenen Phasen ihres Lebenszyklus zu ber\u00fccksichtigen und ihr einen angemessenen Wert zuzuweisen. Dieser Wert wurde besser verstanden, nachdem man eine SRE-Perspektive und den damit verbundenen Kulturwandel und die damit verbundenen Vorteile eingenommen hatte. Beispielsweise hat die Skalierbarkeit der Anwendung, um unerwarteten Verkehrsanforderungen zu besonderen Anl\u00e4ssen (wie dem Black Friday) gerecht zu werden, weniger mit der Gesch\u00e4ftslogik der Anwendung zu tun als vielmehr damit, wie Systemvorg\u00e4nge gehandhabt und verwaltet werden. Skalierbarkeit ist die F\u00e4higkeit einer Softwarel\u00f6sung, unerwarteten Verkehrsanforderungen gerecht zu werden.<\/p>\r\n\r\n\r\n\r\n
Andere Beispiele, wie die Optimierung der Cloud-Kosten oder angemessene Backup- und Notfallwiederherstellungsstrategien, die gleichzeitig Kosten und Risiken senken und die operative Exzellenz steigern, haben bewiesen, dass der Betrieb ein wichtiges Wertsch\u00f6pfungszentrum ist (und als solches behandelt werden sollte). Weitere Beispiele:<\/p>\r\n\r\n\r\n\r\n
Site Reliability Engineers sind f\u00fcr die kontinuierliche F\u00f6rderung struktureller Verbesserungen verantwortlich und verf\u00fcgen \u00fcber eine seltene Mischung schwer zu findender Talente: ein umfassendes Verst\u00e4ndnis der Technologie und einen Fokus auf die Bed\u00fcrfnisse der Kunden. Daher ist der Versuch, Kosten f\u00fcr ein SRE-Team zu sparen, indem man die Anzahl der Mitarbeiter reduziert oder die Arbeit auslagert, oft eine schlechte Entscheidung. Es ist wichtig, sich dar\u00fcber im Klaren zu sein, dass nur einige Softwarel\u00f6sungen ein spezialisiertes SRE-Team oder spezielle SRE-Aufgaben erfordern.<\/p>\r\n\r\n\r\n\r\n
Auch bei Google ist die Teilnahme an SRE-Teams freiwillig. Wenn der Umfang der L\u00f6sung oder die Reifephase des Projekts dieses Ma\u00df an Unterst\u00fctzung nicht erfordert, kann die Arbeit, die f\u00fcr SRE geleistet werden muss, vom Entwicklungsteam \u00fcbernommen und vorangetrieben werden. Trotzdem ist es wichtig, im Hinterkopf zu behalten, dass die SRE-Haltung und -Praktiken weiterhin umgesetzt und diese Kultur gepflegt werden muss.<\/p>\r\n\r\n\r\n\r\n
SRE und DevOps sind dieselben Dinge, nur aus unterschiedlichen Perspektiven betrachtet.<\/p>\r\n\r\n\r\n\r\n
SRE (Site Reliability Engineering) und DevOps (Development Operations) sind Tools, die Unternehmen nutzen k\u00f6nnen, um die Kommunikation zwischen ihren Softwareentwicklungs- und Betriebsteams zu verbessern. Unternehmen sollten jedoch den Einsatz von DevOps in Betracht ziehen, wenn sie den Prozess der Markteinf\u00fchrung ihres Produkts beschleunigen und Upgrades w\u00e4hrend der laufenden Produktion integrieren m\u00f6chten. Unternehmen hingegen, die eine Jobautomatisierung im gro\u00dfen Ma\u00dfstab w\u00fcnschen, m\u00fcssen SREs als L\u00f6sung nutzen.<\/p>\r\n\r\n\r\n\r\n
Versuchen Sie Prometteur Solutions, wenn Sie jemanden mit Fachwissen in DevOps oder Site Reliability Engineering einstellen m\u00fcssen.<\/p>\r\n\r\n\r\n\r\n
Prometteur Solutions erm\u00f6glicht es Unternehmen, vorab gepr\u00fcfte Ingenieure in Silicon-Valley-Qualit\u00e4t in nur drei bis f\u00fcnf Werktagen einzustellen. Aus einem Pool von insgesamt 2 Millionen Entwicklern.<\/p>\r\n\r\n\r\n\r\n
Was ist \u201eDevOps\u201c?<\/strong><\/p>\r\n\r\n\r\n\r\n Entwicklung und Betrieb werden in der Praxis zusammengef\u00fchrt, was als \u201eDevOps\u201c bezeichnet wird.<\/p>\r\n\r\n\r\n\r\n Was ist SRE?<\/strong><\/p>\r\n\r\n\r\n\r\n Site Reliability Engineering ist das, was wir meinen, wenn wir SRE sagen. Software Reliability Engineering (SRE) ist eine Partnerschaft zwischen Softwareentwicklung und Systembetrieb.<\/p>\r\n\r\n\r\n\r\n Ja, Codierung ist f\u00fcr SREs erforderlich. Ingenieure, die auf Site Reliability spezialisiert sind, arbeiten daran, Wege zu finden, Systeme zuverl\u00e4ssiger zu machen. Um dieses Ziel zu erreichen, ist es gelegentlich erforderlich, in den Quellcode eines Systems einzudringen, das Problem zu identifizieren und h\u00e4ufig einen Patch f\u00fcr die Codebasis bereitzustellen.<\/p>\r\n\r\n\r\n\r\n In den letzten f\u00fcnf Jahren ist die Nachfrage nach DevOps um 40 bis 50 Prozent gestiegen.<\/p>\r\n\r\n\r\n\r\n Python ist aufgrund der gro\u00dfen Anzahl von Bibliotheksmodulen, die typische Aufgaben ausf\u00fchren k\u00f6nnen, die beliebteste Sprache f\u00fcr DevOps. Die f\u00fcr die Programmierung verwendeten Sprachen bilden das Herzst\u00fcck des Entwicklungsprozesses f\u00fcr DevOps-Systeme. Daher m\u00fcssen Personen, die im DevOps-Bereich arbeiten, die entsprechenden Programmiersprachen kennen, die in diesen Systemtypen verwendet werden k\u00f6nnen.<\/p>\r\n\r\n\r\n\r\n <\/p>\r\n","protected":false},"excerpt":{"rendered":" Was ist der Unterschied zwischen SRE und DevOps? In diesem Essay haben wir versucht zu zeigen, warum die folgenden Antworten auf die Fragen angemessen sind: Was sollten Sie zwischen SRE und DevOps w\u00e4hlen? Ist SRE nur auf Cloud-Umgebungen anwendbar? Was genau ist die Funktion des DevOps-Teams? Sind SRE und DevOps miteinander kompatibel? Ben\u00f6tigt SRE Codierung? […]<\/p>\n","protected":false},"author":8,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","om_disable_all_campaigns":false,"footnotes":""},"categories":[1171],"tags":[],"class_list":{"0":"post-10231","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-uncategorized-de"},"yoast_head":"\n\r\n
\r\n
\r\n