Recentemente abbiamo avviato un piccolo progetto per ripulire il modo in cui parti dei nostri sistemi comunicano dietro le quinte di Buffer. Un rapido contesto: utilizziamo qualcosa chiamato SQS (Amazon Simple Queue Service. Queste code agiscono come sale d'attesa per le attività. Una parte del nostro sistema lascia un messaggio e un'altra lo riprende più tardi. Immagina di lasciare una nota a un collega: "Ehi, quando ne hai la possibilità, elabora questi dati". Il sistema che invia la nota non deve attendere una risposta. Il nostro progetto consisteva nell'eseguire la manutenzione di routine: aggiornare gli strumenti che utilizziamo per testare le code localmente e ripulire la loro configurazione. Ma mentre stavamo mappando quali code utilizziamo effettivamente, abbiamo trovato qualcosa che non ci aspettavamo: sette diversi processi in background (o processi cron, che sono attività pianificate che vengono eseguite automaticamente) e lavoratori che sono rimasti in esecuzione in silenzio per un massimo di cinque anni. Tutti loro non fanno assolutamente nulla di utile. Ecco perché sono importanti, come li abbiamo trovati e cosa abbiamo fatto al riguardo. Perché questo è più importante di quanto si pensiSì, in esecuzione non necessaria. L'infrastruttura costa denaro. Ho fatto un rapido calcolo e per uno di quei lavoratori avremmo pagato circa $ 360-600 in 5 anni. Si tratta di una cifra modesta nel quadro generale delle nostre finanze, ma sicuramente puro spreco per un processo che non fa nulla. Tuttavia, dopo aver eseguito questa pulizia, direi che il costo finanziario è in realtà la parte più piccola del problema. Ogni volta che un nuovo ingegnere si unisce al team ed esplora i nostri sistemi, incontra questi misteriosi processi: "Cosa fa questo lavoratore?" consuma tempo di onboarding e crea incertezza. Siamo stati tutti lì, a fissare un pezzo di codice, con paura di toccarlo perché forse sta facendo qualcosa di importante. Anche l'infrastruttura "dimenticata" a volte richiede attenzione. Aggiornamenti di sicurezza, aumenti delle dipendenze, correzioni di compatibilità quando qualcos'altro cambia. Ciò ha portato il nostro team a dedicare cicli di manutenzione a percorsi di codice che non servivano a nulla. E nel tempo, la conoscenza istituzionale svanisce. Era una soluzione temporanea che è diventata permanente? e il contesto rimasto con loro. Come può accadere? È facile puntare il dito, ma la verità è che ciò accade naturalmente in qualsiasi sistema di lunga durata. Una funzionalità viene deprecata, ma il lavoro in background che la supporta continua a funzionare. Qualcuno avvia un lavoratore "temporaneamente" per gestire una migrazione e non viene mai interrotto che ha controllato l'intero database per i compleanni corrispondenti alla data corrente e ha inviato ai clienti un'e-mail personalizzata. Durante un refactoring nel 2020, abbiamo cambiato il nostro strumento di posta elettronica transazionale ma ci siamo dimenticati di rimuovere questo lavoratore: ha continuato a funzionare per altri cinque anni. Nessuno di questi è un fallimento individuale: è un fallimento del processo. Senza una pulizia intenzionale incorporata nel modo in cui lavoriamo, l'entropia vince. Come molte aziende, Buffer ha abbracciato il movimento dei microservizi (un approccio popolare in cui le aziende dividono il proprio codice. in molti piccoli servizi indipendenti) anni fa. Abbiamo diviso il nostro monolite in servizi separati, ciascuno con il proprio repository, pipeline di distribuzione e infrastruttura. All'epoca, aveva senso: ogni servizio poteva essere distribuito da solo, con confini chiari tra i team. Ma nel corso degli anni, abbiamo scoperto che il sovraccarico della gestione di dozzine di repository superava i vantaggi per un team delle nostre dimensioni. Quindi ci siamo consolidati in un unico repository multiservizio. I servizi esistono ancora come confini logici, ma convivono in un unico posto ciò che ha reso possibile la scoperta. Nel mondo dei microservizi, ogni repository è un'isola a sé stante. Un lavoratore dimenticato in un repository potrebbe non essere mai notato dagli ingegneri che lavorano in un altro. Non esiste un unico posto in cui cercare i nomi delle code, né una visione unificata di cosa è in esecuzione e dove. Con tutto in un repository, potremmo finalmente vedere il quadro completo dei suoi consumatori e produttori trovare l'infrastruttura zombie, ma ce l'ha fattascoperta quasi inevitabile. Cosa abbiamo effettivamente fatto Una volta identificati i processi orfani, abbiamo dovuto decidere cosa farne. Ecco come ci siamo avvicinati. Innanzitutto, abbiamo fatto risalire ciascuno alla sua origine. Abbiamo analizzato la storia di Git e la vecchia documentazione per capire perché ogni lavoratore è stato creato in primo luogo. Nella maggior parte dei casi, lo scopo originale era chiaro: una migrazione dei dati una tantum, una funzionalità che è stata disattivata, una soluzione temporanea che è sopravvissuta alla sua utilità. Quindi abbiamo confermato che erano veramente inutilizzati. Prima di rimuovere qualsiasi cosa, abbiamo aggiunto il logging per verificare che questi processi non stessero tranquillamente facendo qualcosa di importante che ci eravamo persi. Abbiamo monitorato per alcuni giorni per assicurarci che non venissero chiamati affatto e li abbiamo rimossi in modo incrementale. Non abbiamo eliminato tutto in una volta. Abbiamo rimosso i processi uno per uno, osservando eventuali effetti collaterali imprevisti. (Fortunatamente non ce n'erano.) Infine, abbiamo documentato ciò che abbiamo imparato. Abbiamo aggiunto note ai nostri documenti interni sulle operazioni eseguite originariamente da ciascun processo e sul motivo per cui è stato rimosso, in modo che i futuri ingegneri non si chiedessero se è andato perduto qualcosa di importante. Cosa è cambiato dopo la pulizia Siamo ancora all'inizio della misurazione dell'impatto completo, ma ecco cosa abbiamo visto finora. Il nostro inventario delle infrastrutture ora è accurato. Quando qualcuno chiede: "Quali lavoratori gestiamo?" possiamo effettivamente rispondere a questa domanda con sicurezza. Anche le conversazioni di onboarding sono diventate più semplici. I nuovi ingegneri non si imbattono in processi misteriosi chiedendosi se mancano il contesto. La base di codice riflette ciò che facciamo effettivamente, non ciò che abbiamo fatto cinque anni fa. Tratta i refactor come archeologia e prevenzione Il mio più grande insegnamento da questo progetto: ogni refactor significativo è un'opportunità per l'archeologia. Quando sei immerso in un sistema, capendo davvero come i pezzi si collegano, sei nella posizione perfetta per mettere in discussione ciò che è ancora necessario. Quella coda di qualche vecchio progetto? Il lavoratore creato da qualcuno per una migrazione dei dati una tantum? L'attività pianificata che fa riferimento a una funzionalità di cui non hai mai sentito parlare? Potrebbero essere ancora in esecuzione. Ecco cosa stiamo costruendo nel nostro processo per il futuro: Durante qualsiasi refactoring, chiediti: cos'altro tocca questo sistema che non abbiamo esaminato da un po'? Quando deprechi una funzionalità, tracciala fino ai suoi processi in background, non solo al codice rivolto all'utente. Quando qualcuno lascia il team, documenta ciò di cui era responsabile, in particolare le cose che vengono eseguite in background. Abbiamo ancora parti più vecchie della nostra base di codice che non sono state ancora trasferite nel singolo repository. Mentre continuiamo a consolidarci, siamo fiduciosi che troveremo altre di queste reliquie nascoste. Ma ora siamo pronti a catturarli e a impedire che se ne formino di nuovi. Quando tutto il codice risiede in un unico posto, l'infrastruttura orfana non ha nessun posto dove nascondersi.
Cosa abbiamo imparato dopo aver trovato 7 lavori dimenticati in corso da 5 anni
By Social Media
·
·
6 min read
·
174 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
