Біз жуырда Буферде жүйелеріміздің бөліктерінің сахна артында қалай байланысуын тазалау үшін шағын жобаны бастадық. Кейбір жылдам мәтінмән: біз SQS (Amazon Simple Queue Service) деп аталатын нәрсені қолданамыз. Бұл кезектер тапсырмалар үшін күту бөлмелері сияқты әрекет етеді. Жүйенің бір бөлігі хабарламаны түсіріп тастаса, екіншісі оны кейінірек қабылдайды. Мұны әріптесіңізге жазба қалдыру сияқты елестетіп көріңіз, ол деректерді жіберген кезде: " a. note жауап күтудің қажеті жоқ. Біздің жобамыз әдеттегі техникалық қызмет көрсету болды: біз қолданатын құралдарды жергілікті түрде сынау және олардың конфигурациясын тазалау. Бірақ біз шын мәнінде қандай кезектерді қолданатынымызды анықтаған кезде, біз күтпеген нәрсені таптық: жеті түрлі фондық процесс (немесе автоматты түрде орындалатын жоспарланған тапсырмалар) және олардың барлығы бес жыл бойына жұмыс істемейтін жұмысшылар Неліктен бұл маңызды, біз оларды қалай таптық және бұл туралы не істедік. Иә, қажетсіз инфрақұрылымды іске қосу ақшаны қажет етеді, мен 5 жыл ішінде біз $ 360-600 төлейтін едік. Тазалау, мен бұл мәселенің ең кішкентай бөлігі екенін айтқым келеді. Әр жаңа инженер командаға қосылып, біздің жүйелерді зерттеген сайын, олар «бұл жұмысшы не істейді?» деген сұраққа кезігеді. Басқа бірдеңе өзгерген кезде инфрақұрылымға назар аудару қажет. Бұл біздің команданың ешқандай мақсатқа қызмет етпейтін техникалық қызмет көрсету циклдарына әкеліп соқтырды. Уақыт өте келе, оны жасаған адам бұл жағдайды уақытша түзету болды ма? бірақ шындық, бұл кез келген ұзақ өмір сүретін жүйеде табиғи түрде болады. Функция ескіреді, бірақ оны қолдайтын фондық жұмыс тасымалдауды өңдеу үшін жұмысшыны «уақытша» айналдырады және ол ешқашан үзілмейді Ағымдағы күнге сәйкес келетін туған күндер үшін барлық дерекқорды тексеріп, тұтынушыларға жеке электрондық поштаны жіберген жоспарланған тапсырма 2020 жылы рефактор кезінде біз бұл жұмысшыны жоюды ұмытып кеттік — ол тағы бес жыл бойы жұмыс істей берді. Бұлардың ешқайсысы жеке тұлғалардың сәтсіздігі емес — олар біздің архитектурадағы әдейі тазартусыз бізге көмектесті. Буфер микросервистердің қозғалысын (компаниялар өздерінің кодын көптеген шағын, тәуелсіз қызметтерге бөлетін танымал тәсіл) бірнеше жыл бұрын қабылдады. Біз монолитті әрқайсысының өз репозиторийі, орналастыру құбыры және инфрақұрылымы бар бөлек қызметтерге бөлдік. Ол кезде мағынасы болды: әр қызмет өз бетінше орналастырылуы мүмкін, командалар арасындағы нақты шекаралар көп жылдар бойы қайталанады. Біз көп қызмет көрсететін бір репозиторийге біріктірдік, бірақ олар бір жерде бірге өмір сүреді. Бұл микросервистер әлемінде әр репозиторийдің жеке аралы болып табылады. Барлығын бір репозиторийде көрсету арқылы біз оның тұтынушылары мен өндірушілерін анықтай алдық, бірақ тұтынушыларға сілтеме жасайтын жұмысшыларды таба алмадық. Біріктіру оны табуға көмектесу үшін жасалған жоқ.Біз не істедік, жетім процестерді анықтағаннан кейін, олармен не істеу керектігін шешуге тура келді. Міне, біз оған қалай жақындадық. Біріншіден, біз әрқайсысының шығу тегін анықтадық. Әрбір жұмысшының ең алдымен неліктен құрылғанын түсіну үшін біз git тарихын және ескі құжаттаманы зерттедік. Көп жағдайда бастапқы мақсат түсінікті болды: деректерді бір реттік тасымалдау, күн батқан мүмкіндік, пайдалылығын ұзартқан уақытша шешім. Содан кейін олардың шынымен пайдаланылмағанын растадық. Ештеңені алып тастамас бұрын, біз бұл процестердің біз жіберіп алған маңызды нәрсені тыныш орындамағанын тексеру үшін тіркеуді қостық. Біз олардың мүлдем шақырылмағанына көз жеткізу үшін бірнеше күн бақылап отырдық және біз оларды біртіндеп алып тастадық. Біз барлығын бірден жойған жоқпыз. Кез келген күтпеген жанама әсерлерді бақылай отырып, процестерді бір-бірден алып тастадық. (Бақытымызға орай, олар болмады.)Соңында, біз білгендерімізді құжаттадық. Әрбір процестің бастапқыда не істегені және оның неліктен жойылғаны туралы ішкі құжаттарымызға ескертпелер қостық, сондықтан болашақ инженерлер маңызды бірдеңе жоғалып кетті ме деп ойламауы үшін. Тазалаудан кейін не өзгерді. Біз әсерді толық өлшеуге әлі ертерекпіз, бірақ осы уақытқа дейін көргеніміз. Біздің инфрақұрылымды түгендеуіміз дәл қазір. Біреу: «Біз қандай жұмысшыларды басқарамыз?» деп сұрағанда. біз бұл сұраққа сенімді түрде жауап бере аламыз. Борттағы әңгімелер де оңайырақ болды. Жаңа инженерлер жұмбақ процестерден сүрінбейді және контекст жетіспейді ме деп ойламайды. Кодтық база бес жыл бұрын істегенімізді емес, шын мәнінде не істеп жатқанымызды көрсетеді. Рефакторларды археология және профилактика ретінде қарастырыңыз Бұл жобадан алған ең үлкен ұсынысым: әрбір маңызды рефактор археологияға арналған мүмкіндік болып табылады. Жүйені терең меңгерген кезде, бөліктердің қалай қосылатынын шынымен түсінгенде, сіз әлі де қажет нәрсеге күмәндануға тамаша жағдайда боласыз. Бұл ескі жобаның кезегі? Бір реттік деректерді тасымалдау үшін жасалған жұмысшы? Сіз ешқашан естімеген мүмкіндікке сілтеме жасайтын жоспарланған тапсырма? Олар әлі де жұмыс істеп тұрған болуы мүмкін. Міне, біз ілгеріде жатқан үдерісімізді құрастырып жатырмыз: Кез келген рефактор кезінде мынаны сұраңыз: біз біраз уақыттан бері қарастырмаған бұл жүйеге тағы не әсер етеді? Функцияны пайдаланудан бас тартқанда, оны тек пайдаланушыға арналған кодқа ғана емес, оның фондық процестеріне дейін қадағалаңыз. Біреу топтан кеткенде, олар басқаратын нәрселерді құжаттаңыз, әсіресе біздің фондық кодта бізде әлі де бар. әлі жалғыз репозиторийге тасымалданбаған. Біріктіруді жалғастыра отырып, біз осы жасырын жәдігерлерді табатынымызға сенімдіміз. Бірақ қазір біз оларды ұстап алу және жаңаларының пайда болуына жол бермеу үшін реттелдік. Барлық кодыңыз бір жерде тұрғанда, жетім инфрақұрылымның жасырынатын жері болмайды.

You May Also Like

Enjoyed This Article?

Get weekly tips on growing your audience and monetizing your content — straight to your inbox.

No spam. Join 138,000+ creators. Unsubscribe anytime.

Create Your Free Bio Page

Join 138,000+ creators on Seemless.

Get Started Free