Baru-baru ini, iklan semacam itu telah membanjiri Internet. Terlepas dari gaji yang menyenangkan, orang tidak dapat merasa malu karena bid'ah liar tertulis di dalamnya. Pada awalnya diasumsikan bahwa "DevOps" dan "engineer" entah bagaimana dapat dilem bersama dalam satu kata, dan kemudian muncul daftar persyaratan acak, beberapa di antaranya secara jelas disalin dari lowongan administrator sistem.
Dalam posting ini, saya ingin berbicara sedikit tentang bagaimana kita sampai pada titik tentang apa sebenarnya DevOps dan apa yang harus dilakukan dengan itu sekarang.
Kekosongan seperti itu dapat dikutuk dengan segala cara yang mungkin, tetapi faktanya tetap ada: ada banyak dari mereka, dan inilah cara pasar bekerja saat ini. Kami melakukan konferensi devo dan secara terbuka menyatakan: " DevOops - bukan untuk insinyur DevOps." Di sini, akan terasa aneh dan liar bagi banyak orang: mengapa orang yang melakukan acara yang sepenuhnya komersial bertentangan dengan pasar. Kami akan menjelaskan semuanya sekarang.
Tentang budaya dan proses
Untuk mulai dengan, DevOps bukan disiplin teknik. Semuanya dimulai dengan fakta bahwa pembagian peran yang secara historis telah mapan tidak bekerja pada kualitas produk. Ketika programmer hanya memprogram tetapi tidak ingin mendengar apa pun tentang pengujian, perangkat lunak dipenuhi dengan bug. Ketika administrator tidak peduli tentang bagaimana dan mengapa perangkat lunak ditulis, dukungan berubah menjadi neraka.
Sebagai contoh, Google SRE Book yang terkenal dimulai dengan deskripsi perbedaan antara pendekatan sysadmin dan SRE-shny untuk manajemen layanan. Studi menarik dilakukan sebagai bagian dari survei DORA - dapat dilihat bahwa pengembang terbaik entah bagaimana berhasil menyebarkan perubahan baru ke produksi lebih cepat daripada sekali dalam satu jam. Mereka menguji dengan tangan mereka tidak lebih dari 10% (ini terbukti dari DORA tahun lalu ). Bagaimana mereka melakukannya? “Excel or die” kata salah satu tajuk laporan. Untuk diskusi rinci tentang statistik ini dalam hal pengujian, Anda dapat beralih ke keynote utama Baruch Sadogursky “Kami memiliki DevOps. Mari kita tembak semua penguji ” di konferensi kami yang lain, Heisenbug.
"Ketika tidak ada kesepakatan di kawan-kawan,
Itu tidak akan berhasil dengan baik,
Dan itu tidak akan keluar darinya, hanya tepung.
Sekali Swan, Kanker dan Pike ... "
Bagaimana menurut Anda, bagian mana dari programmer web yang benar-benar memahami kondisi di mana aplikasi mereka dioperasikan pada prod? Berapa banyak dari mereka akan pergi ke admin dan mencoba mencari tahu apa yang akan terjadi ketika pangkalan jatuh? Dan siapa di antara mereka yang akan pergi ke penguji dan meminta untuk mengajar cara menulis tes dengan benar? Dan masih ada penjaga keamanan, manajer produk, dan banyak orang.
Ide umum DevOps adalah untuk membangun interaksi antara peran dan departemen. Pertama-tama, ini dicapai bukan oleh beberapa perangkat lunak yang disetel secara cerdik, tetapi oleh praktik komunikasi. DevOps adalah tentang budaya, praktik, metodologi, dan proses. Tidak ada keahlian teknik khusus yang akan menjawab pertanyaan-pertanyaan ini.
Lingkaran jahat
Lalu, dari mana datangnya disiplin “rekayasa teknik”? Kami punya versi! Ide DevOps ternyata bagus - sangat bagus sehingga mereka menjadi korban dari kesuksesan mereka. Di seputar topik ini beberapa perekrut dan pedagang gelap dengan suasana yang sangat istimewa mulai berputar.
Bayangkan: kemarin Anda membuat shawarma di Khimki, dan hari ini Anda sudah menjadi orang besar, perekrut senior. Ada seluruh proses pencarian dan pemilihan kandidat, semuanya tidak mudah, Anda perlu mengerti. Misalkan kepala departemen mengatakan: cari spesialis di X. Kami menetapkan kata "engineer" untuk X, dan intinya ada di topi. Butuh Linux? Yah, itu jelas seorang insinyur Linux, Anda ingin DevOps - insinyur DevOps. Pekerjaan tidak hanya terdiri dari tajuk, tetapi beberapa teks harus dimasukkan di dalamnya. Cara termudah adalah dengan memasukkan serangkaian kata kunci dari Google, untuk siapa imajinasi cukup. DevOps terdiri dari dua kata - "Dev" dan "Ops", yang berarti Anda harus merekatkan kata kunci yang terkait dengan pengembang dan administrator, semuanya dalam satu tumpukan. Jadi ada lowongan tentang memiliki 42 bahasa pemrograman dan 20 tahun menggunakan Kubernetes dan Swarm pada saat bersamaan. Skema kerja.
Jadi gambar tanpa pikir panjang dan tanpa belas kasihan dari seorang pahlawan super tertentu - "devopus" berakar dalam pikiran orang-orang, yang akan membuat setiap orang mengerahkan diri ke Jenkins, dan kebahagiaan akan datang. Ah, kalau saja sesederhana itu. "Dan Anda juga dapat meretas administrator sistem dengan cara ini," pikir Eichar, "kata itu modis, kata kunci sama, mereka harus mematuk."
Permintaan menciptakan persediaan, dan sejumlah administrator sistem yang gila telah menemukan semua lowongan sampah ini, yang telah menyadari bahwa Anda dapat melakukan hal yang sama seperti sebelumnya, tetapi dapatkan beberapa kali lebih banyak, menyebut diri Anda “devops”. Ketika Anda mengkonfigurasi server melalui SSH dengan tangan Anda satu per satu, Anda akan terus mengonfigurasi, tetapi sekarang ini seharusnya merupakan praktik devops. Ini adalah semacam fenomena kompleks, sebagian terkait baik dengan meremehkan admin klasik dan hype di sekitar DevOps, tetapi secara umum, apa yang terjadi ternyata.
Jadi, kami memiliki penawaran dan permintaan. Lingkaran setan yang memberi makan dirinya sendiri. Inilah yang kami perjuangkan (termasuk dengan membuat konferensi DevOops).
Tentu saja, selain administrator sistem, berganti nama menjadi "devops", ada peserta lain - misalnya, SRE profesional atau pengembang Infrastruktur-sebagai-Kode.
Apa yang dilakukan orang di DevOps (sebenarnya)
Jadi, Anda ingin maju dalam mempelajari dan menerapkan praktik-praktik DevOps. Tapi bagaimana cara melakukannya, ke arah mana terlihat? Jelas, dibimbing secara membabi buta oleh kata kunci populer tidak sepadan.
Jika ada pekerjaan, seseorang harus melakukannya. Kami telah menemukan bahwa ini bukan "insinyur DevOps", lalu siapa? Tampaknya lebih tepat untuk merumuskan ini bukan dalam hal posting, tetapi dalam hal area kerja tertentu.
Pertama, Anda dapat melakukan hal yang paling mendasar dari DevOps - proses dan budaya. Budaya bukanlah masalah yang cepat dan sulit, dan meskipun ini secara tradisional merupakan tanggung jawab manajer, dengan satu atau lain cara, semua orang terlibat dalam hal ini, dari pemrogram hingga admin. Beberapa bulan yang lalu, Tim Lister mengatakan dalam sebuah wawancara :
“Budaya diatur oleh nilai-nilai inti organisasi. Biasanya orang tidak memperhatikan ini, tetapi kami, bekerja dalam konsultasi selama bertahun-tahun, terbiasa memperhatikannya. Anda memasuki perusahaan dan secara harfiah dalam beberapa menit Anda mulai merasakan apa yang terjadi. Kami menyebutnya "aroma." Terkadang rasa ini sangat enak. Terkadang menyebabkan mual. (...) Anda tidak dapat mengubah budaya sebelum nilai-nilai dan keyakinan di balik tindakan nyata telah direalisasikan. Perilaku mudah diamati, dan mencari bujukan sulit. DevOps hanyalah contoh yang bagus tentang bagaimana segala sesuatunya menjadi semakin sulit. ”
Ada juga bagian teknis untuk pertanyaan itu, tentu saja. Jika Anda mendapatkan kode baru untuk pengujian dalam sebulan, dan dalam rilis itu hanya muncul dalam setahun, dan secara fisik tidak mungkin untuk mempercepat semua ini, Anda tidak bisa menjalankan praktik yang baik. Praktik yang baik didukung oleh alat yang baik. Misalnya, dengan gagasan Infrastruktur-sebagai-Kode dalam pikiran, Anda dapat menggunakan apa saja dari AWS CloudFormation dan Terraform hingga Chef-Ansible-Puppet. Anda perlu tahu dan bisa melakukan semua ini, dan ini adalah disiplin teknik sepenuhnya. Penting untuk tidak mencampuradukkan penyebabnya dengan konsekuensinya: pada awalnya Anda mengerjakan prinsip-prinsip SRE dan hanya kemudian Anda menerapkan prinsip-prinsip ini dalam bentuk beberapa solusi teknis tertentu. Pada saat yang sama, SRE adalah metodologi yang sangat komprehensif yang tidak berbicara tentang cara mengkonfigurasi Jenkins, tetapi tentang lima prinsip dasar:
- Meningkatkan interaksi antara peran dan departemen
- Menerima kesalahan sebagai bagian integral dari pekerjaan
- Perubahan progresif
- Menggunakan penyetelan dan otomatisasi lainnya
- Mengukur segala sesuatu yang bisa diukur
Ini bukan hanya seperangkat pernyataan, tetapi panduan khusus untuk bertindak . Misalnya, di jalan untuk membuat kesalahan, Anda perlu menangani risiko, mengukur ketersediaan dan tidak dapat diaksesnya layanan menggunakan sesuatu seperti SLI ( indikator tingkat layanan ) dan SLO ( sasaran tingkat layanan ), belajar cara menulis post-mortem dan membuatnya mudah untuk menulis .
Dalam disiplin SRE, penggunaan alat hanyalah satu bagian dari kesuksesan, namun itu penting. Kita perlu terus-menerus mengembangkan secara teknis, melihat apa yang terjadi di dunia dan bagaimana hal itu dapat diterapkan dalam pekerjaan kita.
Pada gilirannya, solusi Cloud Native menjadi sangat populer sekarang. Menurut pemahaman terkini tentang Cloud Native Computing Foundation, teknologi Cloud Native memungkinkan organisasi untuk mengembangkan dan menjalankan aplikasi yang dapat diukur dalam lingkungan dinamis saat ini seperti awan publik, pribadi, dan hybrid. Contohnya termasuk wadah, jerat layanan, layanan mikro, infrastruktur tidak berubah, dan API deklaratif. Semua teknik ini memungkinkan sistem yang digabungkan secara longgar tetap fleksibel, mudah dikelola, dan dapat diamati dengan baik. Otomatisasi yang baik memungkinkan para insinyur untuk membuat perubahan besar sering dan dengan hasil yang dapat diprediksi, tanpa mengubahnya menjadi pekerjaan neraka. Semua ini didukung oleh setumpuk alat terkenal seperti Docker dan Kubernetes.
Definisi yang agak rumit dan berbobot ini terhubung dengan fakta bahwa wilayah tersebut agak rumit. Di satu sisi, dikemukakan bahwa perubahan baru pada sistem ini harus ditambahkan secara sederhana. Di sisi lain, untuk mengetahui cara membuat semacam lingkungan kemas kemas di mana layanan yang digabungkan secara longgar menggunakan infrastruktur yang ditentukan oleh perangkat lunak dan dikirim ke sana menggunakan CI / CD berkelanjutan, dan membangun semua praktik DevOps ini - Anda memerlukan lebih dari satu makan seekor anjing.
Apa yang harus dilakukan dengan semua ini
Masing-masing memecahkan masalah ini dengan caranya sendiri: misalnya, Anda dapat menerbitkan pekerjaan normal untuk memutus lingkaran setan. Anda dapat mengetahui apa arti kata-kata seperti DevOps dan Cloud Native dan menggunakannya dengan benar dan to the point. Anda dapat mengembangkan di DevOps dan menunjukkan pendekatan yang tepat dengan contoh Anda sendiri.
Kami sedang melakukan konferensi Moskow DevOops 2020 , yang memberikan kesempatan untuk lebih memahami hal-hal yang baru saja kita bicarakan. Ada beberapa kelompok laporan untuk ini:
- Proses dan budaya;
- Rekayasa Keandalan Situs;
- Cloud Native
Bagaimana cara memilih ke mana harus pergi? Ada hal yang halus. Di satu sisi, DevOps adalah tentang interaksi, dan kami benar-benar ingin Anda membuka laporan dari blok yang berbeda. Di sisi lain, jika Anda adalah manajer pengembangan yang datang ke konferensi untuk berkonsentrasi pada satu tugas tertentu, maka tidak ada yang membatasi Anda - jelas, ini akan menjadi penghambat proses dan budaya. Jangan lupa bahwa setelah konferensi Anda akan memiliki catatan (setelah mengisi formulir umpan balik), sehingga Anda selalu dapat melihat laporan yang kurang penting nanti.
Jelas, di konferensi itu sendiri Anda tidak dapat langsung pergi ke tiga trek pada saat yang sama, jadi kami membuat program sedemikian rupa sehingga ada tema untuk setiap selera di setiap slot waktu.
Tetap hanya untuk memahami apa yang harus dilakukan jika Anda seorang insinyur DevOps! Pertama, cobalah untuk menentukan apa yang sebenarnya Anda lakukan. Biasanya mereka suka menyebut kata ini:
- Pengembang yang berurusan dengan infrastruktur. SRE dan grup bicara Cloud Native paling cocok untuk Anda.
- Administrator sistem. Itu lebih rumit. DevOops bukan tentang administrasi sistem. Untungnya, ada banyak konferensi hebat, buku, artikel, video di Internet, dll. Tentang masalah administrasi sistem. Di sisi lain, jika Anda tertarik untuk mengembangkan dalam hal memahami budaya dan proses, mengeksplorasi teknologi cloud dan detail kehidupan dengan Cloud Native, maka kami akan senang melihat Anda! Pikirkan tentang ini: di sini Anda berada dalam administrasi, dan kemudian apa yang akan Anda lakukan? Agar tidak tiba-tiba berada dalam situasi yang tidak menyenangkan, ada baiknya belajar sekarang.
Ada pilihan lain: Anda bertahan dan terus mengklaim bahwa Anda adalah insinyur DevOps dan tidak ada yang lain, apa pun artinya. Kemudian dipaksa bersedih, DevOops bukan konferensi untuk insinyur DevOps!
Slide dari laporan Konstantin Diener di Munich
DevOops 2020 Moskow akan diadakan 29-30 April di Moskow, tiket sudah dapat dibeli di situs web resmi .
Selain itu, Anda dapat mengirimkan laporan Anda pada 8 Februari. Harap perhatikan bahwa saat mengisi formulir, Anda harus memilih audiens target yang laporannya akan lebih baik ( kejutan terkubur di dalam daftar ).