Kita bercakap, sudah tentu, tentang Tanpa terlalu terperinci, kami akan mengadakan persidangan pada 30 September dan 1 Oktober tentang menyepadukan proses pembangunan, ujian dan operasi. Jika anda ingin mengetahui butirannya, sila baca.
Dalam pendekatan DevOps, semua aspek 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 suai, dimodelkan dan diuji dalam masa nyata. Ini membantu untuk bertindak balas dengan segera kepada perubahan pasaran.
Pada persidangan itu, kami ingin menunjukkan cara pendekatan ini memberi kesan kepada pembangunan produk, cara ia memastikan kebolehpercayaan sistem dan kebolehsuaian untuk pelanggan, dan cara DevOps mengubah struktur dan pendekatan syarikat kepada organisasi aliran kerja.
Di sebalik tabir
Adalah penting bagi kita untuk memahami bukan sahaja perkara yang dilakukan oleh syarikat yang berbeza dalam pendekatan DevOps, tetapi juga rasional di sebalik semua itu. Itulah sebabnya kami telah menjemput bukan sahaja pakar untuk menyertai Jawatankuasa Program kami, tetapi pakar yang melihat wacana DevOps dari perspektif yang berbeza:
- jurutera kanan;
- pemaju;
- ketua pasukan;
- CTO.
Di satu pihak, ini menimbulkan kesukaran dan konflik apabila membincangkan permintaan pembentangan. Walaupun seorang jurutera berminat untuk menganalisis kemalangan besar, pembangun lebih berminat untuk memahami cara mencipta perisian yang berfungsi dalam awan dan infrastruktur. Tetapi dengan mencapai persetujuan, kami mencipta program yang bernilai dan menarik kepada semua orang, daripada jurutera hingga CTO.
Matlamat persidangan kami bukan semata-mata untuk memilih pembentangan yang paling digembar-gemburkan, tetapi untuk membentangkan gambaran besar: cara pendekatan DevOps berfungsi dalam amalan dan apakah masalah yang boleh timbul apabila beralih kepada proses baharu. Kami sedang membina kandungan, beralih daripada objektif perniagaan kepada teknologi tertentu.
Bahagian persidangan akan kekal sama seperti dalam .
- Platform infrastruktur.
- Infrastruktur sebagai kod.
- Bekalan berterusan.
- Maklum balas.
- Seni bina dalam DevOps, DevOps untuk CTO.
- amalan SRE.
- Latihan dan pengurusan pengetahuan.
- Keselamatan, DevSecOps.
- Transformasi DevOps.
Panggilan untuk Kertas: Kertas Apa Yang Kami Cari?
Kami membahagikan penonton persidangan yang berpotensi kepada lima kumpulan: jurutera, pembangun, pakar keselamatan, ketua pasukan dan CTO. Setiap kumpulan mempunyai motivasi tersendiri untuk menghadiri persidangan tersebut. Melihat DevOps dari perspektif ini membantu kami memahami cara memfokuskan perbincangan kami dan tempat untuk memberi penekanan.
Bagi jurutera, Bagi mereka yang bekerja pada platform infrastruktur, adalah penting untuk memahami arah aliran semasa dan teknologi tercanggih. Mereka akan berminat untuk belajar tentang pengalaman dunia sebenar menggunakan teknologi ini dan bertukar pendapat. Seorang jurutera akan gembira mendengar pembentangan yang menganalisis bencana tegar, dan kami akan melakukan yang terbaik untuk memilih dan memperhalusi pembentangan sedemikian.
Untuk pemaju Adalah penting untuk memahami konsep seperti itu aplikasi asli awanIaitu, 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 kajian kes tentang cara syarikat menyusun proses ini, cara memantau prestasi perisian dan cara keseluruhan proses penghantaran distrukturkan.
Untuk pakar keselamatan siber Adalah penting untuk memahami cara menyediakan proses keselamatan supaya ia tidak menghalang pembangunan dan perubahan proses dalam syarikat. Perbincangan tentang keperluan DevOps yang diletakkan pada pakar sedemikian juga akan menarik minat.
Ketua pasukan ingin tahuBagaimana penyampaian berterusan distrukturkan di syarikat lain. Apakah laluan yang diambil oleh syarikat untuk mencapai matlamat ini, bagaimana proses pembangunan dan jaminan kualiti distrukturkan dalam DevOps. Cloud native juga menarik minat ketua pasukan. Terdapat juga soalan tentang kerjasama dalam pasukan dan antara pasukan pembangunan dan kejuruteraan.
Untuk CTO Perkara yang paling penting ialah memahami cara menghubungkan semua proses ini dan menyesuaikannya dengan keperluan perniagaan. Mereka memastikan aplikasi boleh dipercayai untuk kedua-dua perniagaan dan pelanggan. Ini memerlukan pemahaman teknologi mana yang akan berfungsi untuk tugas perniagaan yang mana, cara menstruktur keseluruhan proses, dan sebagainya. CTO juga bertanggungjawab untuk belanjawan. Contohnya, mereka harus memahami jumlah wang yang diperlukan untuk melatih semula pakar supaya mereka boleh bekerja dalam DevOps.
Jika anda mempunyai sesuatu untuk dikatakan mengenai perkara ini, jangan diam, Tarikh akhir Panggilan untuk Kertas ialah 20 Ogos. Lebih awal anda menyerahkan, lebih banyak masa anda perlu memuktamadkan kertas kerja anda dan bersedia untuk pembentangan anda. Jadi, jangan berlengah.
Nah, jika anda tidak perlu bercakap di khalayak ramai, cuma Datang dan berhubung dengan rakan sekerja anda pada 30 September dan 1 Oktober. 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 dalam gelombang pasaran, saya memerhatikan bagaimana konsep DevOps berkembang dalam semua saiz syarikat, daripada syarikat permulaan kecil kepada syarikat multinasional. Perbincangan ini dibina berdasarkan satu siri soalan, jawapannya boleh membantu anda memahami sama ada syarikat anda bergerak ke arah DevOps atau sama ada terdapat cabaran.
DevOps ialah sistem kompleks yang 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.
Pada penghujung laporan, terdapat gambar rajah yang memberikan gambaran keseluruhan sistem DevOps syarikat. Ia akan membantu anda melihat proses mana yang telah diwujudkan dalam syarikat anda dan proses mana yang belum dibina.
Video laporan boleh dilihat .
Dan kini akan ada bonus: Beberapa video daripada RIT++ 2019 yang menangani isu transformasi DevOps yang paling biasa.
Infrastruktur syarikat sebagai produk
Artem Naumenko mengetuai pasukan DevOps di Skyeng dan menyelia pembangunan infrastruktur syarikatnya. Beliau membincangkan cara infrastruktur memberi kesan kepada proses perniagaan di SkyEng: cara mengira ROInya, metrik yang hendak digunakan dan cara menambah baiknya.
Ke arah perkhidmatan mikro
Nixys menyokong projek web beban tinggi dan sistem teragih. CTOnya, Boris Ershov, menjelaskan cara memodenkan produk perisian yang pembangunannya bermula lima tahun lalu (atau lebih lama lagi).
Lazimnya, projek sedemikian adalah dunia yang berbeza, dipenuhi dengan sudut gelap dan purba infrastruktur yang masih tidak diketahui oleh jurutera semasa. Dan pendekatan seni bina dan pembangunan sebaik sahaja diterima pakai sudah lapuk dan tidak lagi menyokong kadar pembangunan dan keluaran baharu perniagaan sebelum ini. Akibatnya, setiap keluaran produk menjadi pengembaraan yang luar biasa, dengan sesuatu yang sentiasa gagal, dan di tempat yang paling tidak dijangka.
Pengurus projek projek sedemikian sudah pasti menghadapi keperluan untuk mengubah semua proses teknologi. Dalam pembentangannya, Boris menjelaskan:
- Bagaimana untuk memilih seni bina yang betul untuk projek dan menyusun infrastruktur;
- alat apa yang perlu digunakan dan apa masalah yang perlu dihadapi dalam laluan menuju transformasi;
- Apa yang perlu dilakukan seterusnya.
Keluarkan automasi, atau cara menyampaikan dengan cepat dan tanpa rasa sakit
Alexander Korotkov, pembangun utama sistem CI/CD di CIAN, membincangkan alat automasi yang meningkatkan kualiti dan mengurangkan masa yang diambil untuk menghantar kod kepada pengeluaran sebanyak lima kali. Walau bagaimanapun, keputusan sedemikian tidak boleh dicapai melalui automasi sahaja, jadi Alexander turut menumpukan pada perubahan kepada proses pembangunan.
Bagaimanakah kemalangan membantu anda belajar?
Alexey Kirpichnikov telah melaksanakan DevOps dan infrastruktur di SKB Kontur selama lima tahun. Dalam tempoh tiga tahun yang lalu, syarikatnya telah mengalami kira-kira 1000 kegagalan dengan tahap keparahan yang berbeza-beza. Daripada jumlah ini, 36% disebabkan oleh menggunakan keluaran berkualiti rendah kepada pengeluaran, dan 14% disebabkan oleh penyelenggaraan perkakasan di pusat data.
Arkib laporan (postmortem), yang telah diselenggarakan oleh jurutera syarikat selama beberapa tahun, membolehkan maklumat tepat mengenai kemalangan tersebut. Postmortem ditulis oleh jurutera bertugas yang merupakan orang pertama yang bertindak balas terhadap amaran kemalangan dan memulakan pembaikan. Mengapa perlu mengganggu jurutera yang menghabiskan malam mereka melawan kegagalan dengan menulis laporan? Data ini membolehkan kami melihat keseluruhan gambaran dan menggerakkan pembangunan infrastruktur ke arah yang betul.
Dalam pembentangannya, Alexey berkongsi cara menulis postmortem yang benar-benar berguna dan cara melaksanakan laporan sedemikian di sebuah syarikat besar. Jika anda menikmati cerita tentang bagaimana seseorang itu kacau, tonton video pembentangan itu.
Kami faham bahawa visi anda tentang DevOps mungkin berbeza daripada visi kami. Kami berminat untuk mendengar perspektif anda tentang transformasi DevOps. Kongsi pengalaman dan perspektif anda tentang topik ini dalam ulasan.
Apakah laporan yang telah kami terima ke dalam program ini?
Minggu ini, Jawatankuasa Program menerima empat laporan: tentang keselamatan, infrastruktur dan amalan SRE.
Mungkin isu yang paling mendesak dalam transformasi DevOps ialah bagaimana untuk memastikan jabatan keselamatan maklumat tidak mengganggu pautan yang sedia ada antara pembangunan, operasi dan pentadbiran. Sesetengah syarikat menguruskan tanpa jabatan keselamatan maklumatBagaimanakah kita boleh memastikan keselamatan maklumat dalam kes ini? Mona Arkhipova daripada sudo.suDaripada laporannya kita belajar:
- apa dan daripada siapa perlu dilindungi;
- Apakah proses keselamatan rutin;
- bagaimana IT dan proses keselamatan maklumat bersilang;
- Apakah CIS CSC dan cara melaksanakannya;
- Bagaimana dan mengikut penunjuk untuk menjalankan pemeriksaan keselamatan maklumat secara berkala.
Ceramah seterusnya akan memberi tumpuan kepada pembangunan infrastruktur sebagai kod. Adakah mungkin untuk mengurangkan usaha manual tanpa mengubah keseluruhan projek menjadi huru-hara? Soalan ini dijawab. Maxim Kostrikin dari IxtensSyarikat beliau menggunakan Terraform untuk bekerja dengan infrastruktur AWS. Alat ini mudah, tetapi persoalannya ialah bagaimana untuk mengelakkan mencipta pangkalan kod yang besar apabila menggunakannya. Mengekalkan legasi sedemikian akan menjadi semakin mahal dengan setiap tahun yang berlalu.
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 PlaykeyDi sini kita akan membincangkan platform infrastruktur dan belajar:
- Bagaimana untuk memahami jika ruang storan anda digunakan dengan cekap;
- Bagaimanakah beberapa ratus pengguna setiap satu boleh menerima 10 TB kandungan apabila hanya 20 TB storan digunakan?
- Cara memampatkan data 5 kali dan memberikannya kepada pengguna dalam masa nyata;
- Bagaimana untuk menyegerakkan data antara berbilang pusat data dengan cepat;
- Bagaimana untuk menghapuskan sebarang pengaruh antara pengguna apabila menggunakan mesin maya yang sama secara berurutan.
Rahsia keajaiban ini adalah dalam teknologi ZFS untuk FreeBSD dan garpu segarnya ZFS di LinuxVladimir akan berkongsi kajian kes 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 memproses insiden pelanggan melalui bahagian belakangnya, dan berpuluh-puluh pasukan atas panggilan di seluruh dunia telah menyelesaikan 150 insiden. Pada persidangan itu, Matvey akan berkongsi statistik dan pandangan syarikatnya yang telah terkumpul semasa menyelesaikan masalah pelanggan dan menganalisis kegagalan.
Sekali lagi, saya menggesa anda untuk tidak tamak dan berkongsi pengalaman anda sebagai samurai DevOps. Jangan ragu untuk menyerahkan untuk laporan itu, dan anda dan saya akan mempunyai 2,5 bulan untuk menyediakan pembentangan yang sangat baik. Jika anda ingin menjadi pendengar, Langgan surat berita kami untuk kemas kini program dan pertimbangkan dengan serius untuk menempah tiket anda lebih awal, kerana harga akan meningkat apabila persidangan semakin hampir.
Sumber: www.habr.com
