Наскоро започнахме малък проект, за да изчистим как части от нашите системи комуникират зад кулисите в Buffer. Малко бърз контекст: използваме нещо, наречено SQS (Amazon Simple Queue Service. Тези опашки действат като чакални за задачи. Една част от нашата система оставя съобщение, а друга го взима по-късно. Мислете за това като за оставяне на бележка на колега: „Хей, когато имаш възможност, обработи тези данни.“ Системата, която изпраща note не трябва да чака отговор.Нашият проект беше да извършим рутинна поддръжка: да актуализираме инструментите, които използваме за локално тестване на опашки и да изчистим тяхната конфигурация.Но докато картографирахме какви опашки всъщност използваме, открихме нещо, което не очаквахме: седем различни фонови процеса (или cron задания, които са планирани задачи, които се изпълняват автоматично) и работници, които са работили безшумно до пет години. Всички те не правят абсолютно нищо Ето защо това има значение, как ги намерихме и какво направихме по въпроса. Защо това е по-важно, отколкото бихте си помислили. Направих бързо изчисление и за един от тези работници щяхме да платим ~360-600 долара за 5 години. Това е скромна сума в голямата схема на нашите финанси, но определено чиста загуба за процес, който не прави нищо. твърдят, че финансовите разходи всъщност са най-малката част от проблема. Всеки път, когато нов инженер се присъедини към нашите системи, те се натъкват на тези мистериозни процеси. „Какво прави този работник?“ се превръща в въпрос, който изяжда времето за работа и създава несигурност актуализации, грешки в съвместимостта, когато нещо друго се промени. Това доведе до цикли на поддръжка на кодове, които не послужиха за цел. И с течение на времето това беше критично? Беше ли временна корекция, която напусна компанията преди години и контекстът напусна с него? Лесно е да се посочи с пръст, но това се случва естествено дълготрайна система. Една функция се отхвърля, но фоновото задание продължава да работи. Някой пуска воркер, за да се справи с миграцията, и тя никога не се премахва след архитектурна промяна. Ние изпращахме имейли за празнуване на рождени дни в буфера. За да направим това, изпълнихме планирана задача, която провери цялата база данни рождени дни, съответстващи на текущата дата, и изпратихме на клиентите персонализиран имейл. По време на рефакторинг през 2020 г. сменихме нашия инструмент за транзакции по имейл, но забравихме да премахнем този работник — той продължи да работи още пет години. Нито един от тях не е грешка на отделни хора — това е грешка на процеса. Без умишлено почистване в начина, по който работим, ентропията печели. Как нашата архитектура ни помогна да я открием. движението за микроуслуги (популярен подход, при който компаниите разделят кода си на много малки, независими услуги) преди години. Ние разделихме нашия монолит на отделни услуги, всяка със собствено хранилище, тръбопровод за внедряване и инфраструктура По това време имаше смисъл: всяка услуга можеше да бъде разгърната самостоятелно, с ясни граници между екипите. Но през годините открихме, че режийните разходи за управление на десетки хранилища надвишават ползите за. Така че ние се консолидирахме в едно хранилище с няколко услуги. Услугите все още съществуват като логични граници, но се оказа, че откритието е възможно. В света на микроуслугите всяко хранилище е свой собствен остров С всичко в едно хранилище най-накрая можехме да проследим всяка опашка до нейните потребители и производители. Можехме да открием опашки с производители, но не можехме да намерим работници, които препращат към опашки, които вече не съществуват. Консолидацията не беше предназначена да ни помогне да намерим зомби инфраструктура.Откриването е почти неизбежно. Какво всъщност направихме След като идентифицирахме осиротелите процеси, трябваше да решим какво да правим с тях. Ето как подходихме към него. Първо, проследихме всеки един до неговия произход. Разровихме историята на git и старата документация, за да разберем защо всеки работник е създаден на първо място. В повечето случаи първоначалната цел беше ясна: еднократна миграция на данни, функция, която залезе, временно решение, което надживя своята полезност. След това потвърдихме, че те наистина са неизползвани. Преди да премахнем каквото и да било, добавихме регистриране, за да проверим дали тези процеси не извършват тихо нещо важно, което сме пропуснали. Наблюдавахме в продължение на няколко дни, за да се уверим, че изобщо не са извикани, и ги премахнахме постепенно. Не изтрихме всичко наведнъж. Премахнахме процесите един по един, следейки за неочаквани странични ефекти. (За щастие нямаше такива.) Най-накрая документирахме това, което научихме. Добавихме бележки към нашите вътрешни документи за това какво е направил първоначално всеки процес и защо е бил премахнат, така че бъдещите инженери да не се чудят, ако нещо важно е изчезнало. Какво се промени след почистването. Все още сме в началото на измерването на пълното въздействие, но ето какво видяхме досега. Инвентаризацията ни на инфраструктура вече е точна. Когато някой попита: "Какви работници управляваме?" всъщност можем да отговорим на този въпрос с увереност. Разговорите за включване също станаха по-лесни. Новите инженери не се натъкват на мистериозни процеси и не се чудят дали им липсва контекст. Кодовата база отразява това, което всъщност правим, а не това, което направихме преди пет години. Отнасяйте се към рефакторите като към археология и превенция Моят най-голям извод от този проект: всеки значим рефактор е възможност за археология. Когато сте дълбоко в една система, наистина разбирайки как се свързват частите, вие сте в идеалната позиция да поставите под въпрос какво още е необходимо. Тази опашка от някакъв стар проект? Работникът, който някой е създал за еднократна миграция на данни? Насрочената задача, която препраща към функция, за която никога не сте чували? Те може все още да работят. Ето какво вграждаме в нашия процес занапред: По време на всеки рефакторинг, попитайте: какво друго докосва тази система, което не сме разглеждали от известно време? Когато отхвърляте дадена функция, проследете я чак до нейните фонови процеси, а не само до кода, обърнат към потребителя. Когато някой напусне екипа, документирайте за какво е отговарял, особено нещата, които работят във фонов режим. Все още имаме по-стари части от нашите кодова база, които все още не са мигрирани към едно хранилище. Докато продължаваме да се консолидираме, ние сме уверени, че ще намерим повече от тези скрити реликви. Но сега сме готови да ги хванем и да предотвратим образуването на нови. Когато целият ви код живее на едно място, осиротялата инфраструктура няма къде да се скрие.
Какво научихме, след като намерихме 7 забравени работни места, работещи в продължение на 5 години
By Social Media
·
·
6 min read
·
696 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
