Définisi DevOps rumit banget, mula kita kudu miwiti diskusi babagan iki maneh. Ana sewu publikasi babagan topik iki mung ing Habré. Nanging yen sampeyan maca iki, sampeyan bisa uga ngerti apa DevOps. Amarga aku ora. Halo Jenengku Is Alexander Titov (@), lan kita mung bakal ngomong babagan DevOps lan aku bakal nuduhake pengalamanku.
Aku wis suwe mikir babagan carane nggawe critaku migunani, mula bakal ana akeh pitakonan ing kene - sing dakkarepake dhewe lan sing daktakoni marang klien perusahaan. Kanthi mangsuli pitakon kasebut, pangerten dadi luwih apik. Aku bakal pitutur marang kowe kenapa DevOps dibutuhake saka sudut pandangku, apa maneh, saka sudut pandangku, lan kepiye ngerti yen sampeyan pindhah menyang DevOps maneh saka sudut pandangku. Titik pungkasan bakal liwat pitakonan. Kanthi mangsuli dhewe, sampeyan bisa ngerti apa perusahaan sampeyan pindhah menyang DevOps utawa ana masalah ing sawetara cara.
Ing sawijining wektu aku nunggang gelombang penggabungan lan akuisisi. Kaping pisanan, aku kerja ing wiwitan cilik sing diarani Qik, banjur dituku dening perusahaan sing rada gedhe sing diarani Skype, sing banjur dituku dening perusahaan sing rada gedhe jenenge Microsoft. Ing wayahe, aku wiwit ndeleng kepiye ide DevOps ganti ing perusahaan ukuran sing beda-beda. Sawise iku, aku dadi kasengsem ndeleng DevOps saka sudut pandang pasar, lan aku lan kanca-kancaku ngedegake perusahaan Express 42. Kanggo 6 taun saiki kita wis obah ing ombak pasar.
Antarane liyane, aku minangka salah sawijining panitia komunitas DevOps Moscow lan panitia DevOps-Days 2017, nanging aku ora ngatur 2018. Express 42 dianggo karo akeh perusahaan. Kita tuwuh DevOps ing kana, nonton kepiye kedadeyan, nggawe kesimpulan, nganalisa, ngandhani kabeh kesimpulan kita, lan nglatih wong ing praktik DevOps. Umumé, kita nindakake sing paling apik kanggo nambah pengalaman lan keahlian babagan iki.
Kenapa DevOps
Pitakonan pisanan sing ngganggu kabeh wong lan mesthi - kenapa? Akeh wong sing mikir yen DevOps mung otomatisasi utawa kaya sing wis ana ing saben perusahaan.
- Kita duwe Integrasi Terus-terusan - iki tegese kita wis duwe DevOps, lan kenapa kabeh iki dibutuhake? Dheweke seneng-seneng ing luar negeri, nanging ora bisa kerja!
Swara 9 taun pangembangan komunitas lan metodologi, wis dadi jelas manawa iki isih ora glitter marketing, nanging isih durung jelas kenapa dibutuhake. Kaya alat lan proses apa wae, DevOps duwe tujuan khusus sing pungkasane bisa ditindakake.
Kabeh iki amarga kasunyatan sing donya wis ganti. Dheweke pindhah saka pendekatan perusahaan, nalika perusahaan pindhah langsung menyang ngimpi, minangka St. Petersburg klasik kita nyanyi, saka titik A nganti titik B miturut strategi tartamtu, kanthi struktur tartamtu sing dibangun kanggo iki.
Ing asas, kabeh ing IT kudu dibangun miturut pendekatan iki. Ing kene IT digunakake sacara eksklusif kanggo ngotomatisasi proses.
Otomasi ora kerep owah, amarga nalika perusahaan mudhun kanthi apik, apa sing kudu diganti? Kerjane - aja ndemek. Saiki pendekatan ing donya saya ganti, lan sing diarani Agile nuduhake yen titik pungkasan B ora langsung katon.
Nalika perusahaan ngliwati pasar, nggarap klien, terus-terusan njelajah pasar lan ngganti titik pungkasan B. Kajaba iku, luwih kerep perusahaan ngganti arah, luwih sukses ing pungkasan, amarga luwih milih pasar. relung.
Strategi kasebut dituduhake dening perusahaan sing menarik sing aku sinau. One Box Shave minangka layanan pangiriman langganan kanggo silet lan aksesoris cukur ing kothak. Padha ngerti carane ngatur "kothak" kanggo klien beda. Iki ditindakake dening piranti lunak tartamtu, sing banjur ngirim pesenan menyang pabrik Korea sing ngasilake produk kasebut.
Produk iki dituku dening Unilever kanthi rega $1 milyar. Saiki saingan karo Gillette lan wis njupuk bagean pinunjul saka konsumen ing pasar Amérika. Siji Box Shave ngandika:
- 4 lading? Apa sampeyan serius? Napa sampeyan butuh iki - ora nambah kualitas cukur. Krim sing dipilih khusus, wewangian lan silet bermutu kanthi rong lading ngatasi masalah sing luwih akeh tinimbang 4 lading Gillette sing bodho! Apa kita bakal entuk 10 enggal?
Iki carane donya diganti. Unilever ngaku yen dheweke duwe sistem IT sing apik sing ngidini sampeyan nindakake iki. Ing pungkasan katon kaya konsep Wektu-kanggo-pasar, sing durung ana sing ngomong.
Titik Wektu-kanggo-pasar ora sepira kerepe kita nyebarake. Sampeyan bisa kerep nyebar, nanging siklus rilis bakal dawa. Yen siklus rilis telung sasi ditumpangake ing saben liyane, owah-owahan seminggu, pranyata manawa perusahaan kasebut nyebarake seminggu sepisan. Lan saka ide nganti implementasine pungkasan butuh 3 wulan.
Wektu-kanggo-pasar babagan nyilikake wektu saka ide nganti implementasine pungkasan.
Ing kasus iki, piranti lunak sesambungan karo pasar. Iki carane situs web One Box Shave sesambungan karo klien. Dheweke ora duwe salesman - mung situs web sing pengunjung ngeklik lan ninggalake kepinginan. Patut, soko anyar kudu terus-terusan dikirim ing situs lan dianyari sesuai karo wishes. Contone, ing Korea Selatan padha cukur brengos beda saka ing Rusia, lan padha seneng gondho ora saka pinus, nanging, contone, saka wortel lan vanilla.
Amarga perlu ngganti isi situs kanthi cepet, pangembangan piranti lunak owah-owahan banget. Liwat piranti lunak kita kudu ngerteni apa sing dikarepake klien. Sadurunge, kita sinau iki liwat sawetara cara roundabout, contone, liwat manajemen bisnis. Banjur kita ngrancang, sijine syarat menyang sistem IT, lan kabeh iku kelangan. Saiki beda - piranti lunak dirancang dening kabeh wong sing melu proses kasebut, kalebu insinyur, amarga liwat spesifikasi teknis dheweke sinau cara kerja pasar lan uga nuduhake wawasan karo bisnis kasebut.
Contone, ing Qik, dumadakan kita ngerti manawa wong seneng banget ngunggah dhaptar kontak menyang server, lan dheweke menehi aplikasi. Wiwitane kita ora mikir babagan iki. Ing perusahaan klasik, kabeh wong bakal mutusake manawa iki minangka bug, amarga spek kasebut ora ujar manawa kudu kerjane apik lan umume ditindakake ing dhengkul, dheweke bakal mateni fitur kasebut lan ujar: "Ora ana sing butuh iki. sing paling penting yaiku fungsi utama sing bisa digunakake.” . Lan perusahaan teknologi ndeleng iki minangka kesempatan lan wiwit ngganti piranti lunak miturut iki.
Ing taun 1968, wong visioner, Melvin Conway, ngrumusake gagasan ing ngisor iki.
Organisasi sing nggawe sistem diwatesi dening desain sing niru struktur komunikasi organisasi kasebut.
Kanthi luwih rinci, kanggo ngasilake sistem saka jinis sing beda, sampeyan uga kudu duwe struktur komunikasi ing perusahaan saka jinis sing beda. Yen struktur komunikasi sampeyan minangka hirarkis paling dhuwur, mula iki ora bakal ngidini sampeyan nggawe sistem sing bisa nyedhiyakake indikator Wektu-kanggo-Pasar sing dhuwur banget.
maca bisa . Penting kanggo mangerteni budaya utawa filosofi DevOps amarga mung siji-sijine sing owah-owahan dhasar ing DevOps yaiku struktur komunikasi antarane tim.
Saka sudut pandang proses, sadurunge DevOps, kabeh tahapan: analytics, pangembangan, testing, operasi, padha linear.
Ing kasus DevOps, kabeh proses kasebut kedadeyan bebarengan.
Wektu-kanggo-pasar mung cara sing bisa ditindakake. Kanggo wong sing kerja ing proses lawas, iki katon rada kosmik, lan umume kaya ngono.
Dadi kenapa sampeyan butuh DevOps?
Kanggo pangembangan produk digital. Yen perusahaan sampeyan ora duwe produk digital, DevOps ora dibutuhake - iku penting banget.
DevOps ngatasi watesan kacepetan produksi piranti lunak sing berurutan. Ing kabeh proses kedadeyan bebarengan.
Kesulitan mundhak. Nalika penginjil DevOps ngandhani yen bakal luwih gampang sampeyan ngeculake piranti lunak, iki ora ana gunane.
Kanthi DevOps, kabeh bakal dadi luwih rumit.
Ing konferensi ing stand Avito, sampeyan bisa ndeleng kaya apa nyebarake wadhah Docker - tugas sing ora realistis. Kerumitan dadi prohibitive; sampeyan kudu juggle akeh bal ing wektu sing padha.
DevOps rampung ngganti proses lan organisasi ing perusahaan - luwih tepat, dudu DevOps sing diganti, nanging produk digital. Kanggo teka ing DevOps, sampeyan isih kudu ngganti proses iki.
Pitakonan kanggo spesialis
Apa sampeyan duwe? Pitakonan sing bisa sampeyan takon dhewe nalika kerja ing perusahaan lan berkembang minangka spesialis.
Apa sampeyan duwe strategi kanggo nggawe produk digital? Yen ana, iku wis apik. Iki tegese perusahaan sampeyan pindhah menyang DevOps.
Apa perusahaan sampeyan wis nggawe produk digital? Iki tegese sampeyan bisa munggah level liyane sing luwih dhuwur lan nindakake perkara sing luwih menarik - maneh saka sudut pandang DevOps. Aku mung ngomong saka sudut pandang iki.
Apa perusahaan sampeyan minangka salah sawijining pimpinan pasar ing niche produk digital? Spotify, Yandex, Uber minangka perusahaan sing saiki ana ing puncak kemajuan teknologi.
Takon dhewe pitakon iki, lan yen kabeh jawaban ora, mula sampeyan ora kudu nindakake DevOps ing perusahaan iki. Yen topik DevOps pancen menarik kanggo sampeyan, mungkin ... sampeyan kudu pindhah menyang perusahaan liya? Yen perusahaan sampeyan pengin mlebu DevOps, nanging sampeyan mangsuli "Ora" kanggo kabeh pitakon, mula kaya badhak sing ayu sing ora bakal owah.
organisasi
Kaya sing dakkandhakake, miturut Hukum Conway, organisasi perusahaan ganti. Aku bakal miwiti apa sing nyegah DevOps nembus ing perusahaan saka sudut pandang organisasi.
Masalah "sumur"
Tembung Inggris "Silo" diterjemahake ing basa Rusia minangka "sumur". Titik masalah iki yaiku ora ana ijol-ijolan informasi antarane tim. Saben tim digali jero keahliane, tanpa nggawe peta umum kanggo navigasi.
Ing sawetara cara, iki ngelingake aku marang wong sing lagi wae teka ing Moskow lan durung ngerti carane navigasi peta metro. Muscovites biasane ngerti wilayahe, lan ing saindhenging Moskow bisa navigasi nganggo peta metro. Nalika teka ing Moscow kanggo pisanan, sampeyan ora duwe skill iki, lan sampeyan mung disoriented.
DevOps nyaranake ngliwati wayahe disorientasi iki lan kabeh departemen kerja sama kanggo nggawe peta interaksi umum.
Loro faktor ngalangi iki.
Akibat saka sistem manajemen perusahaan. Iki dibangun ing "sumur" hirarkis sing kapisah. Contone, ana KPI tartamtu ing perusahaan sing ndhukung sistem iki. Ing sisih liya, otak saka wong sing angel ngluwihi wates keahliane lan navigasi kabeh sistem. Iku mung ora kepenak. Bayangake yen sampeyan ana ing bandara Bangkok - sampeyan ora bakal cepet-cepet golek dalan. DevOps uga angel dilayari, mulane wong ujar manawa sampeyan kudu golek pandhuan kanggo mlebu.
Nanging sing paling penting yaiku masalah "sumur" kanggo insinyur sing diisi karo semangat DevOps, wis maca Fowler lan akeh buku liyane, ditulis kanthi nyatane. "sumur" ora ngidini sampeyan nindakake perkara sing "jelas".. Kita asring kumpul sawise DevOps Moscow, ngobrol karo siji liyane, lan wong-wong sambat:
- Kita mung pengin mbukak CI, nanging ternyata manajemen ora butuh.
Iki kedadeyan amarga CI и Proses Pangiriman Terus-terusan ana ing tapel wates karo akeh ujian. Mung tanpa ngatasi masalah "sumur" ing tingkat organisasi, sampeyan ora bakal bisa maju, ora ketompo apa sing sampeyan lakoni lan ora ketompo carane sedih.
Saben peserta ing proses ing perusahaan: pangembang backend lan frontend, testing, DBA, operasi, jaringan, digali ing arah dhewe, lan ora ana sing duwe peta umum kajaba manager, sing piye wae ngawasi lan ngatur wong nggunakake "dibagi. lan metode conquer".
Wong berjuang kanggo sawetara lintang utawa gendera, kabeh wong ngeduk keahliane.
Akibaté, nalika ana tugas kanggo nyambungake kabeh iki bebarengan lan mbangun pipa umum, lan ora ana maneh perlu perang kanggo bintang lan panji, pitakonan muncul - apa sing kudu dilakoni? We kudu teka menyang persetujuan piye wae, nanging ora ana sing mulang kita carane nindakake iki ing sekolah. Kita wis diwulang wiwit sekolah: kelas wolu - wow! - dibandhingake karo kelas pitu! Ing kene padha.
Apa padha ing perusahaan sampeyan?
Kanggo mriksa iki, sampeyan bisa takon dhewe pitakonan ing ngisor iki.
Apa tim nggunakake alat umum lan menehi kontribusi kanggo owah-owahan alat umum kasebut?
Sepira kerepe tim ngatur maneh-sawetara spesialis saka siji tim pindhah menyang tim liyane? Ing lingkungan DevOps, iki dadi normal, amarga kadhangkala ana wong sing ora ngerti apa sing ditindakake dening keahlian liyane. Dheweke pindhah menyang departemen liyane, kerja ing kono rong minggu kanggo nggawe peta orientasi lan interaksi karo departemen iki.
Apa bisa mbentuk panitia owah-owahan lan ngganti samubarang? Utawa mbutuhake tangan sing kuwat saka manajemen lan arah sing paling dhuwur? Aku bubar nulis ing Facebook kepiye bank sing ora ngerti ngetrapake alat liwat pesenan: kita nulis pesenan, kita ngetrapake sajrone setaun, lan ndeleng apa sing kedadeyan. Iki, mesthi, dawa lan sedih.
Sepira pentinge manajer nampa prestasi pribadi tanpa mikirake prestasi perusahaan?
Yen sampeyan mangsuli pitakon kasebut dhewe, bakal luwih jelas manawa sampeyan duwe masalah kasebut ing perusahaan sampeyan.
Infrastruktur minangka kode
Sawise masalah iki liwati, laku penting pisanan, tanpa kang angel kanggo advance luwih ing DevOps, punika infrastruktur minangka kode.
Paling asring, infrastruktur minangka kode dirasakake kaya ing ngisor iki:
— Ayo ngotomatisasi kabeh ing bash, tutup nganggo skrip supaya admin kurang kerja manual!
Nanging kuwi ora bener.
Infrastruktur minangka kode tegese sampeyan njlèntrèhaké sistem IT sing sampeyan gunakake ing wangun kode supaya bisa terus ngerti kahanane.
Bebarengan karo tim liyane, sampeyan nggawe peta ing wangun kode sing kabeh wong bisa ngerti lan bisa navigasi lan navigasi. Ora preduli apa sing ditindakake - Chef, Ansible, Salt, utawa nggunakake file YAML ing Kubernetes - ora ana bedane.
Ing konferensi kasebut, kolega saka 2GIS ngandhani carane nggawe internal dhewe kanggo Kubernetes, sing nggambarake struktur sistem individu. Kanggo njlèntrèhaké 500 sistem, padha mbutuhake alat kapisah sing ngasilake gambaran iki. Nalika ana katrangan iki, saben wong bisa mriksa siji liyane, ngawasi owah-owahan, carane ngganti lan nambah, apa sing ilang.
Setuju, skrip bash individu biasane ora menehi pangerten iki. Ing salah sawijining perusahaan sing aku kerja, malah ana jeneng kanggo skrip "nulis mung" - nalika naskah kasebut ditulis, nanging ora bisa diwaca maneh. Aku iki menowo kanggo sampeyan uga.
Infrastruktur minangka kode kode sing nggambarake kahanan saiki infrastruktur. Akeh produk, infrastruktur, lan tim layanan sing makarya bebarengan ing kode iki, lan sing paling penting, kabeh kudu ngerti cara kerjane kode iki.
Kode kasebut dijaga miturut praktik kode sing paling apik: pembangunan bebarengan, review kode, XP-programming, testing, narik panjalukan, CI kanggo infrastruktur kode - kabeh iki cocok lan bisa digunakake.
Kode dadi basa umum kanggo kabeh insinyur.
Ngganti infrastruktur ing kode ora butuh wektu akeh. Ya, kode infrastruktur uga bisa duwe utang teknis. Biasane tim nemoni setahun lan setengah sawise padha miwiti ngleksanakake "infrastruktur minangka kode" ing wangun Bunch saka Tulisan utawa malah Ansible, kang padha nulis kaya kode spageti, lan padha uga uncalan Tulisan bash menyang campuran!
penting: Yen sampeyan durung nyoba iki, elinga Ansible ora bash! Waca dokumentasi kasebut kanthi teliti, sinau apa sing ditulis babagan.
Infrastruktur minangka kode yaiku pamisahan kode infrastruktur dadi lapisan sing kapisah.
Ing perusahaan kita, kita mbedakake 3 lapisan dhasar, sing cetha banget lan prasaja, nanging bisa uga ana luwih akeh. Sampeyan bisa ndeleng kode infrastruktur lan ngerti apa sampeyan duwe kondisi iki utawa ora. Yen ora ana lapisan sing disorot, sampeyan kudu njupuk sawetara wektu lan refactor sethithik.
lapisan dhasar - iki carane OS, serep lan bab-tingkat kurang liyane diatur, contone, carane Kubernetes disebarake ing tingkat dhasar.
Tingkat layanan - iki minangka layanan sing diwenehake kanggo pangembang: logging minangka layanan, ngawasi minangka layanan, database minangka layanan, balancer minangka layanan, antrian minangka layanan, Pangiriman Terus-terusan minangka layanan - sekelompok layanan sing tim individu bisa nyedhiyani pembangunan. Iki kabeh kudu diterangake ing modul kapisah ing sistem manajemen konfigurasi.
Lapisan ing ngendi aplikasi digawe lan nerangake carane bakal mbukak ing ndhuwur rong lapisan sadurunge.
Pitakonan kontrol
Apa perusahaan sampeyan duwe gudang infrastruktur umum? Apa sampeyan ngatur utang teknis ing infrastruktur sampeyan? Apa sampeyan nggunakake praktik pangembangan ing repositori infrastruktur? Apa infrastruktur sampeyan diiris dadi lapisan? Sampeyan bisa mriksa diagram Base-service-APP. Carane angel iku kanggo nggawe owah-owahan?
Yen sampeyan wis ngalami sing njupuk dina lan setengah kanggo nggawe owah-owahan, iki tegese sampeyan duwe utang technical lan kudu bisa karo. Sampeyan mung kesandhung ing rake utang teknis ing kode infrastruktur sampeyan. Aku ngelingi akeh crita kaya nalika, kanggo ngganti sawetara CCTL, sampeyan kudu nulis ulang setengah saka kode infrastruktur, amarga kreatifitas lan kepinginan kanggo ngotomatisasi kabeh mimpin kanggo kasunyatan sing kabeh wis corroded nang endi wae, kabeh gagang wis dibusak, lan iku perlu kanggo refactor.
Pangiriman Terus-terusan
Ayo mbandhingake debit karo kredit. Pisanan nerangake gambaran babagan infrastruktur, sing bisa dadi dhasar. Sampeyan ora kudu njlèntrèhaké kabeh kanthi rinci, nanging sawetara katrangan dhasar dibutuhake supaya sampeyan bisa nggarap. Yen ora, ora jelas apa sing kudu ditindakake kanthi pangiriman terus-terusan sabanjure. Kabeh praktik kasebut mbukak bebarengan nalika sampeyan teka ing DevOps, nanging diwiwiti kanthi ngerti apa sing sampeyan duwe lan cara ngatur. Iki minangka praktik infrastruktur minangka kode.
Sawise dadi cetha yen sampeyan duwe lan carane ngatur, sampeyan bakal miwiti kanggo ngerti carane ngirim kode pangembang kanggo produksi minangka cepet sabisa. Maksudku bebarengan karo pangembang - kita ngelingi masalah "sumur", yaiku, dudu wong individu sing nggawe iki, nanging tim.
Nalika kita karo Vanya Evtukhovich weruh buku pisanan Jez Humble lan klompok penulis "Pengiriman Terus", kang dirilis ing 2009, kita mikir kanggo dangu babagan carane nerjemahake judhul menyang Rusian. Dheweke pengin nerjemahake minangka "Terus ngirim", nanging, sayangé, diterjemahaké minangka "Pangiriman terus-terusan". Iku misale jek kula sing ana soko Rusia ing jeneng kita, kanthi tekanan.
Terus ngirim sarana
Kode sing ana ing gudang produk tansah bisa diundhuh menyang produksi. Dheweke bisa uga ora kempis, nanging dheweke mesthi siap. Mulane, sampeyan tansah nulis kode kanthi rasa kuwatir sing angel dijlentrehake ing ngisor balunge. Asring katon nalika sampeyan muter kode infrastruktur. Rasa kuwatir iki kudu ana - nyebabake proses otak sing ngidini sampeyan nulis kode kanthi beda. Iki kudu dicathet ing aturan ing pangembangan.
Kanggo ngirim kanthi konsisten, sampeyan butuh format artefak sing mlaku ing platform infrastruktur. Yen sampeyan mbuwang "sampah urip" saka macem-macem format ing platform infrastruktur, banjur dadi manunggal, angel kanggo njaga, lan masalah utang technical muncul. Format artefak kudu didadekake siji - iki uga tugas kolektif: kita kabeh kudu kumpul, rustle otak lan nggawe format iki.
Artefak kasebut terus-terusan ditingkatake lan owah-owahan sing cocog karo lingkungan produksi nalika pindhah liwat pipa pangiriman. Nalika artefak obah ing sadawane pipa, iku terus-terusan nemoni sawetara perkara sing ora trep, sing padha karo artefak sing dilebokake ing produksi. Yen ing pangembangan klasik iki ditindakake dening administrator sistem sing nindakake rollout, banjur ing proses DevOps iki kedadeyan kabeh: ing kene dheweke nyoba karo sawetara tes, ing kene dheweke dibuwang menyang kluster Kubernetes, sing meh padha. menyang produksi, banjur dumadakan padha miwiti testing mbukak.
Iki kaya-kaya kaya game Pac-Man - artefak kasebut ngliwati sawetara crita. Ing wektu sing padha, penting kanggo ngontrol apa kode kasebut bener-bener ngliwati crita lan apa ana hubungane karo produksi sampeyan. Crita saka produksi bisa diseret menyang proses Pangiriman Terus-terusan: kaya iki nalika ana sing tiba, saiki ayo program skenario iki ing sistem. Saben-saben kode bakal ngliwati skenario iki, lan sampeyan ora bakal nemoni masalah iki ing wektu sabanjure. Sampeyan bakal sinau babagan iki luwih awal tinimbang tekan klien sampeyan.
Sastranegara penyebaran beda. Contone, sampeyan nggunakake tes AB utawa penyebaran kenari kanggo nyoba kode kanthi beda ing klien sing beda-beda, entuk informasi babagan cara kode kasebut, lan luwih awal tinimbang nalika diluncurake menyang 100 yuta pangguna.
"Konsisten ngirim" katon kaya iki.
Proses pangiriman Dev, CI, Test, PreProd, Prod dudu lingkungan sing kapisah, iki minangka tahapan utawa stasiun kanthi jumlah tahan geni sing dilewati artefak sampeyan.
Yen sampeyan duwe kode infrastruktur sing diterangake minangka Base Service APP banjur mbantu aja lali kabeh naskah, lan tulisen minangka kode kanggo artefak iki, ningkataké artefak lan ngganti nalika sampeyan lunga.
Pitakonan self-test
Wektu saka deskripsi fitur kanggo diluncurake menyang produksi ing 95% kasus kurang saka seminggu? Apa kualitas artefak nambah ing saben tahapan pipa? Apa ana crita sing ditindakake? Apa sampeyan nggunakake strategi panyebaran sing beda?
Yen kabeh jawaban ya, mula sampeyan pancen luar biasa! Tulis jawaban sampeyan ing komentar - Aku bakal bungah).
Saran
Iki minangka praktik sing paling angel. Ing konferensi DevOpsConf, kolega saka Infobip, ngomong babagan iki, rada bingung ing tembung-tembunge, amarga iki pancen praktik sing rumit banget babagan kasunyatan manawa sampeyan kudu ngawasi kabeh!
Contone, wektu kepungkur, nalika aku kerja ing Qik lan kita ngerti yen kita kudu ngawasi kabeh. Kita nindakake iki, lan saiki duwe 150 item ing Zabbix, sing terus dipantau. Iku medeni, direktur teknis bengkong driji ing kuil:
- Wong lanang, kok sampeyan ngrudopekso server sing ora jelas?
Nanging banjur kedadeyan sing nuduhake yen iki pancen strategi sing apik banget.
Salah sawijining layanan wiwit nabrak terus-terusan. Kaping pisanan, ora nabrak, sing menarik, kode kasebut ora ditambahake ing kana, amarga iku broker dhasar, sing praktis ora ana fungsi bisnis - mung ngirim pesen antarane layanan individu. Layanan kasebut ora owah sajrone 4 sasi, lan dumadakan wiwit nabrak kanthi kesalahan "Segmentation fault".
Kita kaget, mbukak grafik ing Zabbix, lan ternyata seminggu lan setengah kepungkur, prilaku panjaluk ing layanan API sing digunakake dening broker iki diganti banget. Sabanjure kita weruh yen frekuensi ngirim jinis pesen tartamtu wis diganti. Mengko kita ngerteni manawa iki minangka klien Android. We takon:
— Wong lanang, apa sing kedadeyan karo sampeyan seminggu setengah kepungkur?
Kanggo nanggepi, kita krungu crita sing menarik babagan carane ngrancang ulang UI. Ora ana sing bakal langsung ngomong yen dheweke ngganti perpustakaan HTTP. Kanggo klien Android, kaya ngganti sabun ing jedhing - padha ora ngelingi. Akibaté, sawise 40 menit obrolan, kita nemokake yen dheweke wis ngganti perpustakaan HTTP, lan wektu standar wis diganti. Iki nyebabake prilaku lalu lintas ing server API ganti, sing nyebabake kahanan sing nyebabake balapan ing broker kasebut, lan wiwit nabrak.
Tanpa ngawasi jero, umume ora bisa mbukak iki. Yen organisasi isih duwe masalah "sumur", nalika saben wong mbuwang dhuwit, iki bisa urip nganti pirang-pirang taun. Sampeyan mung miwiti maneh server amarga ora bisa ngatasi masalah kasebut. Nalika sampeyan ngawasi, nglacak, nglacak kabeh acara sing sampeyan duwe, lan nggunakake ngawasi minangka testing - nulis kode lan langsung nuduhake carane ngawasi, uga ing wangun kode (kita wis duwe infrastruktur minangka kode), kabeh dadi cetha carane ing telapak tangan. Malah masalah rumit kuwi gampang dilacak.
Nglumpukake kabeh informasi babagan apa sing kedadeyan ing artefak ing saben tahap proses pangiriman - ora ing produksi.
Unggah pemantauan menyang CI, lan sawetara perkara dhasar bakal katon ing kana. Mengko sampeyan bakal weruh ing Test, PredProd, lan testing mbukak. Nglumpukake informasi ing kabeh tahapan, ora mung metrik, statistik, nanging uga log: carane aplikasi diluncurake, anomali - ngumpulake kabeh.
Yen ora, bakal angel ngerteni. Aku wis ujar manawa DevOps luwih rumit. Kanggo ngatasi kerumitan iki, sampeyan kudu duwe analytics normal.
Pitakonan kanggo ngontrol diri
Apa ngawasi lan logging alat pangembangan kanggo sampeyan? Nalika nulis kode, apa pangembang sampeyan, kalebu sampeyan, mikir babagan carane ngawasi?
Apa sampeyan krungu masalah saka pelanggan? Apa sampeyan luwih ngerti klien saka ngawasi lan logging? Apa sampeyan luwih ngerti sistem saka ngawasi lan logging? Apa sampeyan ngganti sistem mung amarga sampeyan ndeleng tren ing sistem saya akeh lan sampeyan ngerti yen ing 3 minggu liyane kabeh bakal mati?
Sawise sampeyan duwe telung komponen kasebut, sampeyan bisa mikir babagan platform infrastruktur apa sing sampeyan duwe ing perusahaan sampeyan.
Platform infrastruktur
Intine dudu piranti sing beda-beda sing saben perusahaan duwe.
Titik platform infrastruktur yaiku kabeh tim nggunakake alat kasebut lan ngembangake bebarengan.
Cetha yen ana tim kapisah sing tanggung jawab kanggo pangembangan potongan individu saka platform infrastruktur. Nanging ing wektu sing padha, saben insinyur duwe tanggung jawab kanggo pangembangan, kinerja, lan promosi platform infrastruktur. Ing tingkat internal dadi alat umum.
Kabeh tim ngembangake platform infrastruktur lan nganggep kanthi ati-ati minangka IDE dhewe. Ing IDE sampeyan nginstal plugins beda kanggo nggawe kabeh apik lan cepet, lan hotkeys ngatur. Nalika sampeyan mbukak Sublime, Atom utawa Visual Studio Code, kesalahan kode ditibakake lan sampeyan ngerti manawa ora bisa digunakake, sampeyan langsung sedhih lan sampeyan mbukak kanggo ndandani IDE.
Nambani platform infrastruktur sampeyan kanthi cara sing padha. Yen sampeyan ngerti yen ana sing salah, tinggalake panjaluk yen sampeyan ora bisa ndandani dhewe. Yen ana sing prasaja, nyunting dhewe, ngirim panjaluk narik, wong lanang bakal nimbang lan nambah. Iki minangka pendekatan sing rada beda kanggo alat teknik ing kepala pangembang.
Platform infrastruktur njamin transfer artefak saka pangembangan menyang klien kanthi kualitas terus-terusan. IP diprogram karo sakumpulan crita sing kedadeyan ing kode ing produksi. Sajrone pirang-pirang taun pembangunan, akeh crita kasebut, sawetara sing unik lan mung ana hubungane karo sampeyan - ora bisa digoleki ing Google.
Ing wektu iki, platform infrastruktur dadi kauntungan kompetitif sampeyan, amarga wis dibangun soko sing ora ana ing alat pesaing. IP sampeyan luwih jero, luwih gedhe keuntungan kompetitif sampeyan saka segi Time-to-market. Katon ing kene masalah kunci vendor: Sampeyan bisa njupuk platform wong liya, nanging nggunakake pengalaman wong liya, sampeyan ora bakal ngerti carane cocog kanggo sampeyan. Ya, ora saben perusahaan bisa mbangun platform kaya Amazon. Iki baris angel ngendi pengalaman perusahaan cocog kanggo posisi ing pasar, lan sampeyan ora bisa nggunakake kunci vendor ana. Iki uga penting kanggo dipikirake.
Skema
Iki minangka diagram dhasar saka platform infrastruktur sing bakal mbantu nyiyapake kabeh praktik lan proses ing perusahaan DevOps.
Ayo kang katon ing apa iku kasusun saka.
Sistem orkestrasi sumber daya, sing nyedhiyakake CPU, memori, disk menyang aplikasi lan layanan liyane. Ing ndhuwur iki - layanan tingkat kurang: ngawasi, logging, CI / CD Engine, panyimpenan artefak, infrastruktur minangka kode sistem.
Layanan tingkat sing luwih dhuwur: database minangka layanan, antrian minangka layanan, Load Balance minangka layanan, ukuran gambar minangka layanan, pabrik Big Data minangka layanan. Ing ndhuwur iki - pipeline sing ngirim kode sing terus-terusan diowahi menyang klien sampeyan.
Sampeyan nampa informasi babagan cara piranti lunak sampeyan bisa digunakake kanggo klien, ngganti, nyuplai kode iki maneh, nampa informasi - lan sampeyan terus ngembangake platform infrastruktur lan piranti lunak sampeyan.
Ing diagram, pipa pangiriman kasusun saka pirang-pirang tahapan. Nanging iki diagram skematis sing diwenehake minangka conto - ora perlu mbaleni siji-siji. Tahap sesambungan karo layanan kaya layanan-saben bata saka platform duwe crita dhewe: carane sumber daya dialokasikan, carane aplikasi diluncurake, bisa digunakake karo sumber daya, dipantau, lan owah-owahan.
Penting kanggo ngerti manawa saben bagean platform nggawa crita, lan takon dhewe babagan crita apa sing ditindakake bata iki, bisa uga kudu dibuwang lan diganti karo layanan pihak katelu. Contone, iku bisa kanggo nginstal Okmeter tinimbang bata? Mungkin wong lanang wis ngembangake keahlian iki luwih akeh tinimbang kita. Nanging bisa uga ora - mbok menawa kita duwe keahlian unik, kita kudu nginstal Prometheus lan ngembangake luwih lanjut.
Nggawe platform
Iki minangka proses komunikasi sing kompleks. Yen sampeyan duwe praktik dhasar, sampeyan miwiti komunikasi antarane insinyur lan spesialis sing beda-beda sing ngembangake syarat lan standar, lan terus-terusan ngganti piranti lan pendekatan sing beda. Budaya sing ana ing DevOps penting ing kene.
Kanthi budaya, kabeh gampang banget - iku babagan kolaborasi lan komunikasi, yaiku, kepinginan kanggo bisa ing lapangan umum karo saben liyane, kepinginan kanggo nggunakake siji instrument bebarengan. Ora ana ilmu roket ing kene - kabeh gampang banget, banal. Contone, kita kabeh manggon ing lawang lan tetep resik - tingkat budaya.
Apa sampeyan duwe?
Maneh, pitakonan sampeyan bisa takon dhewe.
Apa platform infrastruktur darmabakti? Sapa sing tanggung jawab kanggo pangembangane? Apa sampeyan ngerti kaluwihan kompetitif platform infrastruktur sampeyan?
Sampeyan kudu terus takon dhewe pitakonan iki. Yen ana sing bisa ditransfer menyang layanan pihak katelu, mula kudu ditransfer, yen layanan pihak katelu wiwit mblokir gerakan sampeyan, mula sampeyan kudu nggawe sistem dhewe.
Dadi, DevOps ...
... iki minangka sistem sing kompleks, kudu duwe:
- Produk digital.
- Modul bisnis sing ngembangake produk digital iki.
- Tim produk sing nulis kode.
- Praktek Pangiriman Terus-terusan.
- Platform minangka layanan.
- Infrastruktur minangka layanan.
- Infrastruktur minangka kode.
- Praktek kapisah kanggo njaga linuwih, dibangun ing DevOps.
- Praktek umpan balik sing nggambarake kabeh.
Sampeyan bisa nggunakake diagram iki, nyorot apa sing wis ana ing perusahaan sampeyan ing sawetara wujud: wis dikembangake utawa isih kudu dikembangake.
Bakal rampung ing sawetara minggu . minangka bagéan saka RIT ++. Teka ing konferensi kasebut, ing ngendi sampeyan bakal nemokake akeh laporan sing apik babagan pangiriman terus-terusan, infrastruktur minangka kode lan transformasi DevOps. , tanggal pungkasan rega yaiku 20 Mei
Source: www.habr.com