Kita bubar miwiti proyek cilik kanggo ngresiki carane bagean saka sistem kita komunikasi konco layar ing Buffer. Sawetara konteks cepet: kita nggunakake soko disebut SQS (Amazon Simple Queue Service. Antrian iki tumindak kaya kamar tunggu kanggo tugas. Salah siji bagéan saka sistem kita irungnya mati pesen, lan liyane njupuk munggah mengko. Mikir kaya ninggalake cathetan kanggo rekan kerja: "Hei, yen sampeyan duwe wektu kanggo ngirim data, iki ora ana kesempatan." a respon.Proyèk kita kanggo nindakake pangopènan rutin: nganyari alat sing digunakake kanggo nyoba antrian sacara lokal lan ngresiki konfigurasi. Nanging nalika kita lagi pemetaan apa antrian kita bener nggunakake, kita nemokake soko kita ora nyana: pitu pangolahan latar mburi beda (utawa cron jobs, kang dijadwal tugas sing mlaku kanthi otomatis) lan buruh sing wis mlaku meneng nganti limang taun, apa ora ana gunane Apa iki luwih penting tinimbang sing sampeyan pikirake. Ya, nglakokake prasarana sing ora perlu biaya dhuwit, aku nggawe pitungan kanthi cepet lan kanggo salah sawijining buruh kasebut, kita bakal mbayar ~ $ 360-600 sajrone 5 taun. gabung karo tim lan njelajah sistem kita, padha nemoni proses misterius iki "Apa sing ditindakake dening para pekerja iki?" dadi pitakonan sing mangan wektu onboarding lan nggawe kahanan sing durung mesthi Siklus ing jalur kode sing ora ana gunane. Lan suwe-suwe, kawruh kelembagaan bakal sirna "sementara" kanggo nangani migrasi, lan ora bakal ambruk A tugas dijadwal dadi keluwih sawise owah-owahan arsitektur, nanging ora ana sing mikir kanggo mriksa. Kita digunakake kanggo ngirim email perayaan ulang taun ing Buffer, kita mbukak tugas dijadwal sing mriksa kabeh database kanggo ulang tahun sing cocog karo tanggal saiki lan ngirim email refactor ing .2 buruh iki-iku tetep mlaku limang taun maneh. Ora ana sing gagal saka individu - padha gagal proses Tanpa reresik disengojo dibangun menyang carane kita bisa, entropi menang.Cara arsitektur kita mbantu kita nemokake iku Kaya akeh perusahaan, Buffer nganut gerakan microservices (pendekatan populer ngendi perusahaan pamisah kode menyang akeh layanan cilik lan independen), kita misahake layanan kita dhewe ing sawetara taun kepungkur. Pipa, lan prasarana. Ing wektu iku, ana akal: saben layanan bisa disebarake dhewe, kanthi wates sing jelas ing antarane tim. Nanging sajrone pirang-pirang taun, kita nemokake overhead kanggo ngatur puluhan repositori ngluwihi keuntungan kanggo tim sing ukurane kita dadi siji repositori multi-layanan, nanging bisa ditindakake kanthi langsung. ing donya microservices, saben repositori dhewe-dhewe. A buruh lali ing siji repo bisa uga ora bakal weruh dening engineers sing makarya ing liyane wis ana maneh. Konsolidasi kasebut ora dirancang kanggo mbantu kita nemokake infrastruktur zombie - nanging bisa ditindakakepanemuan meh ora bisa dihindari.Apa sing sejatine kita lakoni Sawise kita ngerteni proses-proses sing yatim piatu, kita kudu mutusake apa sing kudu ditindakake. Mangkene carane kita nyedhaki. Kita ndudhuk sejarah git lan dokumentasi lawas kanggo ngerti sebabe saben pekerja digawe ing wiwitan. Umume kasus, tujuan asli jelas: migrasi data siji-sijine, fitur sing entuk srengenge, solusi sementara sing ora ana gunane. Banjur kita ngonfirmasi yen dheweke pancen ora digunakake. Sadurunge mbusak apa wae, kita nambahake logging kanggo verifikasi proses kasebut ora kanthi tenang nindakake prekara penting sing ora kejawab. We ngawasi kanggo sawetara dina kanggo mesthekake yen padha ora disebut ing kabeh, lan kita dibusak incrementally. Kita ora mbusak kabeh bebarengan. Kita mbusak proses siji-siji, nonton efek samping sing ora dikarepake. (Untung, ora ana.) Pungkasane, kita nyathet apa sing kita sinau. Kita nambahake cathetan ing dokumen internal babagan apa sing saben proses wis rampung lan kenapa dicopot, mula insinyur ing mangsa ngarep ora bakal mikir yen ana sing penting ilang. Apa sing diganti sawise ngresiki. Nalika ana wong takon: "Pegawe apa sing kita lakoni?" kita bisa bener njawab pitakonan sing karo kapercayan.Onboarding obrolan wis tak prasaja, banget. Insinyur anyar ora kesandhung ing proses misterius lan mikir yen ora ana konteks. Basis kode kasebut nggambarake apa sing sejatine kita lakoni, dudu apa sing ditindakake limang taun kepungkur. Nambani refactor minangka arkeologi lan pencegahanKu paling gedhe saka proyek iki: saben refactor sing penting minangka kesempatan kanggo arkeologi. Nalika sampeyan lagi jero ing sistem, ngerti tenan carane potongan kasebut nyambung, sampeyan ana ing posisi sing sampurna kanggo pitakonan apa sing isih dibutuhake. Sing antrian saka sawetara project lawas? Pekerja sing digawe kanggo migrasi data sepisan? Tugas sing dijadwalake sing ngrujuk fitur sing durung tau krungu? Iki bisa uga isih mlaku. Mangkene apa sing bakal ditindakake ing proses maju: Sajrone refactor apa wae, takon: apa maneh ndemek sistem iki sing wis suwe ora kita deleng? Nalika ngilangi fitur kasebut, lacak kabeh menyang proses latar mburi, ora mung kode sing diadhepi pangguna. Nalika ana wong sing ninggalake tim, dokumen apa sing dadi tanggung jawabe, utamane bagean sing isih ana ing latar mburi. wis migrasi menyang repositori siji durung. Nalika kita terus nggabungake, kita yakin bakal nemokake luwih akeh peninggalan sing didhelikake iki. Nanging saiki kita wis siyap kanggo nyekel wong-wong mau lan nyegah sing anyar saka kabentuk.Yen kabeh kode sampeyan manggon ing sak panggonan, infrastruktur yatim piatu ora ana panggonan kanggo ndhelikake.

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