Pangembang saka Mars, admin saka Venus

Kebetulan iku acak, lan pancen ana ing planet liya ...

Aku pengin nuduhake telung crita sukses lan gagal babagan carane pangembang backend bisa kerja ing tim karo admin.

Sajarah pisanan.
Studio web, jumlah karyawan bisa diitung nganggo tangan siji. Dina iki sampeyan dadi desainer tata letak, sesuk sampeyan dadi backender, sesuk sampeyan dadi admin. Ing tangan siji, sampeyan bisa entuk pengalaman sing luar biasa. Ing sisih liya, ana kekurangan kompetensi ing kabeh wilayah. Aku isih ngelingi dina pisanan karya, aku isih ijo, boss ngandika: "Open putty," nanging aku ora ngerti apa iku. Komunikasi karo admin ora kalebu, amarga sampeyan admin dhewe. Ayo nimbang pros lan cons saka kahanan iki.

+ Kabeh kekuwatan ana ing tanganmu.
+ Ora perlu njaluk sapa wae kanggo ngakses server.
+ Wektu reaksi cepet ing kabeh arah.
+ Nambah katrampilan kanthi apik.
+ Nduwe pangerten lengkap babagan arsitektur produk.

- Tanggung jawab dhuwur.
- Risiko rusak produksi.
- Iku angel dadi spesialis apik ing kabeh wilayah.

Ora kasengsem, ayo nerusake

Crita kapindho.
Perusahaan gedhe, proyek gedhe. Ana departemen administrasi kanthi 5-7 karyawan lan sawetara klompok pangembangan. Nalika sampeyan kerja ing perusahaan kasebut, saben admin mikir yen sampeyan ora teka ing kene kanggo nggarap produk, nanging kanggo ngrusak barang. NDA sing ditandatangani utawa pilihan ing wawancara ora nuduhake liya. Ora, wong iki teka kene karo tangan reged sethitik kanggo ngrusak produksi kissing kita. Mulane, karo wong kuwi sampeyan kudu minimal komunikasi, paling ora, sampeyan bisa uncalan stiker kanggo nanggepi. Aja mangsuli pitakon babagan arsitektur proyek. Disaranake ora menehi akses nganti pimpinan tim takon. Lan nalika dheweke njaluk, dheweke bakal menehi maneh kanthi hak istimewa sing luwih sithik tinimbang sing dijaluk. Meh kabeh komunikasi karo admin kuwi diserep dening bolongan ireng antarane departemen pembangunan lan departemen administrasi. Ora mungkin kanggo ngrampungake masalah kanthi cepet. Nanging sampeyan ora bisa teka langsung - admin sibuk banget 24/7. (Apa sing sampeyan tindakake kabeh wektu?) Sawetara karakteristik kinerja:

• Wektu penyebaran rata-rata kanggo produksi yaiku 4-5 jam
• Wektu panyebaran maksimal ing produksi 9 jam
• Kanggo pangembang, aplikasi ing produksi minangka kothak ireng, kaya server produksi dhewe. Pira jumlahe?
• Kualitas rilis sing kurang, kesalahan sing kerep
• Pangembang ora melu ing proses rilis

Ya, apa sing dakkarepake, mesthine wong anyar ora diidini produksi. Inggih, oke, sawise gained sabar, kita miwiti kanggo gain dateng wong liya. Nanging sakperangan alesan, iku ora dadi prasaja karo admin.

Tumindak 1. Admin ora katon.
Dina rilis, pangembang lan admin ora komunikasi. Admin ora duwe pitakon. Nanging sampeyan ngerti kok mengko. Admin iku wong sing prinsip, ora duwe utusan, ora menehi nomer telpon marang sapa wae, lan ora duwe profil ing jaringan sosial. Ora ana foto dheweke ing endi wae, sampeyan katon kaya apa? Kita njagong karo manager tanggung jawab kanggo bab 15 menit ing bewilderment, nyoba kanggo nggawe komunikasi karo Voyager 1 iki, banjur pesen katon ing email perusahaan sing wis rampung. Apa kita arep ngirim surat? Ngapa ora? Trep, ta? Nah, oke, ayo dadi adhem. Prosesi wis ditindakake, ora ana maneh. Waca pesen maneh. "Aku rampung". Apa sampeyan rampung? ngendi? Ing ngendi aku kudu nggoleki sampeyan? Ing kene sampeyan ngerti kenapa 4 jam kanggo dibebasake iku normal. Kita entuk kejutan pangembangan, nanging kita ngrampungake rilis kasebut. Ora ana maneh kepinginan kanggo ngeculake.

Tumindak 2. Ora versi sing.
Rilis sabanjure. Sawise entuk pengalaman, kita miwiti nggawe dhaptar piranti lunak lan perpustakaan sing dibutuhake kanggo server kanggo pangurus, nuduhake versi kanggo sawetara. Minangka tansah, kita nampa sinyal radio banget sing admin wis rampung soko ana. Tes kemunduran diwiwiti, sing njupuk kira-kira jam. Kabeh katon bisa digunakake, nanging ana siji bug kritis. Fungsi penting ora bisa digunakake. Ing sawetara jam sabanjuré padha nari karo rebana, rejeki-meramal ing latar warung, lan review rinci saben Piece saka kode. Admin ngomong wis rampung kabeh. Aplikasi sing ditulis dening pangembang bengkong ora bisa digunakake, nanging server bisa digunakake. Apa ana pitakonan kanggo dheweke? Ing pungkasan jam, kita njaluk admin kanggo ngirim versi perpustakaan ing server produksi menyang chatting lan bingo - iku ora siji kita kudu. Kita njaluk administrator nginstal versi sing dibutuhake, nanging kanggo nanggepi dheweke ora bisa nindakake iki amarga ora ana versi kasebut ing manajer paket OS. Ing kene, saka recesses memori, manager ngelingi sing admin liyane wis ditanggulangi masalah iki dening mung assembling versi dibutuhake dening tangan. Nanging ora, kita ora bakal nindakake iki. Peraturan nglarang. Karl, kita wis lungguh kene sawetara jam, apa watesan wektu?! We njaluk kejut liyane lan piye wae rampung release.

Tumindak 3, singkat
Tiket cepet, fungsi tombol ora bisa digunakake kanggo salah sawijining pangguna ing produksi. We nglampahi saperangan jam poking lan mriksa. Ing lingkungan pangembangan, kabeh bisa digunakake. Ana pangerten sing jelas yen bakal dadi ide sing apik kanggo ndeleng log php-fpm. Ora ana sistem log kaya ELK utawa Prometheus ing proyek kasebut nalika iku. Kita mbukak tiket menyang departemen administrasi supaya menehi akses menyang log php-fpm ing server. Kene sampeyan kudu ngerti sing kita njaluk akses kanggo alesan, apa sampeyan ora ngelingi bab bolongan ireng lan admin sibuk 24/7? Yen sampeyan takon dheweke ndeleng log dhewe, mula iki minangka tugas kanthi prioritas "ora ana ing urip iki". Tiket digawe, kita nampa respon cepet saka kepala departemen administrasi: "Sampeyan ora perlu akses menyang log produksi, nulis tanpa kewan omo." Tirai.

Tumindak 4 lan sabanjure
Kita isih nglumpukake puluhan masalah ing produksi, amarga macem-macem versi perpustakaan, piranti lunak sing ora dikonfigurasi, beban server sing ora disiapake, lan masalah liyane. Mesthi, ana uga kewan omo kode, kita ora bakal nyalahke admin kanggo kabeh dosa, kita mung bakal sebutno siji operasi liyane khas kanggo project sing. Kita duwe cukup akeh buruh latar mburi sing diluncurake liwat pengawas, lan sawetara skrip kudu ditambahake menyang cron. Kadhangkala buruh sing padha mandheg kerja. Beban ing server antrian tansaya cepet, lan kedhaftar sedih katon ing loader Spinning. Kanggo ndandani buruh kasebut kanthi cepet, cukup kanggo miwiti maneh, nanging maneh, mung administrator sing bisa nindakake iki. Nalika operasi dhasar kasebut ditindakake, sedina muput bisa liwati. Ing kene, mesthine kudu dicathet yen programer bengkong kudu nulis buruh supaya ora nabrak, nanging nalika tiba, luwih becik ngerti sebabe, sing kadhangkala ora mungkin amarga ora duwe akses menyang produksi, saka mesthi, lan minangka akibat, lack of log saka pangembang.

Transfigurasi.
Sawise nandhang kabeh iki cukup suwe, bebarengan karo tim kita wiwit ngarahake arah sing luwih sukses kanggo kita. Kanggo ngringkes, masalah apa sing kita adhepi?

• Kurang komunikasi kualitas antarane pangembang lan departemen administrasi
• Administrator, ternyata (!), Ora ngerti kabeh carane aplikasi wis kabentuk, dependensi apa lan cara kerjane.
• Pangembang ora ngerti cara kerja lingkungan produksi lan, minangka asil, ora bisa nanggapi masalah kanthi efektif.
• Proses penyebaran njupuk dawa banget.
• Rilis sing ora stabil.

Apa sing wis kita lakoni?
Kanggo saben rilis, dhaptar Cathetan Rilis digawe, sing kalebu dhaptar karya sing kudu ditindakake ing server supaya rilis sabanjure bisa digunakake. Dhaptar kasebut ngemot sawetara bagean, pakaryan sing kudu ditindakake dening administrator, wong sing tanggung jawab kanggo rilis, lan pangembang. Pangembang nampa akses non-root menyang kabeh server produksi, sing nyepetake pembangunan ing umum lan pemecahan masalah khusus. Pangembang uga duwe pangerten babagan cara produksi, layanan apa sing dipérang, ing ngendi lan pira rega replika. Sawetara beban pertempuran dadi luwih jelas, sing mesthi mengaruhi kualitas kode kasebut. Komunikasi sajrone proses rilis dumadi ing obrolan salah sawijining utusan instan. Kaping pisanan, kita duwe log kabeh tumindak, lan nomer loro, komunikasi ditindakake ing lingkungan sing luwih cedhak. Duwe riwayat tumindak luwih saka sepisan ngidini karyawan anyar ngatasi masalah kanthi luwih cepet. Iki minangka paradoks, nanging iki asring mbantu para admin dhewe. Aku ora bakal ngandika manawa, nanging misale jek kula sing admins wis wiwit ngerti liyane carane project bisa lan carane iku ditulis. Kadhangkala kita malah nuduhake sawetara rincian karo saben liyane. Wektu rilis rata-rata wis suda dadi jam. Kadhangkala kita rampung ing 30-40 menit. Jumlah kewan omo wis suda banget, yen ora kaping sepuluh. Mesthine, faktor liya uga nyebabake nyuda wektu rilis, kayata autotes. Sawise saben rilis, kita wiwit nindakake retrospektif. Supaya kabeh tim duwe gagasan babagan apa sing anyar, apa sing diganti, lan apa sing wis dibusak. Sayange, admin ora tansah teka, wah, admin sibuk ... Kepuasan kerja minangka developer mesthi saya mundhak. Yen sampeyan bisa ngrampungake meh kabeh masalah sing ana ing area kompetensi sampeyan, sampeyan rumangsa paling dhuwur. Mengko, aku bakal ngerti sing kanggo sawetara ombone kita ngenalaken budaya devops, ora rampung, mesthi, nanging malah awal transformasi iki nyengsemaken.

Crita telu
wiwitan. Siji admin, departemen pangembangan cilik. Sawise tekan aku nol lengkap, amarga ... Aku ora duwe akses ing ngendi wae kajaba saka mail. Kita nulis menyang admin lan njaluk akses. Kajaba iku, ana informasi manawa dheweke ngerti babagan karyawan anyar lan kudu ngetokake login / sandhi. Dheweke menehi akses saka repositori lan VPN. Napa menehi akses menyang wiki, teamcity, rundesk? Ora ana gunane kanggo wong sing diarani nulis kabeh bagean mburi. Mung liwat wektu kita entuk akses menyang sawetara alat. Tekane, mesthi, ditemoni kanthi ora percaya. Aku nyoba alon-alon ngrasakake cara kerja infrastruktur proyek liwat obrolan lan pitakon utama. Sejatine aku ora ngerti apa-apa. Produksi kothak ireng padha karo sadurunge. Nanging luwih saka iku, malah server panggung sing digunakake kanggo testing minangka kothak ireng. Kita ora bisa nindakake apa-apa kajaba nyebarake cabang saka Git ing kana. Kita uga ora bisa ngatur aplikasi kaya file .env. Akses kanggo operasi kasebut ora diwenehake. Sampeyan kudu njaluk supaya baris diganti ing config aplikasi ing server test. (Ana téori sing penting kanggo para admin ngrasa penting ing proyek kasebut; yen ora dijaluk ngganti garis ing konfigurasi, mula ora dibutuhake). Inggih, kaya biasane, apa ora trep? Iki cepet mboseni, sawise ngobrol langsung karo admin, kita ngerteni manawa para pangembang lair kanggo nulis kode sing ora apik, minangka individu sing ora kompeten lan luwih apik kanggo njaga saka produksi. Nanging kene uga saka server test, mung ing kasus. Konflik kasebut kanthi cepet mundhak. Ora ana komunikasi karo admin. Kahanan kasebut saya tambah parah amarga dheweke dhewekan. Ing ngisor iki minangka gambar khas. Ngeculake. Fungsi tartamtu ora bisa digunakake. Butuh wektu suwe kanggo ngerteni apa sing kedadeyan, macem-macem ide saka pangembang dibuwang menyang obrolan, nanging admin ing kahanan kaya ngono biasane nganggep manawa pangembang kudu disalahake. Banjur dheweke nulis ing obrolan, ngenteni, aku mbenerake dheweke. Nalika dijaluk ninggalake crita kanthi informasi babagan masalahe, kita nampa alesan beracun. Kaya, aja nempelake irung ing papan sing ora cocog. Pangembang kudu nulis kode. Kahanan nalika akeh gerakan awak ing sawijining proyek ngliwati siji wong lan mung dheweke duwe akses kanggo nindakake operasi sing dibutuhake kabeh wong pancen sedhih. Wong sing kaya mengkono iku bottleneck sing elek. Yen ide Devops ngupayakake nyuda wektu-kanggo-pasar, mula wong-wong kuwi minangka mungsuh paling gedhe saka ide Devops. Sayange, sandiworo nutup kene.

PS Sawise ngomong sethitik babagan pangembang vs admin ing chats karo wong, Aku ketemu wong sing nuduhake pain sandi. Nanging uga ana sing kandha yen durung nate nemoni kahanan kaya ngene iki. Ing salah sawijining konferensi devops, aku takon Anton Isanin (Alfa Bank) kepiye cara ngatasi masalah bottleneck ing bentuk admin, sing ujar: "Kita ngganti tombol kasebut." Miturut cara podcast karo partisipasine. Aku kaya pracaya sing ana akeh admin luwih apik saka mungsuh. Lan ya, gambar ing wiwitan minangka korespondensi nyata.

Sumber: www.habr.com