Недавно смо започели мали пројекат да очистимо начин на који делови наших система комуницирају иза кулиса у Буффер-у. Брзи контекст: користимо нешто што се зове СКС (Амазон Симпле Куеуе Сервице. Ови редови се понашају као чекаонице за задатке. Један део нашег система испушта поруку, а други је преузима касније. Размислите о томе као о остављању белешке за случајног сарадника, тај процес шаље овај систем: „Он шаље податке.“ белешка не мора да чека на одговор. Наш пројекат је био да извршимо рутинско одржавање: ажурирамо алате које користимо за локално тестирање редова и очистимо њихову конфигурацију. Али док смо планирали које редове заправо користимо, пронашли смо нешто што нисмо очекивали: седам различитих позадинских процеса (или црон послова, који су заказани задаци који се покрећу аутоматски) и радници који су радили без прекида за пет година корисно.Ево зашто је то важно, како смо их пронашли и шта смо урадили у вези са тим.Зашто је ово важније него што мислите.Да, вођење непотребне инфраструктуре кошта пуно новца и за једног од тих радника платили бисмо ~360-600$ током 5 година. тврде да је финансијски трошак заправо најмањи део проблема. Сваки пут када се нови инжењер придружи тиму и истражује наше системе, они се сусрећу са овим мистериозним процесима, што постаје питање које одузима време за учлањење и ствара несигурност ажурирања, грешке у зависности, поправке компатибилности када се нешто друго промени. Ово је довело до тога да наш тим троши циклусе на одржавање кода који нису служили никаквој сврси. Да ли је то било привремено решење које је постало трајно. дуготрајан систем. Функција постаје застарела, али посао у позадини који је подржава и даље ради. Неко „привремено“ окреће радника и никада се не скида рођендани који одговарају тренутном датуму и послали смо клијентима персонализовану е-пошту током рефактора 2020. године, променили смо наш алат за трансакцију е-поште, али смо заборавили да уклонимо овог радника – наставио је да ради још пет година. покрет (популарни приступ где су компаније поделиле свој код на много малих, независних сервиса) пре много година. Поделили смо наш монолит на засебне услуге, од којих је свака имала сопствено складиште, цевовод за примену и инфраструктуру. Дакле, консолидовали смо се у јединствено складиште са више услуга, али они живе заједно на једном месту. Испоставило се да је ово откриће било могуће. У свету микросервиса, свако складиште је своје острво. у једном спремишту, могли смо да видимо потпуну слику. Могли смо да уочимо редове са произвођачима, али не и потрошаче. Могли смо да пронађемо раднике који се позивају на редове који више не постоје.откриће је готово неизбежно. Шта смо заправо урадили Када смо идентификовали процесе без родитеља, морали смо да одлучимо шта ћемо са њима. Ево како смо му приступили. Прво смо пратили сваки до његовог порекла. Копали смо кроз историју гит-а и стару документацију да бисмо разумели зашто је сваки радник уопште створен. У већини случајева, првобитна сврха је била јасна: једнократна миграција података, функција која је престала да ради, привремено решење које је наџивело своју корисност. Затим смо потврдили да су заиста неискоришћени. Пре него што смо било шта уклонили, додали смо евиденцију да бисмо проверили да ови процеси не раде тихо нешто важно што смо пропустили. Пратили смо неколико дана да бисмо били сигурни да уопште нису позвани и постепено смо их уклањали. Нисмо све одједном избрисали. Уклањали смо процесе један по један, пазећи на све неочекиване нежељене ефекте. (Срећом, није их било.) Коначно смо документовали шта смо научили. Додали смо белешке у наше интерне документе о томе шта је сваки процес првобитно урадио и зашто је уклоњен, како се будући инжењери не би питали да ли је нешто важно нестало. Шта се променило након чишћења Још смо рано у мерењу пуног утицаја, али ево шта смо до сада видели. Наш инвентар инфраструктуре је сада тачан. Када неко пита: "Које раднике водимо?" заправо можемо са сигурношћу да одговоримо на то питање. Инбоардинг разговори су такође постали једноставнији. Нови инжењери не наилазе на мистериозне процесе и не питају се да ли им недостаје контекст. База кода одражава оно што ми заправо радимо, а не оно што смо радили пре пет година. Третирајте рефакторе као археологију и превенцију. Мој највећи закључак из овог пројекта: сваки значајан рефактор је прилика за археологију. Када сте дубоко у систему, заиста разумете како се делови повезују, у савршеној сте позицији да преиспитате шта је још потребно. Тај ред из неког старог пројекта? Радник који је неко створио за једнократну миграцију података? Планирани задатак који упућује на функцију за коју никада нисте чули? Можда и даље раде. Ево шта уграђујемо у наш процес за даље: Током било каквог рефактора, питајте: шта још дотиче овај систем који нисмо гледали неко време? Када застаревате функцију, пратите је све до њених позадинских процеса, а не само до кода који је окренут кориснику. Када неко напусти тим, документујте оно за шта су били задужени за наше делове, посебно у позадини имамо ствари за које су задужене. још увек нису премештени у јединствено складиште. Како настављамо да се консолидујемо, уверени смо да ћемо пронаћи још ових скривених реликвија. Али сада смо подешени да их ухватимо и спречимо стварање нових. Када сав ваш код живи на једном месту, осироћена инфраструктура нема где да се сакрије.

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