Pred kratkim smo začeli z majhnim projektom, da bi razčistili, kako deli naših sistemov komunicirajo v zakulisju pri Bufferju. Nekaj hitrega konteksta: uporabljamo nekaj, kar se imenuje SQS (Amazon Simple Queue Service. Te čakalne vrste delujejo kot čakalnice za opravila. En del našega sistema odloži sporočilo, drugi pa ga prevzame pozneje. Pomislite na to, kot da bi pustili sporočilo sodelavcu: "Hej, ko boš imel priložnost, obdelaj te podatke." Sistem, ki pošlje note ni treba čakati na odgovor. Naš projekt je bil izvajanje rutinskega vzdrževanja: posodobitev orodij, ki jih uporabljamo za lokalno testiranje čakalnih vrst, in čiščenje njihove konfiguracije. Toda medtem ko smo načrtovali, katere čakalne vrste dejansko uporabljamo, smo našli nekaj, česar nismo pričakovali: sedem različnih procesov v ozadju (ali opravil cron, ki so načrtovana opravila, ki se izvajajo samodejno) in delavcev, ki so tiho delovali do pet let. Vsi niso delali popolnoma nič Tukaj je, zakaj je to pomembno, kako smo jih našli in kaj smo storili glede tega. Zakaj je to pomembnejše, kot bi si mislili. Da, vodenje nepotrebne infrastrukture stane denar in za enega od teh delavcev bi plačali približno 360–600 USD v 5 letih. trdijo, da so finančni stroški pravzaprav najmanjši del težave. Vsakič, ko se novi inženir pridruži našim sistemom, naleti na te skrivnostne procese. "Kaj dela ta delavec?" postane vprašanje, ki požre čas za pripravo na program. Vsi smo bili tam - strmeli smo v delček kode in se ga bali dotakniti. Tudi "pozabljena" infrastruktura občasno potrebuje pozornost posodobitve, popravki odvisnosti, ko se kaj drugega spremeni. To je pripeljalo do tega, da je naša ekipa porabila cikle vzdrževanja na poteh kode, ki niso služile namenu. In sčasoma je bilo to kritično? Ali je bil to začasen popravek, ki je zapustil podjetje pred leti. Kako se to sploh zgodi? Resnica je, da se to zgodi naravno Dolgoživ sistem. Funkcija je zastarela, vendar opravilo v ozadju, ki ga je podpiralo, še naprej deluje. Nekdo "začasno" zažene delavca, ki opravi selitev, in načrtovano opravilo po arhitekturni spremembi ne postane odveč, vendar nihče ne pomisli, da bi to preveril. V Bufferju smo pošiljali e-poštna sporočila za praznovanje. Da bi to naredili, smo zagnali načrtovano opravilo, ki je preverilo celotno bazo podatkov rojstni dnevi, ki se ujemajo s trenutnim datumom, in strankam poslali prilagojeno e-pošto. Med refaktorjem leta 2020 smo zamenjali naše orodje za transakcijsko e-pošto, vendar smo pozabili odstraniti tega delavca – delovalo je še pet let. Nič od tega ni napaka posameznikov – brez namernega čiščenja, ki je vgrajeno v naše delo, zmaga entropija. gibanje mikrostoritev (priljubljen pristop, pri katerem podjetja razdelijo svojo kodo na številne majhne, neodvisne storitve) pred leti. Naš monolit smo razdelili na ločene storitve, od katerih ima vsaka svoje repozitorij, cevovod za uvajanje in infrastrukturo. Takrat je bilo smiselno: vsako storitev je bilo mogoče uvesti samostojno, z jasnimi mejami med ekipami. Toda z leti smo ugotovili, da so režijski stroški upravljanja na desetine repozitorijev odtehtali koristi za. Skupina naše velikosti. Storitve še vedno obstajajo kot logične meje. Izkazalo se je, da je to tisto, kar je omogočilo odkritje. Pozabljenega delavca v enem skladišču morda nikoli ne bodo opazili inženirji, ki delajo v drugem. Ni enotnega mesta za iskanje imen čakalne vrste Z vsem v enem repozitoriju smo lahko končno videli vsako čakalno vrsto do njenih potrošnikov in proizvajalcev. Lahko smo opazili čakalne vrste pri proizvajalcih. Lahko smo našli delavce, ki se sklicujejo na čakalne vrste, ki ne obstajajo več.odkritje skoraj neizogibno. Kaj smo pravzaprav storili. Ko smo identificirali osirotel proces, smo se morali odločiti, kaj bomo z njimi. Evo, kako smo se tega lotili. Najprej smo vsakemu izsledili njegov izvor. Prebrskali smo zgodovino gita in staro dokumentacijo, da bi razumeli, zakaj je bil vsak delavec sploh ustvarjen. V večini primerov je bil prvotni namen jasen: enkratna selitev podatkov, funkcija, ki je prenehala delovati, začasna rešitev, ki je preživela svojo uporabnost. Nato smo potrdili, da so bile resnično neuporabljene. Preden smo kar koli odstranili, smo dodali beleženje, da preverimo, ali ti procesi tiho počnejo nekaj pomembnega, kar smo zamudili. Nekaj dni smo spremljali, da bi se prepričali, da sploh niso bili poklicani, in smo jih postopoma odstranili. Nismo izbrisali vsega naenkrat. Procese smo odstranili enega za drugim in opazovali morebitne nepričakovane stranske učinke. (Na srečo jih ni bilo.) Končno smo dokumentirali, kar smo se naučili. Našim notranjim dokumentom smo dodali opombe o tem, kaj je posamezen proces prvotno naredil in zakaj je bil odstranjen, da se bodoči inženirji ne bi spraševali, če je kaj pomembnega izginilo. Kaj se je spremenilo po čiščenju. Še vedno smo na začetku merjenja celotnega učinka, toda to je tisto, kar smo videli do zdaj. Naš inventar infrastrukture je zdaj točen. Ko nekdo vpraša: "Katere delavce vodimo?" na to vprašanje lahko dejansko odgovorimo z zaupanjem. Tudi pogovori o uvajanju so postali enostavnejši. Novi inženirji ne naletijo na skrivnostne procese in se ne sprašujejo, ali jim manjka kontekst. Baza kode odraža to, kar dejansko počnemo, in ne tistega, kar smo počeli pred petimi leti. Refaktorje obravnavajte kot arheologijo in preventivo. Moj največji zaključek tega projekta: vsak pomemben refaktor je priložnost za arheologijo. Ko ste globoko v sistemu in resnično razumete, kako se deli povezujejo, ste v popolnem položaju, da se sprašujete, kaj je še potrebno. Tista čakalna vrsta iz nekega starega projekta? Delavec, ki ga je nekdo ustvaril za enkratno selitev podatkov? Načrtovano opravilo, ki se sklicuje na funkcijo, za katero še niste slišali? Morda se še vedno izvajajo. Tukaj je tisto, kar vgrajujemo v naš proces naprej: med kakršnim koli refaktorjem se vprašajte: kaj se še dotika tega sistema, česar že nekaj časa nismo pogledali? Ko funkcijo opuščamo, ji sledite vse do procesov v ozadju, ne le do kode, ki je namenjena uporabniku. Ko nekdo zapusti ekipo, dokumentirajte, za kaj je bil zadolžen, zlasti stvari, ki se izvajajo v ozadju. Še vedno imamo starejše dele našega kodno zbirko, ki še ni bila preseljena v eno samo skladišče. Ko nadaljujemo s konsolidacijo, smo prepričani, da bomo našli več teh skritih relikvij. Toda zdaj smo pripravljeni, da jih ujamemo in preprečimo nastanek novih. Ko je vsa vaša koda na enem mestu, se osirotela infrastruktura nima kam skriti.
Kaj smo se naučili, ko smo našli 7 pozabljenih služb, ki so trajale 5 let
By Social Media
·
·
6 min read
·
535 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
