Kita bercakap, sudah tentu, tentang . Jika anda tidak menjelaskan secara terperinci, maka pada 30 September dan 1 Oktober kami akan mengadakan persidangan mengenai menggabungkan proses pembangunan, ujian dan operasi, dan jika anda pergi ke butiran, sila, di bawah cat.
Dalam pendekatan DevOps, semua bahagian pembangunan teknologi projek saling berkait, berlaku secara selari dan mempengaruhi satu sama lain. Amat penting di sini ialah penciptaan proses pembangunan automatik yang boleh diubah, disimulasikan dan diuji dalam masa nyata. Ini membantu anda bertindak balas serta-merta kepada perubahan dalam pasaran.
Pada persidangan itu kami ingin menunjukkan bagaimana pendekatan ini mempengaruhi pembangunan produk. Bagaimana kebolehpercayaan dan kebolehsuaian sistem untuk pelanggan dipastikan. Bagaimana DevOps mengubah struktur dan pendekatan syarikat untuk mengatur proses kerjanya.
disebalik tabir
Adalah penting bagi kita untuk mengetahui bukan sahaja perkara yang dilakukan oleh syarikat yang berbeza dalam rangka kerja pendekatan DevOps, tetapi juga untuk memahami mengapa semua ini dilakukan. Oleh itu, kami menjemput bukan sahaja pakar untuk menyertai Jawatankuasa Program, tetapi pakar yang melihat wacana DevOps dari jawatan yang berbeza:
- jurutera kanan;
- pemaju;
- ketua pasukan;
- CTO.
Di satu pihak, ini menimbulkan kesukaran dan konflik apabila membincangkan permintaan untuk laporan. Jika seorang jurutera berminat untuk menganalisis kemalangan besar, maka adalah lebih penting bagi pembangun untuk memahami cara mencipta perisian yang berfungsi dalam awan dan infrastruktur. Tetapi dengan bersetuju, kami mencipta program yang bernilai dan menarik kepada semua orang: daripada jurutera hingga CTO.
Matlamat persidangan kami bukan sahaja untuk memilih laporan gembar-gembur yang paling banyak, tetapi untuk membentangkan gambaran keseluruhan: cara pendekatan DevOps berfungsi dalam amalan, jenis rake yang boleh anda hadapi apabila beralih ke proses baharu. Pada masa yang sama, kami membina bahagian kandungan, turun daripada masalah perniagaan kepada teknologi tertentu.
Bahagian persidangan akan kekal sama seperti dalam .
- Platform infrastruktur.
- Infrastruktur sebagai kod.
- Penghantaran berterusan.
- Maklum balas.
- Seni bina dalam DevOps, DevOps untuk CTO.
- amalan SRE.
- Latihan dan pengurusan pengetahuan.
- Keselamatan, DevSecOps.
- Transformasi DevOps.
Call for Papers: jenis laporan yang kami cari
Kami secara bersyarat membahagikan penonton berpotensi persidangan itu kepada lima kumpulan: jurutera, pembangun, pakar keselamatan, ketua pasukan dan CTO. Setiap kumpulan mempunyai motivasi tersendiri untuk datang ke persidangan tersebut. Dan, jika anda melihat DevOps daripada kedudukan ini, anda boleh memahami cara memfokuskan topik anda dan tempat untuk memberi penekanan.
Bagi jurutera, yang sedang mencipta platform infrastruktur, adalah penting untuk memahami arah aliran yang sedia ada, untuk memahami teknologi mana yang kini paling maju. Mereka akan berminat untuk belajar tentang pengalaman sebenar dalam menggunakan teknologi ini dan bertukar pendapat. Seorang jurutera akan gembira mendengar laporan yang menganalisis beberapa kemalangan tegar, dan kami, seterusnya, akan cuba memilih dan menggilap laporan sedemikian.
Untuk pemaju adalah penting untuk memahami konsep seperti aplikasi asli awan. Iaitu, bagaimana untuk membangunkan perisian supaya ia berfungsi dalam awan dan pelbagai infrastruktur. Pembangun perlu sentiasa menerima maklum balas daripada perisian. Di sini kami ingin mendengar kes tentang cara syarikat membina proses ini, cara memantau prestasi perisian dan cara keseluruhan proses penghantaran berfungsi.
Pakar keselamatan siber Adalah penting untuk memahami cara menyediakan proses keselamatan supaya ia tidak menghalang proses pembangunan dan perubahan dalam syarikat. Topik tentang keperluan yang DevOps letakkan pada pakar sedemikian juga akan menjadi menarik.
Ketua pasukan ingin tahu, bagaimana proses penghantaran berterusan berfungsi di syarikat lain. Apakah laluan yang diambil oleh syarikat untuk mencapai matlamat ini, bagaimana mereka membina proses pembangunan dan jaminan kualiti dalam DevOps. Ketua pasukan juga berminat dengan Cloud native. Dan juga soalan tentang interaksi dalam pasukan dan antara pembangunan dan pasukan kejuruteraan.
Untuk CTO perkara yang paling penting ialah memikirkan cara menghubungkan semua proses ini dan menyesuaikannya dengan keperluan perniagaan. Dia memastikan bahawa aplikasi itu boleh dipercayai untuk kedua-dua perniagaan dan pelanggan. Dan di sini anda perlu memahami teknologi mana yang akan berfungsi untuk tugas perniagaan yang mana, cara membina keseluruhan proses, dsb. CTO juga bertanggungjawab untuk belanjawan. Contohnya, dia mesti memahami jumlah wang yang perlu dibelanjakan untuk melatih semula pakar supaya mereka boleh bekerja dalam DevOps.
Jika anda mempunyai sesuatu untuk dikatakan tentang perkara ini, jangan berdiam diri, . Tarikh akhir untuk Panggilan untuk Kertas ialah 20 Ogos. Lebih awal anda mendaftar, lebih banyak masa anda perlu memuktamadkan laporan anda dan bersedia untuk pembentangan anda. Jadi, jangan berlengah.
Nah, jika anda tidak perlu bercakap secara terbuka, cuma dan datang pada 30 September dan 1 Oktober untuk berkomunikasi dengan rakan sekerja. Kami berjanji ia akan menarik dan memberi inspirasi.
Bagaimana kita melihat DevOps
Untuk memahami dengan tepat apa yang kami maksudkan dengan DevOps, saya mengesyorkan membaca (atau membaca semula) laporan saya β" Berjalan melalui gelombang pasaran, saya memerhatikan bagaimana idea DevOps berubah dalam syarikat saiz yang berbeza: daripada syarikat permulaan kecil kepada syarikat multinasional. Laporan ini dibina berdasarkan satu siri soalan, dengan menjawabnya anda boleh memahami sama ada syarikat anda bergerak ke arah DevOps atau sama ada terdapat masalah di suatu tempat.
DevOps ialah sistem yang kompleks, ia mesti termasuk:
- Produk digital.
- Modul perniagaan yang membangunkan produk digital ini.
- Pasukan produk yang menulis kod.
- Amalan Penghantaran Berterusan.
- Platform sebagai perkhidmatan.
- Infrastruktur sebagai perkhidmatan.
- Infrastruktur sebagai kod.
- Amalan berasingan untuk mengekalkan kebolehpercayaan, terbina dalam DevOps.
- Amalan maklum balas yang menerangkan semuanya.
Di penghujung laporan terdapat gambar rajah yang memberi gambaran tentang sistem DevOps dalam syarikat. Ia akan membolehkan anda melihat proses dalam syarikat anda yang telah diperkemas dan yang masih belum dibina.
Anda boleh menonton video laporan tersebut .
Dan kini akan ada bonus: beberapa video daripada RIT++ 2019, yang menyentuh isu paling umum transformasi DevOps.
Infrastruktur syarikat sebagai produk
Artyom Naumenko mengetuai pasukan DevOps di Skyeng dan menjaga pembangunan infrastruktur syarikatnya. Beliau memberitahu cara infrastruktur mempengaruhi proses perniagaan di SkyEng: cara mengira ROI untuknya, apakah metrik yang perlu dipilih untuk pengiraan dan cara berusaha untuk memperbaikinya.
Dalam perjalanan ke perkhidmatan mikro
Syarikat Nixys menyediakan sokongan untuk projek web yang sibuk dan sistem yang diedarkan. Pengarah teknikalnya, Boris Ershov, memberitahu cara menterjemah produk perisian, yang pembangunannya bermula 5 tahun lalu (atau lebih), ke platform moden.
Sebagai peraturan, projek sedemikian adalah dunia istimewa di mana terdapat sudut gelap dan purba infrastruktur yang tidak diketahui oleh jurutera semasa. Dan pendekatan kepada seni bina dan pembangunan yang pernah dipilih adalah ketinggalan zaman dan tidak dapat menyediakan perniagaan dengan kadar pembangunan dan pengeluaran versi baharu yang sama. Akibatnya, setiap keluaran produk bertukar menjadi pengembaraan yang luar biasa, di mana sesuatu sentiasa jatuh, dan di tempat yang paling tidak dijangka.
Pengurus projek sedemikian sudah pasti menghadapi keperluan untuk mengubah semua proses teknologi. Dalam laporannya, Boris berkata:
- bagaimana untuk memilih seni bina yang sesuai untuk projek dan menyusun infrastruktur;
- apakah alat untuk digunakan dan apakah perangkap yang dihadapi dalam laluan menuju transformasi;
- apa yang perlu dilakukan seterusnya.
Automasi keluaran atau cara menyampaikan dengan cepat dan tanpa rasa sakit
Alexander Korotkov ialah pembangun terkemuka sistem CI/CD di CIAN. Beliau bercakap tentang alat automasi yang memungkinkan untuk meningkatkan kualiti dan mengurangkan masa untuk menghantar kod kepada pengeluaran sebanyak 5 kali. Tetapi keputusan sedemikian tidak dapat dicapai dengan automasi sahaja, jadi Alexander juga memberi perhatian kepada perubahan dalam proses pembangunan.
Bagaimanakah kemalangan membantu anda belajar?
Alexey Kirpichnikov telah melaksanakan DevOps dan infrastruktur di SKB Kontur selama 5 tahun. Dalam tempoh tiga tahun, kira-kira 1000 fakap dari pelbagai peringkat epik berlaku di syarikatnya. Antaranya, sebagai contoh, 36% disebabkan oleh melancarkan keluaran berkualiti rendah ke dalam pengeluaran, dan 14% disebabkan oleh kerja penyelenggaraan perkakasan di pusat data.
Arkib laporan (bedah siasat) yang telah diselenggarakan oleh jurutera syarikat selama beberapa tahun berturut-turut memungkinkan untuk mendapatkan maklumat yang tepat tentang kemalangan. Bedah siasat ditulis oleh jurutera yang bertugas, yang merupakan orang pertama yang bertindak balas terhadap isyarat kecemasan dan mula membetulkan segala-galanya. Mengapa menyeksa jurutera yang bergelut pada waktu malam dengan facaps dengan menulis laporan? Data ini membolehkan anda melihat keseluruhan gambaran dan menggerakkan pembangunan infrastruktur ke arah yang betul.
Dalam ucapannya, Alexey berkongsi cara menulis postmortem yang benar-benar berguna dan bagaimana untuk melaksanakan amalan laporan sedemikian dalam sebuah syarikat besar. Jika anda suka cerita tentang bagaimana seseorang itu kacau, tonton video persembahan itu.
Kami faham bahawa visi anda tentang DevOps mungkin tidak sepadan dengan visi kami. Ia akan menjadi menarik untuk mengetahui cara anda melihat transformasi DevOps. Kongsi pengalaman dan visi anda tentang topik ini dalam ulasan.
Apakah laporan yang telah kami terima ke dalam program ini?
Minggu ini Jawatankuasa Program menerima pakai 4 laporan: tentang keselamatan, infrastruktur dan amalan SRE.
Mungkin topik transformasi DevOps yang paling menyakitkan: bagaimana untuk memastikan bahawa orang dari jabatan keselamatan maklumat tidak memusnahkan hubungan yang telah dibina antara pembangunan, operasi dan pentadbiran. Sesetengah syarikat menguruskan tanpa jabatan keselamatan maklumat. Bagaimana untuk memastikan keselamatan maklumat dalam kes ini? Mengenainya Mona Arkhipova daripada sudo.su. Daripada laporannya kita belajar:
- apa yang perlu dilindungi dan daripada siapa;
- apakah proses keselamatan rutin;
- bagaimana IT dan proses keselamatan maklumat bersilang;
- apakah CIS CSC dan cara melaksanakannya;
- bagaimana dan dengan penunjuk apa untuk menjalankan pemeriksaan keselamatan maklumat secara berkala.
Laporan seterusnya melibatkan pembangunan infrastruktur sebagai kod. Kurangkan jumlah rutin manual dan jangan ubah keseluruhan projek menjadi huru-hara, adakah ini mungkin? Kepada soalan ini Maxim Kostrikin dari Ixtens. Syarikat beliau menggunakan Terraform untuk bekerja dengan infrastruktur AWS. Alat ini mudah, tetapi persoalannya ialah bagaimana untuk mengelakkan membuat blok kod yang besar apabila menggunakannya. Penyelenggaraan legasi sedemikian akan menjadi lebih mahal setiap tahun.
Maxim akan menunjukkan cara corak peletakan kod berfungsi, bertujuan untuk memudahkan automasi dan pembangunan.
Satu lagi kita akan mendengar tentang infrastruktur daripada Vladimir Ryabov dari Playkey. Di sini kita akan bercakap tentang platform infrastruktur, dan kita akan belajar:
- bagaimana untuk memahami sama ada ruang storan digunakan dengan berkesan;
- bagaimana beberapa ratus pengguna boleh menerima 10 TB kandungan jika hanya 20 TB storan digunakan;
- bagaimana untuk memampatkan data 5 kali dan memberikannya kepada pengguna dalam masa nyata;
- bagaimana untuk menyegerakkan data dengan cepat antara beberapa pusat data;
- bagaimana untuk menghapuskan sebarang pengaruh pengguna antara satu sama lain apabila menggunakan satu mesin maya secara berurutan.
Rahsia sihir ini adalah teknologi ZFS untuk FreeBSD dan garpunya yang segar ZFS di Linux. Vladimir akan berkongsi kes daripada Playkey.
Matvey Kukuy dari Amixr.IO bersedia dengan contoh dari kehidupan , apa dah jadi SRE dan cara ia membantu membina sistem yang boleh dipercayai. Amixr.IO meneruskan insiden pelanggan melalui bahagian belakangnya; berpuluh-puluh pasukan bertugas di seluruh dunia telah menangani 150 ribu kes. Pada persidangan itu, Matvey akan berkongsi statistik dan pandangan yang telah dikumpul oleh syarikatnya dengan menyelesaikan masalah pelanggan dan menganalisis kegagalan.
Sekali lagi saya menggesa anda untuk tidak tamak dan berkongsi pengalaman anda sebagai samurai DevOps. Hidang untuk laporan, dan anda dan saya akan mempunyai 2,5 bulan untuk menyediakan ucapan yang sangat baik. Jika anda ingin menjadi pendengar, ke surat berita dengan kemas kini program dan fikirkan dengan serius tentang tempahan tiket lebih awal, kerana tiket itu akan menjadi lebih mahal lebih dekat dengan tarikh persidangan.
Sumber: www.habr.com