Baru-baru ini kami memulai proyek kecil untuk membersihkan cara bagian-bagian sistem kami berkomunikasi di balik layar di Buffer. Beberapa konteks singkat: kami menggunakan sesuatu yang disebut SQS (Amazon Simple Queue Service. Antrean ini bertindak seperti ruang tunggu untuk tugas. Salah satu bagian dari sistem kami mengirimkan pesan, dan bagian lain mengambilnya nanti. Anggap saja seperti meninggalkan pesan untuk rekan kerja: "Hai, jika Anda mendapat kesempatan, proses data ini." Sistem yang mengirimkan catatan tidak perlu menunggu tanggapan. Proyek kami adalah untuk melakukan pemeliharaan rutin: memperbarui alat yang kami gunakan untuk menguji antrean secara lokal dan membersihkan konfigurasinya. Namun saat kami memetakan antrean apa yang sebenarnya kami gunakan, kami menemukan sesuatu yang tidak kami harapkan: tujuh proses latar belakang yang berbeda (atau tugas cron, yang merupakan tugas terjadwal yang berjalan secara otomatis) dan pekerja yang telah berjalan secara diam-diam hingga lima tahun. Semuanya sama sekali tidak melakukan apa pun yang berguna. Inilah alasannya hal itu penting, cara kami menemukannya, dan apa yang kami lakukan untuk mengatasinya. Mengapa hal ini lebih penting daripada yang Anda kira Ya, menjalankan biaya infrastruktur yang tidak perlu uang. Saya melakukan perhitungan cepat dan untuk salah satu pekerja tersebut, kami akan membayar ~$360-600 selama 5 tahun. Ini adalah jumlah yang tidak seberapa dalam skema besar keuangan kami, namun jelas merupakan pemborosan untuk proses yang tidak menghasilkan apa-apa. Namun, setelah melalui pembersihan ini, menurut saya biaya finansial sebenarnya adalah bagian terkecil dari masalahnya. Setiap kali seorang insinyur baru bergabung dengan tim dan menjelajahi sistem kami, mereka menghadapi proses misterius ini. "Apa yang dilakukan pekerja ini?" waktu orientasi dan menciptakan ketidakpastian. Kita semua pernah mengalaminya — menatap sepotong kode, takut untuk menyentuhnya karena mungkin melakukan sesuatu yang penting. Bahkan infrastruktur yang "terlupakan" terkadang memerlukan perhatian. Pembaruan keamanan, peningkatan ketergantungan, perbaikan kompatibilitas ketika ada perubahan lain. Hal ini menyebabkan tim kami menghabiskan siklus pemeliharaan pada jalur kode yang tidak ada gunanya. Dan seiring berjalannya waktu, pengetahuan institusional memudar. Apakah ini perbaikan sementara yang menjadi permanen? mereka.Bagaimana hal ini bisa terjadi?Sangat mudah untuk menuding, namun kenyataannya hal ini terjadi secara alami dalam sistem yang berumur panjang.Sebuah fitur tidak digunakan lagi, namun pekerjaan latar belakang yang mendukungnya tetap berjalan. Seseorang menjalankan pekerja "sementara" untuk menangani migrasi, dan itu tidak pernah dirobohkan. Tugas yang dijadwalkan menjadi mubazir setelah perubahan arsitektur, tetapi tidak ada yang berpikir untuk memeriksanya. Kami biasa mengirim email perayaan ulang tahun di Buffer ulang tahun yang cocok dengan tanggal saat ini dan mengirimkan email yang dipersonalisasi kepada pelanggan. Selama refactor pada tahun 2020, kami mengganti alat email transaksional kami tetapi lupa menghapus pekerja ini—pekerja ini terus berjalan selama lima tahun berikutnya. Tidak ada satu pun dari hal ini yang merupakan kegagalan individu — ini adalah kegagalan proses. Tanpa pembersihan yang disengaja dalam cara kami bekerja, entropilah yang menang. Bagaimana arsitektur kami membantu kami menemukannya lalu. Kami membagi monolit kami menjadi beberapa layanan terpisah, yang masing-masing memiliki repositori, jalur penerapan, dan infrastrukturnya sendiri. Pada saat itu, hal ini masuk akal: setiap layanan dapat diterapkan sendiri-sendiri, dengan batasan yang jelas antar tim. Namun selama bertahun-tahun, kami mendapati bahwa biaya yang dikeluarkan untuk mengelola lusinan repositori melebihi manfaatnya bagi tim sebesar kami. Jadi, kami menggabungkannya ke dalam repositori tunggal multi-layanan. Layanan-layanan tersebut masih ada sebagai batasan yang logis, namun tetap ada di satu tempat. Hal inilah yang memungkinkan penemuan. Di dunia layanan mikro, setiap repositori memiliki pulau tersendiri. Pekerja yang terlupakan dalam satu repositori mungkin tidak akan pernah diketahui oleh teknisi yang bekerja di repositori lain. Tidak ada satu tempat pun untuk mencari nama antrean, tidak ada pandangan terpadu tentang apa yang sedang berjalan. Dengan semua yang ada di satu repositori, kami akhirnya dapat melihat gambaran lengkapnya. Kami dapat melacak setiap antrean hingga ke konsumen dan produsennya. Kami dapat menemukan antrean dengan produsen, namun tidak ada konsumen yang merujuk ke antrean yang sudah tidak ada lagi.penemuan hampir tidak bisa dihindari. Apa yang sebenarnya kami lakukan Setelah kami mengidentifikasi proses yang tidak ada lagi, kami harus memutuskan apa yang harus dilakukan terhadap proses tersebut. Begini cara kami mendekatinya. Pertama, kami menelusuri asal-usulnya masing-masing. Kami menggali sejarah git dan dokumentasi lama untuk memahami alasan setiap pekerja diciptakan. Dalam kebanyakan kasus, tujuan awalnya sudah jelas: migrasi data satu kali, fitur yang dihentikan, solusi sementara yang sudah tidak berguna lagi. Lalu kami mengonfirmasi bahwa fitur tersebut benar-benar tidak digunakan. Sebelum menghapus apa pun, kami menambahkan logging untuk memverifikasi bahwa proses ini tidak secara diam-diam melakukan sesuatu yang penting yang kami lewatkan. Kami memantau selama beberapa hari untuk memastikan mereka tidak dipanggil sama sekali, dan kami menghapusnya secara bertahap. Kami tidak menghapus semuanya sekaligus. Kami menghapus proses satu per satu, mengamati efek samping yang tidak terduga. (Untungnya, tidak ada.) Akhirnya, kami mendokumentasikan apa yang kami pelajari. Kami menambahkan catatan ke dokumen internal kami tentang apa saja yang dilakukan setiap proses pada awalnya dan mengapa proses tersebut dihapus, sehingga teknisi di masa depan tidak akan bertanya-tanya apakah ada sesuatu yang penting yang hilang. Apa yang berubah setelah pembersihan? Kami masih dalam tahap awal dalam mengukur dampak keseluruhannya, namun inilah yang telah kami lihat sejauh ini. Inventaris infrastruktur kami sekarang sudah akurat. Saat seseorang bertanya, "Pekerja apa yang kami jalankan?" kami sebenarnya dapat menjawab pertanyaan itu dengan percaya diri. Percakapan orientasi juga menjadi lebih sederhana. Insinyur baru tidak menemukan proses misterius dan bertanya-tanya apakah proses tersebut kehilangan konteks. Basis kode mencerminkan apa yang sebenarnya kami lakukan, bukan apa yang kami lakukan lima tahun lalu. Perlakukan refactor sebagai arkeologi dan pencegahan Hal terbesar yang dapat saya ambil dari proyek ini: setiap refactor yang signifikan adalah peluang untuk arkeologi. Ketika Anda mendalami suatu sistem, benar-benar memahami bagaimana bagian-bagiannya terhubung, Anda berada dalam posisi yang tepat untuk mempertanyakan apa yang masih dibutuhkan. Antrian dari proyek lama itu? Pekerja yang dibuat seseorang untuk migrasi data satu kali? Tugas terjadwal yang merujuk pada fitur yang belum pernah Anda dengar? Mereka mungkin masih berjalan. Inilah yang sedang kami kembangkan dalam proses kami ke depan: Selama pemfaktoran ulang apa pun, tanyakan: apa lagi yang mempengaruhi sistem ini yang sudah lama tidak kita lihat? Saat menghentikan fitur, lacak fitur tersebut hingga ke proses latar belakangnya, bukan hanya kode yang dilihat pengguna. Saat seseorang keluar dari tim, dokumentasikan apa yang menjadi tanggung jawabnya, terutama hal-hal yang berjalan di latar belakang. Kami masih memiliki bagian lama dari basis kode kami yang belum dimigrasikan ke repositori tunggal. Saat kami terus melakukan konsolidasi, kami yakin akan menemukan lebih banyak peninggalan tersembunyi ini. Namun sekarang kami siap untuk menangkap mereka dan mencegah terbentuknya kode baru. Ketika semua kode Anda berada di satu tempat, infrastruktur yang tidak ada lagi tidak akan bisa bersembunyi.
Apa yang Kami Pelajari Setelah Menemukan 7 Pekerjaan yang Terlupakan Selama 5 Tahun
By Social Media
·
·
6 min read
·
552 views
Read in:
aa
ace
af
ak
alz
am
ar
as
awa
ay
az
ba
ban
be
bew
+191 more
bg
bho
bik
bm
bn
brx
bs
bug
ca
ceb
cgg
ckb
co
crh
cs
cv
cy
da
de
din
doi
dv
dyu
dz
ee
el
en
eo
es
et
eu
fa
ff
fi
fj
fo
fr
fur
fy
ga
gd
gl
gom
gn
gu
ha
haw
he
hi
hil
hne
hmn
hr
hrx
ht
hu
hy
id
ig
ilo
is
it
ja
jam
jv
ka
kab
kbp
kg
kha
kk
kl
km
kn
ko
kri
ku
ktu
ky
la
lb
lg
li
lij
ln
lo
lmo
lt
ltg
lua
luo
lus
lv
mai
mak
mg
mi
min
mk
ml
mn
mni-mtei
mos
mr
ms
mt
my
nd
ne
nl
nn
no
nr
nso
nus
ny
oc
om
or
pa
pag
pam
pap
pl
ps
pt
pt-br
qu
rn
ro
ru
rw
sa
sah
sat
sc
scn
sg
si
sk
sl
sm
sn
so
sq
sr
ss
st
su
sus
sv
sw
szl
ta
tcy
te
tg
th
ti
tiv
tk
tl
tn
to
tpi
tr
trp
ts
tt
tum
ty
udm
ug
uk
ur
uz
ve
vec
vi
war
wo
xh
yi
yo
yua
yue
zap
zh
zh-hk
zh-tw
zu
