Hiljuti alustasime väikese projektiga, et puhastada meie süsteemide osade puhvris kulisside taga suhtlemist. Väike kontekst: kasutame SQS-i (Amazon Simple Queue Service. Need järjekorrad toimivad ülesannete ooteruumidena. Üks osa meie süsteemist saadab sõnumi ja teine võtab selle hiljem üles. Mõelge sellele, nagu jätaksite märkme töökaaslasele: "Hei, süsteem, kui teil on võimalus saada see andmed." ootame vastust.Meie projekti eesmärk oli teostada rutiinset hooldust: värskendada tööriistu, mida kasutame järjekordade kohapeal testimiseks ja nende konfiguratsiooni puhastamiseks.Kuid kaardistasime, milliseid järjekordi me tegelikult kasutame, leidsime midagi, mida me ei oodanud: seitse erinevat taustaprotsessi (või cron-tööd, mis on ajastatud toimingud, mis käivad automaatselt) ja töötajad, kes olid töötanud vaikselt kuni viis aastat neid ja mida me sellega tegime.Miks see on olulisem, kui arvate?Jah, tarbetu infrastruktuuri käitamine maksab, tegin kiire arvutuse ja me oleksime maksnud 5 aasta jooksul ~360–600 dollarit. See on meie rahanduse suures plaanis tagasihoidlik summa, kuid tegelikult on see puhas raiskamine protsessi eest, mis ei tee sellest puhastamisest midagi. Iga kord, kui uus insener liitub meeskonnaga ja uurib meie süsteeme, puutuvad nad kokku nende salapäraste protsessidega. "Mida see töötaja teeb?" See viis selleni, et meie meeskond kulutas hooldustsükleid koodiradadele, mis ei teeninud mingit eesmärki. Kas see oli ajutine lahendus, mis sai ettevõttest aastaid tagasi ja kontekst jäi temaga. Kuidas see üldse juhtub? töötab keegi, et migratsiooniga toime tulla ja see ei katke kunagi. Ajastatud ülesanne muutub pärast arhitektuurilist muudatust üleliigseks, kuid keegi ei mõtle seda kontrollida. Selleks käivitasime ajastatud ülesande, mis kontrollis kogu andmebaasi sünnipäevade kohta, mis vastavad meie praegusele kuupäevale20 tehingute e-posti tööriist, kuid unustas selle töötaja eemaldada – see töötas veel viis aastat. Ükski neist ei ole üksikisikute tõrge – need on protsessi tõrkeid, kui meie töösse ei ole sisse ehitatud tahtlikku puhastust, võidab entroopia.Kuidas meie arhitektuur aitas meil seda leida.Nagu paljud ettevõtted, võttis puhver omaks mikroteenuste liikumise (populaarne lähenemine, kus ettevõtted jagasime oma teenused aastaid tagasi, jagasime oma teenused paljudeks osadeks. Igaühel neist oli oma hoidla, juurutamistoru ja infrastruktuur. Sel ajal oli see loogiline: iga teenust sai kasutusele võtta eraldiseisvate meeskondade vahel. Kuid aastate jooksul avastasime, et kümnete hoidlate haldamise kulud kaalusid üles meie suuruse meeskonna jaoks See osutus võimalikuks. Mikroteenuste maailmas on ühes repostooriumis unustatud töötajat teises töötavad insenerid tuvastada järjekorrad tootjatega, kuid mitte tarbijaid. Võisime leida töötajaid, kes viitasid järjekordadele, mida enam ei eksisteerinud. Konsolideerimise eesmärk ei olnud aidata meil leida zombie infrastruktuuri, kuid see tegi seda.avastus on peaaegu vältimatu. Mida me tegelikult tegime Kui orb protsessid tuvastasime, pidime otsustama, mida nendega peale hakata. Sellele lähenesime järgmiselt. Esiteks leidsime igaühe päritolu. Kaevasime läbi giti ajaloo ja vana dokumentatsiooni, et mõista, miks iga töötaja üldse loodi. Enamikul juhtudel oli algne eesmärk selge: ühekordne andmete üleviimine, funktsioon, mis loojus, ajutine lahendus, mis oli oma aja ära elanud. Seejärel kinnitasime, et need on tõesti kasutamata. Enne millegi eemaldamist lisasime logimise, et kontrollida, kas need protsessid ei tee vaikselt midagi olulist, millest me ilma jäime. Jälgisime paar päeva, et veenduda, et neile üldse ei helistatud, ja eemaldasime need järk-järgult. Me ei kustutanud kõike korraga. Eemaldasime protsessid ükshaaval, jälgides ootamatuid kõrvalmõjusid. (Õnneks neid ei olnud.) Lõpuks dokumenteerisime õpitu. Lisasime oma sisemistesse dokumentidesse märkused selle kohta, mida iga protsess oli algselt teinud ja miks see eemaldati, et tulevased insenerid ei imestaks, kui midagi olulist kaotsi läheb.Mis muutus pärast puhastamist Oleme alles alguses kogu mõju mõõtmisel, kuid siin on see, mida oleme seni näinud.Meie infrastruktuuri inventar on nüüd täpne. Kui keegi küsib: "Mis töötajaid me juhime?" saame tegelikult sellele küsimusele enesekindlalt vastata. Ka vestlusvestlused on muutunud lihtsamaks. Uued insenerid ei komista salapäraste protsesside otsa ega mõtle, kas neil puudub kontekst. Koodibaas kajastab seda, mida me tegelikult teeme, mitte seda, mida me tegime viis aastat tagasi. Käsitlege refaktoreid kui arheoloogiat ja ennetamist.Minu suurim väljavõte sellest projektist: iga oluline refaktor on võimalus arheoloogiale. Kui olete süsteemis sügaval ja mõistate tõeliselt, kuidas osad omavahel ühendavad, on teil suurepärane võimalus küsida, mida veel vaja on. See järjekord mingist vanast projektist? Töötaja, mille keegi lõi ühekordseks andmete migratsiooniks? Ajastatud ülesanne, mis viitab funktsioonile, millest te pole kunagi kuulnud? Need võivad ikka veel töötada.Me arendame oma protsessi edasi järgmiselt.Mistahes refaktori ajal küsige: mis seda süsteemi veel puudutab, mida me pole tükk aega vaadanud?Funktsiooni katkestamisel jälgige seda kuni selle taustaprotsessideni, mitte ainult kasutajale suunatud koodini.Kui keegi meeskonnast lahkub, dokumenteerige, mille eest nad vastutasid, eriti meie koodi vanemates osades, mis veel töötavad. on veel ühtsesse hoidlasse üle viidud. Kui jätkame konsolideerimist, oleme kindlad, et leiame neid peidetud säilmeid veelgi. Kuid nüüd oleme valmis neid püüdma ja takistama uute tekkimist. Kui kogu teie kood on ühes kohas, pole orvuks jäänud infrastruktuuril kuhugi peituda.

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