Abdi nembé ngahadiran DevOpsForum 2019, anu diayakeun ku Logrocon. Dina konperénsi ieu, pamilon nyobian milarian solusi sareng alat anyar pikeun interaksi anu efektif antara bisnis sareng pamekaran sareng spesialis jasa téknologi inpormasi.
Konperénsi éta suksés: aya seueur laporan anu mangpaat, format presentasi anu pikaresepeun sareng seueur komunikasi sareng panyatur. Sareng penting pisan yén teu aya anu ngusahakeun ngajual nanaon ka kuring, hal anu narasumber dina konperénsi ageung parantos kaliru.
Kutipan tina pidato Raiffeisenbank, Alfastrakhovanie, pangalaman Mango Telecom dina ngalaksanakeun otomatisasi sareng detil sanésna dina cut.
Nami abdi Yana, abdi damel salaku tester, abdi ngalakukeun automation, ogé DevOps, sareng abdi resep kana konperénsi sareng rapat. Sapanjang dua taun katukang, kuring kantos ka konferensi Oleg Bunin (HighLoad ++, TeamLead Conf), acara Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Anu mimiti, kuring narik perhatian kana program konperénsi. Kuring neuteup kirang dina naon laporan bakal ngeunaan, sarta leuwih dina speaker. Sanaos laporan tétéla pisan téknologis sareng pikaresepeun, éta sanés kanyataan yén anjeun bakal tiasa nerapkeun sababaraha prakték pangsaéna tina laporan di perusahaan anjeun. Teras anjeun peryogi spiker.
Cahaya dina tungtung pipa di Raiffeisenbank
Biasana, kuring moro speaker dina sela-sela nu dipikaresep ku kuring. Di DevOpsForum 2019, spiker ti Raiffeisenbank, Mikhail Bizhan, narik minat kuring. Dina pidatona, anjeunna nyarioskeun kumaha aranjeunna laun-laun ngahubungkeun timna dina DevOps, naha aranjeunna peryogina, sareng kumaha cara ngajual ideu transformasi DevOps kana bisnis. Nya, sacara umum, kuring nyarioskeun kumaha ningali cahaya dina tungtung pipa.
Mikhail Bizhan, diréktur automation di Raiffeisenbank
Ayeuna aranjeunna henteu ngagaduhan "DevOps" di perusahaanna. Nyaéta, anjeunna damel, tapi henteu di sadaya tim. Nalika ngalaksanakeun DevOps, aranjeunna ngandelkeun kesiapan tim, boh dina hal insinyur khusus, sareng dina hal kabutuhan produk sareng kematangan platform dimana produk ieu diwangun. Misha nyarioskeun kumaha ngajelaskeun ka bisnis naha DevOps diperyogikeun.
Bagéan perbankan ngagaduhan sababaraha panggerak pertumbuhan: biaya jasa sareng ékspansi basis klien. Ngaronjatkeun biaya jasa sanés mangrupikeun supir anu saé, tapi ningkatkeun basis klien nyaéta sabalikna. Lamun pesaing ngaleupaskeun hiji produk obyektif tiis, sadaya konsumén indit ka dinya, lajeng kana waktu tingkat pasar kaluar. Ku alatan éta, ngenalkeun produk anyar ka pasar sareng laju perkenalanna mangrupikeun hal utama anu difokuskeun ku bank. Ieu persis pikeun DevOps, sareng usaha ngartos ieu.
Catetan penting salajengna: DevOps henteu salawasna ngirangan waktos ka pasar. DevOps teu tiasa dianggo nyalira, éta ngan bagian tina prosés nyiptakeun sareng nyangking produk ka pasar tina pamekaran ka produksi (tina kode ka palanggan). Tapi sadayana sateuacan kode henteu langsung aya hubunganana sareng DevOps. Hartina, marketers bisa diajar pasar pikeun taun sarta méakkeun sakabéh kahirupan maranéhanana catching up kalawan pesaing. Perlu gancang ngartos naon anu diperyogikeun ku klien sareng ngarencanakeun palaksanaan fitur ieu atanapi éta - sering ieu anu henteu cekap pikeun DevOps damel sareng perusahaan pikeun ngahontal tujuanana. Ku alatan éta, mimiti sagala, Raiffeisenbank sapuk jeung bisnis anu diperlukeun pikeun neuleuman kumaha carana make DevOps. Automation demi automation moal mantuan loba dina tarung pikeun konsumén anyar.
Sacara umum, Misha percaya yén DevOps kedah dilaksanakeun, tapi sacara bijaksana. Sarta kami kudu disiapkeun pikeun kanyataan yén dina awal transformasi produktivitas tim urang bakal lungsur, éta bakal earn kirang duit, tapi lajeng bakal diyakinkeun.
Automation tina nguji di Mango Telecom
laporan sejen metot pikeun kuring salaku tester dibikeun ku Egor Maslov ti Mango Telecom. Presentasi éta disebut "Otomasi siklus tés lengkep dina tim SCRUM." Egor percaya yén DevOps didamel khusus pikeun SCRUM, tapi dina waktos anu sami, ngenalkeun DevOps kana tim SCRUM rada masalah. Ieu kajadian sabab tim SCRUM sok ngajalankeun wae, teu aya waktu keur kacau ku inovasi jeung ngawangun deui prosés. Masalahna ogé aya dina kanyataan yén SCRUM henteu ngalibetkeun pamisahan sub-tim dina tim (tim uji, tim pangembangan, sareng sajabana). Nya, salian ti éta, pikeun ngajadikeun otomatis prosés anu aya, dokuméntasi diperyogikeun, sareng dina SCRUM, paling sering henteu aya dokuméntasi lengkep - "produk langkung penting tibatan sababaraha jinis tulisan."
Saatos ngalih ka SCRUM, panguji mimiti konsultasi sareng pamekar ngeunaan cara nguji fitur. Saeutik demi saeutik, volume fungsionalitas ningkat, teu aya dokuméntasi, sareng aranjeunna mimiti nyekel seueur bug dina fungsionalitas anu henteu katutupan ku tés sareng sacara umum henteu jelas deui saha anu diuji sareng iraha. Dina nutshell - kabingungan jeung vacillation. Urang mutuskeun pikeun pindah ka nguji automation. Tapi sanajan harita aya kagagalan lengkep. Aranjeunna hired spesialis automation outsourced anu nulis dina tumpukan kanyahoan mun testers in-imah. Kerangka pikeun autotests digawé, tangtosna, tapi sanggeus outsourcers ditinggalkeun, éta lumangsung salila dua minggu. Salajengna nya éta usaha pikeun ngawanohkeun autotesting nomer dua. Dimimitian ku kanyataan yén sadayana kedah diwangun dina perusahaan, nyalira (vektor anu leres: ngawangun kaahlian internal), dina kerangka SCRUM, sareng nyiptakeun dokuméntasi dina prosésna. Tumpukan pikeun automation kudu sarua jeung tumpukan produk (di dieu Kuring nambahkeun eta, ulah nguji proyék JavaScript anjeun kalawan nanaon sejenna). Dina ahir sprint, aranjeunna ngadamel demo kumaha autotest tiasa dianggo sareng sadayana tim (manfaat). Ku kituna, involvement sadaya anggota tim dina prosés automation ngaronjat, kitu ogé kapercayaan di autotests sarta kasempetan yén autotest ieu pasti bakal dipaké (jeung moal commented kaluar dina sabulan alatan gagal konstan).
Ku jalan kitu, di DevOpsForum 2019 aya mikropon kabuka - anu parantos dikenal sareng, dina pamanggih kuring, format pidato anu mangpaat. Anjeun leumpang sapertos kieu, ngadangukeun laporan, teras mutuskeun yén dina konperénsi éta patut ngabahas topik atanapi masalah anu tangtu, ngabagi pangalaman anu relevan dina ngarengsekeun masalah.
Kuring ogé perhatikeun yén panitia ngadamel aliran laporan pondok. Tiap laporan lumangsung teu leuwih ti 10 menit, dituturkeun ku patarosan. Ku cara ieu anjeun tiasa nutupan seueur topik sakaligus sareng naroskeun patarosan ka panyatur anu dipikaresep ku anjeun.
Antara presentasi, abdi walked sabudeureun stan sahiji mitra konferensi sarta maok / meunang loba barang. Eh, kuring resep kana handout!
Méja buleud sareng masalah DevOps sareng direktur pamekaran di Alfastrakhovanie
Icing dina jajan DevOpsForum 2019 pikeun kuring nyaéta sidang paripurna sajam sareng ahli DevOps. Opat pamilon sési diondang pikeun ningali DevOps tina sudut anu béda: Anton Isanin (Alfastrakhovanie, diréktur pamekaran), Nailya Zamashkina (Fintech Lab, diréktur operasi), Oleg Egorkin (Rostelecom, palatih tangkas) sareng Anton Martyanov (ahli mandiri, melong DevOps). tina sudut pandang bisnis).
Para ahli calik ngadeukeutan jalma-jalma teras hal-hal mimiti kajantenan: salami sajam, pamilon ti panongton naroskeun patarosanana, sareng para ahli nyandak rap. Kadang-kadang aya debat nyata. Patarosanna béda pisan, contona: insinyur DevOps diperyogikeun pisan, naha aranjeunna henteu tiasa dilatih salaku pangurus sistem, kedah DevOps ditawarkeun ka sadayana, naon nilaina, sareng sajabana.
Saterusna, kuring ngobrol jeung Anton Isanin pribadi. Kami ngabahas kabutuhan pikeun mawa budaya DevOps ka unggal bumi sareng ngungkabkeun sisi poék transformasi DevOps.
Hayu urang bayangkeun yén sadayana ngumpul sareng mutuskeun yén DevOps diperyogikeun ku produk sareng ku bisnis sareng tim. Hayu urang laksanakeun. Sagalana digawé kaluar. Urang ambekan. DevOps parantos ngadeukeutkeun urang ka klien, ayeuna urang tiasa gancang nedunan sagala kahayangna. Hasilna, urang boga departemén Ops badag kalayan peraturan ketat tur sarat, sarta eta terus manggihan defects dina produk jeung nyiptakeun kebat tina requests. Leuwih ti éta, sagala defects ditugaskeun status "urgent", sanajan klien nu teu disangka-sangka hayang warna tombol konéng tinimbang héjo. Proyék naék, jumlah sékrési ningkat sareng, sasuai, jumlah cacad sareng salah paham kana fungsionalitas énggal ku klien. Ops nyewa 10 jalma deui pikeun ngajaga laporan cacad, sareng pamekaran nyewa 15 deui pikeun nutupana. Sareng tinimbang ngenalkeun fitur-fitur anyar, tim damel sareng SD sajajalan, ngajelaskeun fungsionalitas ka pangguna sareng dukungan dina waktos anu sami. Hasilna, duanana Ops sareng pamekaran berpungsi, tapi klien sareng bisnis henteu bagja: fitur énggal macét. Tétéla yén DevOps sigana aya, tapi sigana henteu aya.
Ngeunaan kabutuhan pikeun nerapkeun DevOps, Anton jelas nyatakeun yén ieu langsung gumantung kana skala bisnis. Lamun ngalayanan hiji klien sataun brings parusahaan samilyar, DevOps teu diperlukeun (sayogi anjeun teu perlu gulung kaluar parobahan anyar pikeun klien ieu rutin). Sagalana ditutupan ku coklat. Tapi upami bisnisna tumbuh sareng langkung seueur klien muncul, maka anjeun kedah matuh. Sakumaha aturan, teu aya Ops anu keren di perusahaan mimitina. Kahiji urang motong produk, sarta ngan lajeng urang ngarti yén dina urutan pikeun produk jalan, urang kudu tetep hiji panon on server na ngawas suplai. Éta nalika Ops muncul. Tetep dipikaharti yén Ops, salaku divisi anu misah, bakal mimiti nempatkeun sakumpulan halangan pikeun pangwangunan sareng sadaya pangiriman bakal mimiti macet. Nyaéta, dina hal ieu, budaya DevOps parantos relevan, tapi urang henteu kedah hilap ngeunaan sisi poékna.
sumber: www.habr.com