{"id":55735,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/eshhe-raz-o-devops-i-sre"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"eshhe-raz-o-devops-i-sre","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/eshhe-raz-o-devops-i-sre","title":{"rendered":"Noch einmal \u00fcber DevOps und SRE.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Anl\u00e4sslich der Diskussion im Chat AWS Minsk Community<\/a><\/noindex><\/p>\n

In letzter Zeit entbrennen echte K\u00e4mpfe um die Definition der Begriffe DevOps und SRE.
\nObwohl die Diskussionen zu diesem Thema schon vielerorts ausgelutscht sind, auch f\u00fcr mich, habe ich beschlossen, meine Sichtweise dem Habr-Community zur Pr\u00fcfung vorzulegen. Wer interessiert ist, ist herzlich eingeladen, unter den Cut zu gehen. Und lasst uns alles neu beginnen!
\n<\/a><\/noindex><\/p>\n

Vorgeschichte<\/h4>\n

\nIn alten Zeiten lebte das Team der Softwareentwickler und die Serveradministratoren getrennt. Die ersten schrieben erfolgreich Code, w\u00e4hrend die zweiten, die verschiedene warme, liebevolle Worte an die ersten richteten, die Server einrichteten und gelegentlich zu den Entwicklern kamen, um die ersch\u00f6pfende Antwort \"Auf meinem Rechner funktioniert alles\" zu erhalten. Das Gesch\u00e4ft wartete auf die Software, alles stand still, st\u00fcrzte gelegentlich ab, und alle waren nerv\u00f6s. Besonders derjenige, der f\u00fcr das ganze Chaos bezahlte. Die glorreiche analoge \u00c4ra. Aber das wisst ihr ja bereits, woher DevOps kommt. <\/p>\n

Die Geburt der DevOps-Praktiken<\/h4>\n

\nDann kamen ernsthafte Herren und sagten - das ist keine Industrie, so kann man nicht arbeiten. Und sie brachten Lebenszyklus-Modelle mit. Hier zum Beispiel das V-Modell.<\/p>\n

\"Noch
\nAlso, was sehen wir? Das Gesch\u00e4ft kommt mit einem Konzept, Architekten planen L\u00f6sungen, Entwickler schreiben Code, danach kommt das Versagen. Jemand testet das Produkt auf die eine oder andere Weise, jemand liefert es irgendwie an den Endbenutzer und irgendwo am Ende dieses Wunder-Modells sitzt ein einsamer Gesch\u00e4ftskunde und wartet auf das versprochene Wetter am Meer. Es wurde festgestellt, dass Methoden ben\u00f6tigt werden, die diesen Prozess optimieren. Und sie beschlossen, Praktiken zu schaffen, die dies umsetzen w\u00fcrden.<\/p>\n

Ein lyrischer Einschub dar\u00fcber, was Praxis ist<\/b>
\nUnter Praxis verstehe ich die Verbindung von Technologie und Disziplin. Beispiel - die Praxis der Beschreibung von Infrastruktur mit Code in Terraform. Die Disziplin ist, wie man die Infrastruktur mit Code beschreibt, sie ist im Kopf des Entwicklers, und die Technologie ist das eigentliche Terraform.<\/p>\n

Und so beschlossen sie, sie DevOps-Praktiken zu nennen \u2014 ich denke, sie hatten von Entwicklung bis Betrieb gemeint. Sie erfanden verschiedene komplizierte Dinge \u2014 CI\/CD-Praktiken, Praktiken, die auf dem IaC-Prinzip basieren, tausende davon. Und los ging's, die Entwickler schreiben Code, die DevOps-Ingenieure verwandeln die Beschreibung des Systems in Form von Code in funktionierende Systeme (ja, Code ist leider nur eine Beschreibung und keinesfalls die Verk\u00f6rperung des Systems), die Auslieferung dreht sich, und so weiter. Die fr\u00fcheren Administratoren, die sich mit neuen Praktiken vertraut gemacht hatten, qualifizierten sich stolz zu DevOps-Ingenieuren um, und alles nahm seinen Lauf. Und es war Abend, und es war Morgen... Entschuldigung, das war nicht von dort.<\/p>\n

Alles wieder nicht zum Lob Gottes<\/h4>\n

\nGerade als sich alles beruhigt hatte, begannen verschiedene brillante \"Methodologen\", dicke B\u00fccher \u00fcber DevOps-Praktiken zu schreiben, es entbrannten leise Streitigkeiten dar\u00fcber, wer denn nun dieser ber\u00fcchtigte DevOps-Ingenieur ist und dass DevOps eine Produktionskultur ist, wieder machte sich Unzufriedenheit breit. Pl\u00f6tzlich stellte sich heraus, dass die Softwareauslieferung eine absolut knifflige Aufgabe ist. Jede Entwicklungsinfrastruktur hat ihren eigenen Stack; irgendwo muss man bauen, irgendwo die Umgebung einrichten, hier braucht man Tomcat, dort gibt es einen noch komplizierteren Weg, um zu starten \u2014 im Grunde schwirrt einem der Kopf. Und ein weiteres Problem, seltsamerweise, lag haupts\u00e4chlich in der Organisation der Prozesse \u2014 diese Lieferfunktion, wie ein Flaschenhals, begann, die Prozesse zu blockieren. Auch die Operations wurden nicht abgeschafft. Sie ist in dem V-Modell nicht sichtbar, und dort ist noch der ganze Lebenszyklus auf der rechten Seite. Am Ende muss man die Infrastruktur unterst\u00fctzen, auf das Monitoring achten, Vorf\u00e4lle managen und sich auch um die Auslieferung k\u00fcmmern. Das hei\u00dft, man sitzt mit einem Bein sowohl in der Entwicklung als auch in der Betriebstechnik \u2014 und pl\u00f6tzlich entstand so etwas wie Development & Operations. Und dann kam auch noch der allgemeine Hype um Microservices. Und damit begann die Entwicklung von lokalen Maschinen in die Cloud umzuziehen \u2014 versuche etwas lokal zu debuggieren, wenn es Dutzende und Hunderte von Microservices gibt, da wird die st\u00e4ndige Auslieferung zum \u00dcberlebensmittel. F\u00fcr eine \u201ekleine bescheidene Firma\u201c mag das noch gehen, aber was ist mit Google?<\/p>\n

SRE von Google<\/h4>\n

\nGoogle kam, fra\u00df die gr\u00f6\u00dften Kakteen und entschied \u2013 das brauchen wir nicht, wir brauchen Zuverl\u00e4ssigkeit. Und Zuverl\u00e4ssigkeit muss gemanagt werden. Also entschied er \u2013 wir brauchen Spezialisten, die die Zuverl\u00e4ssigkeit managen. Er nannte sie SR-Ingenieure und sagte, hier habt ihr alles, macht es wie gewohnt, gut. Hier habt ihr SLI, hier habt ihr SLO, hier habt ihr Monitoring. Und zeigte auf die Operationen. Und nannte sein \u201ezuverl\u00e4ssiges DevOps\u201c SRE. Scheinbar ist alles gut, aber es gibt einen schmutzigen Hack, den sich Google leisten konnte \u2013 f\u00fcr die Position der SR-Ingenieure Leute einzustellen, die die Qualifikation von Entwicklern hatten und zudem ein wenig von zu Hause aus die Funktionsweise arbeitender Systeme verstanden. Au\u00dferdem hat Google selbst Probleme bei der Einstellung solcher Leute \u2013 haupts\u00e4chlich, weil er ja auch mit sich selbst konkurriert \u2013 schlie\u00dflich muss irgendjemand die Gesch\u00e4ftslogik beschreiben. Die Auslieferung \u00fcbertrug er auf die Release-Ingenieure, SR-Ingenieure managen die Zuverl\u00e4ssigkeit (klar, nicht direkt, sondern durch Einfluss auf die Infrastruktur, \u00c4nderung der Architektur, \u00dcberwachung von \u00c4nderungen und Kennzahlen, sowie der Bearbeitung von Vorf\u00e4llen). Sch\u00f6n, man kann B\u00fccher schreiben<\/a><\/noindex>. Was aber tun, wenn man nicht Google ist und die Zuverl\u00e4ssigkeit dennoch ein Anliegen ist?<\/p>\n

Entwicklung von DevOps Ideen<\/h4>\n

\nHier kam Docker gerade recht, das aus lxc hervorging, ebenso wie verschiedene Orchestrierungssysteme wie Docker Swarm und Kubernetes, und die DevOps-Ingenieure atmeten auf \u2013 die Vereinheitlichung der Praktiken erleichterte die Auslieferung. Sie erleichterte es so sehr, dass es sogar m\u00f6glich wurde, die Auslieferung den Entwicklern zu \u00fcberlassen \u2013 was ist schon deployment.yaml? Containerisierung l\u00f6st das Problem. Au\u00dferdem ist die Reife der CI\/CD-Systeme mittlerweile auf dem Niveau, dass man eine Datei schreibt und alles losgeht \u2013 die Entwickler schaffen das selbst. Und hier fangen wir an zu sprechen, wie wir unser eigenes SRE machen, mit\u2026 naja, mit irgendjemandem. <\/p>\n

SRE nicht bei Google<\/h4>\n

\nNun gut, die Lieferung haben wir \u00fcbergeben, wir k\u00f6nnen scheinbar aufatmen und zu den alten guten Zeiten zur\u00fcckkehren, als die Admins die Prozessorlast \u00fcberwachten, Systeme optimierten und leise aus Tassen etwas Unverst\u00e4ndliches in Stille und Ruhe tranken... Halt. Daf\u00fcr haben wir das alles nicht gemacht (schade!). Pl\u00f6tzlich stellt sich heraus, dass wir aus dem Ansatz von Google gro\u00dfartige Praktiken \u00fcbernehmen k\u00f6nnen \u2014 nicht die Prozessorlast ist wichtig, und nicht wie oft wir die Platten dort wechseln oder wie wir im Cloud die Kosten optimieren, sondern die Gesch\u00e4ftskennzahlen \u2014 all die ber\u00fcchtigten SLx. Und das Management der Infrastruktur wurde uns nicht genommen, und Vorf\u00e4lle m\u00fcssen gel\u00f6st werden, und man muss gelegentlich Dienst schieben und \u00fcberhaupt in den Gesch\u00e4ftsprozessen auf dem Laufenden sein. Und Jungs, fangt an, schon langsam auf gutem Niveau zu programmieren, Google wartet schon auf euch.<\/p>\n

Zusammenfassend. Pl\u00f6tzlich, aber ihr seid schon m\u00fcde zu lesen und k\u00f6nnt es kaum erwarten, dem Autor einen Kommentar zum Artikel zu schreiben. DevOps als Praktik der Bereitstellung war, ist und wird sein. Und es wird nirgends hingehen. SRE als eine Sammlung von Betriebspraktiken macht diese Bereitstellung erfolgreich.
\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u043e \u043c\u043e\u0442\u0438\u0432\u0430\u043c \u0434\u0438\u0441\u043a\u0443\u0441\u0441\u0438\u0438 \u0432 \u0447\u0430\u0442\u0435 AWS Minsk Community \u0412 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u0440\u0430\u0437\u0433\u043e\u0440\u0430\u044e\u0442\u0441\u044f \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0435 \u0431\u0438\u0442\u0432\u044b \u043d\u0430 \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u043d\u044f\u0442\u0438\u044f DevOps \u0438 SRE. \u041d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u0443\u0436\u0435 \u0432\u043e \u043c\u043d\u043e\u0433\u043e\u043c \u0434\u0438\u0441\u043a\u0443\u0441\u0441\u0438\u0438 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443 \u0443\u0436\u0435 \u043d\u0430\u0431\u0438\u043b\u0438 \u043e\u0441\u043a\u043e\u043c\u0438\u043d\u0443, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u0438 \u043c\u043d\u0435, \u0440\u0435\u0448\u0438\u043b \u0432\u044b\u043d\u0435\u0441\u0442\u0438 \u043d\u0430 \u0441\u0443\u0434 \u0445\u0430\u0431\u0440\u0430-\u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u0430 \u0438 \u0441\u0432\u043e\u0439 \u0432\u0437\u0433\u043b\u044f\u0434 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443. \u0422\u0435\u043c, \u043a\u043e\u043c\u0443 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e, \u0434\u043e\u0431\u0440\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":55736,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55735","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Noch einmal zu DevOps und SRE | ProHoster","description":"Basierend auf der Diskussion im Chat der AWS Minsk Community zuletzt entfachen sich echte K\u00e4mpfe um die Definition des Begriffs.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/eshhe-raz-o-devops-i-sre","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0415\u0449\u0435 \u0440\u0430\u0437 \u043e DevOps \u0438 SRE | ProHoster","og:description":"\u041f\u043e \u043c\u043e\u0442\u0438\u0432\u0430\u043c \u0434\u0438\u0441\u043a\u0443\u0441\u0441\u0438\u0438 \u0432 \u0447\u0430\u0442\u0435 AWS Minsk Community \u0412 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u0440\u0430\u0437\u0433\u043e\u0440\u0430\u044e\u0442\u0441\u044f \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0435 \u0431\u0438\u0442\u0432\u044b \u043d\u0430 \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u043d\u044f\u0442\u0438\u044f.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/eshhe-raz-o-devops-i-sre","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-01-26T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:52+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55735","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:37:39","updated":"2022-10-05 06:23:35","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/55735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=55735"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/55735\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/55736"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=55735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=55735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=55735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}