Setidaknya beberapa tahun telah berlalu sejak kata "DevOps" didengar oleh semua orang. Siapa yang tidak menerapkannya, dan apa yang tidak.

Sementara itu, wilayah ini sangat belum dijelajahi, penuh dengan banyak penemuan. Sebagai contoh, komunitas berbahasa Rusia masih belum memutuskan terminologi: seseorang sudah mempekerjakan orang untuk jabatan "devops", dan seseorang selalu mengatakan bahwa "devops" adalah budaya dan praktik yang dirancang untuk menggabungkan pengembangan, operasi dan Oleh karena itu, menyebut posisi itu salah.

Banyak yang mencari jawaban di buku-buku, karena akhir-akhir ini ada banyak sekali. Misalnya, salah satu yang paling penting bagi saya adalah Buku Pegangan Devops, yang ditulis oleh pembicara kami John Willis, dan Google SRE Book, tersedia di Internet secara gratis. Namun, ketika membaca buku-buku ini, saya menemukan hal berikut: teks kering tidak terlalu cocok untuk transfer pengetahuan, sangat banyak didasarkan pada karya nyata orang yang hidup. Ternyata pengetahuannya terlalu abstrak.

Misalnya, kita ambil bab 14, “Mengelola Insiden . ” Kami diberi dua contoh: pada awalnya, kisah satu insiden, yang ditangani secara tidak benar, diceritakan dengan penuh warna. Kemudian kisah yang sama diceritakan, tetapi dengan struktur yang tepat dan hasil yang baik. Hasil yang baik terjadi jika Anda mengikuti praktik penting:

• Pembagian peran yang jelas, dengan alokasi mereka yang bertanggung jawab untuk:
  
  • seluruh insiden ("komandan");
  • bagian operasi;
  • komunikasi
  • perencanaan kerja;
• Menyoroti pos tim (baik obrolan fisik dan hanya);
• Sebuah dokumen yang terus diperbarui yang menggambarkan keadaan saat kejadian;
• Pemindahan wewenang yang tepat waktu dan dapat dipahami (misalnya, pada akhir pergantian).

Pada akhirnya, banyak nasihat baik diberikan tentang segala hal di dunia. Pada prinsipnya, itu bagus, tetapi ada pertanyaan: dan bagaimana menerapkan semua ini? Setiap item cocok untuk seluruh buku, dan beberapa di antaranya memerlukan keterampilan lunak yang tidak dapat dijelaskan dalam buku. Bayangkan di tengah-tengah insiden, CTO mendatangi Anda dan mulai memberikan saran yang tidak berguna dari kehidupan TI di masa lalu: ia akan menawarkan untuk meningkatkan ukuran halaman memori di Linux, meskipun sangat berbeda, atau mematikan hambatan ext4, meskipun caching dihidupkan. Apakah begitu mudah untuk menendang pantatnya dari pos komando kami dengan dalih bahwa ia tidak memiliki peran dalam tim? Bagaimana orang yang menulis artikel melakukan ini?

Idealnya, saya ingin yang berikut ini: pertama, memiliki lebih dari satu sudut pandang tentang masalah yang sama, termasuk yang diperoleh dari pengalaman berbagai tim. Tidak semua perusahaan seperti Google. Meski begitu: Perusahaan seperti Google dapat dihitung dengan jari. Kedua, saya ingin bertemu dengan penulis dari pengetahuan sakral ini secara langsung, melihat ke mata saya dan mengajukan beberapa pertanyaan. Sebagai contoh, banyak penulis dokumen pujian tentang devoop yang luar biasa di organisasi mereka adalah kebohongan yang dangkal, tetapi sebenarnya mereka memiliki skrip bash dan tongkat yang dilekatkan pada pita listrik di dalamnya. Sangat berguna untuk menatap mata. Dan saya benar-benar ingin mendapatkan bukan hanya beberapa saran umum, tetapi untuk mengajukan pertanyaan rumit saya sendiri - dan mendapatkan jawaban.

Pertanyaan dari banyak sudut pandang dan berbagai masalah tidak diselesaikan dengan cara apa pun oleh mitaps kecil. Dengan bantuan buku, Anda tidak dapat menggali lebih dalam dan berbicara dari hati ke hati. Tidak ada yang pasti memutuskan masalah seperti terminologi praktis, komposisi lowongan tergantung pada situasi. Untuk memperoleh pengetahuan yang relevan dan berguna, Anda dapat dan harus menggunakan semua sumber daya pada saat yang sama.

Tahun lalu, kami menyadari bahwa semuanya begitu membingungkan sehingga tiba saatnya untuk mengadakan konferensi besar tentang DevOps dan hanya dia. Itu disebut DevOops dan berlangsung pada musim gugur di St. Petersburg. Waktu berikutnya akan diadakan pada 14 Oktober tahun ini.

Sebuah konferensi besar adalah yang memecahkan sebagian besar masalah yang dinyatakan. Misalnya, jika Anda salah memahami sesuatu dalam buku John Willis, Anda tidak hanya dapat pergi ke laporannya dan memahami topik lebih terinci, tetapi juga bertemu dengannya di area diskusi dan mengajukan pertanyaan secara langsung.

Hanya tentang DevOps

Pertama, fiturnya adalah bahwa konferensi ini hanya tentang DevOps. Pada prinsipnya, pada sebagian besar konferensi TI besar di Rusia sekarang ada beberapa topik devoptic. Jika Anda segera pergi ke banyak konferensi, Anda bisa mendapatkan basis yang baik. Tetapi mereka harus mendengarkan banyak hal yang Java, .NET, programer JavaScript dan sebagainya menjadi menyakitkan, dan biasanya - tidak berhasil. Tapi semua ini sangat panjang dan sangat mahal. Konferensi DevOops hanya berfokus pada DevOps dan dengan demikian memecahkan banyak masalah organisasi yang mengganggu.

Mereka akan berbicara tentang wadah dan orkestrasi mereka, virtualisasi dan cloud, pemantauan dan audit, CI dan CD, dan secara umum segala sesuatu yang terlintas dalam pikiran ketika kata "DevOps".

Presenter

Namun yang paling penting adalah para pembicara. Sudah, pada saat pengumuman konferensi, sembilan orang dari perusahaan seperti Google dan Microsoft siap untuk berbagi pengalaman mereka. Pada akhirnya, program ini akan memiliki sekitar 17 laporan dalam tiga lagu. Mungkin akan ada lebih banyak lagu dan laporan. Kami dengan cermat mempelajari umpan balik Anda dari DevOops sebelumnya dan mencoba mengundang mereka yang paling Anda inginkan. Mari kita lihat siapa yang sudah bersama kita.

John Willis

Tidak mungkin menyampaikan dalam kata-kata betapa kerennya dia datang kepada kita. John adalah salah satu dari beberapa bapak DevOps, penulis 10 buku yang diterbitkan selama dua puluh tahun terakhir, termasuk DevOps Handbook dan Beyond the Fenix ​​Project yang terkenal , seorang guru Ops selama 35 tahun dan hanya legenda hidup.

Atur Wargo

Seth adalah Advokat Pengembang Google, dan sebelum itu ia bekerja di HashiCorp, Perangkat Lunak Chef, dan tempat-tempat lain. Anda mungkin telah membaca bukunya Learning Chef atau sudah bertemu di konferensi.

Laporannya disebut Keamanan Modern dengan Layanan Mikro dan Cloud . Pentingnya keamanan dalam aplikasi layanan mikro sulit ditaksir terlalu tinggi, dan ini membuat laporan Seth sangat relevan. Laporan ini akan mencakup deskripsi tentang prinsip-prinsip dasar keamanan dan praktik terbaik dalam sistem modern berdasarkan pada layanan mikro, dan juga akan ada demo langsung Vault sebagai contoh aplikasi mereka.

Beras liz

Penginjil teknis di Aqua Security, kepala Komite Program KubeCon, membuat pembicara utama terbaik di konferensi di seluruh dunia.

Awalnya mengkhususkan diri dalam pengembangan perangkat lunak (khususnya, implementasi tumpukan jaringan lintas-platform), Liz fasih dalam Kubernetes, Go dan Python ( profil pada GitHub jelas menunjukkan bahwa ia bukan salah satu dari penginjil yang lupa bagaimana kode), menulis posting di Medium ( karena dia tidak memiliki undangan ke Habr! ) dan memiliki banyak keterampilan khusus seperti live coding .

Liz akan membuat laporan berjudul "Langkah-langkah praktis untuk mengamankan penyebaran kontainer Anda" , intinya adalah bahwa ketika Anda pindah ke budaya DevOps, keamanan entah bagaimana menjadi tanggung jawab semua orang di tim. Hal-hal konkrit akan diperlihatkan tentang bagaimana prinsip-prinsip keamanan disediakan di semua tahap pipa CI / CD dan apa yang sebenarnya perlu dilakukan dengan tangan.

Jessica dekan

Jessica adalah perwakilan komunitas pengembang Microsoft Cloud, yang berspesialisasi dalam Azure, infrastruktur, dan wadah. Dan dia tahu banyak tentang GNU / Linux dan Open Source - katakan padaku lima tahun yang lalu bahwa saya akan menulis tentang seseorang dari Microsoft, dia akan tertawa.

Sebelum bergabung dengan Microsoft, ia bekerja dengan pengguna akhir San Francisco sebagai konsultan IT dan administrator sistem untuk lingkungan perusahaan selama lebih dari sepuluh tahun.

Jessica selama 4 tahun memegang peringkat Microsoft Most Valuable Professional dalam kategori "Windows and Devices for IT" (di dunia Microsoft ini adalah hal yang cukup penting). Tentu saja, ia memiliki banyak sertifikasi lain. Secara khusus, pada 2013 dia menerima sertifikasi FEMA dari Departemen Keamanan Dalam Negeri AS (Homeland Security) sebagai pemimpin dalam krisis dan keadaan darurat.

Dia juga melakukan crossfit dan secara fisik sangat bersemangat. Dengan dia, Anda dapat mendiskusikan banyak pertanyaan di pesta dan tidak pada topik devops. Jangan lupa bahwa penutur tidak hanya sumber abstrak pengetahuan tentang satu subjek yang sempit, tetapi juga kepribadian yang sangat serbaguna yang memiliki sesuatu untuk dipelajari dalam bidang yang sangat berbeda.

Paul Stack

Paul adalah pengembang infrastruktur yang dulu bekerja di HashiCorp dan terlibat dalam pengembangan alat yang digunakan oleh jutaan orang (seperti Terraform). Dia sering berbicara di konferensi dan menyampaikan praktik dari garis depan implementasi CI / CD, prinsip-prinsip organisasi yang tepat dari bagian operasi, dan mampu menjelaskan dengan jelas mengapa administrator melakukan ini sama sekali.

Paul sudah berbicara di DevOops sebelumnya, dan peserta konferensi sangat menyukainya sehingga kami memutuskan untuk mengundangnya lagi!

Rekaman laporan sebelumnya dapat dilihat di sini:

Kali ini laporannya akan sangat berbeda. Esensinya adalah bahwa kita membangun sistem toleran-kesalahan yang andal - tetapi bagaimana memastikan bahwa sistem tersebut benar-benar dapat diandalkan? Kami punya pilihan: menunggu insiden dan memperbaiki dalam api, atau menambahkan insiden sendiri sampai kami belajar bagaimana bertahan hidup. Tidak bisa mengalahkan insiden? Kalau begitu, kepala mereka! Paul berjanji untuk menunjukkan cara menambahkan Chaos ke infrastruktur Anda dan cara menolaknya.

Alena Prokharchik

Alena adalah Insinyur Perangkat Lunak Utama di Rancher Labs (ya, ini adalah orang-orang yang sama yang membuat Rancher , yang slogannya terdengar seperti “Kubernetes Everywhere”) dan Komite Manajemen Proyek di Apache Software Foundation. Sebelumnya, saya bekerja untuk membangun layanan infrastruktur untuk mesin virtual di proyek CloudStack, dan sekarang, seperti yang Anda duga, untuk kontainer dengan penekanan pada Kubernetes. Ini adalah orang yang tidak hanya tahu segalanya tentang Kubernetes, tetapi juga dapat membicarakannya, mengambil tempat teratas di konferensi.

Laporannya adalah “Membangun platform untuk mengelola beberapa kluster Kubernet: perangkap dan solusi” . Intinya adalah bahwa jika dulunya sulit untuk bekerja dengan k8 dalam sebuah cluster, sekarang ini adalah masalah yang diselesaikan, dan pekerjaan tersebut telah pindah ke bidang pengelolaan beberapa kluster. Masalah dan solusi konkrit akan dipertimbangkan, didukung bukan oleh alasan abstrak, tetapi oleh contoh solusi mereka dalam pengembangan Rancher. Tapi ini bukan laporan tentang Rancher sebagai produk, tetapi pada pengalaman yang diperoleh bahwa insinyur mungkin perlu di bagian dev dan di bagian operasional. Jika Anda tidak tahu mengapa perusahaan memiliki lebih dari satu kluster Kubernetes, maka Anda harus membuka laporan ini.

Anton Weiss

Anton Weiss adalah co-pemilik konsultan teknologi Otomato Software, pemilik lebih dari 15 tahun pengalaman di bidang teknologi tinggi. Dia adalah seorang ahli dalam pengajaran teknis, penggagas dan penulis bersama kursus sertifikasi DevOPS Israel pertama. Anton berpartisipasi dalam konferensi internasional dan dikenal sebagai pembicara yang keren.

Kali ini, Anton akan datang kepada kami dengan laporan "DevOps for dinosaurus: bagaimana mengubah proses, pendekatan, dan pemikiran dalam perusahaan tradisional . " Selama tiga tahun terakhir, Otomato telah melaksanakan proyek Transformasi DevOps di beberapa perusahaan internasional besar. Mereka membantu dengan transisi ke teknologi baru, infrastruktur cloud, dan proses pengiriman berkelanjutan.
Tetapi yang utama adalah kami telah mengubah model kerja sama dan arus informasi.
Itu tidak mudah, jauh dari segalanya berhasil. Butuh lebih banyak waktu dan usaha daripada yang diinginkan. Laporan ini didasarkan pada pengalaman nyata. Di dalamnya, Anton akan mempertimbangkan semua yang telah mereka pelajari, dan memberi tahu Anda: apa yang berhasil, apa yang tidak berhasil, apa yang perlu dilakukan terlebih dahulu, lalu apa, dan apa yang harus Anda perhatikan pertama-tama.

Anton Babenko

Banyak orang tahu dan menggunakan Terraform dalam pekerjaan sehari-hari mereka. Namun sejauh ini, tidak ada praktik terbaik untuk Terraform. Setiap tim harus menemukan pendekatan, metode, sendiri.
Anton menjalankan koleksi modul komunitas Terraform untuk AWS di GitHub ( terraform-aws-modules , omong-omong - lebih dari satu juta unduhan!) Dan mengetahui segala sesuatu tentang pemeliharaan jangka panjang Terraform dalam produksi. Dia siap untuk berbagi pengalamannya yang berharga dengan kami. Cara menulis modul TF sehingga tidak sakit.

Alexander Titov

Alexander adalah penyelenggara komunitas DevOps Moscow dan konferensi DevOpsDays Moscow.

Sebagai mitra pengelola di Express 42, ia sekarang mengembangkan DevOps di perusahaan teknologi. Sebelum itu, ia adalah direktur teknis hosting awan pertama di Rusia - Scalaxy, dan sebelum itu ia mengikuti jalur pengambilalihan yang menarik bersama Qik - mulai dari mengoperasikan startup yang tumbuh cepat hingga beroperasi di perusahaan besar internasional Microsoft.

Kirill Tolkachev ( @tolkv )

Ini adalah salah satu pembicara yang sangat diinginkan audiens. Anda mungkin mengenalnya sebagai salah satu pendiri Two Devs One Ops, podcast yang sangat subyektif dan keren tentang DevOps dan tumpukan modern. Atau sebagai penduduk tetap podcast Pembekalan podcast, atau dari cerita dan laporan tentang Groovy, Gradle, Spring, dan tumpukan teknologi Netflix.

Sampai saat ini, Cyril bertindak sebagai pengembang utama di Laboratorium Alpha dan mengembangkan API perbankan, membentuk prinsip dan toolkit untuk bekerja dengan arsitektur layanan mikro. Dia tahu metodologi DevOps secara langsung dan memiliki empat tahun pengalaman dalam penerapannya. Sekarang Cyril dienkripsi, tetapi dia mungkin memiliki sesuatu untuk dibagikan.

Baruch Sadogursky ( @jbaruch ) dan Leonid Igolnik

Ini akan menjadi laporan bersama dari teman-teman hebat kami dan beberapa keyouter terbaik di konferensi Grup JUG.ru. Detail tentang laporan masih belum diketahui, jadi ada banyak waktu untuk menikmati intrik.

Di DevOops, mereka membuat keynote penutup yang indah, sebuah rekaman yang dapat dilihat di sini:

Bagi mereka yang belum tahu (ada?), Baruch adalah advokat pengembang di JFrog dan melakukan 3 hal dalam hidup: bergaul dengan pengembang, pengguna dan klien, menulis kode untuk mereka dan berbicara tentang tayangan di blog dan di konferensi - seperti DockerCon, DevOps Days, Container World, JPoint dan Joker, dan banyak lainnya. Jadi selama lebih dari sepuluh tahun berturut-turut, tidak satu menit pun menyesalinya.

Leonid adalah malaikat bisnis dan stasiun layanan dari sebuah perusahaan besar di Silicon Valley, di mana ia mengelola pengembangan aplikasi SaaS di bidang keamanan perusahaan. Sepanjang karirnya, ia telah terlibat dalam aplikasi online, memulainya di salah satu penyedia internet pertama Israel. Jelas sekali, Leonid sangat mengenal perkembangan, dan dengan manajemen, dan dengan administrasi proyek-proyek skala besar.

Panggilan untuk surat-surat

Apakah Anda memiliki topik yang menarik untuk laporan? Ingin bersaing dengan bison seperti Set Wargo dan Liz Rice? Jadi sudah waktunya untuk melamar! FP ditutup dengan kecepatan yang luar biasa, hingga tanggal empat belas Agustus, hanya ada sedikit waktu, dan hanya ada beberapa tempat yang tersisa dalam program. Daftar sekarang .

Langkah selanjutnya

DevOops 2018 akan diadakan pada 14 Oktober 2018 di St. Petersburg.

Kenalan lebih lanjut dengan proyek dapat dilanjutkan di situs . Perhatikan formulir berlangganan di halaman utama: pasti akan ada berita.

Sampai jumpa di DevOops 2018! Itu akan luar biasa!