Sugeng rawuh, Habr! Sadurunge, aku ngeluh babagan urip ing Infrastruktur minangka paradigma kode lan ora menehi apa-apa kanggo ngatasi kahanan saiki. Dina iki aku bali kanggo pitutur marang kowe apa pendekatan lan laku sing bakal mbantu uwal saka jurang putus asa lan kemudi kahanan ing arah sing bener.
Ing artikel sadurunge Aku nuduhake kesan babagan wilayah iki, nyoba nggambarake kahanan saiki ing wilayah iki, lan malah menehi saran supaya praktik standar sing dingerteni kabeh pangembang bisa mbantu. Sampeyan bisa uga katon yen ana akeh keluhan babagan urip, nanging ora ana usulan kanggo metu saka kahanan saiki.
Sapa kita, ing ngendi kita lan apa masalah kita
Saiki kita ana ing Tim Onboarding Sre, sing kalebu enem programer lan telung insinyur infrastruktur. Kita kabeh nyoba nulis Infrastruktur minangka kode (IaC). Kita nindakake iki amarga kita ngerti carane nulis kode lan duwe sejarah minangka pangembang "ndhuwur rata-rata".
- Kita duwe sawetara kaluwihan: latar mburi tartamtu, kawruh babagan praktik, kemampuan kanggo nulis kode, kepinginan kanggo sinau perkara anyar.
- Lan ana bagean sagging, sing uga minus: kurang kawruh babagan hardware infrastruktur.
Tumpukan teknologi sing digunakake ing IaC kita.
- Terraform kanggo nggawe sumber daya.
- Packer kanggo ngrakit gambar. Iki minangka gambar Windows, CentOS 7.
- Jsonnet kanggo nggawe bangunan sing kuat ing drone.io, uga ngasilake packer json lan modul terraform kita.
- Azure.
- Ansible nalika nyiapake gambar.
- Python kanggo layanan tambahan lan skrip provisioning.
- Lan kabeh iki ing VSCode kanthi plugin sing dituduhake ing antarane anggota tim.
Kesimpulan saka sandi kaya iki: Aku nyoba kanggo instill (pisanan kabeh ing dhewe) optimisme, Aku wanted kanggo ngomong sing kita bakal nyoba pendekatan lan laku dikenal kanggo kita kanggo menehi hasil karo kangelan lan complexities sing ana ing wilayah iki.
Saiki kita lagi berjuang karo masalah IaC ing ngisor iki:
- Ora sampurna alat lan sarana kanggo pangembangan kode.
- Penyebaran alon. Infrastruktur minangka bagean saka jagad nyata, lan bisa uga alon.
- Kurang pendekatan lan praktik.
- Kita anyar lan ora ngerti akeh.
Extreme Programming (XP) kanggo ngluwari
Kabeh pangembang kenal karo Extreme Programming (XP) lan praktik sing ana ing mburi. Akeh kita wis nggarap pendekatan iki, lan wis sukses. Dadi, kenapa ora nggunakake prinsip lan praktik sing diwenehake kanggo ngatasi tantangan infrastruktur? Kita mutusake kanggo njupuk pendekatan iki lan ndeleng apa sing kedadeyan.
Priksa aplikasi pendekatan XP kanggo industri sampeyanMangkene katrangan babagan lingkungan sing cocog karo XP, lan kepiye hubungane karo kita:
1. Syarat piranti lunak kanthi dinamis ganti. Iku cetha kanggo kita apa tujuan pungkasan. Nanging rincian bisa beda-beda. Kita dhewe mutusake ngendi kita kudu mendhoan, supaya syarat diganti sacara periodik (utamane dhewe). Yen kita njupuk tim SRE, sing nindakake otomatisasi dhewe lan uga mbatesi syarat lan ruang lingkup kerja, mula titik iki cocog.
2. Resiko sing disebabake proyek wektu tetep nggunakake teknologi anyar. Kita bisa nemoni risiko nalika nggunakake sawetara perkara sing ora dingerteni. Lan iki 100% kasus kita. Kabeh proyek kita yaiku nggunakake teknologi sing durung ngerti. Umumé, iki minangka masalah sing tetep, amarga ... Ana akeh teknologi anyar sing muncul ing sektor infrastruktur sawayah-wayah.
3,4. Tim pangembang sing luwih cilik, dumunung bebarengan. Teknologi otomatis sing sampeyan gunakake ngidini tes unit lan fungsional. Loro poin iki ora cocog karo kita. Kaping pisanan, kita dudu tim sing terkoordinasi, lan nomer loro, ana sanga, sing bisa dianggep minangka tim gedhe. Sanajan, miturut sawetara definisi tim "gedhe", akeh 14+ wong.
Ayo goleki sawetara praktik XP lan kepiye carane mengaruhi kacepetan lan kualitas umpan balik.
Prinsip Loop Umpan Balik XP
Ing pangerten, umpan balik minangka jawaban kanggo pitakonan, apa aku nindakake perkara sing bener, apa kita bakal ana? XP duwe skema gaib kanggo iki: loop umpan balik wektu. Sing menarik yaiku yen luwih murah, luwih cepet kita bisa entuk OS kanggo mangsuli pitakon sing dibutuhake.
Iki minangka topik sing rada menarik kanggo diskusi, yen ing industri IT kita bisa entuk OS kanthi cepet. Mbayangno carane nglarani iku kanggo nindakake proyek kanggo nem sasi lan mung banjur ngerti yen ana kesalahan ing awal banget. Iki kedadeyan ing desain lan ing sembarang konstruksi sistem kompleks.
Ing kasus IaC, umpan balik mbantu kita. Aku bakal langsung nggawe pangaturan cilik kanggo diagram ing ndhuwur: rencana rilis ora duwe siklus saben wulan, nanging kedadeyan kaping pirang-pirang dina. Ana sawetara praktik sing ana gandhengane karo siklus OS iki sing bakal kita deleng kanthi luwih rinci.
Penting: umpan balik bisa dadi solusi kanggo kabeh masalah sing kasebut ing ndhuwur. Digabungake karo praktik XP, bisa narik sampeyan metu saka jurang putus asa.
Carane narik dhewe metu saka telenging putus asa: telung laku
Tes
Tes kasebut kaping pindho ing daur ulang umpan balik XP. Ora mung kaya ngono. Dheweke penting banget kanggo kabeh teknik Pemrograman Ekstrim.
Dianggep sampeyan duwe tes Unit lan Penerimaan. Sawetara menehi umpan balik ing sawetara menit, liyane ing sawetara dina, supaya luwih suwe kanggo nulis lan dideleng luwih jarang.
Ana piramida tes klasik, sing nuduhake yen kudu ana tes liyane.
Kepiye kerangka kerja iki ditrapake kanggo kita ing proyek IaC? Bener... ora babar pisan.
- Tes unit, sanajan kasunyatane kudu akeh, ora bisa akeh banget. Utawa lagi nyoba soko banget ora langsung. Nyatane, kita bisa ngomong yen kita ora nulis kabeh. Nanging ing ngisor iki sawetara aplikasi kanggo tes kasebut sing bisa ditindakake:
- Nguji kode jsonnet. Iki, contone, yaiku pipa perakitan drone, sing cukup rumit. Kode jsonnet uga dijamin dening tes.
Kita nggunakake iki . - Tes kanggo skrip sing dieksekusi nalika sumber daya diwiwiti. Scripts ditulis ing Python, lan mulane tes bisa ditulis ing wong.
- Nguji kode jsonnet. Iki, contone, yaiku pipa perakitan drone, sing cukup rumit. Kode jsonnet uga dijamin dening tes.
- Sampeyan bisa uga mriksa konfigurasi ing tes, nanging kita ora nindakake. Sampeyan uga bisa kanggo ngatur mriksa aturan konfigurasi sumber liwat . Nanging, mriksa ana mung banget dhasar kanggo terraform, nanging akeh skrip test ditulis kanggo AWS. Lan kita lagi ing Azure, supaya iki maneh ora ditrapake.
- Tes integrasi komponen: gumantung carane sampeyan nggolongake lan ing ngendi sampeyan nyelehake. Nanging padha Sejatine bisa.
Iki minangka tes integrasi.
Iki minangka conto nalika nggawe gambar ing Drone CI. Kanggo nggayuh, sampeyan kudu ngenteni 30 menit nganti gambar Packer dibentuk, banjur ngenteni 15 menit maneh supaya bisa lulus. Nanging padha ana!Algoritma verifikasi gambar
- Packer kudu nyiapake gambar kanthi lengkap.
- Sabanjure kanggo test ana terraform karo negara lokal, kang digunakake kanggo masang gambar iki.
- Nalika mbukak, modul cilik sing ana ing cedhak digunakake supaya luwih gampang nggarap gambar kasebut.
- Sawise VM disebarake saka gambar, pamriksa bisa diwiwiti. Sejatine, mriksa ditindakake kanthi mobil. Iku mriksa carane skrip bisa digunakake nalika wiwitan lan cara kerja daemon. Kanggo nindakake iki, liwat ssh utawa winrm kita mlebu menyang mesin sing mentas wungu lan mriksa status konfigurasi utawa apa layanan wis munggah.
- Kahanan kasebut padha karo tes integrasi ing modul kanggo terraform. Punika tabel singkat sing nerangake fitur tes kasebut.
Umpan balik babagan pipa kira-kira 40 menit. Kabeh kedadeyan suwe banget. Bisa digunakake kanggo regresi, nanging kanggo pangembangan anyar umume ora nyata. Yen sampeyan wis siyap banget, nyiyapake skrip sing mlaku, banjur sampeyan bisa nyuda nganti 10 menit. Nanging iki isih dudu tes Unit, sing nggawe 5 potongan sajrone 100 detik.
Ora ana tes Unit nalika ngumpulake gambar utawa modul terraform nyengkuyung owah-owahan karya menyang layanan kapisah sing mung bisa ditindakake liwat REST, utawa skrip Python.
Contone, kita kudu nggawe manawa mesin virtual diwiwiti, ndhaptar dhewe ing layanan kasebut , lan nalika mesin virtual wis numpes, dibusak dhewe.
Awit kita duwe ScaleFT minangka layanan, kita kepeksa nggarap liwat API. Ana bungkus sing ditulis ing kono sing bisa ditarik lan ujar: "Mlebu lan busak iki lan iki." Iki nyimpen kabeh setelan lan akses sing dibutuhake.
Kita wis bisa nulis tes normal kanggo iki, amarga ora beda karo piranti lunak biasa: sawetara jinis apiha dipoyoki, sampeyan narik, lan ndeleng apa sing kedadeyan.
Asil saka tes: Unit testing, kang ngirim menehi OS ing menit, ora menehi. Lan jinis tes sing luwih dhuwur ing piramida efektif, nanging mung nutupi bagean saka masalah kasebut.
Pemrograman pasangan
Tes, mesthi, apik. Sampeyan bisa nulis akeh, bisa dadi macem-macem jinis. Dheweke bakal kerja ing level lan menehi saran. Nanging masalah karo tes Unit ala, sing menehi OS paling cepet, tetep. Ing wektu sing padha, aku isih pengin OS cepet sing gampang lan nyenengake kanggo nggarap. Ora kanggo sebutno kualitas solusi sing diasilake. Untunge, ana teknik sing bisa menehi umpan balik sing luwih cepet tinimbang tes unit. Iki minangka pemrograman pasangan.
Nalika nulis kode, sampeyan pengin entuk umpan balik babagan kualitase kanthi cepet. Ya, sampeyan bisa nulis kabeh ing cabang fitur (supaya ora ngrusak apa wae kanggo sapa wae), nggawe panjaluk tarik ing Github, nemtokake kanggo wong sing mratelakake panemume duwe bobot, lan ngenteni respon.
Nanging sampeyan bisa ngenteni suwe. Wong kabeh sibuk, lan jawabane, sanajan ana, bisa uga ora kualitas sing paling dhuwur. Upamane yen wangsulane langsung teka, pamawas langsung ngerti kabeh gagasan, nanging jawabane isih telat, sawise kasunyatan. Aku pengin luwih dhisik. Iki minangka program pasangan sing dituju - langsung, nalika nulis.
Ing ngisor iki gaya pemrograman pasangan lan ditrapake kanggo nggarap IaC:
1. Klasik, Experienced+Experienced, shift dening timer. Loro peran - driver lan navigator. wong loro. Dheweke nggarap kode sing padha lan ngalih peran sawise wektu sing wis ditemtokake.
Ayo dipikirake kompatibilitas masalah kita karo gaya:
- Masalah: ora sampurna alat lan alat kanggo pangembangan kode.
Dampak negatif: butuh luwih suwe kanggo berkembang, kita alon-alon, irama / irama kerja ilang.
Cara perang: kita nggunakake alat sing beda, IDE umum lan uga sinau trabasan. - Masalah: Penyebaran alon.
Dampak negatif: nambah wektu kanggo nggawe potongan kode sing bisa digunakake. Kita bosen nalika ngenteni, tangan kita tekan kanggo nindakake liyane nalika ngenteni.
Carane perang: kita ora ngalahake. - Masalah: kurang pendekatan lan praktik.
Dampak negatif: ora ana kawruh babagan carane nindakake kanthi becik lan carane nindakake kanthi apik. Lengthens panrimo saka saran.
Kepiye cara perang: saling tukar pendapat lan praktik ing karya pasangan meh ngrampungake masalah kasebut.
Masalah utama nggunakake gaya iki ing IaC yaiku kacepetan kerja sing ora rata. Ing pangembangan piranti lunak tradisional, sampeyan duwe gerakan sing seragam. Sampeyan bisa nglampahi limang menit lan nulis N. Nglampahi 10 menit lan nulis 2N, 15 menit - 3N. Kene sampeyan bisa nglampahi limang menit lan nulis N, lan banjur nglampahi liyane 30 menit lan nulis sepuluh saka N. Kene sampeyan ora ngerti apa-apa, sampeyan lagi macet, bodho. Penyelidikan mbutuhake wektu lan ngganggu program kasebut dhewe.
Kesimpulan: ing wangun murni iku ora cocok kanggo kita.
2. Ping-pong. Pendekatan iki kalebu siji wong sing nulis tes lan liyane nindakake implementasine. Njupuk menyang akun kasunyatan sing kabeh iku rumit karo tes Unit, lan sampeyan kudu nulis test integrasi sing njupuk wektu dawa kanggo program, kabeh ease saka ping-pong ilang.
Aku bisa ngomong yen kita nyoba misahake tanggung jawab kanggo ngrancang skrip test lan ngleksanakake kode kasebut. Siji peserta teka munggah karo script, ing bagean iki karya kang tanggung jawab, kang wis tembung pungkasan. Lan liyane tanggung jawab kanggo implementasine. Iku bisa metu uga. Kualitas naskah kanthi pendekatan iki mundhak.
Kesimpulan: sayange, kecepatan kerja ora ngidini panggunaan ping-pong minangka praktik pemrograman pasangan ing IaC.
3. Gaya Kuwat. . Ide iki yaiku yen siji peserta dadi navigator arahan, lan sing kapindho njupuk peran minangka pembalap eksekusi. Ing kasus iki, hak nggawe keputusan mung ana ing navigator. Pembalap mung nyithak lan bisa mengaruhi apa sing kedadeyan karo tembung. Peran ora owah nganti suwe.
Apik kanggo sinau, nanging mbutuhake katrampilan alus sing kuwat. Iki ngendi kita faltered. Teknik kasebut angel. Lan dudu babagan infrastruktur.
Kesimpulan: duweni potensi bisa digunakake, kita ora nyerah nyoba.
4. Mobbing, swarming lan kabeh dikenal nanging ora kadhaptar gaya Kita ora nganggep, amarga Kita durung nyoba lan ora bisa ngomong babagan iki ing konteks karya kita.
Asil umum babagan nggunakake pemrograman pasangan:
- Kita duwe jangkah kerja sing ora rata, sing mbingungake.
- Kita mlayu menyang katrampilan alus sing ora cukup apik. Lan area subyek ora mbantu ngatasi kekurangan kita iki.
- Tes dawa lan masalah karo alat nggawe pangembangan pasangan dadi angel.
5. Senadyan iki, ana sukses. Kita nggawe metode dhewe "Konvergensi - Divergensi". Aku bakal njlèntrèhaké sedhela cara kerjane.
Kita duwe mitra permanen sawetara dina (kurang saka seminggu). Kita nindakake siji tugas bebarengan. Kita njagong bebarengan kanggo sawetara wektu: siji nulis, liyane lenggah lan nonton tim dhukungan. Banjur kita bubar sawetara wektu, saben nindakake sawetara perkara sing mandiri, banjur kita kumpul maneh, nyinkronake kanthi cepet, nindakake apa wae lan banjur bubar maneh.
Perencanaan lan komunikasi
Blok praktik pungkasan sing bisa dirampungake masalah OS yaiku organisasi kerja kanthi tugas kasebut. Iki uga kalebu ijol-ijolan pengalaman sing ana ing njaba karya pasangan. Ayo ndeleng telung praktik:
1. Sasaran liwat wit gol. We diatur manajemen sakabèhé saka project liwat wit sing dadi endlessly menyang mangsa. Secara teknis, pelacakan ditindakake ing Miro. Ana siji tugas - iku goal penengah. Saka iku dadi gol cilik utawa klompok tugas. Tugas dhewe teka saka wong-wong mau. Kabeh tugas digawe lan dikelola ing papan iki.
Skema iki uga menehi umpan balik, sing kedadeyan sapisan dina nalika kita nyinkronake ing rapat umum. Duwe rencana umum ing ngarep kabeh wong, nanging wis kabentuk lan mbukak kabeh, ngidini saben wong ngerti apa sing kedadeyan lan sepira kita wis maju.
Kauntungan saka visi visual tugas:
- kausalitas. Saben tugas ndadékaké kanggo sawetara goal global. Tugas diklompokaké dadi gol sing luwih cilik. Domain infrastruktur dhewe cukup teknis. Ora mesthi langsung jelas apa impact tartamtu, contone, nulis runbook ing migrasi menyang nginx liyane wis ing bisnis. Duwe kertu target ing cedhak nggawe luwih jelas.
Kausalitas minangka properti penting saka masalah. Iki langsung mangsuli pitakon: "Apa aku nindakake perkara sing bener?" - Paralelisme. Ana sangang kita, lan iku mung fisik mokal kanggo uncalan saben wong ing siji tugas. Tugas saka siji wilayah bisa uga ora cukup. Kita dipeksa kanggo parallelize karya antarane kelompok kerja cilik. Ing wektu sing padha, klompok lungguh ing tugas kanggo sawetara wektu, padha bisa dikiataken dening wong liya. Kadhangkala wong tiba saka grup kerja iki. Ana wong sing preian, ana sing nggawe laporan kanggo conf DevOps, ana sing nulis artikel babagan Habr. Ngerti apa tujuan lan tugas sing bisa ditindakake bebarengan dadi penting banget.
2. Ganti presenter rapat esuk. Ing stand-up kita duwe masalah iki - wong nindakake akeh tugas ing podo karo. Kadhangkala tugas disambungake lan ora ngerti sapa sing nindakake. Lan pendapat anggota tim liyane penting banget. Iki minangka informasi tambahan sing bisa ngganti dalan kanggo ngrampungake masalah kasebut. Mesthi, biasane ana wong karo sampeyan, nanging saran lan tips tansah migunani.
Kanggo nambah kahanan iki, kita nggunakake technique "Ngganti Anjog Stand-Up". Saiki lagi diputer miturut dhaptar tartamtu, lan iki duwe efek. Nalika giliran sampeyan, sampeyan kepeksa nyilem lan ngerti apa sing kedadeyan kanggo nindakake rapat Scrum sing apik.
3. Demo internal. Bantuan kanggo ngrampungake masalah saka program pasangan, visualisasi ing wit masalah lan bantuan ing rapat-rapat scrum ing wayah esuk apik, nanging ora becik. Minangka pasangan, sampeyan mung diwatesi dening kawruh. Wit tugas mbantu ngerti sacara global sapa sing nindakake apa. Lan presenter lan kanca-kanca ing rapat esuk ora bakal nyilem menyang masalah sampeyan. Padha mesthi bisa kantun soko.
Solusi kasebut ditemokake kanthi nduduhake karya sing ditindakake saben liyane lan banjur ngrembug. Kita ketemu seminggu sepisan sajrone sejam lan nuduhake rincian solusi kanggo tugas sing wis ditindakake sajrone minggu kepungkur.
Sajrone demonstrasi, perlu kanggo mbukak rincian tugas lan manawa kanggo nduduhake operasi kasebut.
Laporan kasebut bisa ditindakake kanthi nggunakake checklist.1. Ketik konteks. Saka endi tugas kasebut, kok malah perlu?
2. Kepriye masalahe dirampungake sadurunge? Contone, klik mouse gedhe-gedhe dibutuhake, utawa ora bisa nindakake apa-apa.
3. Carane kita nambah. Contone: "Lah, saiki ana scriptosik, iki readme."
4. Tampilake cara kerjane. Apike kanggo langsung ngleksanakake sawetara skenario pangguna. Aku pengin X, aku Y, aku weruh Y (utawa Z). Contone, aku masang NGINX, ngrokok url, lan entuk 200 OK. Yen tumindake dawa, nyiapake luwih dhisik supaya bisa ditampilake mengko. Disaranake supaya ora ngilangi jam sadurunge demo, yen rapuh.
5. Nerangake carane sukses masalah ditanggulangi, apa kangelan tetep, apa ora rampung, apa dandan bisa ing mangsa. Contone, saiki CLI, banjur bakal ana otomatisasi lengkap ing CI.
Disaranake saben speaker tetep nganti 5-10 menit. Yen wicara sampeyan temenan penting lan bakal njupuk maneh, koordinasi iki ing advance ing saluran sre-takeover.
Sawise adhep-adhepan mesthi ana rembugan ing thread. Iki ngendi umpan balik sing kita butuhake kanggo tugas kita katon.
Akibaté, survey ditindakake kanggo nemtokake gunane apa sing kedadeyan. Iki minangka umpan balik babagan inti pidato lan pentinge tugas.
Kesimpulan sing dawa lan apa sing sabanjure
Mesthine, nada artikel kasebut rada pesimis. Iki salah. Loro tingkat umpan balik sing luwih murah, yaiku tes lan pemrograman pasangan, kerja. Ora sampurna kaya ing pembangunan tradisional, nanging ana efek positif saka iku.
Tes, ing wangun saiki, mung nyedhiyakake jangkoan kode parsial. Akeh fungsi konfigurasi pungkasane durung diuji. Pengaruhe ing karya nyata nalika nulis kode kurang. Nanging, ana efek saka tes integrasi, lan ngidini sampeyan nindakake refactorings tanpa wedi. Iki prestasi gedhe. Uga, kanthi owah-owahan fokus kanggo pangembangan ing basa tingkat dhuwur (kita duwe python, go), masalah kasebut ilang. Lan sampeyan ora perlu akeh mriksa kanggo "lem"; mriksa integrasi umum cukup.
Makarya ing pasangan luwih gumantung ing wong tartamtu. Ana faktor tugas lan katrampilan alus kita. Karo sawetara wong iku bisa metu banget, karo liyane iku luwih elek. Mesthi ana keuntungan saka iki. Cetha yen sanajan aturan kerja pasangan ora diamati kanthi cukup, kasunyatane nindakake tugas bebarengan duwe pengaruh positif marang kualitas asil. Secara pribadi, aku nemokake kerja pasangan luwih gampang lan luwih nyenengake.
Cara sing luwih dhuwur kanggo mengaruhi OS - ngrancang lan nggarap tugas kanthi tepat ngasilake efek: ijol-ijolan kawruh sing berkualitas lan kualitas pangembangan sing luwih apik.
Kesimpulan singkat ing siji baris
- Praktisi HR makarya ing IaC, nanging kanthi efisiensi kurang.
- Nguatake apa sing dianggo.
- Nggawe mekanisme lan praktik kompensasi dhewe.
Source: www.habr.com