हमने हाल ही में यह साफ करने के लिए एक छोटा सा प्रोजेक्ट शुरू किया है कि हमारे सिस्टम के कुछ हिस्से बफ़र पर पर्दे के पीछे कैसे संचार करते हैं। कुछ त्वरित संदर्भ: हम एसक्यूएस (अमेज़ॅन सिंपल क्यू सर्विस) नामक कुछ का उपयोग करते हैं। ये कतारें कार्यों के लिए प्रतीक्षा कक्ष की तरह काम करती हैं। हमारे सिस्टम का एक हिस्सा एक संदेश छोड़ देता है, और दूसरा इसे बाद में उठाता है। इसे एक सहकर्मी के लिए एक नोट छोड़ने जैसा समझें: "अरे, जब आपको मौका मिले, तो इस डेटा को संसाधित करें।" नोट भेजने वाले सिस्टम को प्रतिक्रिया के लिए इंतजार नहीं करना पड़ता है। हमारा प्रोजेक्ट नियमित रखरखाव करना था: स्थानीय रूप से कतारों का परीक्षण करने और उनके कॉन्फ़िगरेशन को साफ़ करने के लिए हम जिन उपकरणों का उपयोग करते हैं उन्हें अपडेट करें। लेकिन जब हम यह मैप कर रहे थे कि हम वास्तव में किस कतार का उपयोग करते हैं, तो हमें कुछ ऐसा मिला जिसकी हमें उम्मीद नहीं थी: सात अलग-अलग पृष्ठभूमि प्रक्रियाएं (या क्रॉन जॉब्स, जो स्वचालित रूप से चलने वाले निर्धारित कार्य हैं) और वे सभी जो पांच साल से चुपचाप चल रहे थे, बिल्कुल कोई उपयोगी काम नहीं कर रहे थे। यहां बताया गया है कि यह क्यों मायने रखता है, हमने उन्हें कैसे पाया, और हमने इसके बारे में क्या किया। यह आपके विचार से अधिक क्यों मायने रखता है, हां, चल रहा है। अनावश्यक बुनियादी ढांचे में पैसा खर्च होता है। मैंने एक त्वरित गणना की और उन श्रमिकों में से एक के लिए, हमने 5 वर्षों में ~$360-600 का भुगतान किया होगा। यह हमारे वित्त की भव्य योजना में एक मामूली राशि है, लेकिन निश्चित रूप से एक प्रक्रिया के लिए शुद्ध बर्बादी है। हालांकि, इस सफाई से गुजरने के बाद, मैं तर्क दूंगा कि वित्तीय लागत वास्तव में समस्या का सबसे छोटा हिस्सा है। हर बार जब कोई नया इंजीनियर टीम में शामिल होता है और हमारे सिस्टम की खोज करता है, तो उन्हें इन रहस्यमय प्रक्रियाओं का सामना करना पड़ता है ऑनबोर्डिंग का समय नष्ट हो जाता है और अनिश्चितता पैदा होती है। हम सभी कोड के एक टुकड़े को घूरते रहते हैं, इसे छूने से डरते हैं क्योंकि शायद यह कुछ महत्वपूर्ण काम कर रहा है। यहां तक कि "भूल गए" बुनियादी ढांचे पर भी कभी-कभी ध्यान देने की आवश्यकता होती है। जब कुछ और बदलता है तो हमारी टीम को कोड पथों पर रखरखाव चक्र खर्च करना पड़ता है। और समय के साथ, क्या यह एक अस्थायी सुधार था जो इसे बनाने वाले व्यक्ति ने कंपनी छोड़ दी थी? पहले, और संदर्भ उनके पास रह गया। यह कैसे होता है? उंगलियां उठाना आसान है, लेकिन सच्चाई यह है कि यह किसी भी लंबे समय तक चलने वाले सिस्टम में स्वाभाविक रूप से होता है। एक सुविधा को हटा दिया जाता है, लेकिन इसका समर्थन करने वाला पृष्ठभूमि कार्य चलता रहता है। कोई माइग्रेशन को संभालने के लिए एक कार्यकर्ता को "अस्थायी रूप से" नियुक्त करता है, और यह कभी भी वास्तुशिल्प परिवर्तन के बाद अनावश्यक नहीं होता है, लेकिन कोई भी जांच करने के बारे में नहीं सोचता है। ऐसा करने के लिए, हम जन्मदिन समारोह ईमेल भेजते थे scheduled task that checked the entire database for birthdays matching the current date and sent customers a personalized email. During a refactor in 2020, we switched our transactional email tool but forgot to remove this worker—it kept running for five more years.None of these are failures of individuals — they're failures of process. Without intentional cleanup built into how we work, entropy wins.How our architecture helped us find itLike many companies, Buffer embraced the microservices movement (a popular approach where companies split वर्षों पहले हमने अपने मोनोलिथ को अलग-अलग सेवाओं में विभाजित किया था, प्रत्येक की अपनी रिपॉजिटरी, परिनियोजन पाइपलाइन और बुनियादी ढांचा था। उस समय, यह समझ में आया: प्रत्येक सेवा को टीमों के बीच स्पष्ट सीमाओं के साथ अपने आप तैनात किया जा सकता था। लेकिन वर्षों से, हमने पाया कि दर्जनों रिपॉजिटरी के प्रबंधन का ओवरहेड हमारे आकार की टीम के लिए लाभों से अधिक था, इसलिए हमने एक बहु-सेवा एकल रिपॉजिटरी में समेकित किया स्थान। इससे खोज संभव हो गई। माइक्रोसर्विसेज की दुनिया में, प्रत्येक रिपॉजिटरी का अपना द्वीप होता है। एक रिपॉजिटरी में एक भूले हुए कर्मचारी को दूसरे में काम करने वाले इंजीनियरों द्वारा कभी नहीं देखा जा सकता है। वहां क्या चल रहा है, इसका कोई एकीकृत दृश्य नहीं है। एक रिपॉजिटरी में सब कुछ के साथ, हम अंततः प्रत्येक कतार को उसके उपभोक्ताओं और उत्पादकों के साथ देख सकते हैं, लेकिन हमें ऐसी कतारें नहीं मिल सकती हैं जो अब मौजूद नहीं हैं अस्तित्व में है। समेकन हमें ज़ोंबी बुनियादी ढांचे को खोजने में मदद करने के लिए डिज़ाइन नहीं किया गया था - लेकिन इसने इसे बनायाखोज लगभग अपरिहार्य है। हमने वास्तव में क्या किया एक बार जब हमने अनाथ प्रक्रियाओं की पहचान कर ली, तो हमें यह तय करना था कि उनके साथ क्या करना है। यहां बताया गया है कि हम इस तक कैसे पहुंचे। सबसे पहले, हमने प्रत्येक के मूल का पता लगाया। हमने यह समझने के लिए गिट इतिहास और पुराने दस्तावेज़ों को खंगाला कि प्रत्येक कार्यकर्ता को पहले स्थान पर क्यों बनाया गया था। ज्यादातर मामलों में, मूल उद्देश्य स्पष्ट था: एक बार डेटा माइग्रेशन, एक सुविधा जो समाप्त हो गई, एक अस्थायी समाधान जिसने इसकी उपयोगिता को समाप्त कर दिया। फिर हमने पुष्टि की कि वे वास्तव में अप्रयुक्त थे। कुछ भी हटाने से पहले, हमने यह सत्यापित करने के लिए लॉगिंग जोड़ी कि ये प्रक्रियाएँ चुपचाप कुछ महत्वपूर्ण काम नहीं कर रही थीं जो हम चूक गए थे। हमने यह सुनिश्चित करने के लिए कुछ दिनों तक निगरानी की कि उन्हें बिल्कुल भी नहीं बुलाया गया था, और हमने धीरे-धीरे उन्हें हटा दिया। हमने सब कुछ एक साथ नहीं हटाया. किसी भी अप्रत्याशित दुष्प्रभाव पर नज़र रखते हुए हमने प्रक्रियाओं को एक-एक करके हटा दिया। (सौभाग्य से, वहाँ कोई नहीं था।) अंततः, हमने जो सीखा उसे प्रलेखित किया। हमने अपने आंतरिक दस्तावेज़ों में नोट्स जोड़े हैं कि प्रत्येक प्रक्रिया ने मूल रूप से क्या किया था और इसे क्यों हटाया गया था, ताकि भविष्य के इंजीनियरों को आश्चर्य न हो कि कुछ महत्वपूर्ण गायब हो गया है। सफाई के बाद क्या बदल गया हम अभी भी पूर्ण प्रभाव को मापने में जल्दी हैं, लेकिन हमने अब तक जो देखा है वह यहां दिया गया है। हमारी बुनियादी ढांचा सूची अब सटीक है। जब कोई पूछता है, "हम कौन से कर्मचारी चलाते हैं?" हम वास्तव में आत्मविश्वास के साथ उस प्रश्न का उत्तर दे सकते हैं। ऑनबोर्डिंग वार्तालाप भी सरल हो गए हैं। नए इंजीनियर रहस्यमयी प्रक्रियाओं से जूझ नहीं रहे हैं और सोच रहे हैं कि कहीं वे संदर्भ भूल तो नहीं रहे हैं। कोडबेस दर्शाता है कि हम वास्तव में क्या करते हैं, न कि वह जो हमने पांच साल पहले किया था। रिफैक्टरों को पुरातत्व और रोकथाम के रूप में मानें। इस परियोजना से मेरी सबसे बड़ी सीख: प्रत्येक महत्वपूर्ण रिफैक्टर पुरातत्व के लिए एक अवसर है। जब आप एक प्रणाली में गहरे होते हैं, वास्तव में समझते हैं कि टुकड़े कैसे जुड़ते हैं, तो आप यह सवाल करने की सही स्थिति में हैं कि अभी भी क्या आवश्यक है। That queue from some old project? वह कार्यकर्ता जिसे किसी ने एक बार के डेटा माइग्रेशन के लिए बनाया है? वह निर्धारित कार्य जो उस सुविधा का संदर्भ देता है जिसके बारे में आपने कभी नहीं सुना है? वे अभी भी चल रहे होंगे। यहां बताया गया है कि हम अपनी आगे की प्रक्रिया में क्या निर्माण कर रहे हैं: किसी भी रिफैक्टर के दौरान, पूछें: इस सिस्टम को और क्या छूता है जिसे हमने कुछ समय से नहीं देखा है? किसी सुविधा को हटाते समय, इसे केवल उपयोगकर्ता-सामना करने वाले कोड के अलावा इसकी पृष्ठभूमि प्रक्रियाओं तक ट्रेस करें। जब कोई टीम छोड़ता है, तो दस्तावेज करें कि वे किसके प्रभारी थे, विशेष रूप से पृष्ठभूमि में चलने वाली सामग्री। हमारे पास अभी भी हमारे कोडबेस के पुराने हिस्से हैं जिन्हें एकल में स्थानांतरित नहीं किया गया है भंडार अभी तक. जैसे-जैसे हम समेकित होते जा रहे हैं, हमें विश्वास है कि हम इनमें से और भी छिपे हुए अवशेष ढूंढ लेंगे। लेकिन अब हम उन्हें पकड़ने और नए कोड बनने से रोकने के लिए तैयार हैं। जब आपका सारा कोड एक ही स्थान पर रहता है, तो अनाथ बुनियादी ढांचे के पास छिपने के लिए कोई जगह नहीं होती है।
5 वर्षों से चली आ रही 7 भूली हुई नौकरियाँ ढूँढ़ने के बाद हमने क्या सीखा
By Social Media
·
·
6 min read
·
576 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
