Nous avons récemment lancé un petit projet pour nettoyer la façon dont certaines parties de nos systèmes communiquent en coulisses chez Buffer. Un peu de contexte : nous utilisons quelque chose appelé SQS (Amazon Simple Queue Service. Ces files d'attente agissent comme des salles d'attente pour les tâches. Une partie de notre système dépose un message et une autre le récupère plus tard. Pensez-y comme si vous laissiez une note à un collègue : « Hé, quand vous en avez l'occasion, traitez ces données. » Le système qui envoie la note n'a pas à attendre une réponse. Notre projet était de effectuer une maintenance de routine : mettre à jour les outils que nous utilisons pour tester les files d'attente localement et nettoyer leur configuration. Mais pendant que nous cartographiions les files d'attente que nous utilisons réellement, nous avons découvert quelque chose auquel nous ne nous attendions pas : sept processus d'arrière-plan différents (ou tâches cron, qui sont des tâches planifiées qui s'exécutent automatiquement) et des travailleurs qui fonctionnaient silencieusement depuis cinq ans, tous ne faisant absolument rien d'utile. Voici pourquoi cela est important, comment nous les avons trouvés et ce que nous avons fait à ce sujet. J'ai fait un calcul rapide et pour l'un de ces travailleurs, nous aurions payé environ 360 à 600 $ sur 5 ans. C'est un montant modeste dans le grand schéma de nos finances, mais c'est certainement du pur gaspillage pour un processus qui ne fait rien. Cependant, après avoir effectué ce nettoyage, je dirais que le coût financier est en fait la plus petite partie du problème. Cela a conduit notre équipe à consacrer des cycles de maintenance à des chemins de code qui ne servaient à rien. Et au fil du temps, les connaissances institutionnelles s'estompent-elles ? Était-ce un correctif temporaire qui est devenu permanent ? Comment cela se produit-il ? Il est facile de pointer du doigt, mais la vérité est que cela se produit naturellement dans tout système de longue durée. Une fonctionnalité devient obsolète, mais le travail en arrière-plan qui la supportait continue de s'exécuter. Quelqu'un lance un travailleur "temporairement" pour gérer une migration, et il n'est jamais détruit. Une tâche planifiée devient redondante après un changement architectural, mais personne ne pense à vérifier. anniversaires correspondant à la date actuelle et avons envoyé aux clients un e-mail personnalisé. Lors d'une refactorisation en 2020, nous avons changé notre outil de messagerie transactionnelle, mais avons oublié de supprimer ce travailleur - il a continué à fonctionner pendant cinq ans supplémentaires. Aucun de ces échecs n'est dû à des individus - ce sont des échecs de processus. Sans un nettoyage intentionnel intégré à notre façon de travailler, l'entropie l'emporte. Il y a quelques années, nous avons divisé notre monolithe en services distincts, chacun avec son propre référentiel, son pipeline de déploiement et sa propre infrastructure. À l'époque, cela avait du sens : chaque service pouvait être déployé seul, avec des limites claires entre les équipes. Mais au fil des années, nous avons constaté que les frais liés à la gestion de dizaines de référentiels dépassaient les avantages pour une équipe de notre taille. Dans le monde des microservices, chaque référentiel est son propre îlot. Un travailleur oublié dans un dépôt peut ne jamais être remarqué par les ingénieurs travaillant dans un autre. Il n'y a pas d'endroit unique pour rechercher les noms de files d'attente, pas de vue unifiée de ce qui s'exécute et où. Avec tout dans un seul référentiel, nous avons pu enfin avoir une vue d'ensemble de chaque file d'attente jusqu'à ses consommateurs et ses producteurs. Nous avons pu repérer les files d'attente avec les producteurs, mais aucun consommateur. ça a fait çadécouverte presque inévitable. Ce que nous avons réellement fait Une fois que nous avons identifié les processus orphelins, nous avons dû décider quoi en faire. Voici comment nous l'avons abordé. Tout d'abord, nous avons retracé chacun jusqu'à son origine. Nous avons fouillé l'historique de Git et l'ancienne documentation pour comprendre pourquoi chaque travailleur a été créé en premier lieu. Dans la plupart des cas, l’objectif initial était clair : une migration de données ponctuelle, une fonctionnalité qui a pris fin, une solution de contournement temporaire qui a perdu son utilité. Nous avons ensuite confirmé qu’elles étaient réellement inutilisées. Avant de supprimer quoi que ce soit, nous avons ajouté une journalisation pour vérifier que ces processus n'effectuaient pas discrètement quelque chose d'important que nous avions manqué. Nous avons surveillé pendant quelques jours pour nous assurer qu’ils n’étaient pas appelés du tout, et nous les avons supprimés progressivement. Nous n'avons pas tout supprimé d'un coup. Nous avons supprimé les processus un par un, en surveillant tout effet secondaire inattendu. (Heureusement, il n'y en avait pas.) Enfin, nous avons documenté ce que nous avons appris. Nous avons ajouté des notes à nos documents internes sur ce que chaque processus avait fait à l'origine et pourquoi il a été supprimé, afin que les futurs ingénieurs ne se demandent pas si quelque chose d'important avait disparu. Ce qui a changé après le nettoyage Nous sommes encore tôt pour mesurer l'impact total, mais voici ce que nous avons vu jusqu'à présent. Notre inventaire des infrastructures est désormais précis. Quand quelqu'un demande : « Quels travailleurs dirigeons-nous ? » nous pouvons réellement répondre à cette question en toute confiance. Les conversations d’intégration sont également devenues plus simples. Les nouveaux ingénieurs ne tombent pas sur des processus mystérieux et ne se demandent pas s'ils manquent de contexte. La base de code reflète ce que nous faisons réellement, pas ce que nous avons fait il y a cinq ans. Traitez les refactors comme de l'archéologie et de la prévention. Ce que je retiens le plus de ce projet : chaque refactor important est une opportunité pour l'archéologie. Cette file d'attente d'un vieux projet ? Le travailleur que quelqu'un a créé pour une migration de données ponctuelle ? La tâche planifiée qui fait référence à une fonctionnalité dont vous n'avez jamais entendu parler ? Ils sont peut-être encore en cours d'exécution. Voici ce que nous intégrons à notre processus à l'avenir : lors de toute refactorisation, demandez-vous : qu'est-ce qui touche ce système que nous n'avons pas examiné depuis un certain temps ? Lorsque vous désapprouvez une fonctionnalité, tracez-la jusqu'à ses processus d'arrière-plan, pas seulement le code destiné à l'utilisateur. Lorsque quelqu'un quitte l'équipe, documentez ce dont il était responsable, en particulier les éléments qui s'exécutent en arrière-plan. Au fur et à mesure que nous poursuivons la consolidation, nous sommes convaincus que nous trouverons davantage de ces reliques cachées. Mais nous sommes désormais prêts à les détecter et à empêcher la formation de nouveaux. Lorsque tout votre code réside au même endroit, l'infrastructure orpheline n'a nulle part où se cacher.
Ce que nous avons appris après avoir trouvé 7 emplois oubliés pendant 5 ans
By Social Media
·
·
6 min read
·
187 views
Read in:
aa
ace
af
ak
alz
am
ar
as
awa
ay
az
ba
ban
be
bew
+191 more
bg
bho
bik
bm
bn
brx
bs
bug
ca
ceb
cgg
ckb
co
crh
cs
cv
cy
da
de
din
doi
dv
dyu
dz
ee
el
en
eo
es
et
eu
fa
ff
fi
fj
fo
fr
fur
fy
ga
gd
gl
gom
gn
gu
ha
haw
he
hi
hil
hne
hmn
hr
hrx
ht
hu
hy
id
ig
ilo
is
it
ja
jam
jv
ka
kab
kbp
kg
kha
kk
kl
km
kn
ko
kri
ku
ktu
ky
la
lb
lg
li
lij
ln
lo
lmo
lt
ltg
lua
luo
lus
lv
mai
mak
mg
mi
min
mk
ml
mn
mni-mtei
mos
mr
ms
mt
my
nd
ne
nl
nn
no
nr
nso
nus
ny
oc
om
or
pa
pag
pam
pap
pl
ps
pt
pt-br
qu
rn
ro
ru
rw
sa
sah
sat
sc
scn
sg
si
sk
sl
sm
sn
so
sq
sr
ss
st
su
sus
sv
sw
szl
ta
tcy
te
tg
th
ti
tiv
tk
tl
tn
to
tpi
tr
trp
ts
tt
tum
ty
udm
ug
uk
ur
uz
ve
vec
vi
war
wo
xh
yi
yo
yua
yue
zap
zh
zh-hk
zh-tw
zu
