Depuis treize ans, nous recherchons des moyens de faire évoluer le développement afin que tout fonctionne de manière fiable à mesure qu'il se développe et, en même temps, de nouvelles fonctionnalités sont publiées rapidement. Autrefois, il semblait important de renommer facilement les colonnes d'une base de données. Maintenant, je devais changer toute l'architecture en déplacement.
Il s'agit du troisième poste de développement annuel du Black Friday, la semaine de pointe. Pourquoi pensons-nous enfin que nous sommes grands; ce qu'ils ont fait pour cela; pourquoi nous avons rencontré des difficultés et ce que nous prévoyons de faire ensuite.
Résumé: deux ans de travail pour une bonne raison
Pour la cinquième année consécutive, la charge de Mindbox double environ chaque année. En novembre 2020, nous avons traité 8,75 milliards de demandes d'API, contre 4,48 milliards un an plus tôt. Le pic est de 400 000 requêtes par minute. Envoyé 1,64 milliard d'e-mails et 440 millions de notifications mobiles. Il y a un an, il y avait 1,1 milliard de courriels, mais il n'y avait presque pas de poussée.
Dynamique du nombre de mailings par semaine du Black Friday:
Selon nos données, cela est comparable au niveau de charge de hh.ru sur les requêtes API, en termes de charge sur les bases de données - avec Avito. Environ un tiers de Yandex-taxi sur les demandes par minute.
En 2018 et 2019Au fil des années, nous avons mal géré cela: les clients ont souffert de refus. Fin 2018, j'espérais des améliorations rapides et j'attendais une feuille de route commerciale, qui n'a jusqu'à présent été qu'à moitié achevée. En 2019, j'ai décidé de garder le silence sur la feuille de route, car la fiabilité se détériorait, les échecs ont commencé en septembre, et le Black Friday, ils se sont répétés, malgré le gros travail effectué.
Aujourd'hui, nous pouvons conclure: nous avons appris à faire face à la croissance. Le Black Friday 2020 s'est déroulé sans incident affectant plus d'un client. Il y a eu deux pannes partielles à court terme dues à une infrastructure externe qui n'a pas violé le SLA. Malheureusement, il y a eu des plaintes de plusieurs des plus gros clients, mais ce sont des histoires uniques que nous comprenons et sur lesquelles nous travaillons.
De plus, les données et les avis subjectifs des utilisateurs montrent une tendance à long terme à l'augmentation de la qualité du développement. Les défauts - erreurs critiques, pannes et performances médiocres - sont réduits.
Le graphique montre les violations du SLA interne (plus strict que le SLA externe), que nous avons également rendu plus strict cette année:
Nombre de violations de SLA internes par un client moyen
Nous avons réussi à «réinventer» complètement le développement en deux ans, en continuant à croître à un taux moyen de 40% du chiffre d'affaires par an (en 2019 - 431 millions, en 2020 - 618 millions) et en publiant de nouvelles fonctionnalités. Sentiments - sur la façon de changer le moteur d'une voiture à pleine vitesse.
Ce qui a été fait en deux ans:
- (LESS) , , .
- 50% , ( ) .
- SRE. SRE .
- , , .
- SLA .
- «-», .
C'est loin d'être tout prévu. Nous continuons d'augmenter le montant des ressources allouées à la qualité. Nous nous attendons à de nouvelles améliorations de la qualité et à une version plus rapide des nouvelles fonctionnalités en 2021 et au-delà.
En passant, nous écrivons régulièrement sur les mises à jour des produits et maintenons une page d'état avec un historique des incidents .
Les origines des difficultés: 2008-2018
Mindbox est un produit à la logique métier complexe, depuis 2008 nous développons en tant que service pour les grandes entreprises, avec une part des coûts de développement de plus de 30%. D'un point de vue architectural, il s'agissait d'une application monolithique traditionnelle, mais de très haute qualité: chaque jour, nous publions et publions encore plusieurs mises à jour monolithiques.
En 2014, le marché nous a fait nous tourner vers un segment plus grand, incluant le e-commerce et le retail. Cela a nécessité un investissement dans le service client, les ventes et le marketing.
L'entreprise n'a jamais attiré d'investissements externes, elle s'est toujours développée sur son propre profit. De plus, en 2017, six mois après que je suis devenu PDG, nous avons fait face à une pénurie d'argent, j'ai eu peur et j'ai augmenté ma rentabilité de manière excessive. Tout cela a conduit à une réduction des coûts de développement à 24% du chiffre d'affaires en 2018-2019.
Dans le même temps, il était nécessaire de libérer de nombreuses fonctions nécessaires aux nouveaux clients - avec une augmentation rapide de la charge et du nombre de clients. Nous avons fait face à l'arriéré du produit et de l'architecture d'origine, ainsi qu'à la décentralisation - la formation d'équipes de produits autonomes.
Malheureusement, l'expertise technique de ces équipes n'a pas suivi le rythme de la croissance de l'entreprise, qui a été encore exacerbée par les limites du possible dans l'architecture monolithique. La dette technique s'accumulait, la technologie utilisée était dépassée et les salaires étaient inférieurs au marché. L'embauche d'ingénieurs est devenue de plus en plus difficile, malgré les défis difficiles et la culture unique de l'entreprise. En 2018, le nombre de clients avait été multiplié par 10, le succès du produit devenait évident, ainsi que les problèmes de fiabilité et de développement en général.
Quelles mesures avons-nous prises
Processus et ressources
La première hypothèse était la centralisation: en 2019, LESS a été introduit - c'est alors que plusieurs équipes travaillent sur un même projet en même temps. Nous avons commencé à concevoir conjointement des épopées et à travailler avec fiabilité, nous avons réussi à augmenter la prévisibilité et à trouver des pratiques de conception utiles. Cependant, au bout d'un an, l'inefficacité du processus est devenue évidente: démotivation et responsabilité réduite des équipes par manque de sens de «leurs» fonctionnalités, coûts de gestion élevés, ce que personne n'aimait faire.
Au cours d'une année de conception collaborative, une vision d'une architecture décentralisée a émergé qui permettrait à chaque équipe d'être responsable de microservices isolés tout en continuant à fournir un produit unique aux clients. Parallèlement à la vision, des arriérés de tâches sont apparus et il est devenu clair qu'il était nécessaire de travailler sur l'infrastructure avec des spécialistes dédiés, sans l'interrompre avec une feuille de route commerciale.
Nous avons convenu d'allouer 30% de la ressource à la dette technique sur une base continue. La première équipe d'infrastructure a été formée et des équipes autonomes ont recommencé à être affectées. Dans le même temps, un certain nombre de processus de collaboration centralisés ont été préservés, visant principalement à maintenir la qualité:
- conception,
- analyse des défauts,
- modéliser la charge sur le fer,
- états de démonstration et de synchronisation.
Responsabilité des architectes et des équipes des métriques de fiabilité et des prévisions de coût des serveurs. De plus, nous avons alloué 30% dans chaque équipe pour la dette technique et les bugs, en attendant la continuité des activités.
En 2020, les processus se sont stabilisés: nous avons formé une deuxième équipe d'infrastructure, et la livraison a été ajustée. La part des ressources pour les tâches métier a commencé à croître lentement à partir d'un point bas d'environ 50%, et la part des bogues a commencé à diminuer:
Allocation des ressources de développement par tâches. Le graphique n'est pas très informatif, car une métrique fiable a été établie relativement récemment, mais est étayée par des impressions du
terrain.Pendant ce temps, nous avons appris comment embaucher et intégrer les SRE, les séparer du DevOps et de l'informatique de bureau, formé des processus de service et décrit le rôle.
La pénurie d'ingénieurs a été réduite de deux manières:
- Nous avons créé une école de développement qui forme 8 à 12 développeurs juniors par an. Ce sont des développeurs qui ont de l'expérience avec notre stack, dans les capacités desquels nous sommes confiants. Aujourd'hui, l'école compte 2 équipes de 4 stagiaires.
- Nous avons systématiquement augmenté la masse salariale pour le développement, puisque les résultats commerciaux le permettaient. Le salaire moyen en développement est passé de 120 mille roubles en 2015 à 170+ à la fin de 2020 et continue de croître. Cela nous a permis de recruter plusieurs nouveaux seniors et chefs de file technologiques. La part des coûts de développement est passée à 28% et le nombre de personnes est passé de 27 à 64.
Métriques, métriques et métriques automatiques
Dans notre culture, il est d'usage de gérer par des données et non par des opinions personnelles. Des mesures efficaces sont peut-être l'une des questions difficiles auxquelles les méthodologies modernes de gestion du développement ne donnent pas de réponse directe.
Nous avons commencé par automatiser quatre métriques du livre Accelerate et accélérer le pipeline de livraison. Cela n'a eu aucun effet évident immédiat. Mais l'échange d'expérience avec hh.ru et Yandex-Cloud nous a conduit à l'automatisation de la métrique de violation de SLA et à l'établissement automatique des défauts. Ici, nous avons clairement ressenti le bénéfice et le lien avec les efforts déployés. Le graphique de cette métrique avec une tendance se trouve au début de l'article.
Discret, mais je pense que nous sommes l'une des rares entreprises au monde à disposer d'une API pour les clients qui vous permet d'obtenir une métrique de la disponibilité des composants de la plateforme en temps réel.
La métrique décrite ci-dessus pour la part des bugs et de la dette technique dans l'équipe semble également utile. De plus, nous considérons comment les équipes remplissent les promesses faites pour le sprint et les développeurs respectent les délais pour les tâches quotidiennes et hebdomadaires.
Enfin, des sondages trimestriels anonymes (les textes se sont améliorés depuis, mais l'essence du sondage n'a pas changé) et une note élevée sur Habr-Karer montrent une diminution des malheurs du développement. Il s'agit de l'évaluation de ses revenus par rapport au marché, aux raffineries et à l'eNPS (données pour seulement deux trimestres à ce jour).
Enquête sur les revenus des
développeurs : Enquête sur la révision des développeurs: Développeurs eNPS:
sur une échelle de 1 à 10, quelle est la probabilité que vous recommandiez Mindbox comme lieu de travail?
Dernier point mais non le moindre, la technologie
Tout cela a permis d'organiser la réécriture d'un produit monolithique - plus de 2 millions de lignes de code sur IIS + ASP.NET + NLB / Windows Service / MS SQL - simultanément dans toutes les directions:
- Microservice API et backend, lorsqu'une demande client à API Gateway est gérée de manière transparente par plusieurs microservices, y compris les requêtes synchrones (modèle de saga).
- Microfront-end, où les sections d'interface sont séparées des applications SPA principales qui peuvent être hébergées dans leurs propres référentiels, avec leur propre pipeline de mise en page.
- Transfert de microservices multi-locataires de MS SQL vers des stockages évolutifs distribués: Cassandra, lickhouse. Kafka au lieu de RabbitMQ.
- Transfert de l'application vers .NET Core, linux et transfert partiel vers Managed Kubernetes "Yandex-clouds". Mise en œuvre immédiate des technologies SRE et DevOps modernes: OctopusDeploy + Helm, Prometheus, Grafana, Graylog + Sentry, Amixr.IO.
Peut-être sommes-nous l'un des clients les plus chargés de Yandex Cloud, alors Nikita Prudnikov a parlé de notre mise en œuvre et de la résolution conjointe des difficultés du CTO avec Yandex à Yandex Scale 2020 .
Dans notre article du Black Friday, vous pouvez en savoir plus sur nos principales approches de mise à l'échelle en utilisant l'exemple d'un composant de liste de diffusion qui n'a pas cassé l'année dernière et qui n'a pas cassé celui-ci.
Plans de développement ultérieurs
Malgré les résultats obtenus, je dois dire que moins de la moitié de ce qui était prévu a été fait. Devant:
- Continuer à augmenter les revenus des développeurs et à embaucher les meilleurs responsables senior et tech
- La troisième équipe de l'école de développement, qui permettra d'embaucher jusqu'à 12 développeurs par an
- Poursuite de la traduction de l'application vers .NET, k8s et Yandex-cloud, mise à l'échelle automatique, mise en page bleu-vert avec restauration instantanée
- Vers l'établissement automatique des incidents sur la page de statut, en éliminant les faux positifs de SLA
- Migration vers .NET 5, EF.Core et PostgreSQL (et les développeurs vers de nouveaux MacBook)
- Isolement de plusieurs autres pièces à grande échelle du monolithe
Envie de grandir Motivé .NET développeurs tehlidov et SRE-spécialistes pour répondre à notre notre travail à hh.ru . Ce sera intéressant, vous pourrez vivre une expérience unique sur le marché et faire des choses.
Plateformes de la feuille de route en 2021
Nous avons senti une base solide sous nos pieds, ce qui nous donne l'espoir de pouvoir à nouveau tenir les promesses de notre feuille de route commerciale. Nous essayons les processus de planification décentralisée pendant un an pour la première fois, mais je me permettrai imprudemment de former les attentes du public.
Cette année, nous ajouterons à la plateforme:
- Constructeur de scénario .
- Stocker et signaler des commandes anonymes
- Plus de rapports rapides dans l'interface ( comme dans notre cours )
- Intégration avec BI
- Nouveau module de notifications push mobiles, y compris un nouveau SDK
- La possibilité de supprimer rapidement toutes les entités, en tenant compte des dépendances les unes des autres
- Plus d'algorithmes de ML et de nombreuses améliorations de qualité par rapport aux algorithmes existants
- Plus de pages dans un nouveau design avec une réactivité d'interface améliorée
- Personnalisation simplifiée des intégrations standard et de la mécanique
Les plans pour 2022 sont plus ambitieux, mais j'espère en écrire dans un an, si l'optimisme se justifie.
Je vous remercie
Comme les histoires de réussite de clients, celle-ci est le mérite de personnes spécifiques à qui j'exprime ma gratitude:
Nikita Prudnikov, CTO, pour la vision, la cohérence et la compression systématique.
Roman Ivonin, architecte principal, pour sa patience, son esprit d'équipe, sa large responsabilité, son leadership informel et ses nuits blanches.
Igor Kudrin, CIO, pour la fondation de l'expertise SRE, la vision et le salut de tout quand personne ne sait comment.
Rostislav, Leonid, Dmitry, Mitya, Ilya, deux Artyom, Alexey, Sergei, Nikolai, Ivan, Slava, Zhenya et d'autres développeurs, produits, chefs de file technologiques et SRE attentionnés qui en ont fait une réalité. Désolé si je n'ai mentionné personne.
Un merci spécial aux clients qui ont enduré, malgré le fait que nous avons échoué, et ont donné l'opportunité de s'améliorer. Nous mettrons tout en œuvre pour continuer à nous améliorer.