Il y a environ un an, une tâche assez sérieuse m'était assignée: organiser une conférence de 2 heures pour les managers sur l'histoire d'Agile et de DevOps.
C'est ainsi qu'a commencé mon retour du plan softskill de la formation Agile vers l'informatique. Et selon les organisateurs, plus de 1000 chefs de produit ont suivi cette conférence, dont environ 48/50 personnes ont entendu le mot «Load Balancer» pour la première fois dans ma classe.
J'ai même eu une divinité comique "un grand équilibreur, maître des mises à jour sans temps d'arrêt, bon marché pour implémenter des tests A / B sans programmation, et généralement une bonne nuit de sommeil d'un manager".
Bien sûr, les collègues de l'informatique peuvent rire de cette simplification, et même être scandalisés que le monde ne soit pas d'accord sur le mot «équilibreur» et sur la quantité d'attention qui peut y être accordée.
Mais quand dans mon gymnase 48 personnes sur 50 n'ont pas entendu parler du phénomène d'équilibrage de charge, c'est un peu triste. Oui, et les développeurs des backends de certaines applications mobiles, même les grandes banques peuvent pécher par l'absence de tels schémas.
Ma banque jaune préférée, par exemple, met à jour le serveur principal d'une application mobile à 5 heures, heure de Moscou, environ 2 fois par semaine. Pourquoi est-ce que je le sais? Parce qu'à Novossibirsk, où je revenais vivre un an en 2016, il était déjà 9h à ce moment-là, et l'erreur 000 est apparue. C'est terrible d'imaginer que c'est déjà le déjeuner pour l'Extrême-Orient.
Peut-être avons-nous une chance de rendre ce monde un peu meilleur si les gestionnaires pensent à la tolérance aux pannes au moment de budgétiser les capacités des serveurs, et il n'y aura pas 1 serveur pour tout, mais un degré vraiment proportionné de risque et de configuration de charge du système.
Pourquoi?
La toute première question qui se pose lors de la définition d'une tâche, bien sûr: pourquoi?
Il existe un tel cadre:Pourquoi en avons-nous besoin? | Pourquoi en ont-ils besoin?
Pourquoi en avons-nous besoin?
Si nous imaginons que «nous» sommes beaucoup de gens de l'informatique, non seulement des développeurs et des spécialistes connexes, mais aussi des consultants en technologie, des coachs RH et Agile, qui sont en contact quotidien avec des managers qui n'ont pas de formation informatique.
Pour ma part, j'ai répondu tout simplement à la première question: l'amélioration des connaissances techniques des managers réduit considérablement la probabilité de tâches inadéquates et augmente le bonheur des développeurs.
Pourquoi en ont-ils besoin?
Pourquoi les managers très éloignés de l'informatique le savent-ils?Nous sommes tous des êtres humains et nous voulons tous dormir paisiblement. Les managers prennent souvent la responsabilité de quelque chose qu'ils ne sont pas en mesure d'influencer vraiment. Le niveau de stress dans ce cas est comparable aux passagers de l'aéronef qui souffrent d'aérophobie.
Et c'est probablement le seul argument qui ne ressemblera pas au snobisme «eh bien, comment pouvez-vous ne pas savoir des choses aussi évidentes» ou «toute personne devrait la nuit les yeux bandés simplifier l'intégrale indéfinie». D'après mon expérience, si une personne est «au coude dans la console», alors même inconsciemment, mais elle peut souvent fonctionner avec de tels tampons.
Comment puis-je expliquer les images simples complexes
Les illustrations ci-dessous ne revendiquent pas la vérité absolue et n'ont pas de valeur indépendante, d'autant plus que ces simplifications ne doivent pas être utilisées comme guide d'action lors de la construction d'architectures tolérantes aux pannes, car je n'avais pas l'intention d'y tracer divers points subtils, tels que la mise en cache. Ce n'est qu'un modèle simplifié.
Dans l'apprentissage des adultes, et l'assimilation de nouvelles informations fait partie de la formation, il est important de comprendre que toute information doit être répétée au moins trois fois pour augmenter la probabilité qu'elle soit réellement absorbée.
Par exemple, un tel schéma sera très probablement associé au mème «n'essayez pas de quitter Omsk» et confirmera seulement la personne qui pense que «tout est compliqué, mais ils veulent aussi beaucoup de serveurs».
Mais ce schéma, illustré dans un premier temps, peut créer l'association d'une personne du mot «équilibreur» avec le phénomène d'équilibrage de la charge sur le serveur. Sans aucune garantie d'une compréhension correcte de ce processus, mais en sachant avec certitude qu'il existe et pourquoi il est nécessaire.
Gâchons les points du
manifeste Agile à cet endroit et disons "c'est-à-dire, sans diminuer la valeur de ce qui est à droite, nous valorisons davantage ce qui est à gauche".
Par exemple, parce que ce schéma vous permet de comprendre comment configurer le système de test A / B sans écrire des tonnes de code source et comment mettre à jour le serveur sans boire pour le courage (au gestionnaire, pas à l'administrateur) avant cela.
Et ensuite?
Et cette compréhension même ouvre la voie au gestionnaire dans le monde magnifique du CI / CD, car si nous connaissons déjà le travail minimum requis pour rendre l'infrastructure partiellement tolérante aux pannes, nous avons moins peur des versions fréquentes. Et cela change fondamentalement l'approche de mise à jour des politiques en général.
Eh bien, ce n'est pas à moi de vous dire que des modifications plus petites sont prévues à 1/10 de la capacité (même si c'est 1 serveur sur 3, mais seulement 10% du trafic lui est donné), c'est une forte diminution des passions lors de la mise à niveau. Même si les serveurs arrêtent complètement de traiter toutes les 10 demandes.
Nous avons déjà eu une baisse de 20% à RPS 600, et il a été rapidement éliminé, il semble même sans la participation des gens. C'est alors que moi, en tant que PM technique, responsable de tous les backends de la direction, j'ai pratiquement commencé à répéter avec aspiration le mot «équilibreur» aux autres managers.
Comme mon expérience le montre, cette connaissance est extrêmement utile précisément pour que les managers puissent comprendre comment minimiser les risques de la sortie et s’intéresser au CI / CD et à diverses expériences technologiques.
Il y a environ 4 ans, à peu près la même histoire dans ma pratique était de parler aux développeurs de systèmes de «brunching» de type GitFlow pour stabiliser les versions et les moratoires sur les validations dans la branche des versions, pris en charge au niveau du hook, mais dernièrement, il est devenu de moins en moins et moins requis.
À mon avis, il est maintenant vraiment important d'augmenter les connaissances techniques des gestionnaires non techniques. Absolument pas nécessairement de cette manière, bien sûr.