Nedávno sme spustili malý projekt na vyčistenie toho, ako časti našich systémov komunikujú v zákulisí vo vyrovnávacej pamäti. Niekoľko rýchlych súvislostí: používame niečo, čo sa nazýva SQS (Amazon Simple Queue Service. Tieto fronty fungujú ako čakáreň na úlohy. Jedna časť nášho systému odošle správu a druhá ju vyzdvihne neskôr. Predstavte si to ako zanechanie poznámky pre spolupracovníka: „Hej, spracuj, keď dostaneš tieto údaje, keď dostaneš príležitosť.“ odpoveď.Naším projektom bolo vykonávať rutinnú údržbu: aktualizovať nástroje, ktoré používame na lokálne testovanie frontov a čistenie ich konfigurácie. Kým sme však mapovali, aké fronty v skutočnosti používame, našli sme niečo, čo sme neočakávali: sedem rôznych procesov na pozadí (alebo úlohy cron, čo sú naplánované úlohy, ktoré sa spúšťajú automaticky) a pracovníkov, ktorí bežali potichu až päť rokov, a prečo sme na tom vôbec nič nerobili. záleží viac, ako by ste si mysleliÁno, prevádzka nepotrebnej infraštruktúry stojí peniaze. Urobil som rýchly výpočet a za jedného z týchto pracovníkov by sme zaplatili približne 360 – 600 $ v priebehu 5 rokov, ale určite je to čistý odpad za proces, ktorý nič nerobí. Po tomto čistení by som však tvrdil, že finančné náklady sú v skutočnosti najmenším problémom nášho tímu. procesy. „Čo robí tento pracovník?“ sa stáva otázkou, ktorá zaberá čas pri nástupe a vytvára neistotu. Všetci sme tam boli – zízali sme na kúsok kódu a bojíme sa ho dotknúť, pretože možno robí niečo dôležité. Aj „zabudnutá“ infraštruktúra občas potrebuje pozornosť, keď sa niečo iné zmení. Bola to dočasná oprava, ktorá sa stala trvalou? Osoba, ktorá ju vytvorila, opustila spoločnosť pred rokmi a zostal s ňou aj kontext. Ako sa to vôbec stalo? Je ľahké ukázať prstom, ale pravdou je, že sa to deje prirodzene v akomkoľvek dlhotrvajúcom systéme. Funkcia je zastaraná, ale úloha na pozadí, ktorá ju podporovala, stále beží, ale nikto ju po migrácii nezruší a nezmení na kontrolu. Na tento účel sme spustili naplánovanú úlohu, ktorá skontrolovala celú databázu na narodeniny zodpovedajúce aktuálnemu dátumu a odoslala zákazníkom prispôsobený e-mail nám to pomohlo nájsť Rovnako ako mnohé spoločnosti, aj Buffer si pred rokmi osvojil hnutie mikroslužieb (populárny prístup, pri ktorom spoločnosti rozdeľujú svoj kód na mnoho malých, nezávislých služieb). Rozdelili sme náš monolit na samostatné služby, z ktorých každá mala svoje vlastné úložisko, nasadzovacie kanály a infraštruktúru. Zjednotili sme sa do jedného úložiska s viacerými službami, stále existujú ako logické hranice, ale žijú spolu na jednom mieste. Ukázalo sa, že to umožnilo objavovanie. Vo svete mikroslužieb je každý repozitár vlastným ostrovom Zabudnutý pracovník v jednom úložisku si inžinieri pracujúci v inom nikdy nevšimnú. zobraziť úplný obraz Mohli sme vysledovať všetky fronty k ich spotrebiteľom a výrobcom. Dokázali sme nájsť zamestnancov, ktorí odkazovali na fronty, ktoré už neexistovali. Konsolidácia nebola navrhnutá tak, aby nám pomohla nájsť zombie infraštruktúru.objav takmer nevyhnutný. Čo sme vlastne urobili Keď sme identifikovali osirelé procesy, museli sme sa rozhodnúť, čo s nimi urobíme. Tu je návod, ako sme k tomu pristúpili. Najprv sme vystopovali každý z nich k jeho pôvodu. Prekopali sme históriu git a starú dokumentáciu, aby sme pochopili, prečo bol každý pracovník vytvorený. Vo väčšine prípadov bol pôvodný účel jasný: jednorazová migrácia údajov, funkcia, ktorá bola ukončená, dočasné riešenie, ktoré prežilo svoju užitočnosť. Potom sme potvrdili, že sa skutočne nepoužívajú. Pred odstránením čohokoľvek sme pridali protokolovanie, aby sme overili, že tieto procesy nerobia potichu niečo dôležité, čo sme premeškali. Sledovali sme niekoľko dní, aby sme sa uistili, že ich vôbec nevolali, a postupne sme ich odstraňovali. Nevymazali sme všetko naraz. Procesy sme odstraňovali jeden po druhom, pričom sme sledovali akékoľvek neočakávané vedľajšie účinky. (Našťastie žiadne neboli.) Nakoniec sme zdokumentovali, čo sme sa naučili. Do našich interných dokumentov sme pridali poznámky o tom, čo každý proces pôvodne vykonal a prečo bol odstránený, aby sa budúci inžinieri nečudovali, že niečo dôležité zmizlo. Čo sa zmenilo po vyčistení Stále sme skoro v meraní úplného vplyvu, ale tu je to, čo sme doteraz videli. Náš inventár infraštruktúry je teraz presný. Keď sa niekto opýta: "Akých pracovníkov prevádzkujeme?" môžeme skutočne odpovedať na túto otázku s istotou. Konverzácie pri pripájaní sa tiež zjednodušili. Noví inžinieri nenarážajú na záhadné procesy a nepremýšľajú, či im nechýba kontext. Kódová základňa odráža to, čo v skutočnosti robíme, nie to, čo sme robili pred piatimi rokmi. Považujte refaktory za archeológiu a prevenciu Môj najväčší prínos z tohto projektu: každý významný refaktor je príležitosťou pre archeológiu. Keď ste hlboko v systéme a skutočne rozumiete tomu, ako sa jednotlivé časti spájajú, ste v perfektnej pozícii, aby ste si položili otázku, čo je ešte potrebné. Ten front z nejakého starého projektu? Pracovník, ktorý niekto vytvoril na jednorazovú migráciu údajov? Plánovaná úloha, ktorá odkazuje na funkciu, o ktorej ste nikdy nepočuli? Môžu byť stále spustené. Tu je to, čo zabudovávame do nášho procesu v budúcnosti: Pri akomkoľvek refaktorovaní sa opýtajte: čo ešte ovplyvňuje tento systém, na ktorý sme sa dlho nepozerali? Keď zavrhujete funkciu, sledujte ju až po procesy na pozadí, nielen kód pre používateľa. Keď niekto opustí tím, zdokumentujte, čo mal na starosti našu základňu kódu, najmä tie časti, ktoré sme ešte spustili v migrácii na pozadí. zatiaľ jediné úložisko. Ako pokračujeme v konsolidácii, sme si istí, že nájdeme viac týchto skrytých relikvií. Teraz sme však pripravení ich zachytiť a zabrániť vzniku nových. Keď je celý váš kód na jednom mieste, osirotená infraštruktúra sa nemá kam skryť.

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