Comment faire pousser un produit sain (exemple Juno)

On a beaucoup parlé des avantages de travailler dans une entreprise d'épicerie, et il est difficile d'être original ici. Mais loin de tout le monde sait comment maintenir la «santé» d'un produit et ce qu'il est possible de faire dans une entreprise alimentaire, en plus de développer des fonctionnalités. Nous vous expliquerons comment nous utilisons le produit chez Juno et comment le service des opérations et les spécialistes techniques y participent.

Nous ne déclarons pas que notre chemin est le plus correct. Nous essayons constamment, faisons des erreurs et essayons d'apprendre de nos erreurs. Nous espérons que notre expérience vous sera utile.

À propos de nous: Juno est un service de dissimulation de trajets opérant sur le marché américain et faisant partie du groupe d'entreprises Gett.

Juno écrit du code dans les langues Go, Swift, Kotlin, Python, React.js au sein des équipes d'applications mobiles, Backend, Frontend, Data Science, Technical Operation Support, créant un service qui fait désormais partie de la vie quotidienne de dizaines de milliers de conducteurs et de centaines de milliers de nouveaux résidents York.

En quoi consiste la gestion des produits

Comprenons le processus de fonctionnement dans Juno et essayons de le décomposer en ses parties constituantes.
Nous avons identifié trois composants clés pour nous-mêmes:

1. Bureau opérationnel
   
2. Mesures et surveillance
   
3. Enquête sur l'incident
   

Le but du fonctionnement du produit est de répondre en temps opportun aux problèmes et changements émergents, quelle que soit leur nature.
Pour ce faire, vous avez besoin de:

• Définir les indicateurs de santé du système
  
• Comprendre comment les changements au sein du système affectent les métriques
  
• Comprendre comment les changements du marché affectent les performances
  
• Comprendre quand le changement devient un problème
  

Avec cette approche, les décisions commerciales sont basées sur des données. Notre équipe d'exploitation travaille à New York, car le service Juno n'est actuellement disponible que pour les résidents de cette métropole.
La liste de tâches quotidiennes de l'équipe ressemble à ceci:

• Suivez et répondez rapidement aux changements réglementaires. Les changements courants incluent l'apparition d'une nouvelle route à péage et le transfert d'une zone d'attente pour les chauffeurs à l'aéroport. Dès que nous recevons des informations sur de tels événements, l'employé quitte le lieu pour mettre à jour correctement la carte et analyser la liste des problèmes possibles. Lorsque l'équipe de développement met à jour la carte sur les serveurs, l'employé teste les modifications des «conditions de terrain» et s'assure que cela fonctionne correctement.
  
• Mener des recherches «sur le terrain». Lorsque nous avons lancé le service à New York, le plan était d'abord de recruter un certain nombre de chauffeurs pour le fonctionnement stable du service dans n'importe quel quartier de la ville. Pour cette raison, pendant quelques mois, les conducteurs qui nous ont rejoints ont d'abord conduit sans passagers et n'ont reçu que rarement des trajets de bêta-testeurs. Ces voyages n'ont pas suffi à rassembler les informations nécessaires. Ensuite, nous avons décidé d'envoyer l'équipe d'exploitation dans les «champs» afin d'évaluer la qualité du service et de connaître les plaintes des chauffeurs concernant l'application. Cette approche s'est avérée utile et nous l'utilisons constamment pour publier des changements significatifs ou pour tester des hypothèses.
  
• Nouvelles "Calendrier des événements" - une liste d'événements, de vacances et d'événements météorologiques qui peuvent affecter la quantité et la qualité des voyages. Cela permet de comprendre et d'anticiper les changements d'indicateurs clés (par exemple, le nombre de voyages ou le nombre de conducteurs en ligne) qui ne sont pas évidents pour l'équipe de développement de Minsk. Certaines épreuves peuvent être googlées (conditions météorologiques, finales SuperBowl, marathons, courses cyclistes, etc.), mais certaines sont plus difficiles. Par exemple, au cours de la première année de travail, nous avons été surpris de constater que le Ramadan affecte considérablement le nombre de conducteurs prêts à accepter une commande. Aux États-Unis, de nombreux musulmans travaillent comme chauffeurs et ne vont pas travailler en vacances. Il est difficile de prendre en compte un tel fait à Minsk.
  
• Suivez l'évolution des mesures commerciales. Au cours du troisième mois après le lancement de Juno et la croissance rapide du nombre de voyages, nous avons constaté qu'il n'y avait pas suffisamment de chauffeurs en ligne, ce qui a affecté le temps de livraison de la voiture et le désir des passagers de voyager avec nous. Il s'est avéré qu'un concurrent a lancé une campagne garantissant aux conducteurs une augmentation des paiements pour les trajets aux heures de pointe du matin et du soir. Les informations ont été rapidement transmises à Minsk et, en peu de temps, nous avons également eu la possibilité de proposer de telles conditions. Cette étape nous a aidés à récupérer des chauffeurs et à continuer de croître.
  

Mesures et surveillance

Dans Juno, toutes les équipes ont des métriques, que nous avons convenu de diviser en:

• Mesures commerciales.
  
• Mesures techniques.
  

Les métriques commerciales sont une série d'indicateurs qui mesurent la «santé» d'un produit. Nous les divisons conditionnellement en deux parties:

• En ligne Les plus évidents sont le nombre de conducteurs et de passagers en ligne, le nombre de trajets par statut. Moins évidents sont le nombre de nouveaux utilisateurs, la conversion de l'écran avec le prix préliminaire du voyage en réservation de voyage, le temps d'attente moyen pour une voiture dans une zone spécifique, la vitesse de la file d'attente à l'aéroport, etc.
  
• Hors ligne Toutes les informations ne peuvent pas être obtenues et traitées rapidement en temps réel, et ce n'est pas toujours nécessaire. Lorsque nous planifions des promotions pour les pilotes ou de nouvelles fonctionnalités, nous sommes intéressés par les tendances à long terme ou les réactions des utilisateurs à l'expérience A / B, qu'il s'agisse d'un nouveau design, d'une nouvelle fonction ou d'une remise supplémentaire.
  

Pour créer des rapports analytiques basés sur les métriques collectées, nous utilisons Tableau. Pour de tels rapports, nous sommes responsables de l'équipe Business Intelligence (BI). Ils travaillent dans le bureau de Tel Aviv à côté de l'équipe d'épicerie. Les deux équipes travaillent en étroite collaboration avec des collègues de New York, ce qui permet aux analystes basés sur BI d'évaluer le succès des actions entreprises, de formuler des hypothèses de vérification dans les «domaines» et d'ajuster le plan de développement de produit.

D'un autre côté, il existe un certain nombre de paramètres techniques qui affectent le système dans son ensemble.

Les métriques techniques sont une série d'indicateurs indiquant le fonctionnement sans erreur de composants individuels, sur la base desquels une conclusion est tirée sur le fonctionnement du système dans son ensemble. Ils montrent combien de temps les appels entre les services prennent, combien de mémoire ils consomment et s'il y a des erreurs critiques lors du transfert de messages entre eux. Il existe de nombreuses mesures de ce type dans Juno. Ils sont quelque peu redondants, mais dans des situations critiques, cela aide à trouver rapidement la cause du problème. Le suivi et l'utilisation de métriques techniques nous aident à:

• Tableau de bord - affiche les signes vitaux importants du système. Chaque équipe de développement compile son propre ensemble de métriques qui les aident à comprendre comment un changement particulier a affecté les microservices qui leur sont confiés. Ainsi, par exemple, une équipe surveille les mesures liées au paiement de l'argent aux conducteurs et aux paiements des passagers, et l'autre examine la mesure responsable du temps de recherche du conducteur ou le nombre de coordonnées reçues.
  

• Journaux Nous enregistrons les événements des appareils mobiles et des microservices backend. En 2017, ils occupaient 400 à 500 gigaoctets par semaine, en 2018, ce chiffre avait doublé. Nous sommes intéressés par les événements suivants: appels de microservices à des sources d'informations externes, à d'autres microservices, demandes reçues et envoyées à des clients, toutes sortes d'erreurs (commerciales et techniques). Il convient de noter que les informations sont anonymisées: les données personnelles, telles que les mots de passe et les informations bancaires, ne sont pas enregistrées.
  

Pour surveiller les performances, nous utilisons Grafana et Prometheus. Lors du développement d'un nouveau service ou de l'ajout d'une nouvelle fonction, les développeurs ajoutent les métriques nécessaires au service, puis chaque équipe établit des alertes pour elle-même.

Grâce à des alertes personnalisées, l'équipe de support technique effectue une première analyse et transforme le problème en développement ou en équipes commerciales pour une résolution ultérieure.
Si le problème est de nature technique et menace le fonctionnement normal du service, l'équipe de support technique crée un incident de production. Grâce au processus automatisé, les parties prenantes sont immédiatement informées, y compris l'équipe de support client (Service client aka Helpdesk aka support L1), qui se prépare à un éventuel afflux d'appels.

Enquête sur l'incident

Au fil du temps, nous sommes arrivés à la conclusion qu'après chaque incident grave, une sorte de «débriefing» avait lieu. Nous apportons des modifications aux processus qui nous aident à éviter ou à mieux gérer des événements similaires à l'avenir.

Les éléments mentionnés ci-dessus: métriques, tableaux de bord, alertes et journaux aident à comprendre ce qui s'est passé. Les équipes s'assoient ensemble, analysent les changements des indicateurs techniques et commerciaux, tiennent compte des erreurs et en tirent des leçons.

Nous devons faire face aux incidents de production, ainsi qu'à toute autre situation où il est impossible de répondre rapidement «ce qui s'est passé». Et ici, l'équipe de support technique aide (TechSupport aka support L2).

Quels problèmes sont résolus dans le support technique? On pense que c'est un travail ennuyeux, comme dans la série IT Crowd, où trois nerds au sous-sol font juste ce qu'ils disent: "essayez d'éteindre et d'allumer l'ordinateur." En fait, les questions se posent de façon complexe et controversée.

Le premier niveau de support (service client) est organisé selon le principe de «suivre le soleil» (suivre le soleil). Avec cette approche, une assistance utilisateur 24h / 24 est possible sans quarts de nuit. À l'heure européenne, un bureau est situé à Tel Aviv, et aux heures américaines - à Portland. La tâche de cette équipe est d'écouter et de comprendre la «douleur» du conducteur ou du passager, de se calmer, de l'aider si possible. Les gars qui y travaillent sont responsables des questions concernant le fonctionnement du service. Dans le même temps, l'équipe n'est pas «technique», et dès que vient le moment où il faut approfondir les nuances techniques, la demande est redirigée vers l'équipe de support technique. Cette équipe travaille à Minsk et fait partie du centre de développement. Les gars résolvent exclusivement des problèmes techniques et ne communiquent pas directement avec les conducteurs et les passagers. Tâche d'équipe: enquête sur les incidents et automatisation des processus.

Dans le cas d'un incident de production, la tâche de l'équipe de support technique est la suivante: un bogue a été détecté ou une défaillance s'est produite lors du déploiement, nous avons remarqué un problème, l'avons résolu, mais nous devons encore comprendre comment cela a affecté le système et ce qui doit être restauré du point de vue de la gestion des produits:

• Les données sont-elles endommagées ou leur intégrité est-elle violée?
  
• Comment cet incident a-t-il affecté les utilisateurs?
  
• Tous les utilisateurs sont-ils affectés?
  
• Que peut-on réparer?
  

Les questions sont simples, mais pour y répondre, vous devez très bien comprendre comment fonctionne le système et comment son comportement a changé pendant l'incident. Lorsque vous répondez à la question, il convient de considérer le processus de déploiement en cours, comme la probabilité que quelque chose puisse changer à chaque minute.

Par exemple, lorsque le support technique était nécessaire pour que le produit fonctionne correctement, considérons le cas «Je n'ai pas fait de voyage». Le chauffeur a emmené un autre passager et a fait un voyage pour lequel notre passager ne veut pas payer. Dans ce cas, il est nécessaire de distinguer entre une demande légitime et une tentative de fraude lorsque l'utilisateur essaie de ne pas payer pour les services fournis.

Si la demande arrive à plusieurs reprises, elle est automatisée par l'équipe de support technique et fournie à l'équipe de support utilisateur sous la forme d'une application Web. Cette approche vous permet de réduire le temps nécessaire pour traiter la demande d'un utilisateur et de ne pas «gonfler» l'équipe d'assistance technique. Néanmoins, la vacance de l'ingénieur du support technique est toujours ouverte pour nous, alors que les gars grandissent et passent à d'autres équipes de développement.

Tous les chemins mènent à Rome

Une description détaillée du travail de l'équipe de support technique dans le cadre de cet article n'est pas accidentelle. Il se trouve que c'est devenu un lieu où l'information circule de toutes les sources. Un seul point de contact réduit le nombre d'interprètes et donc le nombre de distorsions.

Cela ne signifie pas que l'équipe de support technique soit le maillon principal de la gestion du produit de l'opération, car la société de produits est un organisme vivant: tous les organes sont importants et nécessaires. Il est impossible de choisir ce qui est le plus important pour une personne - le cerveau ou le cœur, les poumons ou le système circulatoire. Seul le développement harmonieux et l'interaction de tous les organes garantissent le bon fonctionnement du corps ou de l'entreprise informatique.

Santé à vous et à vos produits!