{"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":"Waisen-Services: die Kehrseite der (Mikro)-Service-Architektur","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Der Direktor f\u00fcr den Betrieb des Portals Banki.ru, Andrei Nikolsky, sprach auf der Konferenz im letzten Jahr DevOpsDays Moskau<\/a><\/noindex> \u00fcber Waisendienste: wie man einen Waise im System erkennt, welche Probleme Waisendienste haben, was man mit ihnen tun kann und wie man vorgeht, wenn nichts hilft.<\/p>\n

Unter dem Cut ist die textliche Version des Berichts. <\/p>\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex>
\nGuten Tag, Kollegen! Ich hei\u00dfe Andrei und leite den Betrieb bei Banki.ru.<\/p>\n

Wir haben gro\u00dfe Dienste, das sind Monolithdienste, es gibt Dienste im klassischeren Sinne, und es gibt ganz kleine. In meiner Arbeitssprache sage ich, dass ein Dienst einfach und klein ist, dann ist er Mikro, und wenn er nicht ganz einfach und nicht klein ist, dann ist es einfach ein Dienst. <\/p>\n

Vorteile von Dienstleistungen<\/b><\/h3>\n

\nIch werde schnell die Vorteile der Dienstleistungen durchgehen. <\/p>\n

\"Waisen-Services:
\n
\nErstens \u2014 Skalierbarkeit. Sie k\u00f6nnen schnell etwas auf dem Dienst machen und in die Produktion starten. Sie haben Traffic bekommen, Sie haben den Dienst klonen k\u00f6nnen. Ihr kommt noch mehr Traffic, Sie klonen nochmal und damit leben Sie. Das ist ein guter Bonus, und im Grunde genommen, als wir angefangen haben, galt das als das Wichtigste, warum wir das alles \u00fcberhaupt machen.<\/p>\n

\"Waisen-Services:
\n
\nZweitens, isolierte Entwicklung, wenn Sie mehrere Entwicklungsteams haben, mehrere verschiedene Entwickler in jedem Team, und jedes Team entwickelt seinen eigenen Dienst.<\/p>\n

Bei den Teams gibt es ein Nuance. Entwickler sind unterschiedlich. Und es gibt zum Beispiel Schneeflockenmenschen<\/a><\/noindex>. Ich habe das zum ersten Mal bei Maxim Dorofeev gesehen. Manchmal gibt es Schneeflockenmenschen in einigen Teams, in anderen gibt es sie nicht. Das macht die verschiedenen Dienste, die im Unternehmen verwendet werden, etwas ungleichm\u00e4\u00dfig. <\/p>\n

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

\"Waisen-Services:
\n
\nDienste erm\u00f6glichen es, verschiedene Programmiersprachen zu verwenden, die besser f\u00fcr unterschiedliche Aufgaben geeignet sind. Ein Dienst ist in Go, ein anderer in Erlang, einer in Ruby, etwas in PHP, etwas in Python. Insgesamt kann man sich sehr breit entfalten. Auch hier gibt es Nuancen.<\/p>\n

\"Waisen-Services:
\n
\nService-orientierte Architektur bedeutet in erster Linie DevOps. Das hei\u00dft, wenn Sie keine Automatisierung haben, keinen Bereitstellungsprozess, wenn Sie es h\u00e4ndisch einstellen, k\u00f6nnen sich Ihre Konfigurationen von Instanz zu Instanz unterscheiden, und Sie m\u00fcssen dort hinein gehen und etwas machen, dann sind Sie im Chaos. <\/p>\n

Zum Beispiel haben Sie 20 Services und m\u00fcssen manuell deployen, haben 20 Konsolen und dr\u00fccken gleichzeitig wie ein Ninja auf \u201eEnter\u201c. Das ist nicht ideal. <\/p>\n

Wenn Sie einen Service nach dem Testen haben (sofern es Tests gibt) und ihn noch nachbearbeiten m\u00fcssen, damit er in der Produktion funktioniert, habe ich leider auch schlechte Nachrichten f\u00fcr Sie. <\/p>\n

Wenn Sie auf spezifische Amazon-Services angewiesen sind und dabei in Russland arbeiten, hatten Sie vor zwei Monaten auch \u201eAlles brennt, mir geht's gut, alles ist super\u201c.<\/p>\n

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

Ich werde nicht ausf\u00fchrlich darauf eingehen, da der Vortrag eher \u00fcber Interaktionspraktiken und nicht \u00fcber technische Implementierungen handelt. <\/p>\n

\"Waisen-Services:
\n
\nWir hatten beispielsweise Probleme, dass Puppet auf dem Server mit Ruby 2 funktioniert, w\u00e4hrend eine bestimmte Anwendung f\u00fcr Ruby 1.8 geschrieben wurde, und zusammen funktionieren sie nicht. Da entsteht ein Problem. Wenn Sie mehrere Ruby-Versionen auf einem Rechner halten m\u00fcssen, fangen die Probleme normalerweise an. <\/p>\n

Zum Beispiel stellen wir jedem Entwickler eine Plattform zur Verf\u00fcgung, auf der alles, was wir haben, verf\u00fcgbar ist, alle Services, die entwickelt werden k\u00f6nnen, damit er eine isolierte Umgebung hat, in der er herumexperimentieren und aufbauen kann, wie er m\u00f6chte. <\/p>\n

Manchmal wird ein speziell kompilierter Paket ben\u00f6tigt, das etwas unterst\u00fctzt. Das ist ziemlich strikt. Ich habe einen Vortrag geh\u00f6rt, in dem das Docker-Image 45 GB gro\u00df war. Unter Linux ist es nat\u00fcrlich einfacher, da ist alles kleiner, aber trotzdem wird der Platz knapp. <\/p>\n

Es gibt auch widerspr\u00fcchliche Abh\u00e4ngigkeiten, bei denen ein Teil des Projekts von einer Bibliothek einer Version abh\u00e4ngt, w\u00e4hrend ein anderer Teil von einer anderen Version abh\u00e4ngt, und diese Bibliotheken k\u00f6nnen \u00fcberhaupt nicht zusammen installiert werden. <\/p>\n

\"Waisen-Services:
\n
\nWir haben Websites und Services auf PHP 5.6, wof\u00fcr wir uns sch\u00e4men, aber was sollen wir machen. Das ist unsere eine Plattform. Es gibt Websites und Services auf PHP 7, von denen es mehr gibt, und daf\u00fcr sch\u00e4men wir uns nicht. Und jeder Entwickler hat seine eigene Datenbank, in der er fr\u00f6hlich arbeitet. <\/p>\n

Wenn Sie in einem Unternehmen in einer einzigen Programmiersprache schreiben, klingt es normal, drei virtuelle Maschinen pro Entwickler zu haben. Wenn Sie verschiedene Programmiersprachen haben, wird die Situation schwieriger.<\/p>\n

\"Waisen-Services:
\n
\nSie haben Websites und Dienste daf\u00fcr, daf\u00fcr, dann noch eine Plattform f\u00fcr Go, eine Plattform f\u00fcr Ruby, noch ein Redis daneben. Am Ende verwandelt sich das alles in ein gro\u00dfes Feld f\u00fcr Support, und st\u00e4ndig kann etwas davon kaputtgehen.<\/p>\n

\"Waisen-Services:
\n
\nDeshalb haben wir die Vorz\u00fcge der Programmiersprache durch die Nutzung unterschiedlicher Frameworks ersetzt, da Frameworks in PHP ziemlich unterschiedlich sind, sie haben unterschiedliche M\u00f6glichkeiten, unterschiedliche Communities, unterschiedlichen Support. Und man kann den Dienst so schreiben, dass man bereits etwas Fertiges daf\u00fcr hat. <\/p>\n

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

\n\"Waisen-Services:
\n
\nUnser gr\u00f6\u00dfter Vorteil, der sich \u00fcber mehrere Jahre herauskristallisiert hat, ist, dass jeder Dienst sein eigenes Team hat. Das ist praktisch f\u00fcr ein gro\u00dfes Projekt, man kann Zeit bei der Dokumentation sparen, die Manager kennen ihr Projekt gut. <\/p>\n

Support-Aufgaben k\u00f6nnen hervorragend einflie\u00dfen. Zum Beispiel, wenn der Versicherungsdienst ausgefallen ist. Und sofort geht das Team, das sich um die Versicherung k\u00fcmmert, ihn reparieren. <\/p>\n

Neue Funktionen werden schnell umgesetzt, denn wenn Sie einen atomaren Dienst haben, kann man schnell etwas einbauen. <\/p>\n

Und wenn Sie Ihren Dienst kaputt gemacht haben, was unvermeidlich passiert, haben Sie keine anderen Dienste besch\u00e4digt, und es kommen keine Entwickler mit Schl\u00e4gen aus anderen Teams zu Ihnen, um zu sagen: \"Oh-oh, das sollten Sie nicht tun.\" <\/p>\n

\"Waisen-Services:
\n
\nWie immer gibt es Nuancen. Wir haben stabile Teams, die Manager sind fest mit dem Team verbunden. Es gibt klare Dokumente, die Manager achten genau darauf. Jedes Team hat mit dem Manager mehrere Dienste und einen bestimmten Kompetenzbereich. <\/p>\n

Wenn die Teams wechselhaft sind (was wir manchmal auch haben), gibt es eine gute Methode, die \u201eSternenkarte\u201c genannt wird.<\/p>\n

\"Waisen-Services:
\n
\nSie haben eine Liste von Diensten und Personen. Ein Sternchen bedeutet, dass die Person ein Experte in diesem Dienst ist, ein Buch bedeutet, dass die Person diesen Dienst studiert. Die Aufgabe der Person besteht darin, das Buch gegen ein Sternchen auszutauschen. Wenn gegen\u00fcber dem Dienst nichts geschrieben steht, beginnen Probleme, \u00fcber die ich sp\u00e4ter berichten werde. <\/p>\n

Wie entstehen Waise-Dienste?<\/b><\/h3>\n

\n\"Waisen-Services:
\n
\nDas erste Problem und die erste M\u00f6glichkeit, einen Service-Waisen in Ihrer Infrastruktur zu erhalten, sind Entlassungen von Mitarbeitern. Hat jemand schon einmal erlebt, dass Fristen aus dem Unternehmen gesetzt werden, bevor die Aufgaben bewertet wurden? Manchmal sind die Fristen so eng, dass es nicht genug Zeit f\u00fcr die Dokumentation gibt. \u201eDer Service muss in die Produktion \u00fcbergeben werden, den Rest schreiben wir sp\u00e4ter.\u201c <\/p>\n

Wenn das Team klein ist, gibt es manchmal nur einen Entwickler, der alles schreibt, w\u00e4hrend die anderen unterst\u00fctzend t\u00e4tig sind. \u201eIch habe die Hauptarchitektur geschrieben, du kannst die Schnittstellen entwerfen.\u201c Dann verl\u00e4sst irgendwann ein Manager das Team. In diesem Zeitraum, wenn der Manager nicht mehr da ist und kein neuer gefunden wurde, entscheiden die Entwickler selbst, wohin sich der Service bewegt und was dort passiert. Und wie wir wissen (wir erinnern uns an ein paar Folien zur\u00fcck), gibt es in einigen Teams individuelle \u201eSchneeflocken\u201c-Mitglieder, manchmal ist eine Schneeflocke der Teamleiter. Dann k\u00fcndigt er, und wir haben einen Service-Waisen. <\/p>\n

\"Waisen-Services:
\n
\nDabei verschwinden die Aufgaben von Support und Business nicht, sie sammeln sich im Backlog. Wenn bei der Entwicklung des Dienstes architektonische Fehler aufgetreten sind, bleiben sie ebenfalls im Backlog. Der Service degeneriert langsam. <\/p>\n

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

\nDiese Liste beschreibt die Situation ganz gut. Wer hat bei sich in der Infrastruktur etwas erkannt?<\/p>\n

\"Waisen-Services:
\n
\nZu dokumentierten Workarounds: Es gibt einen Service, der insgesamt funktioniert, und es gibt ein Handbuch von zwei Seiten, wie man damit umgeht, aber wie es intern funktioniert, wei\u00df niemand. <\/p>\n

Oder zum Beispiel gibt es einen Linkverk\u00fcrzer. Bei uns zum Beispiel gibt es derzeit drei Linkverk\u00fcrzer f\u00fcr unterschiedliche Zwecke in verschiedenen Services. Das sind die Folgen davon. <\/p>\n

\"Waisen-Services:
\n
\nJetzt werde ich der Kapit\u00e4n der Offensichtlichkeit. Was sollte man unternehmen? Erstens, den Service an einen anderen Manager oder ein anderes Team \u00fcbergeben. Wenn Ihr Teamleiter noch nicht gek\u00fcndigt hat, sollten Sie in dieses andere Team, wenn Sie merken, dass der Service wie ein Waisen-Service aussieht, jemanden einbeziehen, der wenigstens ein bisschen davon versteht. <\/p>\n

Das Wichtigste: Sie m\u00fcssen schriftlich festgelegte \u00dcbergabeverfahren haben. In unserem Fall \u00fcberwache ich das normalerweise, weil ich sicherstellen muss, dass alles funktioniert. Die Manager m\u00f6chten, dass es schnell erledigt wird, und was danach mit dem Service passiert, ist ihnen nicht mehr so wichtig. <\/p>\n

\"Waisen-Services:
\n
\nEine weitere M\u00f6glichkeit, ein Waisenkind zu schaffen, ist: \u201eWir lagern es aus, das geht schneller, und dann geben wir es ins Team.\u201c Es ist klar, dass jeder in der Gruppe irgendwelche Pl\u00e4ne hat, eine Warteliste. Oft denkt der Gesch\u00e4ftskunde, dass die Auslagerer es genauso machen wie die Technikabteilung im Unternehmen. Aber ihre Motivationen sind unterschiedlich. Bei der Auslagerung gibt es oft merkw\u00fcrdige technische L\u00f6sungen und seltsame algorithmische Entscheidungen.<\/p>\n

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

Auslagerer haben oft selbstgeschriebene Frameworks. Das ist einfach nur nacktes PHP, das vom vorherigen Projekt kopiert wurde, wo man allerlei finden kann. Gro\u00dfe Kr\u00fccken in den Deployment-Skripten, wenn Sie mit einigen komplizierten Bash-Skripten ein paar Zeilen in einer Datei \u00e4ndern m\u00fcssen, w\u00e4hrend diese Deployment-Skripte von einem dritten Skript aufgerufen werden. Am Ende \u00e4ndern Sie das Deployment-System, w\u00e4hlen etwas anderes aus, und zack, der Service funktioniert nicht mehr. Weil man daf\u00fcr noch 8 Links zwischen verschiedenen Ordnern setzen musste. Oder es kommt vor, dass tausend Eintr\u00e4ge funktionieren, aber hunderttausend schon nicht mehr. <\/p>\n

Ich mache weiter mit dem Kapit\u00e4n. Die Abnahme des Services aus der Auslagerung ist ein Verfahren, das zwingend erforderlich ist. Wer hat schon einmal erlebt, dass ein Service aus der Auslagerung ankommt und nirgendwo angenommen wird? Das ist nicht so popul\u00e4r wie ein Waisenkind-Service, aber dennoch. <\/p>\n

\"Waisen-Services:
\n
\nDienste m\u00fcssen \u00fcberpr\u00fcft und bewertet werden, Passw\u00f6rter m\u00fcssen ge\u00e4ndert werden. Wir hatten einen Fall, in dem uns ein Dienst mit einer Admin-Oberfl\u00e4che mit \"if login == 'admin' && password == 'admin'...\" untergeschoben wurde, direkt im Code geschrieben. Wir sitzen da und denken, dass Menschen so etwas 2018 schreiben?<\/p>\n

Die Testung des Speichervolumens ist ebenfalls notwendig. Man muss schauen, was bei hunderttausend Eintr\u00e4gen passiert, bevor man diesen Service in die Produktion gibt. <\/p>\n

\"Waisen-Services:
\n
\nEs sollte nicht peinlich sein, den Service zur Nachbesserung zu senden. Wenn Sie sagen: \u201eWir nehmen diesen Service nicht an, wir haben 20 Aufgaben, machen Sie diese, dann nehmen wir ihn an\u201c, ist das normal. Man sollte kein schlechtes Gewissen haben, dass man den Manager in die Bredouille bringt oder dass das Unternehmen Geld ausgibt. Das Unternehmen wird sp\u00e4ter mehr ausgeben.<\/p>\n

Wir hatten einen Fall, als wir beschlossen, ein Pilotprojekt in der Auslagerung zu machen.<\/p>\n

\"Waisen-Services:
\n
\nEs wurde rechtzeitig \u00fcbergeben, und das war das einzige Qualit\u00e4tskriterium. Daher wurde ein weiteres Pilotprojekt gestartet, das schon l\u00e4ngst kein richtiges Pilotprojekt mehr war. Diese Services wurden bereitgestellt, es wurden administrative Mittel eingesetzt und gesagt, hier ist Ihr Code, hier ist das Team, hier ist Ihr Manager. Die Services haben tats\u00e4chlich schon begonnen, Gewinne zu erwirtschaften. Dennoch sind sie nach wie vor Waisen, niemand versteht, wie sie funktionieren, und die Manager weichen ihren Aufgaben irgendwie aus. <\/p>\n

\"Waisen-Services:
\n
\nEs gibt noch ein hervorragendes Konzept \u2013 die Guerilla-Entwicklung. Wenn eine Abteilung, normalerweise die Marketingabteilung, eine Hypothese \u00fcberpr\u00fcfen m\u00f6chte, beauftragt sie den gesamten Service im Outsourcing. Daraufhin flie\u00dft der Traffic ein, sie schlie\u00dfen die Abrechnungen ab, unterschreiben Vertr\u00e4ge mit dem Auftragnehmer, gehen in Betrieb und sagen: \u201eJungs, wir haben hier einen Service, der bereits Traffic hat, er bringt uns Geld, lasst ihn annehmen.\u201c Wir sagen: \u201eWow, wie kann das sein?\"<\/p>\n

\"Waisen-Services:
\n
\nEine weitere M\u00f6glichkeit, einen Waisendienst zu erhalten: Wenn ein Team pl\u00f6tzlich \u00fcberlastet ist, sagt das Management: \u201eLass uns den Service dieses Teams an ein anderes Team \u00fcbergeben, das weniger belastet ist.\u201c Und dann geben wir ihn an ein drittes Team weiter und wechseln den Manager. Am Ende haben wir wieder einen Waisen.<\/p>\n

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

\n\"Waisen-Services:
\n
\nWer es nicht wei\u00df, das ist das in Schweden gehobene Schlachtschiff Wasa, das daf\u00fcr ber\u00fchmt ist, dass es 5 Minuten nach dem Stapellauf gesunken ist. Und der K\u00f6nig von Schweden hat \u00fcbrigens niemanden daf\u00fcr hingerichtet. Es wurde von zwei Generationen von Ingenieuren erbaut, die nicht wussten, wie man solche Schiffe baut. Ein logischer Effekt.<\/p>\n

Das Schiff h\u00e4tte \u00fcbrigens viel schlimmer untergehen k\u00f6nnen, zum Beispiel, wenn der K\u00f6nig schon bei einem Sturm darauf gefahren w\u00e4re. So sank es sofort, was im Agilen Ansatz gut ist \u2013 fr\u00fch zu scheitern. <\/p>\n

Wenn wir fr\u00fch gescheitert sind, gibt es normalerweise keine Probleme. Zum Beispiel, wenn wir bei der Abnahme zur Nachbearbeitung geschickt wurden. Wenn wir aber bereits in der Produktion gescheitert sind, wenn Geld investiert wurde, k\u00f6nnten Probleme auftreten. Die Folgen, wie sie im Gesch\u00e4ft genannt werden.<\/p>\n

Was ist gef\u00e4hrlich an Waisenservices:<\/p>\n