Setiap Selasa di malam hari, sebuah klub pecinta DevOps anonim berkumpul. Tugas kita jauh lebih ambisius daripada sekadar berbagi masalah dan mungkin mendapatkan nasihat. Kami membahas semua tren industri sehingga akan menyenangkan untuk datang ke
konferensi dan bagian tentang DevOps .
Sejak Juli, kami telah mengerjakan
DevOpsConf Russia , sebuah konferensi profesional tentang integrasi pengembangan, pengujian dan proses operasi, yang tumbuh dari RootConf dan akan diadakan pada 1 dan 2 Oktober di Moskow, di Infospace.
Hari ini saya akan memberi tahu Anda bagaimana kami melakukannya, laporan apa yang kami coba pilih, apa yang diminta pembicara.
Kami memilih integritas sebagai fokus konferensi . Kami akan berbicara tentang DevOps dari berbagai sisi - dari sisi pengembangan, operasi, proses, manajemen, dan peralatan. Itulah sebabnya kami merumuskan seperangkat bagian:
- 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.
Menurut pendapat kami, kit ini sepenuhnya menjelaskan semua aspek penting.
Suatu program yang mencakup semua masalah ini akan menjadi berguna secara komprehensif. Di sisi lain, tugas utama adalah
menjaga keseimbangan , bukan untuk mulai berbicara tentang proses dan budaya dalam isolasi dari teknologi dan alat. Oleh karena itu, kami meminta para pembicara kami untuk memulihkan proses di perusahaan, mengklarifikasi tujuan dan sasaran dan mengikatnya dengan solusi teknologi.
Izinkan saya menjelaskan dengan sebuah contoh: kita akan memiliki pembicara super di semua konferensi DevOps -
Alexey Vakhov , CTO di Uchi.ru.
Kami berbicara dengan Alexei dan menemukan bahwa sejak laporan terakhirnya di infrastruktur mereka dan pengantar pengiriman belum ada inovasi teknologi khusus. Setelah berdiskusi dan sedikit bertukar pikiran, kami baru saja memutuskan untuk pergi dari proses. Bagaimana tepatnya artefak dengan kode masuk dari pengembang ke produksi, apa yang terjadi pada artefak, bagaimana orang-orang melindungi diri mereka dari kesalahan dan bug di seluruh pipa? Alex setuju bahwa ini adalah pandangan yang
benar-benar segar pada apa yang terjadi di dalam perusahaan dan memutuskan untuk mengulangi laporan ini. Dan sekarang kita, sebagai pendengar, tidak hanya akan dapat belajar tentang pengalaman menggunakan berbagai alat di Uchi.ru, tetapi kita juga akan belajar bagaimana proses pengiriman berkelanjutan bekerja.
Jadi, jika Anda, seperti saya, tertarik, maka belum terlambat untuk mendaftar ke konferensi Rusia DevOpsConf !
Ini hanyalah salah satu contoh kerja bersama Komite Program dan pembicara dalam laporan tersebut. Setiap aplikasi melalui diskusi kolegial seperti itu, kami menyelidiki detail sehingga semuanya berjalan dengan sempurna. Karena itu, sekarang saya tidak akan memberi tahu Anda tentang semua laporan, tetapi dalam setiap topik saya akan memilih satu atau dua yang sangat menarik.
Platform infrastruktur
Nikolay Sivko. Kubernet untuk mereka yang berusia di atas 30 tahun
Mereka sering berbicara tentang kubernet sekarang, dan di okmeter.io mereka sampai pada kesimpulan bahwa mereka juga membutuhkan k8 dalam produksi. Meskipun mereka bahkan tidak memiliki CI / CD, ada batasan seperti toleransi kesalahan maksimum yang diperlukan dan kurangnya sumber daya manusia untuk tugas ini.
Dalam
laporannya, Nikolai berjanji untuk mengatakan bagaimana ia berhasil menyelesaikan masalah ini:
- HA k8s pada logam telanjang dari tusuk gigi dan pita listrik biru.
- Ketika jaringan k8s diatur, cluster k8s dan server tetangga terhubung .
- Mengapa tidak menggunakan jaringan layanan k8, tetapi menerapkan layanan tanpa kepala dan penemuan + dns jika memungkinkan.
Pengalaman
okmeter.io akan berguna jika Anda mencari keseimbangan ambang batas / manfaat k8s / kontrol / kinerja.
Anna Stepanyan. Infrastruktur pemantauan Booking.com
Dari
laporan ini kita belajar: data apa tentang operasi aplikasi di Booking.com yang dikumpulkan untuk pemantauan; bagaimana mereka dikumpulkan; metrik dan log apa yang disimpan; bagaimana cara menganalisis.
Pertimbangkan
solusi pemantauan sumber terbuka yang populer, analisis keterbatasan dan fitur, lihat alat apa yang harus Anda implementasikan sendiri.
Pengiriman terus menerus
Alexander Kharkevich. Pengembangan dan pemeliharaan yang efektif untuk peran yang memungkinkan
Ansible adalah salah satu sistem manajemen konfigurasi yang populer, memiliki ambang masuk yang rendah, mudah dikembangkan oleh modul pihak ketiga, memungkinkan
penggunaan kembali kode , dan memiliki sejumlah keunggulan. Tetapi pengenalan sistem manajemen konfigurasi di dahi hanya membantu pada awalnya. Setelah beberapa waktu, menjadi sangat sulit untuk mempertahankan jumlah peran yang diperluas. Alexander Harkevich dari EPAM Systems dalam
laporannya akan berbicara tentang
mekanisme pasokan peran berkelanjutan , sebagai cara paling efektif untuk mendukung mereka. Mari kita periksa perkembangan peran publik dan peran publik, tetapi dengan uji coba dalam infrastruktur swasta.
Umpan balik
Dengan mudah Ozerov. Pemantauan Berbasis Pendapatan
Semua orang mengumpulkan banyak indikator teknis dan beberapa metrik bisnis:
pendapatan, retensi, kualitas . Sayangnya, sangat sering metrik ini dianalisis secara terpisah dari satu sama lain, dan tidak ada yang mencoba menghubungkannya. Apakah Anda tahu berapa banyak uang yang dibawa server web kepada Anda? Bagaimana cara melihat masalah ketika semua sistem pemantauan teknis berwarna hijau?
Berapa banyak uang yang hilang dari bisnis saat database dimuat 90%? Dan 50%? Datanglah ke
laporan Vasily - kami akan mengerti.
Arsitektur di DevOps, DevOps untuk CTO
Maxim Vikharev. Kisah DevOps "tentang microservice template"
Laporan ini akan diajukan sebagai insinyur dan pengembang pengembang proaktif.
Pertimbangkan seluruh siklus hidup layanan (mikro) menggunakan contoh spesifik dari layanan python:
- terdiri dari apa dan apa layanan (mikro) tipikal dalam aplikasi web modern bergantung pada;
- kemampuan arsitektur dan primitif kubernet apa yang digunakan;
- bagaimana layanan (mikro) harus diintegrasikan ke dalam proses pengembangan dan pengiriman aplikasi agar tidak menulis instruksi sepanjang kilometer dan umumnya tidak melakukan sesuatu yang istimewa;
- cara merapat aplikasi dengan layanan sistem di beberapa lingkungan produksi, banyak yang menguji dan men-debug, dan mengapa;
- pengaturan dan keputusan apa yang diperlukan antara tim infrastruktur dan tim pengembangan untuk interaksi yang nyaman dan efektif.
Maxim akan berbagi pengalamannya, yang akan memungkinkan administrator untuk dengan tenang
mendelegasikan konfigurasi dan penyebaran aplikasi ke pengembang . Dan pengembang harus
berkonsentrasi pada fitur tanpa downtime yang signifikan karena beralih ke aktivitas devops.
Praktek SRE
Renato Losio. MySQL di atas awan
Semua penyedia layanan cloud utama, dari AWS hingga Google Cloud, menyediakan berbagai opsi untuk menjalankan database yang kompatibel dengan MySQL atau MySQL di cloud. Anda dapat menggunakan mesin virtual dan mengonfigurasi kluster Anda sendiri, atau mengandalkan layanan dan mengelola basis data dengan
mengklik tombol .
Dalam
laporan kepala arsitek platform cloud Funambol
Renato Losio, kami akan mempertimbangkan
biaya operasional
untuk menjalankan basis data relasional di cloud dan
cara mengintegrasikannya ke dalam infrastruktur kode. Mari kita lihat apakah ini saatnya untuk database tanpa server.
Igor Dolzhikov. Cara memuaskan layanan SRE atau Go dalam wadah dalam 5 menit
Dari
laporan ini kita belajar tidak hanya tentang praktik-praktik SRE yang diterima, Igor akan mengilustrasikan kisahnya dengan contoh-contoh dan yang paling penting berjanji untuk memberikan yang paling berharga - sebuah
templat layanan yang dibentuk yang mencakup pengalaman beberapa tahun bekerja.
Pertimbangkan, khususnya, masalah-masalah berikut: generasi layanan dengan pemilihan modul yang diperlukan; cara untuk menguji dan memvalidasi kode; pengiriman dan eksekusi kode dalam wadah secara lokal dan dalam kluster; struktur modul layanan dari praktik terbaik; penutupan layanan yang sopan (shutdown anggun). Dan lebih dari pengalaman yang tak ternilai dalam pengembangan wadah.
Keamanan, DevSecOps
Sergey Noskov. Mengelola Rahasia dengan Hashicorp Vault
Dari laporan Sergey, kami belajar tentang mengelola rahasia di Avito menggunakan Hashicorp Vault, dan menggunakan
Wayang dan Kubernet . Juga, Sergey berjanji untuk
mendaftar kerucut mana yang telah diisi selama satu setengah tahun penggunaan, dan akan membagikan pemikirannya tentang cara memperbaikinya.
Transformasi DevOps
Anton Isanin. DevOps di Alfa Bank
Anton Isanin adalah penulis strategi transformasi Alfa-Bank DevOps. Dari
laporannya kami menemukan masalah apa yang dihadapi perusahaan dalam proses transformasi.
Mari kita bicara tentang implementasi teknis tertentu : cara menulis cerita pengguna; bagaimana mengatur pengembangan dan pengujian; cara menggunakan; memantau pekerjaan dalam operasi industri, dll. Ada banyak nuansa, dan berguna untuk memperhitungkan pengalaman perusahaan yang telah mengalami transformasi DevOps.
Sampai jumpa di pertemuan besar dan bukan anonim para pecinta DevOps pada 1 dan 2 Oktober! Hanya ingat untuk
memesan tiket terlebih dahulu, lebih dekat ke konferensi itu akan lebih mahal.
Berlangganan Newsletter Bertema Ontiko DevOps untuk menerima pembaruan program segera setelah tersedia. Kami mencoba menjadikan surat-surat itu berguna dan tidak mengganggu, kami mengirim berita konferensi, transkrip laporan, dan video segar.
Ngomong-ngomong, video dapat dipantau secara terpisah di saluran YouTube - ada semua video yang dikumpulkan dalam beberapa tahun terakhir dan daftar ini terus diperbarui.