Testen in der Produktion: Canary Deployment

Der Kanarienvogel ist ein kleiner Vogel, der ständig singt. Diese Vögel sind empfindlich gegenüber Methan und Kohlenmonoxid. Selbst bei einer geringen Konzentration dieser Gase in der Luft verlieren sie das Bewusstsein oder sterben. Goldsucher und Bergleute nahmen die Vögel mit in die Minen: solang die Kanarienvögel singen, kann gearbeitet werden; wenn sie schweigen, ist Gas in der Mine und es ist Zeit zu gehen. Die Bergleute opferten den kleinen Vogel, um lebend aus den Minen zu entkommen.

Eine ähnliche Praxis hat sich auch in der IT etabliert. Zum Beispiel bei der Standardaufgabe, eine neue Version eines Dienstes oder einer Anwendung in der Produktion zu deployen, nachdem zuvor getestet wurde. Eine Testumgebung kann zu teuer sein, automatisierte Tests decken nicht alles ab, was man sich wünscht, und ohne Tests zu arbeiten, gefährdet die Qualität. In solchen Fällen hilft der Ansatz des Canary Deployments, bei dem ein wenig echter Produktionsverkehr auf die neue Version geleitet wird. Diese Methode hilft sicher die neue Version in der Produktion zu prüfen, indem man wenig opfert, um ein großes Ziel zu erreichen. Mehr darüber, wie der Ansatz funktioniert, welche Vorteile er bietet und wie man ihn umsetzt, wird Andrey Markelov (Andrey_V_Markelov), am Beispiel der Implementierung bei Infobip erläutern.

Andrey Markelov — leitender Softwareingenieur bei Infobip, der seit 11 Jahren an der Entwicklung von Java-Anwendungen im Bereich Finanzen und Telekommunikation arbeitet. Er entwickelt Open-Source-Produkte, engagiert sich aktiv in der Atlassian-Community und schreibt Plugins für Atlassian-Produkte. Evangelist für Prometheus, Docker und Redis.

Über Infobip

Eine globale Telekommunikationsplattform, die Banken, Einzelhändlern, Online-Shops und Transportunternehmen ermöglicht, ihren Kunden Nachrichten über SMS, Push-Nachrichten, E-Mails und Sprachmitteilungen zu senden. In diesem Geschäft sind Stabilität und Zuverlässigkeit entscheidend, damit die Kunden rechtzeitig Nachrichten erhalten.

IT-Infrastruktur von Infobip in Zahlen:

• 15 Rechenzentren weltweit;
• 500 einzigartige Dienstleistungen im Einsatz;
• 2500 Instanzen von Services, was deutlich mehr ist als die Anzahl der Teams;
• 4,5 TB monatlicher Traffic;
• 4,5 Milliarden Telefonnummern;

Das Geschäft wächst, ebenso die Anzahl der Releases. Wir führen täglich 60 Releases durch, weil die Kunden mehr Funktionen und Möglichkeiten wollen. Aber das ist schwierig – es gibt viele Services und zu wenige Teams. Man muss schnell Code schreiben, der fehlerfrei in der Produktion funktioniert.

Releases

Ein typisches Release bei uns läuft so ab. Zum Beispiel gibt es die Dienste A, B, C, D und E, wobei jeder von einem eigenen Team entwickelt wird.

Irgendwann beschließt das Team des Dienstes A, eine neue Version zu deployen, aber die Teams der Dienste B, C, D und E wissen nichts darüber. Das Team des Dienstes A hat zwei Optionen.

Es wird ein inkrementelles Release durchführen: zuerst wird eine Version ersetzt und anschließend die andere.

Es gibt jedoch eine zweite Option: Das Team findet zusätzliche Kapazitäten und Maschinen, deployt die neue Version und wechselt dann den Router, sodass die Version in der Produktion läuft.

In jedem Fall treten nach dem Deployment fast immer Probleme auf, selbst wenn die Version getestet wurde. Man kann manuell testen, automatisiert testen oder gar nicht testen — die Probleme werden in jedem Fall auftreten. Der einfachste und richtige Weg, damit umzugehen, ist, auf eine funktionierende Version zurückzukehren. Danach kann man sich mit dem Schaden und den Ursachen beschäftigen und diese beheben.

Also, was wollen wir?

Probleme wollen wir nicht. Wenn Kunden sie schneller entdecken als wir, schadet das unserem Ruf. Deshalb müssen wir Probleme schneller finden als die Kunden. Durch proaktives Arbeiten minimieren wir den Schaden.

Gleichzeitig möchten wir den Deployment-Prozess beschleunigen, damit alles schnell, einfach, selbstverständlich und ohne Druck auf das Team abläuft. Ingenieure, DevOps-Engineers und Programmierer müssen geschont werden — die Veröffentlichung einer neuen Version ist stressig. Das Team ist kein Verbrauchsmaterial; wir streben an, die menschlichen Ressourcen sinnvoll zu nutzen.

Deployment-Probleme

der Kundenverkehr ist unvorhersehbar. Es ist unmöglich vorherzusagen, wann der Kundenverkehr am niedrigsten sein wird. Wir wissen nicht, wo und wann Kunden ihre Kampagnen starten — vielleicht heute Nacht in Indien und morgen in Hongkong. Angesichts der großen Zeitverschiebung garantiert ein Deployment um 2 Uhr morgens nicht, dass die Kunden nicht betroffen sind.

Probleme mit den Anbietern. Messenger und Anbieter sind unsere Partner. Manchmal haben sie Ausfälle, die während des Deployments neuer Versionen Fehler verursachen.

Verteilte Teams. Die Teams, die die Client-Seite und das Backend entwickeln, befinden sich in unterschiedlichen Zeitzonen. Daher können sie oft keine Einigung erzielen.

Rechenzentren lassen sich nicht auf der Staging-Plattform nachbilden. In einem Rechenzentrum gibt es 200 Racks — das in einer Sandbox auch nur annähernd nachzubilden, ist nicht möglich.

Ausfallzeitensind nicht akzeptabel! Wir haben ein zulässiges Verfügbarkeitsniveau (Error Budget), bei dem wir 99,99 % der Zeit arbeiten; die restlichen Prozentsätze sind das 'Recht auf Fehler'. Es ist unmöglich, 100 % Zuverlässigkeit zu erreichen, aber es ist wichtig, Ausfälle und Downtimes kontinuierlich zu überwachen.

Klassische Lösungsansätze

Fehlerfreien Code schreiben. Als ich ein junger Entwickler war, kamen Manager zu mir und baten um einen Release ohne Bugs, aber das ist nicht immer möglich.

Tests schreiben. Tests funktionieren, aber manchmal ganz anders, als es das Geschäft wünscht. Geld zu verdienen ist nicht die Aufgabe von Tests.

Auf der Staging-Umgebung testen. In meinen 3,5 Jahren bei Infobip habe ich noch nie gesehen, dass der Zustand der Staging-Umgebung auch nur teilweise mit der Produktion übereinstimmte.

Wir haben sogar versucht, diese Idee weiterzuentwickeln: Zuerst hatten wir eine Staging-Umgebung, dann eine Pre-Production und schließlich eine Pre-Production der Pre-Production. Aber auch das half nicht — sie stimmten nicht einmal in ihrer Kapazität überein. Mit der Staging-Umgebung können wir grundlegende Funktionalität garantieren, wissen aber nicht, wie sie unter Last funktionieren wird.

Der Release wird von demjenigen durchgeführt, der entwickelt hat. Das ist eine gute Praxis: Selbst wenn jemand den Titel eines Kommentars ändert, wird er sofort in die Produktion eingefügt. Dies fördert Verantwortungsbewusstsein und sorgt dafür, dass Änderungen nicht in Vergessenheit geraten.

Es gibt auch zusätzliche Herausforderungen. Für den Entwickler ist es stressig, viel Zeit damit zu verbringen, alles manuell zu überprüfen.

Konsolidierte Releases. Diese Variante wird normalerweise vom Management vorgeschlagen: „Lassen Sie uns vereinbaren, dass Sie jeden Tag testen und neue Versionen hinzufügen.“ Das funktioniert nicht: Es gibt immer ein Team, das auf die anderen wartet oder umgekehrt.

Smoke-Tests

Eine weitere Möglichkeit, unsere Probleme mit dem Deployment zu lösen. Lassen Sie uns untersuchen, wie Smoke-Tests im vorherigen Beispiel funktionieren, wenn Team A eine neue Version bereitstellen möchte.

Zuerst stellt das Team eine Instanz in der Produktion bereit. Mit Nachrichten in der Instanz von Mocks wird der reale Verkehr simuliert, sodass er mit dem normalen täglichen Verkehr übereinstimmt. Wenn alles gut läuft, schaltet das Team die neue Version auf den Benutzertverkehr um.

Die zweite Möglichkeit ist, zu deployen mit zusätzlicher Hardware. Das Team testet sie in der Produktion, wechselt dann um, und alles funktioniert.

Nachteile der Smoke-Tests:

• Tests sind nicht zuverlässig. Woher bekomme ich den gleichen Traffic wie in der Produktion? Man kann gestrigen oder einer Woche alten Traffic verwenden, aber er stimmt nicht immer mit dem aktuellen überein.
• Schwierig zu verwalten. Es müssen Testkonten verwaltet und vor jedem Deployment zurückgesetzt werden, wenn aktive Datensätze an das Repository gesendet werden. Das ist komplizierter, als einen Test in einer Sandbox zu schreiben.

Der einzige Vorteil hier ist man kann die Leistung überprüfen.

Canary-Releases

Aufgrund der Mängel von Smoke-Tests haben wir begonnen, Canary-Releases zu verwenden.

Eine Praxis, ähnlich wie Bergleute Kanarienvögel zur Anzeige von Gasleveln verwendeten, hat auch in der IT Einzug gehalten. Wir leiten ein wenig echten Produktionsverkehr auf die neue Version, während wir versuchen, die Service Level Agreement (SLA) einzuhalten. SLA ist unser „Recht auf einen Fehler“, das wir einmal im Jahr (oder in einem anderen Zeitraum) nutzen können. Wenn alles gut läuft, fügen wir mehr Traffic hinzu. Wenn nicht, rollen wir die vorherigen Versionen zurück.

Implementierung und Feinheiten

Wie haben wir die Canary-Releases implementiert? Zum Beispiel sendet eine Kundengruppe über unseren Service Nachrichten.

Der Deployment-Prozess verläuft so: Wir entfernen einen Knoten vom Load Balancer (1), ändern die Version (2) und lassen dann schrittweise etwas Traffic laufen (3).

Insgesamt werden in der Gruppe alle zufrieden sein, selbst wenn ein Nutzer unzufrieden ist. Wenn alles gut läuft, ändern wir alle Versionen.

Ich zeige schematisch, wie das in den meisten Fällen für Mikrodienste aussieht.

Es gibt einen Service Discovery und zwei weitere Dienste: S1N1 und S2. Der erste Dienst (S1N1) informiert den Service Discovery, wenn er startet, und dieser speichert ihn. Der zweite Dienst mit zwei Knoten (S2N1 und S2N2) informiert ebenfalls beim Start den Service Discovery.

Der zweite Dienst fungiert für den ersten als Server. Der erste Dienst fragt bei Service Discovery Informationen über seine Server an und sucht und überprüft sie, wenn er diese erhält ("Health Check"). Sobald die Überprüfung erfolgt ist, sendet er ihnen Nachrichten.

Wenn jemand eine neue Version des zweiten Dienstes bereitstellen möchte, teilt er dem Service Discovery mit, dass der zweite Knoten eine Canary-Node sein wird: Auf ihn wird weniger Traffic geleitet, da jetzt das Deployment stattfindet. Wir entfernen die Canary-Node vom Load Balancer, und der erste Dienst sendet keinen Traffic mehr dorthin.

Wir ändern die Version und der Service Discovery weiß, dass der zweite Node jetzt ein Canary ist – wir können ihm weniger Last (5%) zuweisen. Wenn alles gut läuft, ändern wir die Version, stellen die Last wieder her und arbeiten weiter.

Um all dies umzusetzen, benötigen wir:

• Lastverteilung;
• Monitoring, da es wichtig ist zu wissen, was jeder Benutzer erwartet und wie detailliert unsere Dienste funktionieren;
• Versionsanalyse, um zu verstehen, wie gut die neue Version in der Produktion funktionieren wird;
• Automatisierung – wir schreiben die Bereitstellungsreihenfolge (Deployment-Pipeline).

Lastverteilung

Das ist das Erste, worüber wir nachdenken müssen. Es gibt zwei Strategien zur Lastverteilung.

Die einfachste Variante ist, dass ein Node immer ein Canary ist.Dieser Node erhält immer weniger Verkehr und wir beginnen das Deployment mit ihm. Bei Problemen vergleichen wir seine Leistung vor und während des Deployments. Zum Beispiel, wenn die Fehler um das Doppelte gestiegen sind, dann ist auch der Schaden um das Doppelte gewachsen.

Der Canary-Node wird im Verlauf des Deployments festgelegt.Wenn das Deployment abgeschlossen ist und wir den Canary-Status von ihm entfernen, wird die Lastverteilung wiederhergestellt. Mit weniger Maschinen erhalten wir eine faire Verteilung.

Überwachung

Der Grundstein für Canary-Releases. Wir müssen genau verstehen, warum wir das tun und welche Metriken wir sammeln möchten.

Beispiele für Metriken, die wir von unseren Diensten sammeln.

• Anzahl der Fehler, die in die Protokolle geschrieben werden. Dies ist ein offensichtlicher Indikator dafür, dass alles wie gewünscht funktioniert. Insgesamt ist das eine gute Metrik.
• Antwortzeit (Latenz). Diese Metrik wird von allen überwacht, da alle schnell arbeiten möchten.
• Größe der Warteschlange (Durchsatz).
• Anzahl der erfolgreichen Antworten pro Sekunde.
• Die Ausführungszeit von 95 % aller Anfragen.
• Geschäftsmetriken: wie viel Geld das Unternehmen in einem bestimmten Zeitraum verdient oder der Benutzerabwanderung. Diese Metriken könnten für unsere neue Version wichtiger sein als die, die Ingenieure hinzufügen.

Beispiele für Metriken in den meisten gängigen Überwachungssystemen.

Zähler. Dies ist eine zunehmende Größe, zum Beispiel die Anzahl der Fehler. Diese Metrik lässt sich einfach interpolieren und der Verlauf lässt sich betrachten: Gestern gab es 2 Fehler, heute 500, das bedeutet, dass etwas schiefgegangen ist.

Die Anzahl der Fehler pro Minute oder Sekunde ist ein wesentlicher Indikator, der mit dem Counter berechnet werden kann. Diese Daten bieten einen klaren Überblick über die Systemleistung im Laufe der Zeit. Betrachten wir das Beispiel eines Diagramms der Anzahl der Fehler pro Sekunde für zwei Versionen des Produktionssystems.

In der ersten Version gab es wenige Fehler, möglicherweise hat das Audit nicht funktioniert. In der zweiten Version sieht es viel schlimmer aus. Man kann sicher sagen, dass es Probleme gibt, weshalb wir diese Version zurücksetzen müssen.

Gauge. Metriken ähneln dem Counter, aber wir zeichnen Werte auf, die sowohl zunehmen als auch abnehmen können. Zum Beispiel die Ausführungszeit von Anfragen oder die Größe der Warteschlange.

Im Diagramm ist ein Beispiel für die Reaktionszeit (latency) zu sehen. Anhand des Diagramms erkennt man, dass die Versionen ähnlich sind und damit gearbeitet werden kann. Bei genauem Hinsehen ist jedoch deutlich zu erkennen, wie sich der Wert verändert. Wenn die Ausführungszeit von Anfragen mit der Anzahl der Benutzer steigt, ist sofort klar, dass es Probleme gibt — so etwas gab es früher nicht.

Zusammenfassung. Eine der wichtigsten Kennzahlen für das Geschäft sind die Perzentile. Die Metrik zeigt, dass in 95 % der Fälle Unser System funktioniert so, wie wir es möchten. Wir können akzeptieren, wenn es irgendwo Probleme gibt, weil wir die allgemeine Tendenz verstehen, wie gut oder schlecht alles ist.

Werkzeuge

ELK Stack. Ein Canary kann mit Elasticsearch implementiert werden – wir protokollieren Fehler, wenn Ereignisse eintreten. Mit einem einfachen API-Aufruf kann die Anzahl der Fehler zu jedem Zeitpunkt abgerufen und mit früheren Zeiträumen verglichen werden: GET /applg/_cunt?q=level:errr.

Prometheus. Hat sich bei Infobip bewährt. Es ermöglicht die Implementierung multidimensionaler Metriken, da Labels verwendet werden.

Wir können level, Instanz, service, in einem System kombinieren. Damit offset kann zum Beispiel der Wert vor einer Woche mit nur einem Befehl angezeigt werden. GET /api/v1/query?query={query}, wobei {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

Versionsanalyse

Es gibt mehrere Strategien zur Analyse von Versionen.

Nur die Canary-Knoten beobachten. Eine der einfachsten Varianten: eine neue Version bereitgestellt und nur die Leistung untersucht. Aber wenn der Ingenieur in der Zwischenzeit beginnt, die Logs zu studieren und ständig nervös die Seiten neu lädt, unterscheidet sich diese Lösung nicht von anderen.

Der Canary-Knoten wird mit jedem anderen Knoten verglichen.. Dies ist ein Vergleich mit anderen Instanzen, die mit vollem Verkehr arbeiten. Wenn beispielsweise bei geringem Verkehr die Situation schlechter oder nicht besser ist als bei den realen Instanzen, dann stimmt etwas nicht.

Die Canary-Node wird mit sich selbst in der Vergangenheit verglichen. Die für die Canary-Node reservierten Nodes können mit historischen Daten verglichen werden. Wenn vor einer Woche alles gut war, können wir uns auf diese Daten stützen, um die aktuelle Situation zu verstehen.

Automatisierung

Wir möchten die Ingenieure von manuellen Vergleichen entlasten, daher ist es wichtig, die Automatisierung umzusetzen. Der Bereitstellungsprozess (Deployment-Pipeline) sieht normalerweise so aus:

• Wir starten;
• wir nehmen den Node aus dem Load Balancer;
• wir setzen die Canary-Node;
• wir aktivieren den Load Balancer bereits mit einer begrenzten Menge an Verkehr;
• wir vergleichen.

An diesem Punkt implementieren wir automatische Vergleiche. Wie das aussehen kann und warum es besser ist als eine Überprüfung nach der Bereitstellung, werden wir am Beispiel von Jenkins betrachten.

Das ist die Pipeline zu Groovy.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary ist fehlgeschlagen, muss zurückgesetzt werden"  
        return false
    }
}

Hier im Zyklus legen wir fest, dass wir den neuen Knoten für eine Stunde vergleichen werden. Wenn der Canary-Prozess noch nicht abgeschlossen ist, rufen wir die Funktion auf. Sie gibt an, ob alles gut ist oder nicht: def isOk = compare(srv, canary, time, base, offset, metrics).

Wenn alles gut ist — sleep DEFAULT SLEEP, zum Beispiel eine Sekunde, und wir machen weiter. Wenn nicht, brechen wir ab — das Deployment war nicht erfolgreich.

Beschreibung der Metrik. Schauen wir uns an, wie die Funktion compare mit DSL aussehen könnte.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

Angenommen, wir vergleichen die Anzahl der Fehler und möchten die Anzahl der Fehler pro Sekunde in den letzten 5 Minuten wissen.

Wir haben zwei Werte: den Basiswert und den Canary-Knoten. Der Wert des Canary-Knotens ist der aktuelle. Der Basiswert ist baseValue — das ist der Wert eines beliebigen anderen Knotens, der kein Canary-Knoten ist. Wir vergleichen die Werte gemäß der Formel, die wir basierend auf unserer Erfahrung und Beobachtungen festgelegt haben. Wenn der Wert canaryValue schlecht ist, war das Deployment nicht erfolgreich, und wir rollen zurück.

Warum ist das alles notwendig?

Ein Mensch kann Hunderte und Tausende von Metriken nicht überprüfen., insbesondere um dies schnell zu tun. Die automatische Vergleichsfunktion hilft, alle Metriken zu überprüfen und schnell über Probleme zu informieren. Die Zeit für die Benachrichtigung ist entscheidend: Wenn innerhalb der letzten 2 Sekunden etwas passiert ist, ist der Schaden nicht so groß, als wäre es 15 Minuten zuvor geschehen. Während jemand das Problem bemerkt, die Supportanfrage schreibt und wir zurücksetzen, könnte man Kunden verlieren.

Wenn der Prozess abgeschlossen ist und alles gut aussieht, stellen wir alle anderen Knoten automatisch bereit. In dieser Zeit tun die Ingenieure nichts. Erst wenn sie das Canary starten, entscheiden sie, welche Metriken zu berücksichtigen sind, wie lange der Vergleich dauern soll und welche Strategie anzuwenden ist.

Wenn Probleme auftreten, setzen wir den Canary-Knoten automatisch zurück, arbeiten mit früheren Versionen und beheben die gefundenen Fehler. Anhand der Metriken lassen sich die Probleme leicht finden und der Schaden durch die neue Version erkennen.

Hindernisse

Das umzusetzen, ist natürlich nicht einfach. Zunächst brauchen wir ein gemeinsames Überwachungssystem. Die Ingenieure haben ihre eigenen Metriken, der Support und die Analysten andere, und das Business wieder andere. Ein gemeinsames System ist die gemeinsame Sprache, in der das Geschäft und die Entwicklung kommunizieren.

Wir müssen in der Praxis überprüfen die Stabilität der Metriken. Eine Überprüfung hilft zu verstehen, welcher minimale Satz an Metriken erforderlich ist, um Qualität zu gewährleisten..

Wie erreichen wir das? Entwenden Sie den Canary-Dienst nicht während des Deployments.. Wir fügen in der alten Version einen bestimmten Dienst hinzu, der jederzeit einen dedizierten Knoten übernehmen kann, den Verkehr ohne Deployment reduziert. Danach vergleichen wir: Wir untersuchen die Fehler und suchen nach dem Punkt, an dem wir Qualität erreichen.

Welchen Nutzen haben wir aus Canary-Releases gezogen?

Wir haben den Prozentsatz an durch Bugs verursachten Schäden minimiert. Die meisten Deployment-Fehler treten aufgrund von Inkonsistenzen in Daten oder Prioritäten auf. Solche Fehler gibt es nun viel seltener, da wir Probleme in den ersten Sekunden lösen können.

Wir haben die Arbeit der Teams optimiert. Neue Mitarbeiter haben das „Recht auf Fehler“: Sie können ohne Angst vor Fehlern in der Produktionsumgebung deployen, was zusätzliche Initiative und Anreiz zum Arbeiten schafft. Wenn sie etwas kaputt machen, ist das nicht kritisch, und sie werden nicht entlassen.

Wir haben das Deployment automatisiert.. Es ist nicht mehr ein manueller Prozess wie früher, sondern ein echter automatisierter Prozess. Aber es dauert länger.

Wir haben wichtige Metriken hervorgehoben.. Das gesamte Unternehmen, von den Geschäftsführern bis zu den Ingenieuren, versteht, was in unserem Produkt wirklich wichtig ist, welche Kennzahlen wie Nutzerabwanderung und -zuwanderung entscheidend sind. Wir überwachen den Prozess: testen Kennzahlen, führen neue ein und beobachten, wie die bisherigen funktionieren, um ein System zu entwickeln, das profitabler ist.

Wir haben viele großartige Praktiken und Systeme, die uns unterstützen. Dennoch streben wir danach, Profis zu sein und unsere Arbeit qualitativ hochwertig zu erledigen, unabhängig davon, ob wir ein unterstützendes System haben oder nicht.

Ingenieuransätze und -praktiken — der Hauptfokus der TechLead Conf. Wenn Sie auf dem Weg zur technischen Exzellenz Fortschritte gemacht haben und bereit sind, zu teilen, was Ihnen dabei geholfen hat — reichen Sie Ihren Vortrag ein.

Wir planen die Durchführung der TechLead Conf 8. Juni. Wir verstehen, dass es derzeit schwierig ist, Entscheidungen über die Teilnahme an der Konferenz zu treffen. Gleichzeitig sind wir jedoch der Meinung, dass die Quarantäne kein Grund ist, professionellen Austausch und Entwicklung zu stoppen. Deshalb werden wir auf jeden Fall einen Weg finden, die Aufgaben des technischen Leiters und Ansätze zu deren Lösung zu besprechen — wenn nötig, gehen wir online und starten das Networking dort!

Quelle: habr.com