Yakın zamanda sistemlerimizin bazı bölümlerinin Buffer'da perde arkasında nasıl iletişim kurduğunu temizlemek için küçük bir proje başlattık. Kısa bir bağlam: SQS (Amazon Simple Queue Service) adı verilen bir şey kullanıyoruz. Bu kuyruklar görevler için bekleme odaları gibi davranır. Sistemimizin bir kısmı bir mesaj bırakır ve diğeri onu daha sonra alır. Bunu bir iş arkadaşınıza bir not bırakmak gibi düşünün: "Hey, fırsatınız olduğunda bu verileri işleyin." Notu gönderen sistemin bir yanıt beklemesi gerekmez. projemiz rutin bakım yapmaktı: kuyrukları yerel olarak test etmek ve yapılandırmalarını temizlemek için kullandığımız araçları güncellemek. Ancak gerçekte hangi kuyrukları kullandığımızı haritalandırırken beklemediğimiz bir şey bulduk: yedi farklı arka plan işlemi (veya otomatik olarak çalışan zamanlanmış görevler olan cron işleri) ve beş yıla kadar sessizce çalışan işçiler. Hepsi kesinlikle yararlı hiçbir şey yapmıyor. İşte bu neden önemli, onları nasıl bulduğumuz ve bu konuda ne yaptığımız. Bu neden düşündüğünüzden daha önemli Evet, koşuyor. Gereksiz altyapı maliyeti açısından hızlı bir hesaplama yaptım ve bu çalışanlardan biri için 5 yılda ~360-600 dolar ödemiş olurduk. Bu, mali tablomuzun genel planına göre mütevazı bir miktar, ancak hiçbir şey yapmayan bir süreç için kesinlikle saf israf. Ancak, bu temizliği yaptıktan sonra, finansal maliyetin aslında sorunun en küçük kısmı olduğunu iddia ediyorum. Ekibe her yeni mühendis katıldığında ve sistemlerimizi araştırdığında, şu gizemli süreçlerle karşılaşıyorlar: "Bu işçi ne yapıyor?" İlk katılım süresini tüketir ve belirsizlik yaratır. Hepimiz bir kod parçasına bakıyoruz, çünkü önemli bir şey yapıyor olabilir. "Unutulmuş" altyapının bile zaman zaman bakıma ihtiyacı vardır. Başka bir şey değiştiğinde güvenlik güncellemeleri, bağımlılık sorunları, uyumluluk düzeltmeleri. Bu, ekibimizin hiçbir amaca hizmet etmeyen bakım döngüleri yapmasına neden oldu. Ve zamanla kurumsal bilgi kaybolur. Bu kritik bir durum muydu? Onu oluşturan kişi şirketten ayrıldı. Bu nasıl oluyor? İşaret etmek kolaydır, ancak gerçek şu ki, uzun ömürlü herhangi bir sistemde bu doğal olarak gerçekleşir. Bir özellik kullanımdan kaldırılır, ancak onu destekleyen arka plan işi çalışmaya devam eder. Birisi, bir geçişi gerçekleştirmek için bir işçiyi "geçici olarak" çalıştırır ve hiçbir zaman yıkılmaz. Planlanmış bir görev, mimari bir değişiklikten sonra gereksiz hale gelir, ancak kimse kontrol etmeyi düşünmez. Bunu yapmak için, bir işçiyi çalıştırdık. Geçerli tarihle eşleşen doğum günleri için tüm veritabanını kontrol eden ve müşterilere kişiselleştirilmiş bir e-posta gönderen zamanlanmış görev. 2020'deki bir yeniden düzenleme sırasında, işlemsel e-posta aracımızı değiştirmeyi unuttuk; beş yıl daha çalışmaya devam etti. Bunların hiçbiri bireylerin hatası değil; bunlar süreç hataları. Çalışma şeklimize kasıtlı bir temizlik yapılmadan entropi kazanır. Mimarimiz onu bulmamıza nasıl yardımcı oldu Birçok şirket gibi Buffer da mikro hizmetler hareketini (şirketlerin kodlarını böldüğü popüler bir yaklaşım) benimsedi. Monolith'imizi, her biri kendi deposuna, dağıtım hattına ve altyapısına sahip olan ayrı hizmetlere böldük. O zamanlar bu mantıklıydı: Her hizmet, ekipler arasında net sınırlar olacak şekilde kendi başına dağıtılabilirdi. Ancak yıllar geçtikçe, düzinelerce depoyu yönetme yükünün bizim büyüklüğümüzdeki bir ekip için faydalardan daha ağır bastığını gördük. Bu yüzden, çok hizmetli tek bir depoda birleştik. Hizmetler hâlâ mantıksal sınırlar halinde mevcut ancak birlikte tek bir yerde yaşıyorlar. Mikro hizmetler dünyasında, her depo kendi adasıdır. Bir depodaki unutulmuş bir işçi, diğerinde çalışan mühendisler tarafından asla fark edilmeyebilir. Kuyruk adlarını aramak için tek bir yer yoktur, neyin nerede çalıştığına dair birleşik bir görünüm yoktur. Her şeyin tek bir depoda olmasıyla, sonunda resmin tamamını görebildik. Her kuyruğun tüketicilerine ve üreticilerine kadar izini sürebildik, ancak artık var olmayan kuyrukları referans alan işçileri bulamadık. birleştirme zombi altyapısını bulmamıza yardımcı olmak için tasarlanmamıştı - ama bunu sağladıkeşif neredeyse kaçınılmaz. Gerçekte ne yaptık Yetim kalmış süreçleri belirledikten sonra onlarla ne yapacağımıza karar vermemiz gerekiyordu. Buna şu şekilde yaklaştık. İlk olarak her birinin kökenine kadar izini sürdük. Her bir çalışanın neden yaratıldığını anlamak için git geçmişini ve eski belgeleri inceledik. Çoğu durumda asıl amaç açıktı: tek seferlik bir veri geçişi, geçerliliğini yitiren bir özellik, kullanışlılığını yitiren geçici bir çözüm. Sonra bunların gerçekten kullanılmadığını doğruladık. Herhangi bir şeyi kaldırmadan önce, bu süreçlerin gözden kaçırdığımız önemli bir şeyi sessizce yapmadığını doğrulamak için günlük kaydı ekledik. Hiç aranmadıklarından emin olmak için birkaç gün gözlemledik ve onları aşamalı olarak kaldırdık. Her şeyi bir anda silmedik. Beklenmedik yan etkileri gözlemleyerek süreçleri birer birer kaldırdık. (Neyse ki hiç yoktu.) Sonunda öğrendiklerimizi belgeledik. Gelecekteki mühendislerin önemli bir şeyin kaybolup kaybolmadığını merak etmemesi için dahili belgelerimize her sürecin başlangıçta ne yaptığı ve neden kaldırıldığı hakkında notlar ekledik. Temizlemeden sonra neler değişti Tam etkiyi ölçmek için hâlâ erkeniz, ancak şu ana kadar gördüklerimiz şunlar. Altyapı envanterimiz artık doğru. Birisi "Hangi işçileri çalıştırıyoruz?" aslında bu soruyu güvenle cevaplayabiliriz. İlk katılım konuşmaları da daha kolay hale geldi. Yeni mühendisler gizemli süreçlerle karşılaşmıyor ve bağlamın eksik olup olmadığını merak etmiyorlar. Kod tabanı, beş yıl önce yaptıklarımızı değil, gerçekte yaptıklarımızı yansıtıyor. Yeniden düzenlemeleri arkeoloji ve önleme olarak ele alın Bu projeden çıkaracağım en büyük çıkarım: her önemli yeniden düzenleme, arkeoloji için bir fırsattır. Bir sistemin derinliklerine indiğinizde, parçaların nasıl bağlandığını gerçekten anladığınızda, hâlâ neye ihtiyaç duyulduğunu sorgulamak için mükemmel bir konumdasınız. Eski bir projeden gelen kuyruk mu? Birinin tek seferlik veri geçişi için yarattığı çalışan mı? Daha önce hiç duymadığınız bir özelliğe atıfta bulunan zamanlanmış görev mi? Hâlâ çalışıyor olabilirler. İleriye dönük sürecimizde şunları oluşturuyoruz: Herhangi bir yeniden düzenleme sırasında şunu sorun: Bu sisteme bir süredir bakmadığımız başka neler dokunuyor? Bir özelliği kullanımdan kaldırırken, onu yalnızca kullanıcıya yönelik koda değil, arka plan süreçlerine kadar takip edin. Birisi ekipten ayrıldığında, onun neyden sorumlu olduğunu, özellikle de arka planda çalışan şeyleri belgeleyin. Kod tabanımızın hâlâ tek depoya taşınmamış eski bölümleri var. henüz. Birleştirmeye devam ettikçe bu gizli emanetlerden daha fazlasını bulacağımızdan eminiz. Ancak artık onları yakalayıp yenilerinin oluşmasını engellemeye hazırız. Kodunuzun tamamı tek bir yerde yaşadığında, artık altyapının saklanacak yeri kalmaz.
5 Yıldır Çalışan 7 Unutulan İş Bulduktan Sonra Öğrendiklerimiz
By Social Media
·
·
6 min read
·
682 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
