| Jubijub |
tryptique a écrit :
Y a une tendance chez certains dev à pas vouloir être page à 3h du matin pour un truc sur lequel ils ont l'impression de ne pas avoir de contrôle. Genre typiquement "y a moins de signup parce que les gens veulent pas utiliser notre service" :o
|
j'ai souvent ce genre d'argument :D Avec toujours la même technique de l'exagération du propos qui fait passer ce que je demande pour un truc outrancier, alors que pas en fait.
en l'occurence on parle pas des sign-ups, mais des gens déjà actif sur la plateforme (aka des utilisateurs du service, en fait, aka la raison pour laquelle notre équipe existe). Et ensuite on est pas obligé de configurer des seuils débiles. Notre base utilisateur varie pas de 5% chaque jour, pourtant une alerte de ce type aurait détecté ce problème. On a 10 ans d'historique de données, donne moi une aprèm et je te calcule un seuil réaliste avec la saisonnalité :).
Et last, toute alerte nécessite pas de page un SWE au milieu de la nuit, mais si qqn l'avait vu au matin, on passait déjà de 72h à < 12h, et on aurait évité de passer pour des cons parce que c'est une autre équipe qui a trouvé le problème (parce que eux ont du monitoring business, et ils ont vu la chute) bref, j'ai BEAUCOUP de mal avec l'argument "oui mais ça on a pas le controle". :D hephaestos a écrit :
Alors que le PMD (Post Mortem Driven Development c'est tellement efficace. Ouais, on va passer 3 mois à résoudre un problème et à le rendre impossible à se reproduire de 12 façons différentes, on va réveiller 3 oncalls au passage le temps de régler l'alerte, et dans 6 mois la fonctionnalité à protéger aura dégagé. Mais bon, le bug a mis l'affiche au PM devant son VP, du coup c'est code rouge tant que c'est pas réglé.
|
ah non c'est de la merde aussi. On notera que c'est souvent un manager quelconque qui demande ça, parce que c'est l'équivalent dans cette situation du fait de se lever, mettre ses mains dans ses poches, marcher doucement autour de la table, et demander : Yes...but will it scale ? Ça coute rien à celui qui le demande, et ça permet d'assoir son autorité :D
Les bons Post mortem sont en general ceux demandé par les TL/M : si cette personne sent pas la truc, et veut en savoir plus, c'est en general une bonne idée de regarder. hephaestos a écrit :
Je trouves que tu en rajoutes un chouilla [:casper87] Ou alors tu as une équipe de merde. Pour avoir passé les deux derniers mois à installer un système de monitoring sur un nouveau service qui fait 10 QPS, sans que personne ne l'ait demandé, je me sens offensé.
|
j'ai une équipe épuisante : individuellement très forts, mais vivant dans le culte du "Principal Engineer" qui bosse depuis 15 ans chez G dont 10 ici, et n'a jamais trop vu grand chose ailleurs, dans une PA qui historiquement n'a pas de monétisation (c'est Ads qui gagne la thune, pas nous). Pour lui chaque marchant est un fraudeur en puissance, et c'est pas grave si on pète 4 bons marchants tant qu'on a bloqué les 3 réellement mauvais. Cette mentalité change, mais ça prend vraiment du temps, c'est dans la culture depuis trop longtemps.
Ajoute à ça un leadership de merde pendant des années (ça va bien mieux mais ça a pris 3 ans au nouveau VP de faire le ménage), dans le sens "oh nous tant qu'il y a pas d'escalation on s'en fout", et ça aboutit à ça. L'equipe a une nouvelle cheffe (directrice PM) qui est super, vachement pechue, et qui va faire évoluer les choses dans le bon sens. Mais moi ça fait 2 ans que je me tape cette merde, donc je vais gentiment chercher la sortie :)
Moi ça me fait vriller parce que je suis un ancien client G, j'ai été un consultant G pour les clients (où je me suis au passage fait copieusement allumer à cause de nos décisions produit parfois...discutables), et donc me retrouver au sein d'une équipe produit qui en a pas grand chose à foutre c'est dur. Mon propos n'est pas du tout generalisable aux autres équipes Eng (on le voit quand on bosse avec Ads, ou Payment : leurs processes sont à des années lumière des notres, mais c'est pas étonnant : eux sont sur le chemin critique de la thune) |
