Tentu saja, kita berbicara tentang . Jika Anda tidak merincinya, maka pada tanggal 30 September dan 1 Oktober kami akan mengadakan konferensi tentang menggabungkan proses pengembangan, pengujian, dan pengoperasian, dan jika Anda merincinya, silakan di bawah cat.
Dalam pendekatan DevOps, seluruh bagian pengembangan teknologi proyek saling terkait, terjadi secara paralel, dan saling mempengaruhi. Yang paling penting di sini adalah penciptaan proses pengembangan otomatis yang dapat diubah, disimulasikan, dan diuji secara real time. Ini membantu Anda merespons perubahan di pasar secara instan.
Pada konferensi tersebut kami ingin menunjukkan bagaimana pendekatan ini mempengaruhi pengembangan produk. Bagaimana keandalan dan kemampuan beradaptasi sistem untuk klien dipastikan. Bagaimana DevOps mengubah struktur dan pendekatan perusahaan dalam mengatur proses kerjanya.
di balik layar
Penting bagi kita untuk mengetahui tidak hanya apa yang dilakukan berbagai perusahaan dalam kerangka pendekatan DevOps, tetapi juga untuk memahami mengapa semua ini dilakukan. Oleh karena itu, kami mengundang tidak hanya para ahli untuk bergabung dengan Komite Program, namun para spesialis yang melihat wacana DevOps dari berbagai posisi:
- insinyur senior;
- pengembang;
- pemimpin tim;
- CTO.
Di satu sisi, hal ini menimbulkan kesulitan dan konflik ketika membahas permintaan laporan. Jika seorang insinyur tertarik menganalisis kecelakaan besar, maka lebih penting bagi pengembang untuk memahami cara membuat perangkat lunak yang berfungsi di cloud dan infrastruktur. Namun dengan menyetujuinya, kami membuat program yang berharga dan menarik bagi semua orang: mulai dari insinyur hingga CTO.
Tujuan dari konferensi kami bukan hanya untuk memilih laporan yang paling populer, namun untuk menyajikan gambaran keseluruhan: bagaimana pendekatan DevOps bekerja dalam praktiknya, jenis keuntungan apa yang dapat Anda hadapi saat berpindah ke proses baru. Pada saat yang sama, kami membangun bagian konten, mulai dari masalah bisnis hingga teknologi spesifik.
Bagian konferensi akan tetap sama seperti di .
- Platform infrastruktur.
- Infrastruktur sebagai kode.
- Pengiriman berkelanjutan.
- Masukan.
- Arsitektur di DevOps, DevOps untuk CTO.
- praktik SRE.
- Pelatihan dan manajemen pengetahuan.
- Keamanan, DevSecOps.
- Transformasi DevOps.
Call for Papers: laporan seperti apa yang kami cari
Kami secara kondisional membagi calon audiens konferensi menjadi lima kelompok: insinyur, pengembang, spesialis keamanan, pemimpin tim, dan CTO. Setiap kelompok mempunyai motivasi tersendiri untuk datang ke konferensi tersebut. Dan, jika Anda melihat DevOps dari posisi ini, Anda dapat memahami cara memfokuskan topik Anda dan di mana harus memberikan penekanan.
Bagi para insinyur, bagi mereka yang menciptakan platform infrastruktur, penting untuk memahami tren yang ada, untuk memahami teknologi mana yang paling maju saat ini. Mereka akan tertarik untuk mempelajari pengalaman nyata dalam menggunakan teknologi ini dan bertukar pendapat. Seorang insinyur akan dengan senang hati mendengarkan laporan yang menganalisis beberapa kecelakaan besar, dan kami, pada gilirannya, akan mencoba memilih dan menyempurnakan laporan tersebut.
Untuk pengembang penting untuk memahami konsep seperti aplikasi cloud asli. Yakni bagaimana mengembangkan perangkat lunak agar dapat berfungsi di cloud dan berbagai infrastruktur. Pengembang perlu terus-menerus 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 keseluruhan proses pengiriman bekerja.
Spesialis keamanan siber Penting untuk memahami cara mengatur proses keamanan agar tidak menghambat proses pengembangan dan perubahan dalam perusahaan. Topik tentang persyaratan yang diberlakukan DevOps pada spesialis tersebut juga akan menarik.
Pimpinan tim ingin tahu, bagaimana proses pengiriman berkelanjutan bekerja di perusahaan lain. Jalur apa yang diambil perusahaan untuk mencapai hal ini, bagaimana mereka membangun proses pengembangan dan penjaminan kualitas dalam DevOps. Pimpinan tim juga tertarik dengan Cloud asli. Dan juga pertanyaan tentang interaksi dalam tim dan antara tim pengembangan dan teknik.
Untuk CTO yang paling penting adalah mencari cara untuk menghubungkan semua proses ini dan menyesuaikannya dengan kebutuhan bisnis. Dia memastikan bahwa aplikasi tersebut dapat diandalkan baik untuk bisnis maupun klien. Dan di sini Anda perlu memahami teknologi mana yang cocok untuk tugas bisnis apa, bagaimana membangun keseluruhan proses, dll. CTO juga bertanggung jawab atas penganggaran. Misalnya, dia harus memahami berapa banyak uang yang perlu dikeluarkan untuk melatih kembali para spesialis agar mereka dapat bekerja di DevOps.
Jika ada yang ingin Anda sampaikan mengenai hal ini, jangan tinggal diam, . Batas waktu Call for Papers adalah 20 Agustus. Semakin awal Anda mendaftar, semakin banyak waktu yang Anda miliki untuk menyelesaikan laporan dan mempersiapkan presentasi Anda. Jadi, jangan tunda lagi.
Nah, jika Anda tidak perlu berbicara di depan umum, cukup saja dan datang pada tanggal 30 September dan 1 Oktober untuk berkomunikasi dengan rekan-rekan. Kami berjanji ini akan menarik dan menginspirasi.
Bagaimana kami melihat DevOps
Untuk memahami dengan tepat apa yang kami maksud dengan DevOps, saya sarankan untuk membaca (atau membaca ulang) laporan saya “" Saat menelusuri gelombang pasar, saya mengamati bagaimana gagasan DevOps bertransformasi di berbagai ukuran perusahaan: dari perusahaan rintisan kecil hingga perusahaan multinasional. Laporan ini dibuat berdasarkan serangkaian pertanyaan, dengan menjawabnya Anda dapat memahami apakah perusahaan Anda bergerak menuju DevOps atau apakah ada masalah di suatu tempat.
DevOps adalah sistem yang kompleks dan harus mencakup:
- Produk digital.
- Modul bisnis yang mengembangkan produk digital ini.
- Tim produk yang menulis kode.
- Praktik Pengiriman Berkelanjutan.
- Platform sebagai layanan.
- Infrastruktur sebagai layanan.
- Infrastruktur sebagai kode.
- Praktik terpisah untuk menjaga keandalan, dibangun dalam DevOps.
- Sebuah praktik umpan balik yang menggambarkan semuanya.
Di akhir laporan terdapat diagram yang memberikan gambaran tentang sistem DevOps di perusahaan. Ini akan memungkinkan Anda melihat proses mana di perusahaan Anda yang sudah disederhanakan dan mana yang belum dibangun.
Anda dapat menonton video laporannya .
Dan sekarang akan ada bonus: beberapa video dari RIT++ 2019, yang membahas isu-isu paling umum tentang transformasi DevOps.
Infrastruktur perusahaan sebagai produk
Artyom Naumenko memimpin tim DevOps di Skyeng dan menangani pengembangan infrastruktur perusahaannya. Dia menceritakan bagaimana infrastruktur mempengaruhi proses bisnis di SkyEng: bagaimana menghitung ROI, metrik apa yang harus dipilih untuk perhitungan dan bagaimana cara memperbaikinya.
Dalam perjalanan menuju layanan mikro
Perusahaan Nixys menyediakan dukungan untuk proyek web yang sibuk dan sistem terdistribusi. Direktur teknisnya, Boris Ershov, memberi tahu cara menerjemahkan produk perangkat lunak, yang pengembangannya dimulai 5 tahun lalu (atau bahkan lebih), ke dalam platform modern.
Biasanya, proyek semacam itu adalah dunia khusus di mana terdapat sudut infrastruktur yang gelap dan kuno sehingga para insinyur saat ini tidak mengetahuinya. Dan pendekatan terhadap arsitektur dan pengembangan yang pernah dipilih sudah ketinggalan zaman dan tidak dapat memberikan kecepatan pengembangan dan peluncuran versi baru yang sama bagi bisnis. Akibatnya, setiap peluncuran produk berubah menjadi petualangan yang luar biasa, di mana sesuatu terus-menerus jatuh, dan di tempat yang paling tidak terduga.
Manajer proyek semacam itu pasti menghadapi kebutuhan untuk mengubah seluruh proses teknologi. Dalam laporannya, Boris berkata:
- bagaimana memilih arsitektur yang tepat untuk proyek dan menata infrastruktur;
- alat apa yang harus digunakan dan kendala apa yang dihadapi dalam perjalanan menuju transformasi;
- apa yang harus dilakukan selanjutnya.
Otomatisasi rilis atau cara mengirimkannya dengan cepat dan tanpa rasa sakit
Alexander Korotkov adalah pengembang terkemuka sistem CI/CD di CIAN. Dia berbicara tentang alat otomatisasi yang memungkinkan peningkatan kualitas dan mengurangi waktu pengiriman kode ke produksi sebanyak 5 kali lipat. Namun hasil tersebut tidak dapat dicapai hanya dengan otomatisasi, sehingga Alexander juga memperhatikan perubahan dalam proses pengembangan.
Bagaimana kecelakaan membantu Anda belajar?
Alexei Kirpichnikov telah mengimplementasikan DevOps dan infrastruktur di SKB Kontur selama 5 tahun. Selama tiga tahun, sekitar 1000 fakap dengan tingkat kehebatan yang berbeda-beda terjadi di perusahaannya. Diantaranya, misalnya, 36% disebabkan oleh peluncuran rilis berkualitas rendah ke dalam produksi, dan 14% disebabkan oleh pekerjaan pemeliharaan perangkat keras di pusat data.
Arsip laporan (otopsi) yang disimpan oleh para insinyur perusahaan selama beberapa tahun berturut-turut memungkinkan diperolehnya informasi akurat tentang kecelakaan. Post-mortem ditulis oleh insinyur yang bertugas, yang merupakan orang pertama yang merespons sinyal darurat dan mulai memperbaiki semuanya. Mengapa menyiksa para insinyur yang berjuang di malam hari dengan facaps dengan menulis laporan? Data ini memungkinkan Anda melihat gambaran keseluruhan dan menggerakkan pembangunan infrastruktur ke arah yang benar.
Dalam sambutannya, Alexei berbagi bagaimana cara menulis postmortem yang benar-benar bermanfaat dan bagaimana menerapkan praktik laporan tersebut di sebuah perusahaan besar. Jika Anda menyukai cerita tentang bagaimana seseorang melakukan kesalahan, tontonlah video pertunjukannya.
Kami memahami bahwa visi Anda tentang DevOps mungkin tidak sesuai dengan visi kami. Menarik untuk mengetahui bagaimana Anda melihat transformasi DevOps. Bagikan pengalaman dan visi Anda tentang topik ini di komentar.
Laporan apa saja yang telah kami terima dalam program ini?
Minggu ini Komite Program mengadopsi 4 laporan: tentang keamanan, infrastruktur dan praktik SRE.
Mungkin topik transformasi DevOps yang paling menyakitkan: bagaimana memastikan bahwa orang-orang dari departemen keamanan informasi tidak merusak hubungan yang sudah dibangun antara pengembangan, operasi, dan administrasi. Beberapa perusahaan mengelola tanpa departemen keamanan informasi. Bagaimana cara memastikan keamanan informasi dalam kasus ini? Tentang itu Mona Arkhipova dari sudo.su. Dari laporannya kita belajar:
- apa yang perlu dilindungi dan dari siapa;
- bagaimana proses keamanan rutinnya;
- bagaimana proses TI dan keamanan informasi bersinggungan;
- apa itu CIS CSC dan bagaimana cara mengimplementasikannya;
- bagaimana dan dengan indikator apa melakukan pemeriksaan keamanan informasi secara berkala.
Laporan berikutnya menyangkut pembangunan infrastruktur sebagai kode. Kurangi jumlah rutinitas manual dan jangan membuat keseluruhan proyek menjadi kacau, apakah ini mungkin? Untuk pertanyaan ini Maxim Kostrikin dari Ixtens. Perusahaannya menggunakan Terraform untuk bekerja dengan infrastruktur AWS. Alat ini nyaman, tetapi pertanyaannya adalah bagaimana menghindari pembuatan blok kode yang besar saat menggunakannya. Pemeliharaan warisan seperti itu akan menjadi semakin mahal setiap tahunnya.
Maxim akan menunjukkan cara kerja pola penempatan kode, yang bertujuan untuk menyederhanakan otomatisasi dan pengembangan.
Lain kita akan mendengar tentang infrastruktur dari Vladimir Ryabov dari Playkey. Di sini kita akan berbicara tentang platform infrastruktur, dan kita akan belajar:
- bagaimana memahami apakah ruang penyimpanan digunakan secara efektif;
- berapa ratus pengguna yang dapat menerima 10 TB konten jika hanya 20 TB penyimpanan yang digunakan;
- cara mengompresi data sebanyak 5 kali dan memberikannya kepada pengguna secara real-time;
- cara menyinkronkan data dengan cepat antara beberapa pusat data;
- cara menghilangkan pengaruh pengguna satu sama lain saat menggunakan satu mesin virtual secara berurutan.
Rahasia keajaiban ini adalah teknologi ZFS untuk FreeBSD dan garpunya yang segar ZFS di Linux. Vladimir akan membagikan kasus dari Playkey.
Matvey Kukuy dari Amixr.IO siap dengan contoh dari kehidupan , apa yang terjadi SRE dan bagaimana hal ini membantu membangun sistem yang andal. Amixr.IO meneruskan insiden klien melalui backendnya; lusinan tim yang bertugas di seluruh dunia telah menangani 150 ribu kasus. Pada konferensi tersebut, Matvey akan berbagi statistik dan wawasan yang telah dikumpulkan perusahaannya dengan memecahkan masalah pelanggan dan menganalisis kegagalan.
Sekali lagi saya mendorong Anda untuk tidak serakah dan berbagi pengalaman Anda sebagai samurai DevOps. Melayani untuk laporan, dan Anda dan saya memiliki waktu 2,5 bulan untuk mempersiapkan pidato yang bagus. Jika Anda ingin menjadi pendengar, ke buletin dengan pembaruan program dan pikirkan secara serius tentang pemesanan tiket sebelumnya, karena tiket akan menjadi lebih mahal mendekati tanggal konferensi.
Sumber: www.habr.com