Wie man ein gesundes Produkt anbaut (Juno-Beispiel)

Es wurde viel über die Vorteile der Arbeit in einem Lebensmittelunternehmen gesagt, und es ist schwierig, hier originell zu sein. Aber weit davon entfernt weiß jeder, wie man die „Gesundheit“ eines Produkts erhält und was man in einem Lebensmittelunternehmen tun kann, abgesehen von der Entwicklung von Funktionen. Wir werden Ihnen sagen, wie wir das Produkt bei Juno betreiben und wie die Betriebsabteilung und die technischen Spezialisten daran beteiligt sind.

Wir erklären nicht, dass unser Weg der richtigste ist. Wir versuchen ständig, Fehler zu machen und aus unseren Fehlern zu lernen. Wir hoffen, dass unsere Erfahrung für Sie nützlich sein wird.

Über uns: Juno ist ein auf dem US-Markt tätiger Versteckdienst und Teil der Gett-Unternehmensgruppe.

Juno schreibt Code in den Sprachen Go, Swift, Kotlin, Python und React.js als Teil der Teams für mobile Anwendungen, Backend, Frontend, Data Science und Technical Operation Support. Damit wird ein Dienst geschaffen, der Teil des täglichen Lebens von Zehntausenden von Fahrern und Hunderttausenden von neuen Bewohnern geworden ist York.

Worum geht es beim Produktmanagement?

Lassen Sie uns den Prozess des Betriebs in Juno verstehen und versuchen, ihn in seine Bestandteile zu zerlegen.
Wir haben drei Schlüsselkomponenten für uns identifiziert:

1. Betriebsbüro
   
2. Metriken und Überwachung
   
3. Vorfalluntersuchung
   

Der Zweck des Betriebs des Produkts besteht darin, auf neu auftretende Probleme und Änderungen unabhängig von ihrer Art rechtzeitig zu reagieren.
Dazu benötigen Sie:

• Definieren Sie Systemzustandsindikatoren
  
• Verstehen Sie, wie sich Änderungen im System auf Metriken auswirken
  
• Verstehen Sie, wie sich Marktveränderungen auf die Leistung auswirken
  
• Verstehen Sie, wann Veränderungen zu einem Problem werden
  

Bei diesem Ansatz basieren Geschäftsentscheidungen auf Daten. Unser Betriebsteam arbeitet in New York, da der Juno-Service derzeit nur den Bewohnern dieser Metropole zur Verfügung steht.
Die tägliche Aufgabenliste des Teams sieht folgendermaßen aus:

• Verfolgen und reagieren Sie schnell auf regulatorische Änderungen. Zu den allgemeinen Änderungen zählen das Erscheinen einer neuen mautpflichtigen Straße und die Verlegung eines Wartebereichs für Fahrer am Flughafen. Sobald wir Informationen über solche Ereignisse erhalten, verlässt der Mitarbeiter den Ort, um die Karte korrekt zu aktualisieren und die Liste möglicher Probleme zu analysieren. Wenn das Entwicklungsteam die Karte auf den Servern aktualisiert, testet der Mitarbeiter die Änderungen in den „Feldbedingungen“ und stellt sicher, dass sie ordnungsgemäß funktionieren.
  
• Feldforschung betreiben. Als wir den Dienst in New York starteten, war geplant, zunächst eine bestimmte Anzahl von Fahrern für den stabilen Betrieb des Dienstes in einem beliebigen Bereich der Stadt zu rekrutieren. Aus diesem Grund fuhren die Fahrer, die zu uns kamen, einige Monate lang ohne Passagiere und erhielten nur gelegentlich Fahrten von Betatestern. Diese Reisen reichten nicht aus, um die notwendigen Informationen zu sammeln. Dann haben wir beschlossen, das Betriebsteam in die „Felder“ zu schicken, um die Qualität des Dienstes zu bewerten und die Beschwerden der Fahrer über die Anwendung herauszufinden. Dieser Ansatz hat sich als nützlich erwiesen und wird ständig verwendet, wenn signifikante Änderungen veröffentlicht oder Hypothesen getestet werden.
  
• Nachrichten "Veranstaltungskalender" - eine Liste von Ereignissen, Feiertagen und Wetterereignissen, die sich auf die Quantität und Qualität der Reisen auswirken können. Dies hilft, Änderungen bei Schlüsselindikatoren (z. B. die Anzahl der Fahrten oder die Anzahl der Online-Fahrer) zu verstehen und zu antizipieren, die für das Entwicklungsteam aus Minsk nicht offensichtlich sind. Einige Ereignisse können gegoogelt werden (Wetterbedingungen, SuperBowl-Finale, Marathons, Radrennen usw.), aber einige sind schwieriger. Zum Beispiel war es für uns im ersten Arbeitsjahr eine Überraschung, dass der Ramadan die Anzahl der Fahrer, die bereit sind, eine Bestellung anzunehmen, stark beeinflusst. Tatsache ist, dass in den USA viele Muslime als Fahrer arbeiten und im Urlaub nicht zur Arbeit gehen. Es ist schwierig, eine solche Tatsache in Minsk zu berücksichtigen.
  
• Verfolgen Sie Änderungen in den Geschäftsmetriken. Im dritten Monat nach dem Start von Juno und dem rasanten Anstieg der Anzahl der Fahrten stellten wir fest, dass nicht genügend Fahrer online waren, was sich auf die Zeit der Fahrzeugauslieferung und den Wunsch der Passagiere auswirkte, mit uns zu reisen. Es stellte sich heraus, dass ein Konkurrent eine Kampagne startete, die den Fahrern eine höhere Bezahlung für Fahrten in den Hauptverkehrszeiten am Morgen und am Abend garantierte. Die Informationen wurden schnell an Minsk übermittelt, und in kurzer Zeit hatten wir auch die Möglichkeit, solche Bedingungen anzubieten. Dieser Schritt hat uns geholfen, die Fahrer zurückzubekommen und weiter zu wachsen.
  

Metriken und Überwachung

In Juno haben alle Teams Metriken, die wir in folgende Bereiche unterteilt haben:

• Geschäftsmetriken.
  
• Technische Metriken.
  

Geschäftsmetriken sind eine Reihe von Indikatoren, die den „Gesundheitszustand“ eines Produkts messen. Wir teilen sie bedingt in zwei Teile:

• Online Die offensichtlichen sind die Anzahl der Fahrer und Passagiere online, die Anzahl der Fahrten nach Status. Weniger offensichtlich sind die Anzahl der neuen Benutzer, die Umstellung vom Bildschirm mit dem vorläufigen Preis der Reise auf die Buchung einer Reise, die durchschnittliche Wartezeit für ein Auto in einem bestimmten Gebiet, die Geschwindigkeit der Warteschlange am Flughafen usw.
  
• Offline Nicht alle Informationen können schnell in Echtzeit abgerufen und verarbeitet werden, und dies ist nicht immer erforderlich. Wenn wir Werbeaktionen für Fahrer oder neue Funktionen planen, sind wir an langfristigen Trends oder Benutzerreaktionen auf das A / B-Experiment interessiert, sei es ein neues Design, eine neue Funktion oder ein zusätzlicher Rabatt.
  

Um analytische Berichte basierend auf den gesammelten Metriken zu erstellen, verwenden wir Tableau. Für solche Berichte sind wir für das Business Intelligence (BI) -Team verantwortlich. Sie arbeiten im Büro in Tel Aviv neben dem Lebensmittelgeschäft. Beide Teams arbeiten eng mit Kollegen in New York zusammen, sodass BI-basierte Analysten den Erfolg der ergriffenen Maßnahmen bewerten, Hypothesen zur Überprüfung in den „Feldern“ formulieren und den Produktentwicklungsplan anpassen können.

Auf der anderen Seite gibt es eine Reihe technischer Metriken, die sich irgendwie auf das Gesamtsystem auswirken.

Technische Metriken sind eine Reihe von Indikatoren, die den fehlerfreien Betrieb einzelner Komponenten anzeigen, auf deren Grundlage eine Schlussfolgerung über den Betrieb des gesamten Systems gezogen wird. Sie zeigen an, wie viel Zeit Anrufe zwischen Diensten benötigen, wie viel Speicher sie verbrauchen und ob beim Übertragen von Nachrichten zwischen ihnen kritische Fehler auftreten. In Juno gibt es viele solcher Metriken. Sie sind etwas redundant, aber in kritischen Situationen hilft es, die Ursache des Problems schnell zu finden. Das Verfolgen und Verwenden technischer Metriken hilft uns:

• Dashboard - Zeigt wichtige Vitalfunktionen des Systems an. Jedes Entwicklungsteam erstellt seine eigenen Metriken, anhand derer es verstehen kann, wie sich eine bestimmte Änderung auf die ihm anvertrauten Mikrodienste auswirkt. So überwacht beispielsweise ein Team die Metriken für die Zahlung von Geld an Fahrer und Beifahrer, und das andere Team untersucht die Metrik, die für die Fahrersuchzeit oder die Anzahl der empfangenen Koordinaten verantwortlich ist.
  

• Protokolle Wir protokollieren Ereignisse von Mobilgeräten und Backend-Microservices. 2017 belegten sie 400-500 Gigabyte pro Woche, bis 2018 verdoppelte sich diese Zahl. Wir sind an folgenden Ereignissen interessiert: Anrufe von Microservices an externe Informationsquellen, an andere Microservices, Empfangen und Senden von Kundenanfragen, alle Arten von Fehlern (geschäftlich und technisch). Es ist erwähnenswert, dass die Informationen anonymisiert sind: Personenbezogene Daten wie Passwörter und Bankdaten werden nicht protokolliert.
  

Zur Überwachung der Leistung verwenden wir Grafana und Prometheus. Wenn Entwickler einen neuen Service entwickeln oder eine neue Funktion hinzufügen, fügen sie dem Service die erforderlichen Metriken hinzu, und dann richtet jedes Team Warnungen für sich ein.

Dank angepasster Warnungen führt das technische Support-Team eine erste Analyse durch und eskaliert das Problem zur weiteren Lösung in die Entwicklung oder in Geschäftsteams.
Wenn das Problem technischer Natur ist und den normalen Betrieb des Dienstes gefährdet, erstellt das technische Supportteam einen Produktionsvorfall. Dank des automatisierten Prozesses werden die Stakeholder sofort benachrichtigt, einschließlich des Kundensupportteams (Kundendienst alias Helpdesk alias L1-Support), das sich auf einen möglichen Zufluss von Anrufen vorbereitet.

Vorfalluntersuchung

Im Laufe der Zeit kamen wir zu dem Schluss, dass nach jedem schwerwiegenden Vorfall eine Art „Nachbesprechung“ stattfindet. Wir nehmen Änderungen an Prozessen vor, die uns helfen, ähnliche Ereignisse in Zukunft zu vermeiden oder besser zu bewältigen.

Die oben genannten Elemente: Metriken, Dashboards, Warnungen und Protokolle helfen zu verstehen, was passiert ist. Die Teams setzen sich zusammen, analysieren Änderungen der technischen und geschäftlichen Indikatoren, berücksichtigen Fehler und ziehen Lehren für sich.

Wir müssen uns mit Produktionsvorfällen sowie mit jeder anderen Situation befassen, in der es unmöglich ist, schnell zu beantworten, was passiert ist. Und hier hilft das technische Support-Team (TechSupport aka L2-Support).

Welche Probleme werden im technischen Support behoben? Es wird angenommen, dass dies eine langweilige Arbeit ist, wie in der Serie IT Crowd, in der drei Nerds im Keller einfach das tun, was sie sagen: "Versuchen Sie, den Computer auszuschalten und einzuschalten." In der Tat stellen sich Fragen komplex und kontrovers.

Die erste Unterstützungsstufe (Kundendienst) ist nach dem Prinzip „Folge der Sonne“ (Folge der Sonne) organisiert. Mit diesem Ansatz ist eine Benutzerunterstützung rund um die Uhr ohne Nachtschichten möglich. In europäischen Zeiten befindet sich ein Büro in Tel Aviv und zu amerikanischen Zeiten - in Portland. Die Aufgabe dieses Teams ist es, zuzuhören und den „Schmerz“ des Fahrers oder Beifahrers zu verstehen, sich zu beruhigen und wenn möglich zu helfen. Die Leute, die dort arbeiten, sind für Fragen bezüglich des Betriebs des Dienstes verantwortlich. Gleichzeitig ist das Team nicht „technisch“, und sobald der Moment gekommen ist, in dem es notwendig ist, tiefer in die technischen Nuancen einzutauchen, wird die Anfrage an das technische Support-Team weitergeleitet. Dieses Team arbeitet in Minsk und ist Teil des Entwicklungszentrums. Die Jungs lösen ausschließlich technische Probleme und kommunizieren nicht direkt mit Fahrern und Passagieren. Teamaufgabe: Vorfalluntersuchung und Prozessautomatisierung.

Im Falle eines Produktionsvorfalls lautet die Aufgabe für das technische Support-Team wie folgt: Während der Bereitstellung wurde ein Fehler gefunden oder ein Fehler aufgetreten. Wir haben ein Problem festgestellt, es behoben, müssen jedoch noch herausfinden, wie es sich auf das System auswirkt und was aus Sicht des Produktmanagements wiederhergestellt werden muss:

• Sind die Daten beschädigt oder ist ihre Integrität verletzt?
  
• Wie hat sich dieser Vorfall auf die Benutzer ausgewirkt?
  
• Sind alle Benutzer betroffen?
  
• Was kann behoben werden?
  

Die Fragen sind einfach, aber um sie zu beantworten, müssen Sie sehr gut verstehen, wie das System funktioniert und wie sich sein Verhalten während des Vorfalls geändert hat. Bei der Beantwortung der Frage sollten Sie den laufenden Bereitstellungsprozess als die Wahrscheinlichkeit berücksichtigen, dass sich in jeder Minute etwas ändern kann.

Wenn beispielsweise technischer Support erforderlich ist, damit das Produkt ordnungsgemäß funktioniert, betrachten Sie den Fall „Ich habe keine Reise unternommen“. Der Fahrer nahm einen anderen Passagier und machte eine Reise, für die unser Passagier nicht bezahlen möchte. In diesem Fall muss zwischen einer legitimen Anfrage und einem Betrugsversuch unterschieden werden, wenn der Benutzer versucht, die erbrachten Dienstleistungen nicht zu bezahlen.

Wenn die Anfrage wiederholt eingeht, wird sie vom technischen Support automatisiert und dem Benutzer-Support-Team in Form einer Webanwendung zur Verfügung gestellt. Mit diesem Ansatz können Sie die Zeit reduzieren, die für die Bearbeitung der Anfrage eines Benutzers erforderlich ist, und das technische Support-Team nicht aufblasen. Trotzdem ist die Stelle des technischen Supportingenieurs für uns immer offen, da die Jungs wachsen und zu anderen Entwicklungsteams wechseln.

Alle Wege führen nach Rom

Eine detaillierte Beschreibung der Arbeit des technischen Supportteams im Rahmen dieses Artikels ist kein Zufall. So kam es, dass es zu einem Ort wurde, an dem Informationen aus allen Quellen fließen. Ein einziger Kontaktpunkt reduziert die Anzahl der Dolmetscher und damit die Anzahl der Verzerrungen.

Dies bedeutet nicht, dass das technische Support-Team das Hauptglied bei der Verwaltung des Produkts der Operation ist, da das Produktunternehmen ein lebender Organismus ist: Alle Organe sind wichtig und notwendig. Es ist unmöglich zu wählen, was für eine Person wichtiger ist - das Gehirn oder Herz, die Lunge oder das Kreislaufsystem. Nur die harmonische Entwicklung und Interaktion aller Organe garantiert das gesunde Funktionieren des Körpers oder des IT-Unternehmens.

Gesundheit für Sie und Ihre Produkte!