Geekly articles weekly

Konferensi untuk penggemar DevOps

Ini, tentu saja, tentang DevOpsConf . Jika Anda tidak merinci, maka pada 30 September dan 1 Oktober kami akan mengadakan konferensi tentang penyatuan pengembangan, pengujian dan proses operasi, dan jika Anda masuk ke dalamnya, saya meminta kucing.

Dalam kerangka pendekatan DevOps, semua bagian dari pengembangan teknologi proyek saling terkait, terjadi secara paralel dan saling mempengaruhi. Yang sangat penting di sini adalah penciptaan proses pengembangan otomatis yang dapat diubah, disimulasikan dan diuji secara real time. Ini membantu untuk langsung merespons perubahan di pasar.

Pada konferensi tersebut, kami ingin menunjukkan bagaimana pendekatan ini memengaruhi pengembangan produk. Bagaimana keandalan dan kemampuan beradaptasi sistem untuk klien. Bagaimana DevOps mengubah struktur dan pendekatan perusahaan ke organisasi alur kerja.



Backstage


Penting bagi kita untuk mengetahui tidak hanya apa yang dilakukan berbagai perusahaan sebagai bagian dari pendekatan DevOps, tetapi juga untuk memahami mengapa ini semua. Oleh karena itu, kami mengundang tidak hanya para ahli ke Komite Program, tetapi para ahli yang melihat wacana DevOps dari berbagai perspektif:

  • insinyur senior;
  • pengembang
  • timlides;
  • CTO.

Di satu sisi, ini menciptakan kesulitan dan konflik ketika membahas aplikasi untuk laporan. Jika seorang insinyur tertarik untuk menganalisis kecelakaan besar, pengembang lebih penting untuk memahami cara membuat perangkat lunak yang berfungsi di cloud dan infrastruktur. Tetapi dengan menyetujui, kami membuat program yang akan berharga dan menarik bagi semua orang: dari insinyur hingga CTO.



Tugas konferensi kami bukan hanya untuk memilih laporan yang lebih canggih, tetapi juga untuk memberikan gambaran besar: bagaimana pendekatan DevOps bekerja dalam praktiknya, seperti apa rake yang dapat Anda hadapi ketika pindah ke proses baru. Pada saat yang sama, kami membangun bagian konten, turun dari tugas bisnis ke teknologi tertentu.

Bagian-bagian dari konferensi akan tetap sama seperti terakhir kali .

  • Platform infrastruktur.
  • Infrastruktur sebagai kode.
  • Pengiriman terus menerus.
  • Umpan balik.
  • Arsitektur di DevOps, DevOps untuk CTO.
  • Praktek SRE.
  • Pelatihan dan manajemen pengetahuan.
  • Keamanan, DevSecOps.
  • Transformasi DevOps.

Call for Papers: laporan apa yang kami cari


Secara kondisional kami membagi audiens potensial dari konferensi menjadi lima kelompok: insinyur, pengembang, spesialis keamanan, pemimpin tim dan CTO. Setiap kelompok memiliki motivasi sendiri untuk datang ke konferensi. Dan, jika Anda melihat DevOps dari posisi-posisi ini, Anda dapat memahami bagaimana memfokuskan topik Anda dan ke mana harus menekankan.

Untuk insinyur yang menciptakan platform infrastruktur, penting untuk memahami tren yang ada, untuk memahami teknologi mana yang paling maju saat ini. Mereka akan tertarik untuk berkenalan dengan pengalaman nyata menggunakan teknologi ini dan bertukar pandangan. Seorang insinyur akan dengan senang hati mendengarkan laporan dengan analisis kecelakaan parah, kami, pada gilirannya, akan mencoba untuk mengambil dan memoles laporan tersebut.

Untuk pengembang, penting untuk memahami konsep seperti aplikasi cloud asli . Yaitu, bagaimana mengembangkan perangkat lunak sehingga berfungsi di cloud dan berbagai infrastruktur. Pengembang perlu terus menerima umpan balik dari perangkat lunak. Di sini kami ingin mendengar kasus tentang bagaimana perusahaan membangun proses ini, bagaimana memantau kinerja perangkat lunak dan bagaimana seluruh proses pengiriman bekerja.

Penting bagi profesional cybersecurity untuk memahami cara mengatur proses keamanan sehingga tidak menghentikan proses pengembangan dan perubahan dalam perusahaan. Topik-topik tentang persyaratan yang dibuat DevOps untuk spesialis seperti itu akan menarik.

Timlids ingin tahu bagaimana proses pengiriman berkelanjutan di perusahaan lain bekerja . Dengan cara apa perusahaan pergi ke ini, bagaimana proses pengembangan, jaminan kualitas dalam DevOps dibangun. Rekan satu tim Cloud asli juga menarik. Dan juga - pertanyaan tentang interaksi dalam tim dan antara tim pengembang dan insinyur.

Untuk CTO, hal terpenting adalah mencari cara menggabungkan semua proses ini dan menyesuaikannya dengan kebutuhan bisnis. Dia memastikan bahwa aplikasi tersebut dapat diandalkan untuk bisnis dan klien. Dan di sini Anda perlu memahami teknologi apa yang akan bekerja di bawah tugas bisnis mana, bagaimana membangun seluruh proses, dll. CTO juga bertanggung jawab untuk penganggaran. Sebagai contoh, ia harus memahami berapa banyak uang yang perlu dihabiskan untuk melatih ulang spesialis sehingga mereka dapat bekerja di DevOps.



Jika Anda memiliki sesuatu untuk dikatakan pada kesempatan ini, jangan diam, kirimkan laporan . Batas waktu Panggilan untuk Makalah adalah 20 Agustus. Semakin cepat Anda muncul, semakin banyak waktu untuk menyelesaikan laporan dan mempersiapkan presentasi. Jadi, jangan kencangkan.

Nah, jika Anda tidak perlu berbicara di depan umum, beli saja tiket dan datanglah 30 September dan 1 Oktober untuk mengobrol dengan rekan kerja. Kami berjanji ini akan menarik dan menginspirasi.

Seperti yang kita lihat DevOps


Untuk memahami dengan tepat apa yang kami maksud dengan DevOps, saya sarankan membaca (atau membaca ulang) ceramah saya “ Apa itu DevOps ”. Berjalan di sepanjang gelombang pasar, saya menyaksikan bagaimana ide DevOps ditransformasikan di perusahaan-perusahaan berukuran berbeda: dari startup kecil menjadi perusahaan multinasional. Laporan ini dibuat berdasarkan serangkaian pertanyaan, menjawabnya, Anda dapat memahami apakah perusahaan Anda pindah ke DevOps atau ada masalah di suatu tempat.

DevOps adalah sistem yang kompleks, seharusnya:

  • Produk digital.
  • Modul bisnis yang dikembangkan produk digital ini.
  • Tim produk yang menulis kode.
  • Praktik pengiriman berkelanjutan.
  • Platform sebagai layanan.
  • Infrastruktur sebagai layanan.
  • Infrastruktur sebagai kode.
  • Pisahkan praktik keandalan dengan kabel di dalam DevOps.
  • Praktik umpan balik yang menjelaskan semua ini.

Di akhir laporan ada skema yang memberikan gambaran tentang sistem DevOps di perusahaan. Ini akan memungkinkan Anda untuk melihat proses mana di perusahaan Anda yang sudah didebug, dan yang hanya harus dibangun.



Anda dapat menonton laporan video di sini .

Dan sekarang akan ada bonus: beberapa video dari RIT ++ 2019 yang berhubungan dengan masalah paling umum dari transformasi DevOps.

Infrastruktur perusahaan sebagai produk


Artyom Naumenko memimpin tim DevOps di Skyeng dan menangani pengembangan infrastruktur perusahaannya. Dia memberi tahu bagaimana infrastruktur memengaruhi proses bisnis di SkyEng: cara menghitung ROI untuknya, metrik apa yang harus dipilih untuk perhitungan, dan bagaimana cara bekerja untuk memperbaikinya.



Dalam perjalanan ke layanan microser


Nixys berkomitmen untuk mendukung proyek web yang sibuk dan sistem terdistribusi. Direktur teknisnya Boris Ershov memberi tahu cara mentransfer produk perangkat lunak, yang pengembangannya dimulai sekitar 5 tahun yang lalu (atau bahkan lebih), ke rel modern.



Sebagai aturan, proyek-proyek tersebut adalah dunia khusus di mana ada sudut-sudut infrastruktur yang gelap dan kuno sehingga insinyur saat ini tidak tahu tentang mereka. Dan pendekatan yang pernah dipilih untuk arsitektur dan pengembangan sudah ketinggalan zaman dan tidak dapat memberikan bisnis dengan laju pengembangan dan rilis versi baru yang sama. Akibatnya, setiap rilis produk berubah menjadi petualangan yang luar biasa di mana sesuatu selalu jatuh, dan di tempat yang paling tak terduga.

Para manajer proyek semacam itu mau tidak mau harus mengubah semua proses teknologi. Dalam laporannya, Boris berkata:

  • Bagaimana memilih arsitektur yang cocok untuk proyek dan merapikan infrastruktur;
  • alat apa yang digunakan dan perangkap apa yang ditemukan di jalan menuju transformasi;
  • apa yang harus dilakukan selanjutnya



Lepaskan otomatisasi atau cara menyampaikan dengan cepat dan tanpa rasa sakit


Alexander Korotkov adalah pengembang terkemuka sistem CI / CD di CIAN. Dia berbicara tentang alat otomatisasi yang meningkatkan kualitas dan mengurangi waktu pengiriman kode dalam produksi sebanyak 5 kali. Tetapi hasil seperti itu tidak mungkin dicapai hanya dengan satu otomatisasi, jadi Alexander memperhatikan perubahan dalam proses pengembangan.



Bagaimana kecelakaan membantu Anda belajar?


Alexey Kirpichnikov telah mengimplementasikan DevOps dan infrastruktur di SKB Kontur selama 5 tahun. Selama tiga tahun, sekitar 1.000 fakap dengan berbagai tingkat epik terjadi di perusahaannya. Di antara mereka, misalnya, 36% disebabkan oleh peluncuran rilis berkualitas rendah dalam produksi, dan 14% disebabkan oleh pekerjaan pemeliharaan besi di pusat data.

Mendapatkan informasi yang akurat tentang kecelakaan memungkinkan arsip laporan (post-mortem), yang telah dilakukan para insinyur perusahaan selama beberapa tahun berturut-turut. Postmortem menulis insinyur yang bertugas, yang merupakan orang pertama yang menanggapi sinyal tentang kecelakaan itu dan mulai memperbaiki semuanya. Mengapa menyiksa insinyur yang melawan para fakap di malam hari, menulis laporan? Data ini memungkinkan Anda untuk melihat keseluruhan gambar dan memindahkan pembangunan infrastruktur ke arah yang benar.

Dalam pidatonya, Alexey berbagi cara menulis post-mortem yang sangat berguna dan bagaimana menerapkan praktik laporan tersebut di perusahaan besar. Jika Anda suka cerita tentang bagaimana seseorang mengacau, tonton video pertunjukannya.



Kami memahami bahwa visi Anda tentang DevOps mungkin tidak sesuai dengan pandangan kami. Akan menarik untuk mengetahui bagaimana Anda melihat transformasi DevOps. Bagikan pengalaman dan visi Anda tentang topik ini di komentar.

Laporan apa yang sudah kami terima ke dalam program?


Minggu ini, Komite Program mengadopsi 4 laporan: tentang keamanan, infrastruktur, dan praktik SRE.

Mungkin topik yang paling menyakitkan dari transformasi DevOps: bagaimana memastikan bahwa orang-orang dari departemen keamanan informasi tidak merusak koneksi yang sudah dibangun antara pengembangan, operasi dan administrasi. Beberapa perusahaan melakukannya tanpa departemen keamanan informasi . Lalu bagaimana memastikan keamanan informasi? Ini akan memberi tahu Mona Arkhipova dari sudo.su. Dari laporannya kita belajar:

  • apa dan dari siapa perlu untuk melindungi;
  • apa saja proses keamanan rutin;
  • Bagaimana proses IT dan IS berpotongan
  • apa itu CSC CIS dan bagaimana cara mengimplementasikannya;
  • bagaimana dan dengan indikator apa untuk melakukan pemeriksaan IS reguler.

Laporan berikutnya membahas pengembangan infrastruktur sebagai kode. Kurangi jumlah rutin manual dan jangan ubah seluruh proyek menjadi kacau, apakah ini mungkin? Maxim Kostrikin dari Ixtens akan menjawab pertanyaan ini. Perusahaannya menggunakan Terraform untuk bekerja dengan infrastruktur AWS. Alat ini nyaman, tetapi pertanyaannya adalah bagaimana menggunakannya untuk menghindari munculnya banyak kode. Pemeliharaan warisan seperti itu akan semakin mahal setiap tahunnya.

Maxim akan menunjukkan bagaimana pola penempatan kode yang ditujukan untuk menyederhanakan pekerjaan otomatisasi dan pengembangan.

Kami akan mendengar laporan lain tentang infrastruktur dari Vladimir Ryabov dari Playkey . Di sini kita akan berbicara tentang platform infrastruktur, dan kita akan belajar:

  • bagaimana memahami jika kapasitas penyimpanan digunakan secara efisien;
  • berapa ratus pengguna dapat menerima 10 TB konten jika hanya 20 TB penyimpanan digunakan;
  • cara mengompres data 5 kali dan memberikannya kepada pengguna secara waktu nyata;
  • bagaimana on the fly untuk menyinkronkan data antara beberapa pusat data;
  • cara mengecualikan pengaruh pengguna satu sama lain dalam penggunaan berurutan satu mesin virtual.

Rahasia sihir ini adalah dalam teknologi ZFS untuk FreeBSD dan garpu ZFS terbaru di Linux . Vladimir akan berbagi kasus dari Playkey.

Matvey Kukuy dari Amixr.IO siap memberi tahu melalui contoh-contoh dari kehidupan apa itu SRE dan bagaimana hal itu membantu membangun sistem yang andal. Amixr.IO melewati insiden pelanggan melalui backendnya, puluhan tim tugas di seluruh dunia telah menyelesaikan 150 ribu kasus. Pada konferensi tersebut, Matvey akan berbagi statistik dan wawasan yang telah diakumulasikan perusahaannya, memecahkan masalah pelanggan, dan menganalisis kepalsuan.

Sekali lagi, saya mendorong Anda untuk tidak serakah dan berbagi pengalaman Anda dengan DevOps-samurai. Terapkan untuk laporan, dan kami akan memiliki 2,5 bulan untuk menyiapkan presentasi yang sangat baik. Jika Anda ingin menjadi pendengar, berlangganan buletin dengan pembaruan program dan serius memikirkan tiket pemesanan awal, karena mereka akan naik harga lebih dekat dengan tanggal konferensi.

Source: https://habr.com/ru/post/id458920/

More articles:


All Articles