Direktur Operasi portal Banki.ru Andrey Nikolsky ngandika ing konferensi taun kepungkur babagan layanan yatim piatu: carane ngenali bocah yatim piatu ing prasarana, kenapa layanan yatim piatu ala, apa sing kudu ditindakake, lan apa sing kudu ditindakake yen ora ana sing mbantu.
Ing ngisor potong ana versi teks laporan.
Halo rekan kerja! Jenengku Andrey, aku mimpin operasi ing Banki.ru.
We duwe layanan gedhe, iki layanan monolithic kuwi, ana layanan ing pangertèn sing luwih klasik, lan ana cilik banget. Ing terminologi buruh-tani, aku ngomong yen layanan iku prasaja lan cilik, banjur iku mikro, lan yen ora banget prasaja lan cilik, iku mung layanan.
Pros saka layanan
Aku bakal cepet njlentrehake kaluwihan layanan kasebut.
Sing pisanan yaiku scaling. Sampeyan bisa kanthi cepet nindakake soko ing layanan lan miwiti produksi. Sampeyan wis nampa lalu lintas, sampeyan wis kloning layanan. Sampeyan duwe lalu lintas liyane, sampeyan wis kloning lan manggon karo. Iki bonus apik, lan, ing asas, nalika kita miwiti, iki dianggep paling penting kanggo kita, kok kita nindakake kabeh iki.
Kapindho, pangembangan terisolasi, nalika sampeyan duwe sawetara tim pangembangan, sawetara pangembang beda ing saben tim, lan saben tim ngembangake layanan dhewe.
Kanthi tim ana nuansa. Pangembang beda-beda. Lan ana, contone, . Aku pisanan weruh iki karo Maxim Dorofeev. Kadhangkala wong snowflake ana ing sawetara tim lan ora ana ing tim liyane. Iki nggawe macem-macem layanan sing digunakake ing perusahaan dadi ora rata.
Deleng gambar: iki pangembang sing apik, dheweke duwe tangan gedhe, dheweke bisa nindakake akeh. Masalah utama yaiku saka ngendi tangan iki teka.
Layanan ngidini nggunakake basa pamrograman sing beda-beda sing luwih cocog kanggo macem-macem tugas. Sawetara layanan ana ing Go, sawetara ana ing Erlang, sawetara ana ing Ruby, ana ing PHP, ana ing Python. UmumΓ©, sampeyan bisa nggedhekake banget. Ana nuansa ing kene uga.
Arsitektur berorientasi layanan utamane babagan devops. Yaiku, yen sampeyan ora duwe otomatisasi, ora ana proses panyebaran, yen sampeyan ngatur kanthi manual, konfigurasi sampeyan bisa diganti saka conto layanan menyang conto, lan sampeyan kudu pindhah menyang kono kanggo nindakake apa wae, mula sampeyan ana ing neraka.
Contone, sampeyan duwe 20 layanan lan sampeyan kudu masang kanthi tangan, sampeyan duwe 20 nyenengake, lan sampeyan bebarengan mencet "ketik" kaya ninja. Iku ora apik banget.
Yen sampeyan duwe layanan sawise testing (yen ana testing, mesthi), lan sampeyan isih kudu rampung karo file supaya bisa ing produksi, Aku uga duwe kabar ala kanggo sampeyan.
Yen sampeyan ngandelake layanan Amazon tartamtu lan kerja ing Rusia, rong wulan kepungkur sampeyan uga duwe "Kabeh sing ana ing geni, aku ora apa-apa, kabeh apik."
Kita nggunakake Ansible kanggo ngotomatisasi penyebaran, Wayang kanggo konvergensi, Bambu kanggo ngotomatisasi penyebaran, lan Confluence kanggo njlentrehake kabeh.
Aku ora bakal mikir babagan iki kanthi rinci, amarga laporan kasebut luwih akeh babagan praktik interaksi, lan dudu babagan implementasi teknis.
Contone, kita wis masalah ngendi Wayang ing server dianggo karo Ruby 2, nanging sawetara aplikasi ditulis kanggo Ruby 1.8, lan padha ora bisa bebarengan. Ana sing salah ana. Lan nalika sampeyan kudu mbukak pirang-pirang versi Ruby ing siji mesin, sampeyan biasane duwe masalah.
Contone, kita menehi saben pangembang platform sing ana kira-kira kabeh sing kita duwe, kabeh layanan sing bisa dikembangake, supaya dheweke duwe lingkungan sing terisolasi, dheweke bisa ngilangi lan mbangun kaya sing dikarepake.
Mengkono sing mbutuhake sawetara paket khusus nyawiji karo support kanggo soko ana. Iku cukup angel. Aku ngrungokake laporan ing ngendi gambar Docker bobote 45 GB. Ing Linux, mesthi, luwih gampang, kabeh luwih cilik ing kana, nanging isih ora ana papan sing cukup.
Inggih, ana dependensi sing bertentangan, nalika salah sijine proyek gumantung ing perpustakaan siji versi, bagean proyek liyane gumantung ing versi liyane, lan perpustakaan ora diinstal bebarengan.
Kita duwe situs lan layanan ing PHP 5.6, kita isin, nanging apa sing bisa ditindakake? Iki minangka situs siji kita. Ana situs lan layanan ing PHP 7, ana luwih akeh, kita ora isin. Lan saben pangembang duwe basis dhewe ing ngendi dheweke seneng ndeleng.
Yen sampeyan nulis ing perusahaan ing siji basa, telung mesin virtual saben pangembang muni normal. Yen sampeyan duwe basa pamrograman sing beda-beda, kahanan bakal saya elek.
Sampeyan duwe situs lan layanan iki, iki, banjur situs liyane kanggo Go, siji situs kanggo Ruby, lan sawetara Redis liyane ing sisih. AkibatΓ©, kabeh iki dadi lapangan gedhe kanggo dhukungan, lan kabeh wektu sawetara bisa break.
Mula, kita ngganti keuntungan saka basa pamrograman kanthi nggunakake kerangka kerja sing beda-beda, amarga kerangka kerja PHP cukup beda, duwe kemampuan sing beda, komunitas sing beda, lan dhukungan sing beda. Lan sampeyan bisa nulis layanan supaya sampeyan wis duwe sing siap.
Saben layanan duwe tim dhewe
Kauntungan utama kita, sing wis dadi kristal sajrone pirang-pirang taun, yaiku saben layanan duwe tim dhewe. Iki trep kanggo proyek gedhe, sampeyan bisa ngirit wektu kanggo dokumentasi, manajer ngerti proyeke.
Sampeyan bisa kanthi gampang ngirim tugas saka dhukungan. Contone, layanan asuransi rusak. Lan tim sing ngurusi asuransi langsung ndandani.
Fitur-fitur anyar digawe kanthi cepet, amarga yen sampeyan duwe layanan atom, sampeyan bisa kanthi cepet ngaco.
Lan nalika sampeyan ngilangi layanan sampeyan, lan iki mesthi kedadeyan, sampeyan ora mengaruhi layanan wong liya, lan pangembang karo bit saka tim liyane ora bakal teka lan ujar: "Oh, aja ngono."
Minangka tansah, ana nuansa. Kita duwe tim sing stabil, manajer dipaku menyang tim. Ana dokumen sing jelas, manajer ngawasi kanthi rapet kabeh. Saben tim karo manajer duwe sawetara layanan, lan ana titik kompetensi tartamtu.
Yen tim ngambang (kita uga kadang nggunakake iki), ana cara sing apik sing diarani "peta bintang".
Sampeyan duwe dhaptar layanan lan wong. Tanda bintang tegese wong kasebut ahli ing layanan iki, buku tegese wong kasebut sinau layanan iki. Tugase wong iku kanggo ngganti buku karo tanda bintang. Lan yen ora ana sing ditulis ing ngarep layanan, banjur masalah diwiwiti, sing bakal dakkandhakake luwih lanjut.
Kepiye carane layanan yatim piatu katon?
Masalah pisanan, cara pisanan kanggo njaluk layanan yatim piatu ing prasarana sampeyan kanggo murub wong. Apa ana wong sing duwe bisnis ketemu tenggat wektu sadurunge tugas ditaksir? Kadhangkala tenggat wektu sing ketat lan ora cukup wektu kanggo dokumentasi. "Kita kudu nyerahake layanan menyang produksi, banjur kita tambahake."
Yen tim cilik, kedadeyan ana siji pangembang sing nulis kabeh, liyane ana ing swiwi. "Aku nulis arsitektur dhasar, ayo nambah antarmuka." Banjur ing sawetara titik manajer, contone, ninggalake. Lan sajrone wektu kasebut, nalika manajer wis lunga lan sing anyar durung diangkat, pangembang dhewe mutusake menyang ngendi layanan kasebut lan apa sing kedadeyan ing kana. Lan kita ngerti (ayo bali sawetara minger), ing sawetara tim ana snowflake wong, kadhangkala tim snowflake timbal. Banjur dheweke mandheg, lan kita entuk layanan yatim piatu.
Ing wektu sing padha, tugas saka dhukungan lan bisnis ora ilang; Yen ana kesalahan arsitektur sajrone pangembangan layanan kasebut, mula uga ana ing backlog. Layanan iki alon-alon rusak.
Kepiye carane ngenali bocah yatim piatu?
Dhaptar iki nggambarake kahanan kanthi apik. Sapa sing sinau babagan infrastruktur?
Babagan dokumentasi kerja: ana layanan lan, umume, kerjane, duwe manual rong kaca babagan cara nggarap, nanging ora ana sing ngerti cara kerjane.
Utawa, contone, ana sawetara jinis link shortener. Contone, saiki kita duwe telung shortener link sing digunakake kanggo macem-macem tujuan ing layanan sing beda-beda. Iki mung jalaran.
Saiki aku bakal dadi kapten sing jelas. Apa sing kudu ditindakake? Pisanan, kita kudu nransfer layanan menyang manajer liyane, tim liyane. Yen pimpinan tim sampeyan durung mandheg, banjur ing tim liyane iki, yen sampeyan ngerti manawa layanan kasebut kaya bocah yatim piatu, sampeyan kudu nyakup wong sing paling ngerti babagan iki.
Sing utama: sampeyan kudu duwe prosedur transfer sing ditulis ing getih. Ing kasus kita, aku biasane ngawasi iki, amarga aku butuh kabeh supaya bisa digunakake. Manajer kudu dikirim kanthi cepet, lan apa sing kedadeyan mengko ora penting maneh.
Cara sabanjure kanggo nggawe yatim piatu yaiku "Kita bakal nindakake outsourcing, bakal luwih cepet, banjur kita bakal nyerahake menyang tim." Cetha yen saben wong duwe sawetara rencana ing tim, giliran. Asring pelanggan bisnis mikir yen outsourcing bakal nindakake perkara sing padha karo departemen teknis sing diduweni perusahaan. Senajan motivatore beda. Ana solusi teknologi aneh lan solusi algoritma aneh ing outsourcing.
Contone, kita duwe layanan sing wis Sphinx ing macem-macem panggonan sing ora dikarepke. Aku bakal ngandhani apa sing kudu daklakoni.
Outsourcing duwe kerangka kerja sing ditulis dhewe. Iki mung PHP gundhul karo salinan-tempel saka project sadurungΓ©, ngendi sampeyan bisa nemokake kabeh limo iku. Skrip penyebaran minangka kekurangan gedhe nalika sampeyan kudu nggunakake sawetara skrip Bash sing kompleks kanggo ngganti sawetara baris ing sawetara file, lan skrip penyebaran kasebut diarani sawetara skrip katelu. AkibatΓ©, sampeyan ngganti sistem penyebaran, milih liyane, mlumpat, nanging layanan sampeyan ora bisa. Amarga ana iku perlu kanggo sijine 8 pranala liyane antarane folder beda. Utawa kedadeyan sing sewu cathetan bisa, nanging satus ewu ora bisa maneh.
Aku bakal terus dadi kapten. Nampa layanan outsourcing minangka prosedur wajib. Apa ana wong sing wis teka layanan outsourcing lan ora ditampa ing ngendi wae? Iki ora populer, mesthi, minangka layanan yatim piatu, nanging isih.
Layanan kasebut kudu dipriksa, layanan kasebut kudu dideleng, sandhi kudu diganti. Kita duwe kasus nalika menehi layanan, ana panel admin "yen mlebu == 'admin' && sandi == 'admin' ...", ditulis ing kode kasebut. Kita njagong lan mikir, lan wong nulis iki ing 2018?
Nguji kapasitas panyimpenan uga perlu. Sampeyan kudu ndeleng apa sing bakal kelakon ing satus ewu rekaman, malah sadurunge sampeyan sijine layanan iki menyang produksi nang endi wae.
Ora perlu isin ngirim layanan kanggo perbaikan. Nalika sampeyan ujar: "Kita ora bakal nampa layanan iki, kita duwe 20 tugas, lakoni, banjur kita bakal nampa," iki normal. Hati nurani sampeyan ora kena lara amarga sampeyan nggawe manajer utawa bisnis mbuwang dhuwit. Bisnis banjur bakal mbuwang luwih akeh.
Kita duwe kasus nalika mutusake kanggo outsourcing proyek pilot.
Iki dikirim ing wektu, lan iki mung kritΓ©ria kualitas. Mulane kita nggawe proyek pilot liyane, sing dudu pilot maneh. Layanan kasebut ditampa, lan liwat cara administratif dheweke ujar, iki kode sampeyan, iki tim, iki manajer sampeyan. Layanan kasebut pancen wis wiwit ngasilake bathi. Ing wektu sing padha, nyatane isih bocah yatim piatu, ora ana sing ngerti carane kerjane, lan manajer nindakake sing paling apik kanggo nolak tugase.
Ana konsep gedhe liyane - pembangunan gerilya. Nalika sawetara departemen, biasane departemen marketing, pengin nyoba hipotesis lan pesen kabeh layanan outsourcing. Lalu lintas wiwit mlumpat, dheweke nutup dokumen, mlebu dokumen karo kontraktor, mula beroperasi lan ujar: "Wah, kita duwe layanan ing kene, wis ana lalu lintas, nggawa dhuwit, ayo nampa." Kita padha kaya, "Oppa, carane bisa."
Lan cara liya kanggo entuk layanan yatim piatu: nalika sawetara tim tiba-tiba kebanjiran, manajemen ujar: "Ayo mindhah layanan tim iki menyang tim liyane, duwe beban sing luwih cilik." Banjur kita bakal nransfer menyang tim katelu lan ngganti manajer. Lan ing pungkasan kita duwe anak yatim piatu maneh.
Apa masalahe bocah yatim piatu?
Sapa sing ora ngerti, iki kapal perang Wasa sing digedhekake ing Swedia, sing misuwur amarga tenggelam 5 menit sawise diluncurake. Lan Raja Swedia, kanthi cara, ora nglakokake sapa wae kanggo iki. Iki dibangun dening rong generasi insinyur sing ora ngerti carane nggawe kapal kasebut. Efek alam.
Kapal kasebut bisa ambruk, kanthi cara, luwih elek, contone, nalika raja wis numpak prau ing endi wae. Dadi, dheweke langsung tenggelam, miturut Agile, luwih becik gagal awal.
Yen gagal awal, biasane ora ana masalah. Contone, nalika ditampa dikirim kanggo revisi. Nanging yen kita wis gagal ing produksi, nalika dhuwit wis nandur modhal, banjur ana masalah. Akibat, kaya sing diarani bisnis.
Napa layanan yatim piatu mbebayani:
- Layanan bisa tiba-tiba rusak.
- Layanan kasebut mbutuhake wektu suwe kanggo ndandani utawa ora didandani babar pisan.
- Masalah safety.
- Masalah karo dandan lan nganyari.
- Yen layanan penting rusak, reputasi perusahaan bakal cilaka.
Apa sing kudu ditindakake karo layanan yatim piatu?
Aku bakal mbaleni apa maneh. Kaping pisanan, kudu ana dokumentasi. 7 taun ing Banki.ru ngajari aku yen penguji kudu ora njupuk tembung saka pangembang, lan operasi ngirim ora njupuk tembung saka saben wong. Kita kudu mriksa.
Kapindho, perlu kanggo nulis diagram interaksi, amarga kedadeyan layanan sing ora ditampa kanthi apik ngemot dependensi sing ora ana sing ngomong. Contone, pangembang nginstal layanan kasebut ing kunci menyang sawetara Yandex.Maps utawa Dadata. Sampeyan wis entek watesan gratis, kabeh rusak, lan sampeyan ora ngerti apa sing kedadeyan. Kabeh garu kasebut kudu diterangake: layanan kasebut nggunakake Dadata, SMS, liya-liyane.
Katelu, nggarap utang teknis. Nalika sampeyan nindakake sawetara jenis crutches utawa nampa layanan lan ngandika yen soko kudu rampung, sampeyan kudu nggawe manawa iku wis rampung. Amarga banjur bisa nguripake metu sing bolongan cilik ora dadi cilik, lan sampeyan bakal tiba liwat iku.
Kanthi tugas arsitektur, kita duwe crita babagan Sphinx. Salah sawijining layanan sing digunakake Sphinx kanggo ngetik dhaptar. Mung dhaptar paginated, nanging diindeks maneh saben wengi. Iki dirakit saka rong indeks: siji gedhe diindeks saben wengi, lan ana uga indeks cilik sing dicopot. Saben dina, kanthi kemungkinan 50% ngebom utawa ora, indeks kasebut ambruk sajrone pitungan, lan warta kita mandheg nganyari ing kaca utama. Kaping pisanan butuh 5 menit kanggo indeks maneh diindeks, banjur indeks mundhak, lan ing sawetara titik wiwit njupuk 40 menit maneh indeks. Nalika kita ngethok iki, kita ambegan kanthi lega, amarga wis jelas yen sawetara wektu bakal liwati lan indeks kita bakal diindeks maneh kanthi lengkap. Iki bakal dadi kegagalan kanggo portal kita, ora ana kabar sajrone wolung jam - iku, bisnis wis mandheg.
Rencana kanggo nggarap layanan yatim piatu
Nyatane, iki angel banget ditindakake, amarga devops babagan komunikasi. Sampeyan pengin dadi apik karo kolega, lan nalika sampeyan nggegirisi kolega lan manajer sampeyan kanthi peraturan, bisa uga ana perasaan sing bertentangan karo wong sing nindakake iki.
Saliyane kabeh titik kasebut, ana liyane sing penting: wong tartamtu kudu tanggung jawab kanggo saben layanan tartamtu, kanggo saben bagean tartamtu saka prosedur penyebaran. Nalika ora ana wong lan sampeyan kudu narik kawigaten wong liya kanggo sinau kabeh perkara iki, dadi angel.
Yen kabeh iki ora mbantu, lan layanan anak yatim piatu sampeyan isih yatim piatu, ora ana sing pengin njupuk, dokumentasi ora ditulis, tim sing diundang menyang layanan iki ora gelem nindakake apa-apa, ana cara sing gampang - kanggo nggawe maneh kabeh .
Sing, sampeyan njupuk syarat kanggo layanan anew lan nulis layanan anyar, luwih apik, ing platform luwih, tanpa solusi teknologi aneh. Lan sampeyan pindhah menyang ing perang.
Kita duwe kahanan nalika njupuk layanan ing Yii 1 lan nyadari yen kita ora bisa ngembangake luwih lanjut, amarga kita kehabisan pangembang sing bisa nulis kanthi apik ing Yii 1. Kabeh pangembang nulis kanthi apik ing Symfony XNUMX. Apa sing kudu ditindakake? Kita nyedhiyakake wektu, nyedhiyakake tim, ngatur manajer, nulis ulang proyek kasebut lan ngalih lalu lintas kanthi lancar.
Sawise iki, layanan lawas bisa dibusak. Iki minangka prosedur sing paling disenengi, nalika sampeyan kudu njupuk lan ngresiki sawetara layanan saka sistem manajemen konfigurasi banjur goleki lan ndeleng manawa kabeh mobil ing produksi wis dipateni, supaya pangembang ora duwe jejak. Repositori tetep ing Git.
Iki kabeh sing dakkarepake, aku siap ngrembug, topik kasebut holivar, akeh sing nglangi.
Slide kasebut ujar manawa sampeyan nggabungake basa. Conto yaiku ngowahi ukuran gambar. Apa pancene kudu diwatesi kanthi ketat ing siji basa? Amarga ukuran gambar ing PHP, bisa uga ditindakake ing Golang.
Nyatane, iku opsional, kaya kabeh laku. Mbok, ing sawetara kasus, malah undesirable. Nanging sampeyan kudu ngerti yen sampeyan duwe departemen teknis ing perusahaan 50 wong, 45 wong spesialis PHP, liyane 3 devops sing ngerti Python, Ansible, Wayang lan liya-liyane, lan mung siji sing nulis ing sawetara. jenis basa sawetara layanan ngowahi ukuran gambar Go, banjur nalika ninggalake, expertise dadi karo. Lan ing wektu sing padha, sampeyan kudu golek pangembang khusus pasar sing ngerti basa iki, utamane yen langka. Tegese, saka sudut pandang organisasi, iki dadi masalah. Saka sudut pandang devops, sampeyan ora mung kudu kloning sawetara set playbooks sing digunakake kanggo nyebarake layanan, nanging sampeyan kudu nulis maneh.
Saiki kita lagi mbangun layanan ing Node.js, lan iki mung minangka platform sing cedhak kanggo saben pangembang kanthi basa sing kapisah. Nanging kita lungguh lan panginten sing game worth lilin. Sing, iki pitakonan kanggo sampeyan njagong lan mikir.
Kepiye carane sampeyan ngawasi layanan sampeyan? Kepiye carane sampeyan ngumpulake lan ngawasi log?
Kita ngumpulake log ing Elasticsearch lan dilebokake ing Kibana, lan gumantung manawa produksi utawa lingkungan tes, macem-macem kolektor digunakake ing kana. Nang endi wae Lumberjack, nang endi wae liya mergo, Aku ora ngelingi. Lan isih ana sawetara panggonan ing layanan tartamtu ing ngendi kita nginstal Telegraf lan njupuk ing papan liya kanthi kapisah.
Kepiye carane urip karo Wayang lan Ansible ing lingkungan sing padha?
Nyatane, saiki kita duwe rong lingkungan, siji Wayang, liyane Ansible. Kita nggarap hibrida. Ansible minangka kerangka kerja sing apik kanggo persiyapan awal, Wayang minangka kerangka kerja sing ala kanggo persiyapan awal amarga mbutuhake kerja langsung ing platform, lan Wayang njamin konvergensi konfigurasi. Iki tegese platform njogo dhewe ing negara munggah-kanggo-tanggal, lan supaya mesin ansibilized katahan anyar, sampeyan kudu mbukak playbooks ing kabeh wektu karo sawetara frekuensi. Mangkono bedane.
Kepiye carane njaga kompatibilitas? Apa sampeyan duwe konfigurasi ing Ansible lan Puppet?
Iki minangka lara gedhe, kita njaga kompatibilitas karo tangan lan mikir babagan carane nerusake saka kabeh iki ing endi wae saiki. Pranyata metu sing Wayang muter metu paket lan njaga sawetara pranala ana, lan Ansible, contone, muter kode lan nyetel configs aplikasi paling anyar ana.
Presentasi kasebut babagan macem-macem versi Ruby. Solusi apa?
Kita nemoni iki ing sak panggonan, lan kita kudu tetep ing sirah kita kabeh wektu. Kita mung mateni bagean sing mlaku ing Ruby sing ora kompatibel karo aplikasi lan tetep kapisah.
Konferensi taun iki bakal njupuk Panggonan ing 7 Desember ing Technopolis. Kita nampa aplikasi kanggo laporan nganti 11 November. kita yen sampeyan pengin ngomong.
Registrasi kanggo peserta wis dibukak, gabung!
Source: www.habr.com