{"id":39219,"date":"2019-10-31T22:28:31","date_gmt":"2019-10-31T19:28:31","guid":{"rendered":"https:\/\/prohoster.info\/blog\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire\/"},"modified":"2019-10-31T22:28:31","modified_gmt":"2019-10-31T19:28:31","slug":"devops-i-haos-dostavka-po-v-detsentralizovannom-mire","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","title":{"rendered":"DevOps und Chaos: Softwarebereitstellung in einer dezentralen Welt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Anton Weiss, Gr\u00fcnder und Direktor von \u201eOtomato Software\u201c sowie einer der Initiatoren und Ausbilder der ersten DevOps-Zertifizierung in Israel, sprach im vergangenen Jahr DevOpsDays Moscow<\/a><\/noindex> \u00fcber die Chaos-Theorie und die wichtigsten Prinzipien des Chaos Engineering und erkl\u00e4rte, wie die ideale DevOps-Organisation der Zukunft aussieht.<\/p>\n

Wir haben eine Textversion des Vortrags vorbereitet. <\/p>\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center>
\n<\/a><\/noindex>
\nGuten Morgen! <\/p>\n

Die DevOpsDays finden in Moskau zum zweiten Mal statt, ich stehe zum zweiten Mal auf dieser B\u00fchne, und viele von Ihnen sind zum zweiten Mal in diesem Saal. Was bedeutet das? Das bedeutet, dass die DevOps-Bewegung in Russland w\u00e4chst und sich vermehrt. Vor allem bedeutet es, dass es an der Zeit ist, dar\u00fcber zu sprechen, was DevOps im Jahr 2018 wirklich ist. <\/p>\n

Heben Sie die H\u00e4nde, wer denkt, dass DevOps im Jahr 2018 bereits ein Beruf ist? Es gibt solche. Gibt es im Saal DevOps-Ingenieure, die in ihrer Stellenbeschreibung \u201eDevOps-Ingenieur\u201c stehen haben? Gibt es im Saal DevOps-Manager? Solche gibt es nicht. DevOps-Architekten? Auch nicht. Das ist recht selten. Gibt es wirklich niemanden, der als DevOps-Ingenieur eingestuft ist?<\/p>\n

Denken die meisten von Ihnen, dass das ein Anti-Muster ist? Dass es so einen Beruf nicht geben sollte? Wir k\u00f6nnen denken, was wir wollen, w\u00e4hrend die Branche feierlich unter dem Klang der DevOps-Trompeten voranschreitet.<\/p>\n

Wer hat schon von dem neuen Konzept namens DevDevOps geh\u00f6rt? Es handelt sich um eine neue Methode, die eine effektive Zusammenarbeit zwischen Entwicklern und DevOps-Teams erm\u00f6glichen soll. So neu ist es allerdings nicht. Wenn man Twitter glauben darf, wurde vor 4 Jahren bereits dar\u00fcber gesprochen. Und das Interesse w\u00e4chst nach wie vor, was darauf hindeutet, dass es ein Problem gibt. Dieses Problem muss angegangen werden.<\/p>\n

\"DevOps
\n
\nWir sind kreative Menschen, die sich nicht einfach beruhigen lassen. Wir sagen: DevOps ist nicht umfassend genug, es fehlen viele interessante Elemente. Daher ziehen wir uns in unsere geheimen Labore zur\u00fcck und beginnen, kuriose Mutationen zu schaffen: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.<\/p>\n

\"DevOps
\n
\nDie Logik ist klar, oder? Unser Liefersystem funktioniert nicht, unsere Systeme sind instabil und die Nutzer unzufrieden, wir schaffen es nicht, Software rechtzeitig zu ver\u00f6ffentlichen und bleiben im Budget zur\u00fcck. Wie wollen wir all das l\u00f6sen? Wir erfinden ein neues Wort! Es wird auf \"Ops\" enden, und das Problem ist gel\u00f6st.<\/p>\n

So nenne ich diesen Ansatz \u2014 \"Ops, und das Problem ist gel\u00f6st\".<\/p>\n

All das tritt in den Hintergrund, wenn wir uns daran erinnern, warum wir all dies \u00fcberhaupt erfunden haben. Wir haben dieses DevOps konzipiert, um die Softwarelieferung und unsere Arbeit in diesem Prozess so reibungslos, schmerzfrei, effizient und vor allem angenehm wie m\u00f6glich zu gestalten. <\/p>\n

DevOps ist aus Schmerz gewachsen. Und wir haben genug gelitten. Damit das geschehen kann, st\u00fctzen wir uns auf zeitlose Praktiken: effektive Zusammenarbeit, Flie\u00dfpraktiken und vor allem systemisches Denken, denn ohne das funktioniert kein DevOps.<\/p>\n

Was ist ein System?<\/b><\/h3>\n

\nUnd da wir \u00fcber systemisches Denken gesprochen haben, lassen Sie uns daran erinnern, was ein System ist.<\/p>\n

\"DevOps
\n
\nWenn Sie ein revolution\u00e4rer Hacker sind, betrachten Sie Systeme eindeutig als \u00dcbel. Sie sind eine Bedrohung, die \u00fcber Ihnen schwebt und Sie zwingt, Dinge zu tun, die Sie nicht tun m\u00f6chten. <\/p>\n

\"DevOps
\n
\nAus der Perspektive des systemischen Denkens ist ein System ein Ganzes, das aus Teilen besteht. In diesem Sinne ist jeder von uns ein System. Die Organisationen, in denen wir arbeiten, sind Systeme. Das, was wir gemeinsam aufbauen, wird auch als System bezeichnet.<\/p>\n

All dies ist Teil eines gro\u00dfen soziotechnologischen Systems. Nur wenn wir verstehen, wie dieses soziotechnologische System gemeinsam funktioniert, k\u00f6nnen wir in dieser Angelegenheit wirklich optimieren. <\/p>\n

Aus der Perspektive des systemischen Denkens hat ein System verschiedene interessante Eigenschaften. Erstens besteht es aus Teilen, was bedeutet, dass sein Verhalten vom Verhalten der Teile abh\u00e4ngt. Dabei sind alle Teile auch wechselseitig abh\u00e4ngig. Das f\u00fchrt zu der Erkenntnis, dass je mehr Teile ein System hat, desto schwieriger wird es, sein Verhalten zu verstehen oder vorherzusagen. <\/p>\n

Aus Sicht des Verhaltens gibt es noch eine interessante Tatsache. Ein System kann Dinge tun, die keine seiner einzelnen Teile allein tun kann. <\/p>\n

Wie Dr. Russell Ackoff (einer der Begr\u00fcnder des systemischen Denkens) sagte, l\u00e4sst sich dies relativ leicht durch ein Gedankenexperiment beweisen. Wer hier im Raum kann Programmcode schreiben? Viele H\u00e4nde gehen hoch, und das ist normal, denn es ist eine der grundlegenden Anforderungen unseres Berufs. Eure H\u00e4nde sind in der Lage, Code zu schreiben, aber k\u00f6nnen sie das unabh\u00e4ngig von euch? Es gibt Leute, die sagen w\u00fcrden: \u201eNicht meine H\u00e4nde schreiben den Code, sondern mein Gehirn.\u201c Kann das Gehirn also unabh\u00e4ngig von euch Codes schreiben? Wahrscheinlich nicht. <\/p>\n

Das Gehirn ist eine erstaunliche Maschine, von der wir nicht einmal 10% verstehen, wie sie funktioniert, aber es kann nicht unabh\u00e4ngig von dem System, dem unser K\u00f6rper ist, agieren. Das l\u00e4sst sich leicht beweisen: \u00d6ffnet euren Sch\u00e4del, nehmt das Gehirn heraus, legt es vor den Computer und lasst es versuchen, etwas Einfaches zu schreiben. Zum Beispiel \"Hello, world\" in Python.<\/p>\n

Wenn ein System etwas tun kann, was keine der einzelnen Komponenten allein tun kann, bedeutet das, dass sein Verhalten nicht durch das Verhalten seiner Teile bestimmt wird. Was bestimmt es dann? Es wird durch die Interaktionen zwischen diesen Teilen bestimmt. Je mehr Teile es gibt, desto komplexer sind die Interaktionen, desto schwieriger ist es, das Verhalten des Systems zu verstehen und vorherzusagen. Das macht ein solches System chaotisch, denn selbst die kleinste, f\u00fcr das Auge unsichtbare Ver\u00e4nderung in einem der Teile des Systems kann zu v\u00f6llig unvorhersehbaren Ergebnissen f\u00fchren. <\/p>\n

Diese Sensibilit\u00e4t gegen\u00fcber den Anfangsbedingungen wurde erstmals vom amerikanischen Meteorologen Edward Lorenz entdeckt und untersucht. Sp\u00e4ter erhielt sie den Namen \u201eSchmetterlingseffekt\u201c und f\u00fchrte zur Entwicklung einer Denkrichtung in der Wissenschaft, die als \u201eChaos-Theorie\u201c bekannt ist. Diese Theorie war eines der grundlegenden Paradigmenwechsel in der Wissenschaft des 20. Jahrhunderts.<\/p>\n

Chaos-Theorie<\/b><\/h3>\n

\nMenschen, die sich mit dem Studium des Chaos besch\u00e4ftigen, nennen sich Chaosologen.<\/p>\n

\"DevOps
\n
\nDer Grund f\u00fcr diesen Bericht ist, dass ich beim Arbeiten mit komplexen verteilten Systemen und gro\u00dfen internationalen Organisationen irgendwann realisiert habe, dass ich mich als Chaosoperator f\u00fchle. Das ist eine raffinierte Art zu sagen: \u201eIch verstehe nicht, was hier vor sich geht, und ich wei\u00df nicht, was ich damit anfangen soll.\u201c <\/p>\n

Ich denke, viele von Ihnen f\u00fchlen sich ebenso, also sind auch Sie Chaosoperatoren. Ich lade Sie ein, der Gilde der Chaosoperatoren beizutreten. Die Systeme, die wir, liebe Kollegen Chaosoperatoren, untersuchen werden, werden als \u201ekomplexe adaptive Systeme\u201c bezeichnet. <\/p>\n

Was ist Adaptivit\u00e4t? Adaptivit\u00e4t bedeutet, dass das individuelle und kollektive Verhalten der Teile in einem solchen adaptiven System sich ver\u00e4ndert und sich selbst organisiert, um auf Ereignisse oder Ketten von Mikroeignissen im System zu reagieren. Das hei\u00dft, das System passt sich durch Selbstorganisation an Ver\u00e4nderungen an. Diese F\u00e4higkeit zur Selbstorganisation basiert auf freiwilliger, vollst\u00e4ndig dezentraler Zusammenarbeit freier, autonomer Akteure.<\/p>\n

Eine weitere interessante Eigenschaft solcher Systeme ist ihre uneingeschr\u00e4nkte Skalierbarkeit. Das sollte uns als Chaologen-Ingenieure sicherlich interessieren. Wenn wir also sagen, dass das Verhalten eines komplexen Systems durch das Zusammenspiel seiner Teile bestimmt wird, was sollten wir dann im Auge behalten? Das Zusammenspiel. <\/p>\n

Es gibt noch zwei weitere interessante Erkenntnisse.
\n \"DevOps
\n
\nErstens verstehen wir, dass man ein komplexes System nicht vereinfachen kann, indem man seine Teile vereinfacht. Zweitens ist der einzige Weg, ein komplexes System zu vereinfachen, die Vereinfachung der Interaktionen zwischen diesen Teilen. <\/p>\n

Wie interagieren wir? Wir alle sind Teile eines gro\u00dfen Informationssystems, das menschliche Gesellschaft genannt wird. Wir interagieren durch eine gemeinsame Sprache, wenn wir eine haben, wenn wir sie finden.<\/p>\n

\"DevOps
\n
\nAber die Sprache selbst ist ein komplexes, adaptives System. Daher ben\u00f6tigen wir, um effektiver und einfacher zu interagieren, die Schaffung bestimmter Protokolle. Also eine Abfolge von Symbolen und Handlungen, die den Austausch von Informationen zwischen uns einfacher, vorhersehbarer und verst\u00e4ndlicher machen.<\/p>\n

Ich m\u00f6chte sagen, dass die Tendenzen zu Komplexit\u00e4t, Adaptivit\u00e4t, Dezentralisierung und Chaos \u00fcberall zu erkennen sind. Sowohl in den Systemen, die wir gemeinsam aufbauen, als auch in den Systemen, von denen wir Teil sind.<\/p>\n

Um nicht nur zu behaupten, schauen wir uns an, wie sich die Systeme, die wir erschaffen, ver\u00e4ndern.<\/p>\n

\"DevOps
\n
\nIch verstehe, dass Sie auf dieses Wort gewartet haben. Wir sind auf einer DevOps-Konferenz, heute wird dieses Wort etwa hunderttausend Mal gesagt werden und uns sp\u00e4ter nachts tr\u00e4umen.<\/p>\n

Mikroservices sind die erste Softwarearchitektur, die als Reaktion auf DevOps-Praktiken entstanden ist. Sie soll unsere Systeme flexibler und skalierbarer machen und eine kontinuierliche Lieferung gew\u00e4hrleisten. Wie erreicht sie das? Durch die Reduzierung der Anzahl der Dienste, die Einschr\u00e4nkung der Problembereiche, die diese Dienste abdecken, und durch die Verk\u00fcrzung der Lieferzeit. Das hei\u00dft, wir vereinfachen Teile des Systems, erh\u00f6hen deren Anzahl, was zwangsl\u00e4ufig die Komplexit\u00e4t der Interaktionen zwischen diesen Teilen erh\u00f6ht \u2013 dabei entstehen neue Probleme, die wir l\u00f6sen m\u00fcssen.<\/p>\n

\"DevOps
\n
\nMikroservices sind noch nicht das Ende; sie geh\u00f6ren eigentlich schon der Vergangenheit an, denn Serverless steht vor der T\u00fcr. Alle Server sind in Flammen aufgegangen, es gibt keine Server mehr, keine Betriebssysteme, nur reiner ausf\u00fchrbarer Code. Konfigurationen sind separat, Zust\u00e4nde sind separat, alles wird durch Ereignisse gesteuert. Sch\u00f6nheit, Klarheit, Stille \u2013 keine Ereignisse, nichts passiert, alles in bester Ordnung. <\/p>\n

Wo liegt die Herausforderung? Die Herausforderung liegt, das ist offensichtlich, in den Wechselwirkungen. Wie viel kann eine Funktion allein bewirken? Wie interagiert sie mit anderen Funktionen? Nachrichtenqueues, Datenbanken, Load Balancer. Wie kann man ein Ereignis rekonstruieren, wenn ein Fehler aufgetreten ist? Eine Menge Fragen und nur wenige Antworten.<\/p>\n

Mikroservices und Serverless sind alles, was wir, die Computer-Hipster, Cloud Native nennen. Es dreht sich alles um die Cloud. Aber die Cloud ist in ihrer Natur ebenfalls in der Skalierbarkeit eingeschr\u00e4nkt. Wir gew\u00f6hnen uns daran, sie als verteiltes System zu betrachten. Aber wo leben die Server der Cloud-Anbieter? In Rechenzentren. Das hei\u00dft, wir haben hier eine zentralisierte, sehr begrenzte, verteilte Modell.<\/p>\n

Heute verstehen wir, dass das Internet der Dinge nicht nur leere Worte sind. Selbst gem\u00e4\u00df bescheidenen Prognosen werden uns in den n\u00e4chsten f\u00fcnf bis zehn Jahren Milliarden von Ger\u00e4ten erwarten, die mit dem Internet verbunden sind. Eine riesige Menge an n\u00fctzlichen und unn\u00fctzen Daten wird in die Cloud flie\u00dfen und von dort abgerufen werden. <\/p>\n

Die Cloud wird dem nicht standhalten, weshalb wir immer mehr \u00fcber das sprechen, was als \u201eEdge-Computing\u201c bezeichnet wird. Oder wie ich die wunderbare Definition \u201eFog-Computing\u201c nenne. Es hat etwas Mystisches, Romantisches und Geheimnisvolles.<\/p>\n

\"DevOps
\n
\nFog-Computing. Hierbei geht es darum, dass Clouds zentralisierte Ansammlungen von Wasser, Dampf, Eis und Steinen sind. Der Nebel sind die Wassertropfen, die in der Atmosph\u00e4re um uns herum verteilt sind. <\/p>\n

In der Nebelpraxis wird der Gro\u00dfteil der Arbeit von diesen Tropfen v\u00f6llig autonom oder in Zusammenarbeit mit anderen Tropfen erledigt. Sie wenden sich an die Cloud, nur wenn es wirklich notwendig ist. <\/p>\n

Das bedeutet erneut Dezentralisierung, Autonomie, und viele von Ihnen verstehen wahrscheinlich bereits, worauf das alles hinausl\u00e4uft, denn man kann nicht \u00fcber Dezentralisierung sprechen, ohne auch Blockchain zu erw\u00e4hnen. <\/p>\n

\"DevOps
\n
\nEs gibt Menschen, die daran glauben, das sind die, die in Kryptow\u00e4hrungen investiert haben. Es gibt diejenigen, die daran glauben, aber Angst haben, so wie ich. Und dann gibt es die, die nicht glauben. Man kann dazu unterschiedliche Meinungen haben. Es gibt eine Technologie, ein neues, unverst\u00e4ndliches Feld, und es gibt Probleme. Wie jede neue Technologie wirft sie mehr Fragen auf, als sie Antworten liefert. <\/p>\n

Der Hype um die Blockchain ist nachvollziehbar. Selbst wenn man die Goldgr\u00e4berstimmung beiseite l\u00e4sst, bietet die Technologie gro\u00dfartige Versprechen f\u00fcr eine strahlende Zukunft: mehr Freiheit, mehr Autonomie, ein globales, verteiltes Vertrauen. Was k\u00f6nnte man daran nicht m\u00f6gen? <\/p>\n

Dementsprechend beginnen immer mehr Ingenieure auf der ganzen Welt, dezentrale Anwendungen zu entwickeln. Und das ist eine Kraft, die man nicht einfach ignorieren kann, indem man sagt: \u201eAch, die Blockchain ist lediglich eine schlecht implementierte verteilte Datenbank.\u201c Oder wie Skeptiker gerne sagen: \u201eF\u00fcr die Blockchain gibt es keine realen Anwendungen.\u201c Wenn man dar\u00fcber nachdenkt, haben die Leute vor 150 Jahren das Gleiche \u00fcber Elektrizit\u00e4t gesagt. Und in gewisser Weise hatten sie recht, denn das, was Elektrizit\u00e4t heute erm\u00f6glicht, war im 19. Jahrhundert absolut unerreichbar.<\/p>\n

\u00dcbrigens, wer wei\u00df, welches Logo auf dem Bildschirm zu sehen ist? Das ist Hyperledger. Ein Projekt, das unter der \u00c4gide der Linux Foundation entwickelt wird und ein Set von Blockchain-Technologien umfasst. Das ist wirklich die St\u00e4rke unserer Open-Source-Community.<\/p>\n

Chaos Engineering<\/b><\/h3>\n

\n\"DevOps
\n
\nDie Systeme, die wir entwickeln, werden immer komplexer, chaotischer und anpassungsf\u00e4higer. Netflix ist ein Pionier im Bereich der Mikrodienste. Sie geh\u00f6rten zu den ersten, die das verstanden haben, und sie entwickelten eine Reihe von Werkzeugen, die sie Simian Army genannt haben, von denen das bekannteste Chaos Monkey<\/a><\/noindex>ist. Er definierte das, was als \u00bbPrinzipien des Chaos Engineering\u00ab<\/a><\/noindex>.<\/p>\n

\u00dcbrigens haben wir bei der Arbeit an der Pr\u00e4sentation diesen Text sogar ins Russische \u00fcbersetzt, also schaut euch den Link<\/a><\/noindex>an, lest ihn, kommentiert und kritisiert.<\/p>\n

Kurz gesagt, die Prinzipien des Chaos Engineering besagen Folgendes: Komplexe verteilte Systeme sind von Natur aus unberechenbar und haben an ihrer Basis Fehler. Fehler sind unvermeidlich, und das bedeutet, dass wir diese Fehler akzeptieren und mit diesen Systemen ganz anders umgehen m\u00fcssen. <\/p>\n

Wir m\u00fcssen selbst versuchen, diese Fehler in unsere Produktionssysteme einzubringen, um unsere Systeme auf deren Anpassungsf\u00e4higkeit, Selbstorganisation und \u00dcberlebensf\u00e4higkeit zu testen. <\/p>\n

Und das \u00e4ndert alles. Nicht nur, wie wir Systeme in die Produktion bringen, sondern auch, wie wir sie entwickeln und testen. Es gibt keinen Stabilisationsprozess, keine Code-Freigabe, sondern einen kontinuierlichen Prozess der Destabilisierung. Wir versuchen, das System zum Scheitern zu bringen und zu sehen, ob es dennoch \u00fcberlebt.<\/p>\n

Protokolle zur Integration verteilter Systeme<\/b><\/h3>\n

\n\"DevOps
\n
\nDas erfordert von unseren Systemen, dass sie sich ebenfalls \u00e4ndern. Um robuster zu werden, ben\u00f6tigen sie neue Interaktionsprotokolle zwischen ihren Komponenten. Damit diese Teile kommunizieren und eine Form der Selbstorganisation erreichen k\u00f6nnen, entstehen zahlreiche neue Werkzeuge und Protokolle, die ich als \u201eInteraktionsprotokolle verteilter Systeme\u201c bezeichne.<\/p>\n

\"DevOps
\n
\nWovon spreche ich? Zun\u00e4chst einmal vom Projekt Opentracing<\/a><\/noindex>. Ein Versuch, ein gemeinsames Protokoll f\u00fcr verteiltes Tracking zu schaffen, ist ein unerl\u00e4ssliches Werkzeug zur Fehlersuche in komplexen verteilten Systemen.<\/p>\n

\"DevOps
\n
\nAls N\u00e4chstes folgt Open Policy Agent<\/a><\/noindex>. Wir k\u00f6nnen nicht vorhersagen, was mit dem System passieren wird, daher m\u00fcssen wir seine Observability, also die Sichtbarkeit erh\u00f6hen. Opentracing geh\u00f6rt zur Familie von Werkzeugen, die die Observability unserer Systeme bieten. Aber Observability ist n\u00f6tig, um festzustellen, ob das System sich so verh\u00e4lt, wie wir es erwarten oder nicht. Wie bestimmen wir das erwartete Verhalten? Durch die Definition einer Art von Richtlinie, eines Regelwerks. Das Projekt Open Policy Agent besch\u00e4ftigt sich mit der Definition dieses Regelwerks in einem breiten Spektrum: von Zugriffsrechten bis hin zur Ressourcenzuteilung.<\/p>\n

\"DevOps
\n
\nWie bereits erw\u00e4hnt, werden unsere Systeme zunehmend ereignisgesteuert. Serverless ist ein hervorragendes Beispiel f\u00fcr ereignisgesteuerte Systeme. Damit wir Ereignisse zwischen Systemen weiterleiten und deren Verlauf verfolgen k\u00f6nnen, ben\u00f6tigen wir eine gemeinsame Sprache, ein gemeinsames Protokoll, um \u00fcber Ereignisse zu kommunizieren und sie zu \u00fcbermitteln. Dies wird durch ein Projekt namens Cloudevents<\/a><\/noindex>.<\/p>\n

\"DevOps
\n
\nEin kontinuierlicher Fluss von Ver\u00e4nderungen, der unsere Systeme umh\u00fcllt und sie st\u00e4ndig destabilisiert, ist ein st\u00e4ndiger Strom von Software-Artefakten. Damit wir diesen kontinuierlichen Fluss von Ver\u00e4nderungen aufrechterhalten k\u00f6nnen, ben\u00f6tigen wir einen gemeinsamen Protokoll, um dar\u00fcber zu sprechen, was ein Software-Artefakt ist, wie es gepr\u00fcft wird und welche Validierung es durchlaufen hat. Damit besch\u00e4ftigt sich ein Projekt namens Grafeas<\/a><\/noindex>. Das ist also ein gemeinsames Protokoll f\u00fcr Metadaten von Software-Artefakten.<\/p>\n

\"DevOps
\n
\nUnd schlie\u00dflich, wenn wir m\u00f6chten, dass unsere Systeme vollst\u00e4ndig autark, anpassungsf\u00e4hig und selbstorganisierend sind, m\u00fcssen wir ihnen das Recht auf Selbstidentifikation geben. Ein Projekt namens spiffe<\/a><\/noindex> k\u00fcmmert sich genau darum. Dies ist ebenfalls ein Projekt unter dem Dach der Cloud Native Computing Foundation.<\/p>\n

All diese Projekte sind jung und ben\u00f6tigen unsere Unterst\u00fctzung und \u00dcberpr\u00fcfung. Es handelt sich um Open-Source-Code, unser Test, unsere Implementierung. Sie zeigen uns, in welche Richtung sich die Technologie entwickelt. <\/p>\n

DevOps war jedoch nie in erster Linie Technologie; vielmehr ging es immer um die Zusammenarbeit zwischen Menschen. Und entsprechend, wenn wir m\u00f6chten, dass die Systeme, die wir entwickeln, sich \u00e4ndern, m\u00fcssen auch wir uns \u00e4ndern. Tats\u00e4chlich ver\u00e4ndert sich bereits, wir haben nicht wirklich eine Wahl. <\/p>\n

\"DevOps
\n
\nEs gibt ein wunderbares Buch<\/a><\/noindex> der britischen Autorin Rachel Botsman, in dem sie \u00fcber die Evolution des Vertrauens im Laufe der Menschheitsgeschichte schreibt. Sie erkl\u00e4rt, dass Vertrauen urspr\u00fcnglich in primitiven Gesellschaften lokal war, das hei\u00dft, wir vertrauten nur denjenigen, die wir pers\u00f6nlich kannten. <\/p>\n

Dann gab es eine sehr lange Zeit \u2014 eine dunkle Epoche, in der Vertrauen zentralisiert war, als wir anfingen, Menschen, die wir nicht kannten, aufgrund der Tatsache zu vertrauen, dass wir zu demselben sozialen oder staatlichen Institut geh\u00f6rten.<\/p>\n

Und das sehen wir in unserer modernen Welt: Vertrauen wird zunehmend verteilt und dezentralisiert, und es basiert auf der Freiheit der Informationsstr\u00f6me und der Zug\u00e4nglichkeit von Informationen. <\/p>\n

Wenn man dar\u00fcber nachdenkt, ist es genau diese Verf\u00fcgbarkeit, die Vertrauen schafft, und die setzen wir um. Das bedeutet, dass sich auch unsere Zusammenarbeit und die Art und Weise, wie wir arbeiten, \u00e4ndern m\u00fcssen, denn die zentralisierten, hierarchischen IT-Organisationen der alten Schule funktionieren nicht mehr. Sie beginnen, auszusterben. <\/p>\n

Grundlagen der DevOps-Organisation<\/b><\/h3>\n

\nDie ideale DevOps-Organisation der Zukunft ist ein dezentrales, anpassungsf\u00e4higes System, das aus autonomen Teams besteht, die jeweils aus selbst\u00e4ndigen Individuen bestehen. Diese Teams sind weltweit verteilt und arbeiten effizient miteinander durch asynchrone Kommunikation und hochtransparente Informationsaustauschprotokolle. Sehr sch\u00f6n, oder? Eine wundersch\u00f6ne Zukunft.<\/p>\n

Nat\u00fcrlich ist all dies ohne kulturelle Ver\u00e4nderungen unm\u00f6glich. Wir ben\u00f6tigen transformationales Leadership, pers\u00f6nliche Verantwortung und innere Motivation.<\/p>\n

\"DevOps
\n
\nDas ist die Grundlage von DevOps-Organisationen: Transparenz der Informationen, asynchrone Kommunikation, transformationales Leadership, Dezentralisierung. <\/p>\n

Burnout<\/b><\/h3>\n

\nDie Systeme, zu denen wir geh\u00f6ren und die wir aufbauen, werden zunehmend chaotisch, und es f\u00e4llt uns, den Menschen, schwer, mit diesem Gedanken umzugehen. Wir versuchen weiterhin, sie zu kontrollieren, was oft zu Ersch\u00f6pfung f\u00fchrt. Ich spreche aus eigener Erfahrung \u2013 ich habe auch Fehler gemacht und wurde durch unerwartete Ausf\u00e4lle im Produktionsumfeld beeintr\u00e4chtigt.<\/p>\n

\"DevOps
\n
\nErsch\u00f6pfung tritt auf, wenn wir versuchen, das zu kontrollieren, was von Natur aus nicht kontrollierbar ist. Wenn wir ersch\u00f6pft sind, verliert alles seinen Sinn, weil wir das Verlangen verlieren, etwas Neues zu schaffen. Wir nehmen eine defensive Haltung ein und beginnen, das zu verteidigen, was wir haben. <\/p>\n

Der Ingenieurberuf, wie ich mir oft gerne ins Ged\u00e4chtnis rufe, ist in erster Linie ein kreativer Beruf. Wenn wir das Verlangen verlieren, etwas zu schaffen, verwandeln wir uns in Asche, werden zu Staub. Menschen werden ersch\u00f6pft, ganze Organisationen brennen aus.<\/p>\n

Meiner Meinung nach ist nur die Akzeptanz der sch\u00f6pferischen Kraft des Chaos und der Aufbau von Zusammenarbeit nach seinen Prinzipien der Weg, wie wir das Gute, das in unserem Beruf steckt, bewahren k\u00f6nnen. <\/p>\n

Was ich Ihnen w\u00fcnsche: Lieben Sie Ihre Arbeit, lieben Sie, was wir tun. Diese Welt n\u00e4hrt sich von Informationen, und wir haben die Ehre, sie zu versorgen. Lassen Sie uns also das Chaos studieren, Chaosologen werden, Wert schaffen, etwas Neues kreieren. Die Probleme, das haben wir bereits festgestellt, sind unvermeidlich, und wenn sie auftreten, sagen wir einfach \u201eOps!\u201c, und das Problem ist gel\u00f6st. <\/p>\n

Was gibt es au\u00dfer Chaos Monkey?<\/b><\/p>\n

Tats\u00e4chlich sind all diese Werkzeuge noch jung. Netflix baute ihre Werkzeuge selbst. Bauen Sie Werkzeuge f\u00fcr sich selbst. Lesen Sie die Prinzipien der Chaos-Engineering und halten Sie sich an diese Prinzipien, anstatt nach anderen Tools zu suchen, die jemand anders bereits erstellt hat. <\/p>\n

Versuchen Sie zu verstehen, wie Ihre Systeme ausfallen, und beginnen Sie, sie absichtlich zu besch\u00e4digen, um zu sehen, wie sie mit den Schl\u00e4gen umgehen. Das hat oberste Priorit\u00e4t. Werkzeuge k\u00f6nnen Sie sp\u00e4ter suchen. Es gibt viele Projekte. <\/p>\n

Ich habe nicht ganz verstanden, als Sie sagten, dass man ein System nicht vereinfachen kann, indem man seine Komponenten vereinfacht, und sofort auf Mikroservices \u00fcbergingen, die genau das System durch die Vereinfachung der Komponenten vereinfachen und die Interaktionen komplizierter machen. Das sind im Grunde zwei Teile, die sich gegenseitig widersprechen. <\/b><\/p>\n

Ganz genau, Microservices sind ein \u00e4u\u00dferst umstrittenes Thema. Tats\u00e4chlich erh\u00f6ht die Aufsplitterung in kleinere Teile die Flexibilit\u00e4t. Was bringen uns Microservices? Sie bieten uns Flexibilit\u00e4t und Geschwindigkeit, jedoch keinen Zugewinn an Einfachheit. Sie erh\u00f6hen die Komplexit\u00e4t.<\/p>\n

Bedeutet das, dass Microservices in der DevOps-Philosophie nicht wirklich vorteilhaft sind?<\/b><\/p>\n

Jedes Gute hat seine Schattenseiten. Es gibt Vorteile: Es erh\u00f6ht die Flexibilit\u00e4t und erm\u00f6glicht uns schnellere Anpassungen, aber es steigert auch die Komplexit\u00e4t und damit die Fragilit\u00e4t des gesamten Systems. <\/p>\n

Worauf sollte der Fokus mehr liegen: auf der Vereinfachung der Interaktionen oder auf der Vereinfachung der einzelnen Teile?<\/b> <\/p>\n

Der Fokus liegt zweifellos auf der Vereinfachung der Interaktionen, denn wenn wir betrachten, wie wir zusammenarbeiten, sollte die Hauptaufmerksamkeit auf der Vereinfachung der Interaktionen liegen, nicht auf der Vereinfachung der Arbeit jedes Einzelnen. Denn Arbeit zu vereinfachen w\u00e4re, uns zu Robotern zu machen. Bei McDonald's funktioniert das gut, wenn man genau vorgegeben bekommt: Hier den Burger hinlegen, hier die So\u00dfe draufgeben. Das funktioniert in unserer kreativen Arbeit \u00fcberhaupt nicht.<\/p>\n

Ist es wirklich so, dass alles, was Sie beschrieben haben, in einer Welt ohne Konkurrenz existiert, in der das Chaos so freundlich ist und keine Widerspr\u00fcche innerhalb dieses Chaos vorhanden sind, niemand will jemanden essen oder t\u00f6ten? Wie sollten Konkurrenz und DevOps zusammen existieren?<\/b><\/p>\n

Nun, das h\u00e4ngt davon ab, von welcher Konkurrenz wir sprechen. Geht es um Konkurrenz am Arbeitsplatz oder um Konkurrenz zwischen Unternehmen? <\/p>\n

Es geht um die Konkurrenz von Diensten, die existieren, denn Dienste sind nicht nur mehrere Unternehmen. Wir schaffen eine neue Art von Informationsumgebung, und jede Umgebung kann nicht ohne Konkurrenz existieren. \u00dcberall gibt es Konkurrenz.<\/b><\/p>\n

Nehmen wir Netflix als Beispiel. Warum haben sie das entwickelt? Weil sie wettbewerbsf\u00e4hig sein mussten. Diese Flexibilit\u00e4t und Geschwindigkeit sind genau das, was das Wettbewerbsumfeld erfordert, und sie bringen Unordnung in unsere Systeme. Chaos ist also nicht etwas, das wir absichtlich schaffen, weil wir es wollen; es geschieht aufgrund der Anforderungen der Welt. Wir m\u00fcssen uns einfach anpassen. Und Chaos ist genau das Ergebnis von Konkurrenz.<\/p>\n

Das bedeutet, dass Chaos das Fehlen von Zielen ist? Oder sind es die Ziele, die wir nicht sehen wollen? Wir sind in unserem eigenen Raum und verstehen die Ziele anderer nicht. Der Wettbewerb ergibt sich tats\u00e4chlich daraus, dass wir klare Ziele haben und wissen, wo wir im n\u00e4chsten Moment sein werden. Darin liegt aus meiner Sicht das Wesen von DevOps.<\/b><\/p>\n

Das ist auch eine Sichtweise. Ich denke, unser gemeinsames Ziel ist es, zu \u00fcberleben und das mit
\nmaximalem Genuss zu tun. Und das konkurrierende Ziel jeder Organisation ist dasselbe. Das \u00dcberleben erfolgt oft im Wettbewerb, da l\u00e4sst sich nichts machen.<\/p>\n

In diesem Jahr findet die Konferenz DevOpsDays Moscow<\/a><\/noindex> am 7. Dezember im \u201eTechnopolis\u201c statt. Wir nehmen bis zum 11. November Vorschl\u00e4ge f\u00fcr Vortr\u00e4ge an. Kontaktieren Sie<\/a><\/noindex> uns, wenn Sie einen Vortrag halten m\u00f6chten.<\/p>\n

Die Registrierung f\u00fcr Teilnehmer ist er\u00f6ffnet, das Ticket kostet 7000 Rubel. Kommen Sie dazu! \n<\/p><\/blockquote>\n

Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440 \u00abOtomato Software\u00bb, \u043e\u0434\u0438\u043d \u0438\u0437 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0442\u043e\u0440\u043e\u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0418\u0437\u0440\u0430\u0438\u043b\u0435 DevOps-\u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u0410\u043d\u0442\u043e\u043d \u0412\u0430\u0439\u0441 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u043d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e\u0434\u043d\u0435\u043c DevOpsDays Moscow \u043f\u0440\u043e \u0442\u0435\u043e\u0440\u0438\u044e \u0445\u0430\u043e\u0441\u0430 \u0438 \u0433\u043b\u0430\u0432\u043d\u044b\u0435 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0445\u0430\u043e\u0441\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0438\u0438, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043e\u0431\u044a\u044f\u0441\u043d\u0438\u043b, \u043a\u0430\u043a \u0443\u0441\u0442\u0440\u043e\u0435\u043d\u0430 \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u0430\u044f DevOps-\u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f \u0431\u0443\u0434\u0443\u0449\u0435\u0433\u043e. \u041c\u044b \u043f\u0440\u0438\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0442\u0435\u043a\u0441\u0442\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u0414\u043e\u0431\u0440\u043e\u0435 \u0443\u0442\u0440\u043e! DevOpsDays \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 \u0432\u0442\u043e\u0440\u043e\u0439 \u0433\u043e\u0434 \u043f\u043e\u0434\u0440\u044f\u0434, \u044f \u0432\u0442\u043e\u0440\u043e\u0439 \u0440\u0430\u0437 \u043d\u0430 \u044d\u0442\u043e\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29435,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39219","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\udd47DevOps und Chaos: Software-Lieferung in einer dezentralen Welt | ProHoster","description":"Anton Weiss, Gr\u00fcnder und Gesch\u00e4ftsf\u00fchrer von \u201eOtomato Software\u201c und einer der Initiatoren und Ausbilder der ersten DevOps-Zertifizierung in Israel, sprach auf den letzten DevOpsDays in Moskau \u00fcber die Chaos-Theorie und die Hauptprinzipien der Chaos-Ingenieurwissenschaft sowie dar\u00fcber, wie eine ideale DevOps-Organisation der Zukunft aussehen sollte. Wir haben eine Textversion des Vortrags vorbereitet. Guten Morgen! DevOpsDays in Moskau findet nun schon im zweiten Jahr in Folge statt, ich bin das zweite Mal dabei.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","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\u0414\u0435\u0432\u041e\u043f\u0441 \u0438 \u0425\u0430\u043e\u0441: \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0430 \u041f\u041e \u0432 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u043e\u043c \u043c\u0438\u0440\u0435 | ProHoster","og:description":"\u041e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440 \u00abOtomato Software\u00bb, \u043e\u0434\u0438\u043d \u0438\u0437 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0442\u043e\u0440\u043e\u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0418\u0437\u0440\u0430\u0438\u043b\u0435 DevOps-\u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u0410\u043d\u0442\u043e\u043d \u0412\u0430\u0439\u0441 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u043d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e\u0434\u043d\u0435\u043c DevOpsDays Moscow \u043f\u0440\u043e \u0442\u0435\u043e\u0440\u0438\u044e \u0445\u0430\u043e\u0441\u0430 \u0438 \u0433\u043b\u0430\u0432\u043d\u044b\u0435 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0445\u0430\u043e\u0441\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0438\u0438, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043e\u0431\u044a\u044f\u0441\u043d\u0438\u043b, \u043a\u0430\u043a \u0443\u0441\u0442\u0440\u043e\u0435\u043d\u0430 \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u0430\u044f DevOps-\u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f \u0431\u0443\u0434\u0443\u0449\u0435\u0433\u043e. \u041c\u044b \u043f\u0440\u0438\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0442\u0435\u043a\u0441\u0442\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u0414\u043e\u0431\u0440\u043e\u0435 \u0443\u0442\u0440\u043e! DevOpsDays \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 \u0432\u0442\u043e\u0440\u043e\u0439 \u0433\u043e\u0434 \u043f\u043e\u0434\u0440\u044f\u0434, \u044f \u0432\u0442\u043e\u0440\u043e\u0439 \u0440\u0430\u0437 \u043d\u0430 \u044d\u0442\u043e\u0439","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","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":"2019-10-31T19:28:31+00:00","article:modified_time":"2019-10-31T19:28:31+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39219","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":"2026-01-24 01:19:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:41","updated":"2026-01-24 01:19:20"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/39219","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=39219"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/39219\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/29435"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=39219"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=39219"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=39219"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}