Nesen mēs sākām nelielu projektu, lai iztīrītu to, kā mūsu sistēmu daļas sazinās aizkulisēs buferī. Īss konteksts: mēs izmantojam kaut ko, ko sauc par SQS (Amazon Simple Queue Service. Šīs rindas darbojas kā uzdevumu uzgaidāmās telpas. Viena mūsu sistēmas daļa nosūta ziņojumu, bet cita to paņem vēlāk. Padomājiet par to kā atstāt piezīmi kolēģim: "Hei, sistēma, ja jums ir iespēja nosūtīt šo piezīmi." gaidiet atbildi.Mūsu projekts paredzēja veikt kārtējo apkopi: atjaunināt rīkus, ko izmantojam, lai pārbaudītu rindas lokāli un notīrītu to konfigurāciju.Bet, plānojot, kādas rindas mēs faktiski izmantojam, mēs atradām kaut ko negaidāmu: septiņus dažādus fona procesus (vai cron darbus, kas ir ieplānoti uzdevumi, kas tiek izpildīti automātiski) un darbinieki, kas bija palaiduši klusi, kāpēc mēs tos nedarām līdz pieciem gadiem un ko mēs ar to darījām.Kāpēc tam ir lielāka nozīme, nekā jūs domājatJā, es veicu ātru aprēķinu, un par vienu no šiem darbiniekiem mēs būtu samaksājuši aptuveni 360–600 ASV dolārus 5 gadu laikā. Tā ir pieticīga summa mūsu lielajā finanšu shēmā, taču tā noteikti ir tīri izšķērdība procesam, kas nesniedz neko. problēma.Katru reizi, kad komandai pievienojas jauns inženieris, viņi saskaras ar šiem noslēpumainajiem procesiem. "Ko šis darbinieks dara?" Tas noveda pie tā, ka mūsu komanda tērēja apkopes ciklus, kam nebija nozīmes. Un ar laiku iestādes zināšanas izzūd. Vai tas bija pagaidu risinājums, kas to izveidoja pirms vairākiem gadiem, un konteksts viņiem palika. Palaižot, kāds “uz laiku” paceļ darbinieku, lai veiktu migrēšanu, un tas nekad netiek nojaukts. Ieplānots uzdevums kļūst lieks pēc arhitektūras izmaiņām. Mēs izmantojām dzimšanas dienas svinību e-pasta ziņojumus buferī darījumu e-pasta rīks, taču aizmirsu noņemt šo darbinieku — tas darbojās vēl piecus gadus. Neviena no tām nav atsevišķu personu kļūmes — tās ir procesa kļūmes. Bez tīšas tīrīšanas, kas ir iebūvēta mūsu darbā, uzvar entropija.Kā mūsu arhitektūra mums palīdzēja to atrast Tāpat kā daudzi uzņēmumi, Buffer izmantoja mikropakalpojumu kustību (populāru pieeju, kurā mēs sadalījām savus pakalpojumus pirms daudziem gadiem, sadalot savus pakalpojumus). Katram ar savu krātuvi, izvietošanas konveijeru un infrastruktūru. Toreiz tas bija loģiski: katru pakalpojumu varēja izvietot atsevišķi, nosakot skaidras robežas starp komandām. Taču gadu gaitā mēs atklājām, ka mūsu lieluma komandai ir vairāk nekā viena krātuve Vieta.Izrādījās, ka tas bija iespējams. Mikropakalpojumu pasaulē katrs aizmirsts darbinieks, kas strādā citā, nekad nepamanīs. Nav vienas vietas, kur meklēt rindu nosaukumus, nav vienota skatījuma uz to, kas darbojas. Mēs beidzot varētu redzēt visu Pamanīt rindas pie ražotājiem, bet bez patērētājiem Mēs varējām atrast darbiniekus, kas atsaucas uz rindām, kuras vairs nepastāvēja. Konsolidācija nebija paredzēta, lai palīdzētu mums atrast zombiju infrastruktūru, taču tā to padarīja.atklājums gandrīz neizbēgams.Ko mēs patiesībā darījām Kad bijām identificējuši bezsaimnieka procesus, mums bija jāizlemj, ko ar tiem darīt. Lūk, kā mēs to piegājām. Pirmkārt, mēs katrai noskaidrojām tā izcelsmi. Mēs izpētījām git vēsturi un veco dokumentāciju, lai saprastu, kāpēc katrs darbinieks tika izveidots. Vairumā gadījumu sākotnējais mērķis bija skaidrs: vienreizēja datu migrēšana, funkcija, kas tika pārtraukta, pagaidu risinājums, kas savu lietderību pārdzīvoja. Pēc tam mēs apstiprinājām, ka tie patiešām nav izmantoti. Pirms kaut kā noņemšanas mēs pievienojām reģistrēšanu, lai pārbaudītu, vai šie procesi mierīgi neveic kaut ko svarīgu, ko bijām palaiduši garām. Mēs novērojām dažas dienas, lai pārliecinātos, ka viņiem vispār netiek piezvanīts, un pakāpeniski tos noņēmām. Mēs neizdzēsām visu uzreiz. Mēs noņēmām procesus pa vienam, vērojot neparedzētas blakusparādības. (Par laimi, tādu nebija.) Visbeidzot, mēs dokumentējām to, ko uzzinājām. Mēs pievienojām piezīmes saviem iekšējiem dokumentiem par to, ko katrs process sākotnēji bija paveicis un kāpēc tas tika noņemts, lai nākamie inženieri nebrīnītos, ja kaut kas svarīgs ir pazudis.Kas mainījās pēc tīrīšanas Mēs vēl tikai sākam mērīt pilnu ietekmi, taču līdz šim ir redzams, ko esam redzējuši. Mūsu infrastruktūras inventarizācija tagad ir precīza. Kad kāds jautā: "Kādus strādniekus mēs vadām?" mēs patiešām varam droši atbildēt uz šo jautājumu.Iedarbināšanas sarunas arī ir kļuvušas vienkāršākas. Jaunie inženieri neklūp pa noslēpumainiem procesiem un nedomā, vai viņiem trūkst konteksta. Kodu bāze atspoguļo to, ko mēs patiesībā darām, nevis to, ko darījām pirms pieciem gadiem. Uztveriet refaktorus kā arheoloģiju un profilaksi. Mans lielākais ieguvums no šī projekta: katrs nozīmīgais faktors ir iespēja arheoloģijai. Kad esat dziļi iedziļinājies sistēmā un patiešām saprotat, kā detaļas savienojas, varat apšaubīt, kas joprojām ir nepieciešams. Tā rinda no kāda veca projekta? Darbinieks, ko kāds izveidoja vienreizējai datu migrācijai? Ieplānotais uzdevums, kas atsaucas uz līdzekli, par kuru jūs nekad neesat dzirdējis? Tie, iespējams, joprojām darbojas. Lūk, ko mēs iestrādājam savā turpmākajā procesā: jebkuras pārveidošanas laikā jautājiet: kas vēl skar šo sistēmu, ko mēs kādu laiku neesam skatījuši?Kad pārtraucat funkcijas darbību, izsekojiet to līdz fona procesiem, nevis tikai lietotājam paredzētajam kodam. Kad kāds pamet komandu, dokumentējiet, par ko viņš bija atbildīgs, jo īpaši vecajās mūsu koda daļās, kas joprojām darbojas. vēl ir migrēts uz vienu repozitoriju. Turpinot konsolidāciju, mēs esam pārliecināti, ka atradīsim vairāk šo slēpto relikviju. Taču tagad mēs esam izveidoti, lai tos notvertu un novērstu jaunu veidošanos. Kad viss jūsu kods atrodas vienuviet, bāreņu infrastruktūrai nav kur slēpties.

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