Vi startede for nylig et lille projekt for at rydde op i, hvordan dele af vores systemer kommunikerer bag kulisserne hos Buffer. Nogle hurtige sammenhænge: vi bruger noget, der hedder SQS (Amazon Simple Queue Service. Disse køer fungerer som venteværelser til opgaver. En del af vores system afgiver en besked, og en anden samler den op senere. Tænk på det som at efterlade en seddel til en hey, en kollega, der sender data, "hvis du kan sende data:." note behøver ikke at vente på et svar. Vores projekt var at udføre rutinemæssig vedligeholdelse: opdatere de værktøjer, vi bruger til at teste køer lokalt og rydde op i deres konfiguration. Men mens vi kortlagde, hvilke køer vi faktisk bruger, fandt vi noget, vi ikke havde forventet: syv forskellige baggrundsprocesser (eller cron-job, som er planlagte opgaver, der ikke har kørt automatisk i fem år) og arbejdere, der ikke har kørt helt automatisk i fem år nyttigt. Her er hvorfor det betyder noget, hvordan vi fandt dem, og hvad vi gjorde ved det. Hvorfor dette betyder mere end du tror Ja, det koster penge at køre unødvendig infrastruktur, og for en af disse arbejdere ville vi have betalt $360-600 i løbet af 5 år. oprydning, vil jeg hævde, at de økonomiske omkostninger faktisk er den mindste del af problemet. Hver gang en ny ingeniør slutter sig til teamet og udforsker vores systemer, støder de på disse mystiske processer "Hvad gør denne medarbejder bliver et spørgsmål, der optager onboarding-tid og skaber usikkerhed. "glemt" infrastruktur har af og til brug for opmærksomhed, afhængighedsfejl, kompatibilitetsrettelser, når noget andet ændrer sig. Sandheden er, at dette sker naturligt i ethvert langvarigt system. En funktion bliver forældet, men den baggrundsopgave, der understøttede den, bliver ved med at køre en arbejder "midlertidigt" for at håndtere en migrering, og den bliver aldrig revet ned efter en arkitektonisk ændring, men ingen tænker på at sende en e-mail opgave, der tjekkede hele databasen for fødselsdage, der matchede den aktuelle dato, og sendte kunderne en personlig e-mail Under en refaktor i 2020 skiftede vi vores transaktionelle e-mail-værktøj, men glemte at fjerne denne medarbejder – den blev ved med at køre i fem år mere. Ingen af disse er fejl hos enkeltpersoner – de er fejl i processen. omfavnede mikroservicebevægelsen (en populær tilgang, hvor virksomheder opdelte deres kode i mange små, uafhængige tjenester) for mange år siden. Vi opdelte vores monolit i separate tjenester, hver med sit eget lager, implementeringspipeline og infrastruktur. På det tidspunkt gav det mening: hver tjeneste kunne implementeres for sig selv med klare grænser mellem teams. Men i årenes løb fandt vi ud af en lang række fordele for vores team. Så vi konsoliderede til et enkelt lager med flere tjenester. Tjenesterne eksisterer stadig som logiske grænser, men de lever sammen på ét sted. Det viste sig at være det, der gjorde opdagelsen mulig. I mikroserviceverdenen er hvert lager sin egen ø. Vi kunne endelig se det fulde billede til forbrugerne og producenterne. Vi kunne finde køer med producenter, men ingen forbrugere.opdagelse næsten uundgåelig. Hvad vi faktisk gjorde Da vi havde identificeret de forældreløse processer, måtte vi beslutte, hvad vi skulle gøre med dem. Her er, hvordan vi greb det an. Først sporede vi hver enkelt til dets oprindelse. Vi gravede gennem git-historie og gammel dokumentation for at forstå, hvorfor hver enkelt arbejder blev oprettet i første omgang. I de fleste tilfælde var det oprindelige formål klart: en engangsdatamigrering, en funktion, der fik solnedgang, en midlertidig løsning, der overlevede dens brugbarhed. Så bekræftede vi, at de virkelig var ubrugte. Før vi fjernede noget, tilføjede vi logning for at bekræfte, at disse processer ikke stille og roligt gjorde noget vigtigt, vi var gået glip af. Vi overvågede i et par dage for at sikre, at de slet ikke blev ringet op, og vi fjernede dem trinvist. Vi slettede ikke alt på én gang. Vi fjernede processer én efter én og holdt øje med eventuelle uventede bivirkninger. (Heldigvis var der ingen.) Til sidst dokumenterede vi, hvad vi lærte. Vi føjede noter til vores interne dokumenter om, hvad hver proces oprindeligt havde gjort, og hvorfor den blev fjernet, så fremtidige ingeniører ville ikke spekulere på, om noget vigtigt forsvandt. Hvad ændrede sig efter oprydningen Vi er stadig tidligt i gang med at måle den fulde effekt, men her er, hvad vi har set indtil videre. Vores infrastrukturopgørelse er nu nøjagtig. Når nogen spørger: "Hvilke arbejdere kører vi?" vi kan faktisk besvare det spørgsmål med tillid. Onboarding-samtaler er også blevet nemmere. Nye ingeniører snubler ikke over mystiske processer og spekulerer på, om de mangler kontekst. Kodebasen afspejler, hvad vi rent faktisk gør, ikke hvad vi gjorde for fem år siden. Behandl refaktorer som arkæologi og forebyggelse. Mit største udbytte af dette projekt: enhver betydningsfuld refactor er en mulighed for arkæologi. Når du er dybt i et system og virkelig forstår, hvordan brikkerne hænger sammen, er du i den perfekte position til at stille spørgsmålstegn ved, hvad der stadig er brug for. Den kø fra et gammelt projekt? Arbejderen, som nogen oprettede til en engangsdatamigrering? Den planlagte opgave, der refererer til en funktion, du aldrig har hørt om? De kører muligvis stadig.Her er, hvad vi bygger ind i vores proces fremadrettet: Spørg under enhver refactor: hvad rører dette system ellers, som vi ikke har set på i et stykke tid? Når du udfaser en funktion, skal du spore den hele vejen til dens baggrundsprocesser, ikke kun den brugervendte kode. Når nogen forlader holdet, skal du dokumentere, hvad de havde ansvaret for i baggrunden, som vi stadig har i de gamle dele, der kører med vores kodebase. som ikke er blevet migreret til det enkelte lager endnu. Mens vi fortsætter med at konsolidere, er vi overbeviste om, at vi vil finde flere af disse skjulte relikvier. Men nu er vi sat op til at fange dem og forhindre nye i at dannes. Når al din kode findes ét sted, har forældreløs infrastruktur ingen steder at gemme sig.
Hvad vi lærte efter at have fundet 7 glemte job i 5 år
By Social Media
·
·
6 min read
·
526 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
