We zijn onlangs een klein project gestart om op te ruimen hoe delen van onze systemen achter de schermen bij Buffer communiceren. Een korte context: we gebruiken iets dat SQS heet (Amazon Simple Queue Service). Deze wachtrijen fungeren als wachtkamers voor taken. Een deel van ons systeem geeft een bericht af, en een ander deel haalt het later op. Zie het als een briefje achterlaten voor een collega: "Hé, als je de kans krijgt, verwerk deze gegevens." Het systeem dat het briefje verzendt, hoeft niet te wachten op een reactie. Ons project was om routineonderhoud uit te voeren: de tools updaten die we gebruiken om wachtrijen lokaal te testen en hun configuratie op te schonen. Maar terwijl we in kaart brachten welke wachtrijen we daadwerkelijk gebruiken, ontdekten we iets dat we niet hadden verwacht: zeven verschillende achtergrondprocessen (of cron-jobs, dit zijn geplande taken die automatisch worden uitgevoerd) en werknemers die al vijf jaar stil draaiden. Ze deden allemaal absoluut niets nuttigs. Dit is waarom dat ertoe doet, hoe we ze hebben gevonden en wat we eraan hebben gedaan. Waarom dit belangrijker is dan je zou denken Ja, het runnen van onnodige infrastructuur. kost geld. Ik heb een snelle berekening gemaakt en voor een van die werknemers zouden we over een periode van vijf jaar ~$360-600 hebben betaald. Dit is een bescheiden bedrag in het grote geheel van onze financiën, maar absoluut pure verspilling voor een proces dat niets oplevert. Na deze opruiming te hebben doorlopen, zou ik echter zeggen dat de financiële kosten eigenlijk het kleinste deel van het probleem zijn. Elke keer dat een nieuwe ingenieur zich bij het team voegt en onze systemen verkent, komen ze deze mysterieuze processen tegen We hebben er allemaal wel eens last van gehad: naar een stukje code staren, bang om het aan te raken omdat het misschien iets belangrijks doet. Zelfs een ‘vergeten’ infrastructuur heeft af en toe aandacht nodig. Beveiligingsupdates, problemen met de afhankelijkheid, problemen met de compatibiliteit als er iets anders verandert Hoe gebeurt dit eigenlijk? Het is gemakkelijk om met de vinger te wijzen, maar de waarheid is dat dit van nature gebeurt in elk systeem met een lange levensduur. Een functie wordt verouderd, maar de achtergrondtaak die deze ondersteunt, blijft actief. Iemand laat een medewerker 'tijdelijk' draaien om een migratie af te handelen, en deze wordt nooit afgebroken Een hele database voor verjaardagen die overeenkwam met de huidige datum en we stuurden klanten een gepersonaliseerde e-mail. Tijdens een refactoring in 2020 schakelden we over op onze transactionele e-mailtool, maar we vergaten deze medewerker te verwijderen. Deze bleef nog vijf jaar actief. Geen van deze problemen zijn mislukkingen van individuen; het zijn procesfouten. Zonder opzettelijke opschoning die is ingebouwd in de manier waarop we werken, wint entropie. Hoe onze architectuur ons heeft geholpen deze te vinden Zoals veel bedrijven omarmde Buffer de microservices-beweging (een populaire aanpak waarbij bedrijven hun code opsplitsen in vele kleine, We hebben onze monoliet jaren geleden opgesplitst in afzonderlijke services, elk met een eigen repository, implementatiepijplijn en infrastructuur. Destijds was het logisch: elke service kon op zichzelf worden ingezet, met duidelijke grenzen tussen de teams. Maar door de jaren heen kwamen we erachter dat de overhead van het beheren van tientallen repository's groter was dan de voordelen voor een team van onze omvang. Daarom zijn we samengevoegd tot één repository met meerdere services. De services bestaan nog steeds als logische grenzen, maar ze leven samen op één plek wat ontdekking mogelijk maakte. In de wereld van microservices is elke repository zijn eigen eiland. Een vergeten medewerker in de ene repository wordt misschien nooit opgemerkt door ingenieurs die in een andere repository werken. Er is geen enkele plek waar naar wachtrijnamen kan worden gezocht, geen uniform overzicht van wat waar wordt uitgevoerd. Met alles in één repository konden we eindelijk het volledige beeld zien. We konden elke wachtrij traceren naar de consumenten en producenten ervan. We konden wachtrijen met producenten vinden, maar geen consumenten ontworpen om ons te helpen de zombie-infrastructuur te vinden – maar dat is geluktontdekking bijna onvermijdelijk. Wat we feitelijk deden Toen we de verweesde processen eenmaal hadden geïdentificeerd, moesten we beslissen wat we ermee gingen doen. Dit is hoe we het hebben aangepakt. Eerst hebben we ze allemaal teruggevonden naar hun oorsprong. We hebben de git-geschiedenis en oude documentatie doorzocht om te begrijpen waarom elke worker überhaupt is gemaakt. In de meeste gevallen was het oorspronkelijke doel duidelijk: een eenmalige gegevensmigratie, een functie die verdwenen was, een tijdelijke oplossing die zijn bruikbaarheid overleefde. Vervolgens bevestigden we dat ze werkelijk ongebruikt waren. Voordat we iets verwijderden, hebben we logboekregistratie toegevoegd om te verifiëren dat deze processen niet stilletjes iets belangrijks deden dat we hadden gemist. We hebben een paar dagen gecontroleerd om er zeker van te zijn dat ze helemaal niet werden gebeld, en we hebben ze stapsgewijs verwijderd. We hebben niet alles in één keer verwijderd. We hebben processen één voor één verwijderd, waarbij we op onverwachte bijwerkingen letten. (Gelukkig waren die er niet.) Ten slotte documenteerden we wat we leerden. We hebben aan onze interne documenten aantekeningen toegevoegd over wat elk proces oorspronkelijk had gedaan en waarom het werd verwijderd, zodat toekomstige technici zich niet zouden afvragen of er iets belangrijks was verdwenen. Wat is er veranderd na het opruimen We zijn nog maar vroeg bezig met het meten van de volledige impact, maar dit is wat we tot nu toe hebben gezien. Onze infrastructuurinventarisatie is nu nauwkeurig. Als iemand vraagt: "Welke werknemers hebben we?" we kunnen die vraag met vertrouwen beantwoorden. Onboarding-gesprekken zijn ook eenvoudiger geworden. Nieuwe ingenieurs komen geen mysterieuze processen tegen en vragen zich af of ze context missen. De codebasis weerspiegelt wat we feitelijk doen, niet wat we vijf jaar geleden deden. Beschouw refactoren als archeologie en preventie Mijn grootste les uit dit project: elke belangrijke refactor is een kans voor de archeologie. Als je diep in een systeem zit en echt begrijpt hoe de stukken met elkaar verbonden zijn, verkeer je in de perfecte positie om je af te vragen wat er nog nodig is. Die wachtrij van een oud project? De werknemer die iemand heeft gemaakt voor een eenmalige gegevensmigratie? De geplande taak die verwijst naar een functie waar je nog nooit van hebt gehoord? Mogelijk zijn ze nog steeds actief. Dit is wat we in de toekomst aan het inbouwen zijn: Vraag tijdens elke refactor: wat raakt dit systeem nog meer waar we al een tijdje niet meer naar hebben gekeken? Als je een functie beëindigt, traceer deze dan helemaal tot aan de achtergrondprocessen, niet alleen tot de gebruikersgerichte code. Wanneer iemand het team verlaat, documenteer dan waar hij of zij de leiding over had, vooral de dingen die op de achtergrond draaien. We hebben nog steeds oudere delen van onze codebase die niet naar de enkele repository zijn gemigreerd. nog niet. Terwijl we doorgaan met consolideren, zijn we ervan overtuigd dat we meer van deze verborgen relikwieën zullen vinden. Maar nu zijn we klaar om ze te vangen en te voorkomen dat er nieuwe ontstaan. Als al je code op één plek staat, kan de verweesde infrastructuur zich nergens verbergen.
Wat we hebben geleerd nadat we zeven vergeten banen hadden gevonden die vijf jaar lang actief waren
By Social Media
·
·
6 min read
·
651 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
