Niedawno rozpoczęliśmy mały projekt, aby uporządkować sposób, w jaki części naszych systemów komunikują się za kulisami w Buffer. Krótki kontekst: używamy czegoś, co nazywa się SQS (Amazon Simple Queue Service. Te kolejki działają jak poczekalnie na zadania. Jedna część naszego systemu wysyła wiadomość, a inna odbiera ją później. Pomyśl o tym, jak o pozostawieniu notatki współpracownikowi: „Hej, kiedy będziesz miał okazję, przetwórz te dane”. System, który wysyła notatkę, nie musi czekać na odpowiedź. Nasz polegało na rutynowej konserwacji: zaktualizowaniu narzędzi, których używamy do lokalnego testowania kolejek i oczyszczeniu ich konfiguracji. Jednak podczas planowania, jakich kolejek faktycznie używamy, znaleźliśmy coś, czego się nie spodziewaliśmy: siedem różnych procesów w tle (lub zadań cron, które są zaplanowanymi zadaniami uruchamianymi automatycznie) i procesy robocze, które działały w milczeniu przez okres do pięciu lat, a wszystkie z nich nie robiły absolutnie nic pożytecznego. Oto dlaczego to ma znaczenie, jak je znaleźliśmy i co z tym zrobiliśmy. Dlaczego to ma większe znaczenie niż myślisz. Tak, działanie. niepotrzebna infrastruktura kosztuje. Zrobiłem szybkie obliczenia i za jednego z tych pracowników zapłacilibyśmy ~360–600 dolarów w ciągu 5 lat. Jest to skromna kwota w ogólnym planie naszych finansów, ale zdecydowanie marnotrawstwo w przypadku procesu, który nic nie daje. Jednak po przejściu tego czyszczenia twierdzę, że koszty finansowe stanowią w rzeczywistości najmniejszą część problemu. Za każdym razem, gdy nowy inżynier dołącza do zespołu i bada nasze systemy, napotyka te tajemnicze procesy pytanie, które pochłania czas wdrażania i powoduje niepewność. Wszyscy tam byliśmy – wpatrując się w fragment kodu, bojąc się go dotknąć, ponieważ może robi coś ważnego. Nawet „zapomniana” infrastruktura czasami wymaga uwagi. Aktualizacje zabezpieczeń, wzrosty zależności, poprawki dotyczące zgodności, gdy zmienia się coś innego. Doprowadziło to do tego, że nasz zespół spędzał cykle konserwacyjne na ścieżkach kodu, które nie służyły żadnemu celowi. Z biegiem czasu wiedza instytucjonalna zanikała. Czy była to tymczasowa poprawka, która stała się trwała? lata temu i pozostawiony po nich kontekst. Jak to się w ogóle dzieje? Łatwo wskazać palcem, ale prawda jest taka, że dzieje się to naturalnie w każdym długotrwałym systemie. Funkcja staje się przestarzała, ale zadanie w tle, które ją obsługiwało, nadal działa. Ktoś „tymczasowo” uruchamia proces roboczy, aby obsłużyć migrację, i nigdy nie zostaje on rozebrany po zmianie architektury, ale nikt nie myśli o tym, aby to sprawdzić. Zwykliśmy wysyłać e-maile z okazji urodzin do Buffer zaplanowane zadanie, które sprawdziło całą bazę danych pod kątem urodzin odpowiadających bieżącej dacie i wysłało klientom spersonalizowaną wiadomość e-mail. Podczas refaktoryzacji w 2020 r. zmieniliśmy nasze narzędzie do obsługi poczty transakcyjnej, ale zapomnieliśmy usunąć tego pracownika — działało ono przez kolejne pięć lat. Żadna z tych sytuacji nie jest błędami pojedynczych osób — są to błędy procesu. Bez celowego czyszczenia wbudowanego w naszą pracę wygrywa entropia. W jaki sposób nasza architektura pomogła nam to znaleźć. Podobnie jak wiele firm, Buffer przyjął ruch mikrousług (popularne podejście, w którym firmy). podzieliliśmy kod na wiele małych, niezależnych usług) wiele lat temu. Podzieliliśmy nasz monolit na osobne usługi, każda z własnym repozytorium, procesem wdrażania i infrastrukturą. W tamtym czasie miało to sens: każdą usługę można było wdrożyć samodzielnie, z wyraźnymi granicami między zespołami. Jednak z biegiem lat odkryliśmy, że obciążenie związane z zarządzaniem dziesiątkami repozytoriów przewyższyło korzyści dla zespołu naszej wielkości, dlatego skonsolidowaliśmy się w jedno repozytorium obejmujące wiele usług. Usługi nadal stanowią logiczne granice, ale łączą się w jednym Okazało się, że to umożliwiło odkrywanie. W świecie mikrousług każde repozytorium jest osobną wyspą. Zapomniany pracownik w jednym repozytorium może nigdy nie zostać zauważony przez inżynierów pracujących w innym. Nie ma jednego miejsca do wyszukiwania nazw kolejek, nie ma jednolitego obrazu tego, co gdzie jest uruchamiane. Dzięki temu, że wszystko było w jednym repozytorium, mogliśmy wreszcie prześledzić każdą kolejkę do jej konsumentów i producentów. Mogliśmy znaleźć kolejki z producentami, ale bez konsumentów która już nie istniała. Konsolidacja nie miała nam pomóc w znalezieniu infrastruktury zombie — ale to umożliwiłaodkrycie jest prawie nieuniknione. Co właściwie zrobiliśmy Po zidentyfikowaniu osieroconych procesów musieliśmy zdecydować, co z nimi zrobić. Oto jak do tego podeszliśmy. Najpierw prześledziliśmy pochodzenie każdego z nich. Przeszukaliśmy historię Git i starą dokumentację, aby zrozumieć, dlaczego w ogóle stworzono każdego pracownika. W większości przypadków pierwotny cel był jasny: jednorazowa migracja danych, funkcja, która została wyłączona, tymczasowe obejście, które przestało być przydatne. Następnie potwierdziliśmy, że rzeczywiście były nieużywane. Zanim cokolwiek usunęliśmy, dodaliśmy rejestrowanie, aby sprawdzić, czy te procesy nie robiły po cichu czegoś ważnego, co przeoczyliśmy. Monitorowaliśmy przez kilka dni, aby upewnić się, że w ogóle nie zostali wezwani, i stopniowo je usuwaliśmy. Nie usunęliśmy wszystkiego na raz. Usunęliśmy procesy jeden po drugim, obserwując nieoczekiwane skutki uboczne. (Na szczęście nie było żadnych). W końcu udokumentowaliśmy to, czego się dowiedzieliśmy. Do naszych wewnętrznych dokumentów dodaliśmy notatki na temat pierwotnego działania każdego procesu i powodu jego usunięcia, aby przyszli inżynierowie nie zastanawiali się, czy zginęło coś ważnego. Co zmieniło się po oczyszczeniu Wciąż jesteśmy na początku w mierzeniu pełnego wpływu, ale oto, co do tej pory zaobserwowaliśmy. Nasza inwentaryzacja infrastruktury jest teraz dokładna. Kiedy ktoś pyta: „Jakich pracowników zatrudniamy?” właściwie możemy odpowiedzieć na to pytanie z całą pewnością. Rozmowy wprowadzające również stały się prostsze. Nowi inżynierowie nie natrafiają na tajemnicze procesy i nie zastanawiają się, czy brakuje im kontekstu. Baza kodu odzwierciedla to, co faktycznie robimy, a nie to, co zrobiliśmy pięć lat temu. Traktuj refaktoryzatory jako archeologię i zapobieganie. Mój największy wniosek z tego projektu: każdy znaczący refaktor jest szansą dla archeologii. Kiedy zagłębisz się w system i naprawdę rozumiesz, w jaki sposób łączą się jego elementy, jesteś w doskonałej pozycji, aby zakwestionować to, co jest jeszcze potrzebne. Ta kolejka z jakiegoś starego projektu? Pracownik utworzony do jednorazowej migracji danych? Zaplanowane zadanie, które odwołuje się do funkcji, o której nigdy nie słyszałeś? Mogą nadal działać. Oto, co będziemy wbudowywać w nasz proces w przyszłości: Podczas każdego refaktoryzacji zadaj sobie pytanie: co jeszcze wpływa na ten system, a czego nie przyglądaliśmy się od jakiegoś czasu? Kiedy wycofujesz funkcję, prześledź ją aż do procesów w tle, a nie tylko kodu widocznego dla użytkownika. Kiedy ktoś opuszcza zespół, udokumentuj, za co był odpowiedzialny, szczególnie za to, co działa w tle. Nadal mamy starsze części naszej bazy kodu, które nie zostały przeniesione do pojedynczego repozytorium jeszcze. Jesteśmy pewni, że w miarę kontynuowania konsolidacji odnajdziemy więcej tych ukrytych reliktów. Ale teraz jesteśmy gotowi je wyłapywać i zapobiegać tworzeniu nowych. Kiedy cały kod znajduje się w jednym miejscu, osierocona infrastruktura nie ma gdzie się ukryć.
Czego dowiedzieliśmy się po znalezieniu 7 zapomnianych zawodów działających przez 5 lat
By Social Media
·
·
6 min read
·
560 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
