לאחרונה התחלנו פרויקט קטן לניקוי האופן שבו חלקים מהמערכות שלנו מתקשרים מאחורי הקלעים ב-Buffer. קצת הקשר מהיר: אנחנו משתמשים במשהו שנקרא SQS (Amazon Simple Queue Service. התורים האלה פועלים כמו חדרי המתנה למשימות. חלק אחד של המערכת שלנו מוריד הודעה, ואחר קולט אותה מאוחר יותר. תחשוב על זה כמו להשאיר פתק לעמית לעבודה, אתה מקבל את ההזדמנות הזאת למערכת, ההזדמנות הזו. note לא צריך לחכות לתגובה. הפרויקט שלנו היה לבצע תחזוקה שוטפת: לעדכן את הכלים שבהם אנחנו משתמשים כדי לבדוק תורים מקומית ולנקות את התצורה שלהם. אבל בזמן שמיפינו באילו תורים אנחנו משתמשים בפועל, מצאנו משהו שלא ציפינו לו: שבעה תהליכי רקע שונים (או עבודות cron, שהם משימות מתוכננות שפועלות באופן אוטומטי במשך חמש שנים לחלוטין) ועובדים לא פעלו באופן אוטומטי שימושי. הנה למה זה משנה, איך מצאנו אותם ומה עשינו בקשר לזה. למה זה חשוב יותר ממה שאתה חושב כן, הפעלת תשתית מיותרת עולה כסף, ועבור אחד מהעובדים האלה היינו משלמים 360-600$ במשך 5 שנים. ניקיון, אני טוען שהעלות הפיננסית היא למעשה החלק הקטן ביותר של הבעיה. בכל פעם שמהנדס חדש מצטרף לצוות וחוקר את המערכות שלנו, הם נתקלים בתהליכים המסתוריים האלה "מה העובד הזה עושה הופך לשאלה שגוזלת את זמן ההצטרפות ויוצרים אי ודאות שכולנו היינו שם - אולי נוגעים בזה, בגלל משהו חשוב. תשתית "נשכחת" זקוקה מדי פעם לעדכוני אבטחה, תיקוני תאימות כאשר משהו אחר משתנה. האמת היא שזה קורה באופן טבעי בכל מערכת ארוכת טווח. תכונה מתבטלת, אבל עבודת הרקע שתמכה בה ממשיכה לפעול "באופן זמני" של עובד כדי לטפל בהעברה, והיא אף פעם לא נקרעת משימה מתוכננת הופכת למיותרת לאחר שינוי ארכיטקטוני, אבל אף אחד לא חושב לשלוח את לוח הזמנים הזה משימה שבדקה את כל מסד הנתונים עבור ימי הולדת התואמים את התאריך הנוכחי ושלחה ללקוחות אימייל מותאם אישית במהלך ריפאקטור בשנת 2020, החלפנו את כלי הדוא"ל שלנו לעסקאות, אך שכחנו להסיר את העובד הזה - הוא המשיך לפעול במשך חמש שנים נוספות. אף אחד מהם אינו כשלים של אנשים - הם כישלונות בתהליך. אימצו את תנועת המיקרו-שירותים (גישה פופולרית שבה חברות פיצלו את הקוד שלהן להרבה שירותים קטנים ועצמאיים) לפני שנים. חילקנו את המונוליט שלנו לשירותים נפרדים, כל אחד עם מאגר משלו, צינור פריסה ותשתית משלו. בזמנו, זה היה הגיוני: כל שירות יכול להיפרס בפני עצמו, עם גבולות ברורים בין צוותים. אבל עם השנים, ניצחנו את היתרונות של הצוות מחדש. אז התאחדנו למאגר יחיד של שירותים השירותים עדיין קיימים כגבולות לוגיים, אבל הם חיים יחד במקום אחד. זה התברר כדבר שהפך את הגילוי לאפשרי. בעולם המיקרו-שירותים, כל מאגר הוא האי שלו. מאגר, סוף סוף יכולנו לראות את התמונה המלאה של כל תור לצרכנים וליצרנים שלו. יכולנו לזהות תורים עם יצרנים, אבל לא יכולנו למצוא עובדים שמתייחסים לתורים שכבר לא היו קיימים.גילוי כמעט בלתי נמנע. מה בעצם עשינו ברגע שזיהינו את התהליכים היתומים, היינו צריכים להחליט מה לעשות איתם. הנה איך ניגשנו אליו. ראשית, עקבנו אחר כל אחד מהמקור שלו. חפרנו בהיסטוריה של Git ובתיעוד ישן כדי להבין מדוע כל עובד נוצר מלכתחילה. ברוב המקרים, המטרה המקורית הייתה ברורה: העברת נתונים חד-פעמית, תכונה שזכתה לשקיעה, פתרון זמני שהאריך ימים את השימושיות שלה. ואז אישרנו שהם באמת לא היו בשימוש. לפני שהסרנו משהו, הוספנו רישום כדי לוודא שהתהליכים האלה לא עושים משהו חשוב שפספסנו בשקט. עקבנו במשך כמה ימים כדי לוודא שהם לא נקראו כלל, והסרנו אותם בהדרגה. לא מחקנו הכל בבת אחת. הסרנו תהליכים בזה אחר זה, תוך שמירה על תופעות לוואי בלתי צפויות. (למרבה המזל, לא היו כאלה.) לבסוף, תיעדנו את מה שלמדנו. הוספנו הערות למסמכים הפנימיים שלנו לגבי מה כל תהליך עשה במקור ומדוע הוא הוסר, כך שמהנדסים עתידיים לא יתהו אם משהו חשוב נעלם. מה השתנה לאחר הניקוי אנחנו עדיין בשלב מוקדם במדידת ההשפעה המלאה, אבל הנה מה שראינו עד כה. מלאי התשתיות שלנו מדויק כעת. כשמישהו שואל: "איזה עובדים אנחנו מפעילים?" אנחנו באמת יכולים לענות על השאלה הזו בביטחון. גם שיחות ההצטרפות הפכו פשוטות יותר. מהנדסים חדשים לא נתקלים בתהליכים מסתוריים ותוהים אם הם מפספסים הקשר. בסיס הקוד משקף את מה שאנחנו עושים בפועל, לא את מה שעשינו לפני חמש שנים.התייחס לרפקטורים כארכיאולוגיה ומניעה המוצא הכי גדול שלי מהפרויקט הזה: כל רפקטור משמעותי הוא הזדמנות לארכיאולוגיה. כשאתה עמוק במערכת, באמת מבין איך החלקים מתחברים, אתה נמצא בעמדה המושלמת לשאול מה עדיין נחוץ. התור הזה מאיזה פרויקט ישן? העובד שמישהו יצר עבור העברת נתונים חד פעמית? המשימה המתוזמנת שמתייחסת לתכונה שמעולם לא שמעת עליה? יכול להיות שהם עדיין פועלים. הנה מה שאנחנו בונים בתהליך שלנו קדימה: במהלך כל רפקטור, שאלו: מה עוד נוגע למערכת הזו שלא הסתכלנו עליה זמן מה? כשמוציאים משימוש תכונה, עקבו אחריה עד לתהליכי הרקע שלה, לא רק לקוד הפונה למשתמש. כשמישהו עוזב את הצוות, תעדו על מה הוא היה אחראי על הרקע שעדיין מפעילים את הקוד שלנו, במיוחד בחלקים הישנים שלנו. שעדיין לא הועברו למאגר היחיד. ככל שאנו ממשיכים לגבש, אנו בטוחים שנמצא עוד מהשרידים הנסתרים הללו. אבל עכשיו אנחנו ערוכים לתפוס אותם ולמנוע היווצרות של חדשים. כשכל הקוד שלך נמצא במקום אחד, לתשתית יתומה אין איפה להסתתר.
מה למדנו לאחר שמצאנו 7 משרות נשכחות שפועלות במשך 5 שנים
By Social Media
·
·
6 min read
·
185 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
