{"id":38981,"date":"2019-10-31T22:27:10","date_gmt":"2019-10-31T19:27:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury\/"},"modified":"2019-10-31T22:27:10","modified_gmt":"2019-10-31T19:27:10","slug":"servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","title":{"rendered":"Orphan-Services: Die Kehrseite der (Mikro)Service-Architektur","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Andrey Nikolsky, der Direktor f\u00fcr den Betrieb des Portals Banki.ru, sprach auf der letztj\u00e4hrigen Konferenz DevOpsDays Moscow<\/a><\/noindex> \u00fcber Orphan-Services: wie man ein Waisenkind in der Infrastruktur identifiziert, was an Orphan-Services schlecht ist, was man damit machen sollte und wie man vorgeht, wenn nichts hilft.<\/p>\n

Hier ist die schriftliche Version des Vortrags. <\/p>\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex>
\nGuten Tag, Kollegen! Mein Name ist Andrey und ich leite den Betrieb bei Banki.ru.<\/p>\n

Wir haben gro\u00dfe Services, das sind sogenannte Monolith-Services, es gibt Services im klassischen Sinne und es gibt auch ganz kleine. In meiner praktischen Terminologie sage ich, wenn ein Service einfach und klein ist, dann ist er mikro, und wenn er nicht ganz einfach und nicht klein ist, dann ist es einfach ein Service. <\/p>\n

Vorteile der Services<\/b><\/h3>\n

\nIch gehe schnell durch die Vorteile der Services. <\/p>\n

\"Orphan-Services:
\n
\nErstens \u2013 Skalierbarkeit. Sie k\u00f6nnen schnell etwas auf dem Service machen und in die Produktion starten. Wenn der Traffic kommt, klonen Sie den Service. Wenn noch mehr Traffic kommt, klonen Sie noch einmal und leben damit. Das ist ein guter Bonus und, grunds\u00e4tzlich, als wir angefangen haben, galt er als der wichtigste Grund, warum wir all das tun.<\/p>\n

\"Orphan-Services:
\n
\nZweitens gibt es die isolierte Entwicklung, wenn Sie mehrere Entwicklungsteams haben, mit verschiedenen Entwicklern in jedem Team, und jedes Team arbeitet an einem eigenen Service.<\/p>\n

Es gibt einige Nuancen mit den Teams. Die Entwickler sind unterschiedlich. Beispielsweise gibt es Schneeflocken-Menschen<\/a><\/noindex>. Ich habe das zum ersten Mal bei Maxim Dorofeev gesehen. Manchmal gibt es Schneeflocken-Menschen in bestimmten Teams und in anderen nicht. Das f\u00fchrt dazu, dass die verschiedenen in der Firma genutzten Services etwas ungleichm\u00e4\u00dfig sind. <\/p>\n

\"Orphan-Services:
\n
\nSchauen Sie sich das Bild an: Das ist ein guter Entwickler, er hat gro\u00dfe H\u00e4nde und kann viel machen. Das Hauptproblem ist, woher diese H\u00e4nde kommen. <\/p>\n

\"Orphan-Services:
\n
\nDie Services erm\u00f6glichen es, verschiedene Programmiersprachen zu verwenden, die besser f\u00fcr unterschiedliche Aufgaben geeignet sind. Ein Service ist in Go, ein anderer in Erlang, einer in Ruby, einer in PHP, und einer in Python. Man kann sich also ziemlich weit ausbreiten. Auch hier gibt es Nuancen.<\/p>\n

\"Orphan-Services:
\n
\nService-orientierte Architektur bedeutet in erster Linie DevOps. Das hei\u00dft, wenn Sie keine Automatisierung haben, keinen Deploy-Prozess, wenn Sie manuell konfigurieren, k\u00f6nnen sich Ihre Konfigurationen von Instanz zu Instanz unterscheiden, und Sie m\u00fcssen jedes Mal etwas anpassen, dann befinden Sie sich im Chaos. <\/p>\n

Zum Beispiel, wenn Sie 20 Dienste haben und alles manuell deployen m\u00fcssen, haben Sie 20 Konsolen und dr\u00fccken gleichzeitig \u201aEnter\u2018 wie ein Ninja. Das ist nicht gerade optimal. <\/p>\n

Wenn Ihr Service nach dem Testen (sofern es Tests gibt) noch nachjustiert werden muss, um in der Produktion zu funktionieren, habe ich auch schlechte Nachrichten f\u00fcr Sie. <\/p>\n

Wenn Sie auf spezialisierte Amazon-Dienste angewiesen sind und dabei in Russland arbeiten, dann war vor zwei Monaten auch bei Ihnen alles \u201aAlles brennt, ich bin in Ordnung, alles ist toll\u2018.<\/p>\n

\"Orphan-Services:
\n
\nWir verwenden Ansible zur Automatisierung der Bereitstellung, Puppet f\u00fcr die Konvergenz, Bamboo f\u00fcr die Automatisierung des Deployments und Confluence, um all dies zu dokumentieren.<\/p>\n

Ich werde nicht n\u00e4her darauf eingehen, da der Vortrag eher \u00fcber Praktiken der Zusammenarbeit und nicht \u00fcber technische Implementierungen handelt. <\/p>\n

\"Orphan-Services:
\n
\nManchmal hatten wir Probleme, zum Beispiel wenn Puppet auf dem Server mit Ruby 2 l\u00e4uft, aber eine Anwendung f\u00fcr Ruby 1.8 geschrieben ist. Dann funktioniert es nicht zusammen. Da tritt ein Problem auf. Wenn Sie mehrere Ruby-Versionen auf einer Maschine ben\u00f6tigen, entstehen normalerweise Schwierigkeiten. <\/p>\n

Wir stellen beispielsweise jedem Entwickler eine Umgebung bereit, in der alles, was wir haben, verf\u00fcgbar ist \u2013 alle Dienste, die entwickelt werden k\u00f6nnen. So hat er ein isoliertes Umfeld, in dem er experimentieren und aufbauen kann, wie er m\u00f6chte. <\/p>\n

Es kann notwendig sein, ein speziell kompiliertes Paket mit Unterst\u00fctzung f\u00fcr bestimmte Funktionen zu ben\u00f6tigen. Das kann recht kompliziert sein. Ich habe einen Vortrag geh\u00f6rt, in dem das Docker-Image 45 GB gro\u00df war. In Linux ist es nat\u00fcrlich einfacher, da ist alles etwas kleiner, aber dennoch reicht der Platz oft nicht aus. <\/p>\n

Und es gibt manchmal widerspr\u00fcchliche Abh\u00e4ngigkeiten, wenn ein Teil des Projekts von einer Bibliothek in einer Version abh\u00e4ngt und ein anderer Teil von einer anderen Version, und die Bibliotheken sich \u00fcberhaupt nicht miteinander kombinieren lassen. <\/p>\n

\"Orphan-Services:
\n
\nWir haben Websites und Dienste auf PHP 5.6, daf\u00fcr sch\u00e4men wir uns, aber was soll man machen. Das ist unsere eine Plattform. Es gibt mehr Websites und Dienste auf PHP 7, f\u00fcr die sch\u00e4men wir uns nicht. Und jeder Entwickler hat sein eigenes kleines Repository, wo er fr\u00f6hlich programmiert. <\/p>\n

Wenn Sie in Ihrem Unternehmen in einer Sprache schreiben, klingt es normal, drei virtuelle Maschinen pro Entwickler zu haben. Wenn Sie verschiedene Programmiersprachen verwenden, wird die Situation komplizierter.<\/p>\n

\"Orphan-Services:
\n
\nSie haben Websites und Dienste auf dieser, und dann auf dieser, dann kommt eine weitere Plattform f\u00fcr Go, eine Plattform f\u00fcr Ruby, und noch irgendein Redis daneben. Am Ende verwandelt sich das alles in ein gro\u00dfes Supportfeld, und st\u00e4ndig kann etwas davon kaputtgehen.<\/p>\n

\"Orphan-Services:
\n
\nDeshalb haben wir die Vorteile der Programmiersprache gegen die Nutzung verschiedener Frameworks eingetauscht, da die Frameworks in PHP ziemlich unterschiedlich sind, sie haben verschiedene M\u00f6glichkeiten, unterschiedliche Communities und unterschiedliche Unterst\u00fctzung. Und man kann den Dienst so entwickeln, dass man schon etwas Fertiges daf\u00fcr hat. <\/p>\n

Jeder Dienst hat sein eigenes Team.<\/b><\/h3>\n

\n\"Orphan-Services:
\n
\nEin gro\u00dfer Vorteil, der sich \u00fcber die Jahre herauskristallisiert hat, ist, dass jedes Service-Team eigenst\u00e4ndig ist. Das ist besonders praktisch f\u00fcr gro\u00dfe Projekte, da Sie Zeit bei der Dokumentation sparen und die Manager ihr Projekt gut kennen. <\/p>\n

Aufgaben aus dem Support k\u00f6nnen hervorragend delegiert werden. Zum Beispiel, wenn ein Versicherungsservice ausf\u00e4llt, kann sofort das Team, das f\u00fcr die Versicherung zust\u00e4ndig ist, eingreifen und das Problem beheben. <\/p>\n

Neue Features werden schnell umgesetzt, weil, wenn Sie einen bestimmten, atomaren Service haben, \u00c4nderungen rasch integriert werden k\u00f6nnen. <\/p>\n

Wenn Ihr Service einmal ausf\u00e4llt \u2013 was unvermeidlich passiert \u2013 hat das keine Auswirkungen auf die anderen Services. Die Entwickler anderer Teams kommen nicht mit Baseballschl\u00e4gern zu Ihnen und sagen: \u201eOh je, das sollten Sie besser nicht tun\u201c. <\/p>\n

\"Orphan-Services:
\n
\nNat\u00fcrlich gibt es auch Nuancen. Wir haben feste Teams, die an ihre Manager gebunden sind. Es gibt klare Dokumente, und die Manager achten sorgf\u00e4ltig darauf. Jedes Team hat mehrere Services in Verantwortung und eine spezifische Kompetenz. <\/p>\n

Wenn die Teams flexibel sind (was bei uns manchmal der Fall ist), verwenden wir eine gute Methode, die als \u201eSternenkarte\u201c bezeichnet wird.<\/p>\n

\"Orphan-Services:
\n
\nSie haben eine Liste von Diensten und Personen. Ein Sternchen bedeutet, dass die Person ein Experte in diesem Dienst ist, und ein Buchsymbol zeigt an, dass die Person diesen Dienst studiert. Die Aufgabe der Person ist es, das Buchsymbol gegen ein Sternchen einzutauschen. Wenn hingegen nichts neben dem Dienst steht, gibt es Probleme, \u00fcber die ich sp\u00e4ter sprechen werde. <\/p>\n

Wie entstehen ausgesetzte Dienste?<\/b><\/h3>\n

\n\"Orphan-Services:
\n
\nDas erste Problem, die erste M\u00f6glichkeit, einen ausgesetzten Dienst in Ihrer Infrastruktur zu bekommen, sind Entlassungen. Hat jemand schon einmal erlebt, dass Fristen aus dem Gesch\u00e4ft kommen, bevor die Aufgaben bewertet wurden? Manchmal sind die Fristen sehr eng und es bleibt einfach keine Zeit f\u00fcr die Dokumentation. 'Der Dienst muss in die Produktion gehen, sp\u00e4ter werden wir es erg\u00e4nzen.' <\/p>\n

Wenn das Team klein ist, gibt es manchmal nur einen Entwickler, der alles schreibt, w\u00e4hrend die anderen unterst\u00fctzen. \u00abIch habe die Hauptarchitektur entworfen, du kannst die Schnittstellen erstellen.\u00bb Dann verl\u00e4sst zu einem gewissen Zeitpunkt der Manager beispielsweise das Team. In dieser Zeit, in der der Manager gegangen ist und noch kein neuer ernannt wurde, entscheiden die Entwickler selbst, in welche Richtung sich der Service entwickelt und was dort passiert. Wie wir wissen (lassen Sie uns ein paar Folien zur\u00fcckspringen), gibt es in einigen Teams sogenannte Einzelg\u00e4nger, manchmal ist ein Einzelg\u00e4nger-Teamleiter. Wenn dieser dann das Unternehmen verl\u00e4sst, haben wir einen \u201ewaisen\u201c Service. <\/p>\n

\"Orphan-Services:
\n
\nDie Aufgaben von Support und Business verschwinden dabei nicht, sondern sammeln sich im Backlog. Wenn es bei der Entwicklung des Services architektonische Fehler gab, bleiben diese ebenfalls im Backlog. Der Service degradiert langsam. <\/p>\n

Wie erkennt man einen \u201eWaisen-Service\u201c?<\/b> <\/h3>\n

\nDiese Liste beschreibt die Situation recht gut. Wer erkennt etwas \u00c4hnliches in seiner Infrastruktur?<\/p>\n

\"Orphan-Services:
\n
\nZu den dokumentierten Workarounds: Es gibt einen Service, der im Wesentlichen funktioniert, und es gibt ein zweiseitiges Handbuch, wie man damit umgeht, aber wie er intern funktioniert, wei\u00df niemand. <\/p>\n

Oder zum Beispiel gibt es einen Link-Verk\u00fcrzer. Momentan verwenden wir drei verschiedene Link-Verk\u00fcrzer f\u00fcr unterschiedliche Zwecke in verschiedenen Diensten. Das sind die Folgen. <\/p>\n

\"Orphan-Services:
\n
\nJetzt werde ich zum Kapit\u00e4n der Offensichtlichkeit. Was muss unternommen werden? Zun\u00e4chst einmal sollte der Dienst an einen anderen Manager oder ein anderes Team \u00fcbergeben werden. Wenn Ihr Teamleiter noch nicht gek\u00fcndigt hat, sollten Sie jemanden in dieses andere Team einbeziehen, der wenigstens etwas dar\u00fcber versteht, wenn Sie merken, dass der Dienst wie ein Waisenkind behandelt wird. <\/p>\n

Das Wichtigste: Sie m\u00fcssen \u00fcber eindeutig dokumentierte \u00dcbergabeverfahren verf\u00fcgen. In unserem Fall \u00fcberwache ich das in der Regel, da ich m\u00f6chte, dass alles funktioniert. Die Manager wollen, dass es schnell \u00fcbergeben wird, und was danach passiert, ist ihnen nicht so wichtig. <\/p>\n

\"Orphan-Services:
\n
\nEine weitere M\u00f6glichkeit, ein Waisenkind zu schaffen, besteht darin, es 'auszulagern, das geht schneller, und sp\u00e4ter \u00fcbergeben wir es dem Team'. Es ist klar, dass jeder in der Mannschaft seine eigenen Pl\u00e4ne und Warteschlangen hat. Oft denkt der Gesch\u00e4ftskunde, dass der Outsourcing-Anbieter dies genauso gut macht wie die Technikabteilung des Unternehmens. Dabei haben sie unterschiedliche Motivationen. Beim Outsourcing gibt es oft seltsame technologische und algorithmische L\u00f6sungen.<\/p>\n

\"Orphan-Services:
\n
\nWir hatten zum Beispiel einen Service, bei dem Sphinx an verschiedenen unerwarteten Orten vorkam. Ich werde sp\u00e4ter erz\u00e4hlen, was wir tun mussten. <\/p>\n

Outsourcing-Anbieter haben oft selbstgeschriebene Frameworks. Das ist einfach nur nacktes PHP mit Copy-Paste vom vorherigen Projekt, wo man allerlei findet. Gro\u00dfe Stolpersteine in den Deploy-Skripten, wenn man mit komplizierten Bash-Skripten mehrere Zeilen in einer Datei \u00e4ndern muss, w\u00e4hrend diese Deploy-Skripte von einem anderen Skript aufgerufen werden. Am Ende \u00e4ndert man das Deployment-System, w\u00e4hlt etwas anderes und pl\u00f6tzlich funktioniert der Service nicht mehr. Weil man noch 8 Links zwischen verschiedenen Ordnern setzen musste. Oder manchmal funktioniert eine Tausend Zeilen, aber bei hunderttausend l\u00e4uft nichts mehr. <\/p>\n

Ich werde weiterhin das Steuer \u00fcbernehmen. Die Abnahme eines Outsourcing-Services ist ein notwendiger Prozess. Hat jemand schon mal erlebt, dass ein Service aus dem Outsourcing kommt und nirgendwo angenommen wird? Das ist zwar nicht so oft wie bei einem Waise-Service, aber doch. <\/p>\n

\"Orphan-Services:
\n
\nDer Dienst muss regelm\u00e4\u00dfig \u00fcberpr\u00fcft werden, der Dienst muss bewertet werden, Passw\u00f6rter m\u00fcssen ge\u00e4ndert werden. Wir hatten einen Fall, in dem uns ein Dienst angeboten wurde, wo im Code geschrieben stand: \"if login == 'admin' && password == 'admin'...\". Wir sitzen da und fragen uns, dass das Menschen im Jahr 2018 noch schreiben?<\/p>\n

Die \u00dcberpr\u00fcfung des Speicherplatzes ist ebenfalls wichtig. Es ist notwendig zu sehen, was bei hunderttausend Datens\u00e4tzen passieren wird, noch bevor Sie diesen Dienst in die Produktion bringen. <\/p>\n

\"Orphan-Services:
\n
\nEs sollte nicht besch\u00e4mend sein, einen Dienst zur \u00dcberarbeitung zur\u00fcckzusenden. Wenn Sie sagen: \"Wir werden diesen Dienst nicht akzeptieren, wir haben 20 Aufgaben, erledigen Sie diese, dann akzeptieren wir\", ist das v\u00f6llig normal. Ihr Gewissen sollte nicht belastet sein, weil Sie einen Manager in Schwierigkeiten bringen oder das Unternehmen Geld kosten. Das Unternehmen wird sp\u00e4ter noch mehr ausgeben.<\/p>\n

Es gab einen Fall, als wir beschlossen, ein Pilotprojekt im Outsourcing durchzuf\u00fchren.<\/p>\n

\"Orphan-Services:
\n
\nEs wurde p\u00fcnktlich geliefert, und das war das einzige Qualit\u00e4tskriterium. Deshalb wurde ein weiteres Pilotprojekt ins Leben gerufen, das eigentlich kein echtes Pilotprojekt mehr war. Diese Dienste wurden \u00fcbernommen, und administrativ wurde gesagt: 'Hier ist euer Code, hier ist das Team, hier ist euer Manager.' Die Dienste haben bereits angefangen, Gewinne zu erzielen. Faktisch sind sie jedoch immer noch wie Waisen, niemand versteht, wie sie funktionieren, und die Manager distanzieren sich bewusst von ihren Aufgaben. <\/p>\n

\"Orphan-Services:
\n
\nEin weiteres gro\u00dfartiges Konzept ist die Guerilla-Entwicklung. Wenn eine Abteilung, gew\u00f6hnlich die Marketingabteilung, eine Hypothese testen m\u00f6chte, beauftragt sie den gesamten Service an einen Dienstleister. Es kommt Verkehr auf die Seite, sie schlie\u00dfen die Unterlagen ab, unterschreiben die Vertr\u00e4ge mit dem Auftragnehmer, gehen in Betrieb und sagen: 'Leute, wir haben hier einen Service, der bereits Traffic hat und uns Geld einbringt, lasst ihn uns \u00fcbernehmen.' Wir sind dann: 'Wow, wie kann das sein?'<\/p>\n

\"Orphan-Services:
\n
\nUnd ein weiterer Weg, um einen Orphan-Service zu erhalten: Wenn ein Team pl\u00f6tzlich \u00fcberlastet ist, sagt die Leitung: \u201eLass uns den Service von diesem Team zu einem anderen \u00fcbertragen, das weniger Auslastung hat\u201c. Dann geben wir ihn an das dritte Team weiter und wechseln den Manager. Am Ende haben wir wieder einen Waisenservice.<\/p>\n

Was ist das Problem mit Waisenservices?<\/b><\/h3>\n

\n\"Orphan-Services:
\n
\nWer es nicht wei\u00df, das ist das in Schweden gebaute Schlachtschiff Wasa, ber\u00fchmt daf\u00fcr, dass es f\u00fcnf Minuten nach seiner Indienststellung sank. Und der K\u00f6nig von Schweden hat \u00fcbrigens daf\u00fcr niemanden hingerichtet. Es wurde von zwei Generationen von Ingenieuren gebaut, die nicht wussten, wie man solche Schiffe baut. Ein vorhersehbarer Effekt.<\/p>\n

Das Schiff h\u00e4tte \u00fcbrigens viel schlimmer sinken k\u00f6nnen, z. B. wenn der K\u00f6nig schon bei einem Sturm darauf unterwegs gewesen w\u00e4re. Aber so ist es sofort gesunken, was im Agile gut ist \u2013 fr\u00fch scheitern. <\/p>\n

Wenn wir fr\u00fch gescheitert sind, gibt es normalerweise keine Probleme. Zum Beispiel w\u00e4hrend der Abnahme wurde es zur\u00dcberarbeitung geschickt. Wenn wir jedoch bereits im Produktionsumfeld gescheitert sind, in das Geld investiert wurde, k\u00f6nnen Probleme auftauchen. Die Folgen, wie es im Gesch\u00e4ftsleben genannt wird.<\/p>\n

Warum sind Waisenservices gef\u00e4hrlich:<\/p>\n