Wir haben kürzlich ein kleines Projekt gestartet, um zu bereinigen, wie Teile unserer Systeme hinter den Kulissen bei Buffer kommunizieren. Ein kurzer Kontext: Wir verwenden etwas namens SQS (Amazon Simple Queue Service). bestand darin, routinemäßige Wartungsarbeiten durchzuführen: die Tools zu aktualisieren, die wir verwenden, um Warteschlangen lokal zu testen und ihre Konfiguration zu bereinigen. Aber während wir herausgefunden haben, welche Warteschlangen wir tatsächlich verwenden, haben wir etwas gefunden, was wir nicht erwartet hatten: sieben verschiedene Hintergrundprozesse (oder Cron-Jobs, bei denen es sich um geplante Aufgaben handelt, die automatisch ausgeführt werden) und Worker, die bis zu fünf Jahre lang stillschweigend ausgeführt wurden. Hier erfahren Sie, warum das wichtig ist, wie wir sie gefunden haben und was wir dagegen unternommen haben. Warum das wichtiger ist, als Sie denken: Ja, Laufen Unnötige Infrastruktur kostet Geld. Ich habe eine schnelle Berechnung durchgeführt und für einen dieser Arbeiter hätten wir in 5 Jahren etwa 360-600 US-Dollar bezahlt, aber definitiv reine Verschwendung für einen Prozess, der nichts bewirkt. Ich würde jedoch behaupten, dass die finanziellen Kosten tatsächlich den geringsten Teil des Problems ausmachen Eine Frage, die das Onboarding verschlingt und Unsicherheit erzeugt. Wir haben alle Angst davor, einen Code anzufassen, weil er vielleicht etwas Wichtiges tut. Sogar „vergessene“ Infrastrukturen müssen beachtet werden, wenn sich etwas anderes ändert. Und mit der Zeit verblasst das institutionelle Wissen. War es eine vorübergehende Lösung, die das Unternehmen verlassen hat? Es ist einfach, mit dem Finger darauf zu zeigen, aber die Wahrheit ist, dass dies in jedem langlebigen System ganz natürlich geschieht. Eine Funktion wird nicht mehr unterstützt, aber der Hintergrundjob, der sie unterstützt hat, läuft weiter. Eine geplante Aufgabe wird nach einer Architekturänderung überflüssig, aber niemand denkt daran, dies zu überprüfen. Wir führten eine geplante Aufgabe aus, die die gesamte Datenbank auf Geburtstage überprüfte, die mit dem aktuellen Datum übereinstimmten, und schickten den Kunden eine personalisierte E-Mail. Während einer Umgestaltung im Jahr 2020 haben wir unser Transaktions-E-Mail-Tool umgestellt, aber vergessen, diesen Worker zu entfernen – er lief noch fünf Jahre lang weiter. Keines davon ist ein Versagen von Einzelpersonen – es sind Prozessversagen. Ohne absichtliche Bereinigung, die in unsere Arbeitsweise integriert ist, gewinnt die Entropie. Wie unsere Architektur uns dabei geholfen hat, sie zu finden (ein beliebter Ansatz, bei dem Unternehmen ihren Code in viele kleine, unabhängige Dienste aufteilen) vor Jahren. Wir haben unseren Monolithen in separate Dienste aufgeteilt, jeder mit seinem eigenen Repository, seiner eigenen Bereitstellungspipeline und seiner Infrastruktur. Damals machte es Sinn: Jeder Dienst konnte für sich allein mit klaren Grenzen zwischen den Teams bereitgestellt werden. Im Laufe der Jahre stellten wir jedoch fest, dass der Aufwand für die Verwaltung Dutzender Repositorys die Vorteile für ein Team unserer Größe überwog. Deshalb haben wir die Dienste in einem einzigen Repository mit mehreren Diensten zusammengefasst Es stellte sich heraus, dass dies die Entdeckung ermöglichte. In der Welt der Microservices ist jedes Repository eine eigene Insel. Es gibt keinen einzigen Ort, an dem nach Warteschlangennamen gesucht werden kann, und es gibt keine einheitliche Ansicht darüber, was wo ausgeführt wird. Wir konnten jede Warteschlange auf ihre Produzenten und Produzenten zurückführen, aber auf diese existierte nicht mehr. Die Konsolidierung war nicht dazu gedacht, uns dabei zu helfen, Zombie-Infrastruktur zu finden – aber sie hat es geschafftEntdeckung fast unvermeidlich. Was wir tatsächlich getan haben Nachdem wir die verwaisten Prozesse identifiziert hatten, mussten wir entscheiden, was wir mit ihnen machen wollten. So haben wir es angegangen: Zuerst haben wir jedes einzelne zu seinem Ursprung zurückverfolgt. Wir haben den Git-Verlauf und die alte Dokumentation durchforstet, um zu verstehen, warum jeder Worker überhaupt erstellt wurde. In den meisten Fällen war der ursprüngliche Zweck klar: eine einmalige Datenmigration, eine Funktion, die eingestellt wurde, eine vorübergehende Problemumgehung, die ihren Nutzen überlebte. Dann bestätigten wir, dass sie tatsächlich ungenutzt waren. Bevor wir etwas entfernten, haben wir eine Protokollierung hinzugefügt, um sicherzustellen, dass diese Prozesse nicht stillschweigend etwas Wichtiges tun, das wir übersehen haben. Wir haben einige Tage lang überwacht, um sicherzustellen, dass sie überhaupt nicht angerufen wurden, und haben sie dann schrittweise entfernt. Wir haben nicht alles auf einmal gelöscht. Wir haben die Prozesse einzeln entfernt und auf unerwartete Nebenwirkungen geachtet. (Zum Glück gab es keine.) Abschließend haben wir dokumentiert, was wir gelernt haben. Wir haben unseren internen Dokumenten Notizen darüber hinzugefügt, was jeder Prozess ursprünglich getan hat und warum er entfernt wurde, damit zukünftige Ingenieure sich nicht wundern, wenn etwas Wichtiges verloren geht. Was sich nach der Bereinigung geändert hat: Wir sind noch am Anfang der Messung der vollständigen Auswirkungen, aber hier ist, was wir bisher gesehen haben. Unsere Infrastrukturinventur ist jetzt korrekt. Wenn jemand fragt: „Welche Arbeiter beschäftigen wir?“ Wir können diese Frage tatsächlich mit Zuversicht beantworten. Auch die Onboarding-Gespräche sind einfacher geworden. Neue Ingenieure stolpern nicht über mysteriöse Prozesse und fragen sich, ob ihnen der Kontext fehlt. Die Codebasis spiegelt wider, was wir tatsächlich tun, und nicht das, was wir vor fünf Jahren getan haben. Behandeln Sie Refaktoren als Archäologie und Prävention. Meine größte Erkenntnis aus diesem Projekt: Jeder bedeutende Refaktor ist eine Chance für die Archäologie. Wenn Sie tief in einem System stecken und wirklich verstehen, wie die Teile zusammenhängen, sind Sie in der perfekten Position, zu hinterfragen, was noch benötigt wird. Diese Warteschlange aus einem alten Projekt? Der Worker, den jemand für eine einmalige Datenmigration erstellt hat? Die geplante Aufgabe, die auf eine Funktion verweist, von der Sie noch nie gehört haben? Möglicherweise laufen sie noch. Folgendes bauen wir künftig in unseren Prozess ein: Fragen Sie bei jedem Refactoring: Was berührt dieses System sonst noch, was wir eine Weile nicht betrachtet haben? das einzige Repository noch. Während wir uns weiter konsolidieren, sind wir zuversichtlich, dass wir weitere dieser verborgenen Relikte finden werden. Aber jetzt sind wir darauf vorbereitet, sie einzufangen und zu verhindern, dass sich neue bilden. Wenn sich Ihr gesamter Code an einem Ort befindet, kann sich die verwaiste Infrastruktur nirgendwo verstecken.
Was wir gelernt haben, nachdem wir 7 vergessene Jobs gefunden haben, die 5 Jahre lang laufen
By Social Media
·
·
6 min read
·
534 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
