Am început recent un mic proiect pentru a curăța modul în care părți ale sistemelor noastre comunică în culise la Buffer. Un context rapid: folosim ceva numit SQS (Amazon Simple Queue Service. Aceste cozi acționează ca niște săli de așteptare pentru sarcini. O parte a sistemului nostru trimite un mesaj, iar alta îl preia mai târziu. Gândiți-vă la asta ca și cum ați lăsa o notă pentru un coleg de lucru: „Hei, coleg de lucru: atunci când trimiteți un sistem.” Nota nu trebuie să aștepte un răspuns. Proiectul nostru a fost să efectuăm întreținere de rutină: să actualizăm instrumentele pe care le folosim pentru a testa cozile la nivel local și pentru a le curăța configurația. Dar, în timp ce mapam ce cozi pe care le folosim de fapt, am găsit ceva la care nu ne așteptam: șapte procese de fundal diferite (sau joburi cron, care sunt sarcini programate care rulează automat) și lucrătorii care nu rulau absolut nimic de cinci ani util. Iată de ce contează, cum i-am găsit și ce am făcut în privința asta. De ce contează asta mai mult decât ați crede Da, gestionarea infrastructurii inutile costă bani. Am făcut un calcul rapid și pentru unul dintre acești lucrători, am fi plătit ~ 360-600 USD în 5 ani. Aceasta este o sumă modestă în marele proces al finanțelor noastre. de curățare, aș argumenta că costul financiar este de fapt cea mai mică parte a problemei. De fiecare dată când un nou inginer se alătură echipei și explorează sistemele noastre, se confruntă cu aceste procese misterioase „Ce face acest lucrător devine o întrebare care consumă timpul de îmbarcare și creează incertitudine – ne-am uitat cu toții la un cod. Ocazional, o infrastructură „uitată” necesită atenție, Actualizări de securitate, probleme de dependență, remedieri de compatibilitate atunci când se schimbă altceva. Adevărul este că acest lucru se întâmplă în mod natural în orice sistem cu durată lungă de viață. O funcție devine depreciată, dar munca de fundal care a susținut-o continuă să ruleze „temporar” pentru a gestiona o migrare și nu este niciodată desființată Întreaga bază de date pentru zilele de naștere care corespunde datei curente și le-a trimis clienților un e-mail personalizat. În timpul unei refactorări în 2020, am schimbat instrumentul nostru de e-mail tranzacțional, dar am uitat să eliminăm acest lucrător - a continuat să funcționeze încă cinci ani. Nici unul dintre acestea nu sunt eșecuri ale unor persoane - sunt eșecuri de proces încorporate în modul în care lucrăm, întropia a ajutat multe companii să le câștige. Mișcarea microserviciilor (o abordare populară în care companiile își împărțeau codul în multe servicii mici, independente) cu ani în urmă. Ne-am împărțit monolitul în servicii separate, fiecare cu propriul depozit, pipeline de implementare și infrastructură. La momentul respectiv, avea sens: fiecare serviciu putea fi implementat singur, cu limite clare între echipe într-un depozit unic cu mai multe servicii. Serviciile există încă ca limite logice, dar trăiesc împreună într-un singur loc. Acesta s-a dovedit a fi ceea ce a făcut posibilă descoperirea. În lumea microserviciilor, fiecare depozit este propria sa insulă. am putut vedea în sfârșit imaginea completă. Am putut urmări fiecare coadă până la consumatorii și producătorii săi. Am putut identifica cozile cu producători, dar nu am putut găsi lucrători care nu mai existau. Consolidarea nu a fost concepută pentru a ne ajuta să găsim infrastructura zombie.descoperirea aproape inevitabilă.Ce am făcut de fapt Odată ce am identificat procesele orfane, a trebuit să decidem ce să facem cu ele. Iată cum l-am abordat. În primul rând, am urmărit fiecare dintre ele până la originea sa. Am săpat prin istoria git și documentația veche pentru a înțelege de ce fiecare lucrător a fost creat în primul rând. În cele mai multe cazuri, scopul inițial a fost clar: o migrare unică a datelor, o caracteristică care s-a apus, o soluție temporară care și-a depășit utilitatea. Apoi am confirmat că au fost cu adevărat neutilizate. Înainte de a elimina orice, am adăugat înregistrarea în jurnal pentru a verifica că aceste procese nu făceau în liniște ceva important pe care l-am ratat. Am monitorizat câteva zile pentru a ne asigura că nu au fost apelați deloc și le-am eliminat treptat. Nu am șters totul deodată. Am eliminat procesele unul câte unul, urmărind orice efecte secundare neașteptate. (Din fericire, nu au existat.) În cele din urmă, am documentat ceea ce am învățat. Am adăugat note în documentele noastre interne despre ceea ce a făcut inițial fiecare proces și de ce a fost eliminat, astfel încât viitorii ingineri să nu se întrebe dacă ceva important a dispărut. Ce s-a schimbat după curățare Suntem încă devreme în măsurarea impactului total, dar iată ce am văzut până acum. Inventarul nostru de infrastructură este acum exact. Când cineva întreabă: „Ce muncitori conducem?” De fapt, putem răspunde la această întrebare cu încredere. Conversațiile de integrare au devenit, de asemenea, mai simple. Noii ingineri nu dau peste procese misterioase și nu se întreabă dacă le lipsește contextul. Baza de cod reflectă ceea ce facem de fapt, nu ceea ce făceam acum cinci ani. Tratați refactorii ca arheologie și prevenție. Cea mai mare concluzie a mea din acest proiect: fiecare refactor semnificativ este o oportunitate pentru arheologie. Când sunteți adânc într-un sistem, înțelegând cu adevărat modul în care piesele se conectează, sunteți în poziția perfectă pentru a pune la îndoială ce mai este nevoie. Acea coadă de la vreun proiect vechi? Lucrătorul creat de cineva pentru o migrare unică a datelor? Sarcina programată care face referire la o caracteristică despre care nu ați auzit niciodată? S-ar putea să fie încă în funcțiune. Iată ce construim în procesul nostru de acum înainte: în timpul oricărei refactorări, întrebați: ce altceva afectează acest sistem pe care nu l-am privit de ceva vreme? Când renunțăm la o caracteristică, urmăriți-o până la procesele ei de fundal, nu doar codul cu care se confruntă utilizatorul. Când cineva părăsește echipa, documentați ceea ce era în fundal pe care încă le conducem, mai ales părțile pe care le conducem. bază de cod care nu a fost încă migrată la un singur depozit. Pe măsură ce continuăm consolidarea, suntem încrezători că vom găsi mai multe dintre aceste relicve ascunse. Dar acum suntem pregătiți să le prindem și să împiedicăm formarea altora noi. Când tot codul dvs. locuiește într-un singur loc, infrastructura orfană nu are unde să se ascundă.
Ce am învățat după ce am găsit 7 locuri de muncă uitate, care au funcționat timp de 5 ani
By Social Media
·
·
6 min read
·
724 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
