Baru-baru ini, iklan semacam itu membanjiri Internet. Meskipun gajinya bagus, orang pasti merasa malu karena ada ajaran sesat liar yang tertulis di dalamnya. Pada awalnya diasumsikan bahwa "DevOps" dan "engineer" entah bagaimana dapat direkatkan menjadi satu kata, dan kemudian ada daftar persyaratan acak, beberapa di antaranya dengan jelas disalin dari lowongan sysadmin.
Dalam postingan ini saya ingin berbicara sedikit tentang bagaimana kita sampai pada titik kehidupan ini, apa sebenarnya DevOps dan apa yang harus dilakukan saat ini.
Lowongan seperti itu bisa dikutuk dengan segala cara, namun faktanya tetap ada: ada banyak lowongan, dan begitulah cara kerja pasar saat ini. Kami mengadakan konferensi devops dan secara terbuka menyatakan: “ - bukan untuk insinyur DevOps." Ini mungkin tampak aneh dan liar bagi banyak orang: mengapa orang-orang yang mengadakan acara komersial sepenuhnya menentang pasar. Sekarang kami akan menjelaskan semuanya.
Tentang budaya dan proses
Mari kita mulai dengan fakta bahwa DevOps bukanlah disiplin ilmu teknik. Semuanya dimulai dengan fakta bahwa pembagian peran yang ditetapkan secara historis tidak sesuai dengan kualitas produk. Ketika pemrogram hanya memprogram, tetapi tidak ingin mendengar apa pun tentang pengujian, perangkat lunak tersebut penuh dengan bug. Ketika admin tidak peduli bagaimana atau mengapa perangkat lunak itu ditulis, dukungan menjadi seperti neraka.
Misalnya, menjelaskan perbedaan antara administrator sistem dan pendekatan SRE terhadap manajemen layanan . Studi menarik telah dilakukan di dalamnya — jelas bahwa pengembang terbaik entah bagaimana berhasil menerapkan perubahan baru pada produksi lebih cepat dari satu kali dalam satu jam. Mereka menguji dengan tangan tidak lebih dari 10% (hal ini terlihat dari ). bagaimana mereka melakukan ini? “Unggul atau mati” adalah salah satu judul laporan. Untuk pembahasan rinci tentang statistik ini dalam konteks pengujian, Anda dapat merujuk pada keynote Baruch Sadogursky di konferensi kami yang lain, Heisenbug.
“Ketika tidak ada kesepakatan di antara kawan-kawan,
Bisnis mereka tidak akan berjalan dengan baik,
Dan tidak ada yang keluar darinya, hanya tepung.
Dahulu kala seekor Angsa, Udang Karang, dan Pike..."
Menurut Anda, bagian mana dari pemrogram web yang benar-benar memahami kondisi di mana aplikasi mereka digunakan dalam produksi? Berapa banyak dari mereka yang akan menemui admin dan mencoba mencari tahu apa yang akan terjadi jika database crash? Dan siapa di antara mereka yang akan mendatangi penguji dan meminta mereka mengajari mereka cara menulis tes dengan benar? Dan ada juga penjaga keamanan, manajer produk, dan banyak orang lainnya.
Ide keseluruhan DevOps adalah untuk menciptakan kolaborasi antar peran dan departemen. Pertama-tama, hal ini dicapai bukan melalui perangkat lunak yang dikonfigurasi secara cerdik, namun melalui praktik komunikasi. DevOps adalah tentang budaya, praktik, metodologi, dan proses. Tidak ada keahlian teknik yang dapat menjawab pertanyaan-pertanyaan ini.
Lingkaran jahat
Dari mana datangnya disiplin “rekayasa devops”? Kami punya versinya! Ide-ide DevOps bagus—sangat bagus sehingga menjadi korban kesuksesan mereka sendiri. Beberapa perekrut licik dan pedagang manusia, yang memiliki suasananya sendiri, mulai membahas topik ini secara keseluruhan.
Bayangkan: kemarin Anda membuat shawarma di Khimki, dan hari ini Anda sudah menjadi orang besar, perekrut senior. Ada proses pencarian dan seleksi calon yang menyeluruh, semuanya tidak mudah, perlu dipahami. Katakanlah kepala departemen mengatakan: temukan spesialis di X. Kita menugaskan kata “insinyur” ke X, dan selesai. Butuh Linux? Ya, ini pasti seorang insinyur Linux, jika Anda menginginkan DevOps, maka seorang insinyur DevOps. Lowongan tersebut tidak hanya terdiri dari judul, tetapi juga beberapa teks harus dimasukkan di dalamnya. Cara termudah adalah dengan memasukkan kumpulan kata kunci dari Google, tergantung imajinasi Anda. DevOps terdiri dari dua kata - “Dev” dan “Ops”, yang berarti kita perlu merekatkan kata kunci yang terkait dengan pengembang dan administrator ke dalam satu tumpukan. Ini adalah bagaimana muncul lowongan tentang kemahiran dalam 42 bahasa pemrograman dan 20 tahun menggunakan Kubernetes dan Swarm secara bersamaan. Diagram kerja.
Beginilah gambaran yang tidak masuk akal dan tanpa ampun dari pahlawan super “devops” tertentu telah mengakar di benak orang-orang, yang akan mengkonfigurasi semua orang untuk ditempatkan di Jenkins, dan kebahagiaan akan datang. Oh, andai saja semuanya sesederhana itu. “Dan ini juga merupakan cara untuk memburu administrator sistem,” pikir HR, “ini adalah kata yang populer, kata kuncinya sama, mereka harus mengambil umpan.”
Permintaan menciptakan pasokan, dan semua kekosongan sampah ini telah diisi oleh sejumlah besar administrator sistem yang menyadari: Anda dapat melakukan semuanya sama seperti sebelumnya, tetapi mendapatkan beberapa kali lebih banyak dengan menyebut diri Anda “devops.” Sama seperti Anda mengonfigurasi server melalui SSH secara manual satu per satu, Anda akan terus mengonfigurasinya, tetapi sekarang ini seharusnya merupakan praktik devops. Ini adalah semacam fenomena kompleks, sebagian terkait dengan meremehkan admin klasik dan hype seputar DevOps, tetapi secara umum, apa yang terjadi, terjadilah.
Jadi kita punya penawaran dan permintaan. Lingkaran setan yang memberi makan dirinya sendiri. Inilah yang kami lawan (termasuk dengan membuat konferensi DevOops).
Tentu saja, selain administrator sistem yang telah mengganti nama dirinya menjadi “devops”, ada peserta lain - misalnya, SRE profesional atau pengembang Infrastruktur sebagai Kode.
Apa yang dilakukan orang-orang di DevOps (sebenarnya)
Jadi, Anda ingin maju dalam mempelajari dan menerapkan praktik DevOps. Tapi bagaimana melakukan ini, ke arah mana harus melihat? Tentu saja, Anda tidak boleh begitu saja mengandalkan kata kunci populer.
Jika ada pekerjaan, seseorang harus melakukannya. Kita telah mengetahui bahwa mereka bukanlah “insinyur devops”, lalu siapa? Tampaknya lebih tepat merumuskannya bukan dalam istilah jabatan, tetapi dalam bidang pekerjaan tertentu.
Pertama, Anda dapat mengatasi inti DevOps—proses dan budaya. Budaya adalah bisnis yang lambat dan sulit, dan meskipun secara tradisional merupakan tanggung jawab manajer, semua orang terlibat dalam satu atau lain cara, mulai dari pemrogram hingga administrator. Beberapa bulan yang lalu Tim Lister :
“Budaya ditentukan oleh nilai-nilai inti organisasi. Biasanya orang tidak memperhatikan hal ini, tetapi setelah bekerja di bidang konsultasi selama bertahun-tahun, kami terbiasa memperhatikannya. Anda memasuki sebuah perusahaan dan dalam beberapa menit Anda mulai merasakan apa yang terjadi. Kami menyebutnya "rasa". Terkadang aroma ini sangat enak. Terkadang hal itu menyebabkan mual. (...) Anda tidak dapat mengubah suatu budaya sampai nilai dan keyakinan di balik tindakan tertentu dipahami. Perilaku mudah diamati, namun mencari keyakinan itu sulit. DevOps hanyalah contoh bagus tentang bagaimana segala sesuatunya menjadi semakin kompleks.”
Tentu saja ada juga bagian teknis dari masalah ini. Jika kode baru Anda diuji dalam satu bulan, namun baru dirilis setahun kemudian, dan secara fisik tidak mungkin untuk mempercepat semuanya, Anda mungkin tidak menjalankan praktik yang baik. Praktik yang baik didukung oleh alat yang baik. Misalnya, dengan mempertimbangkan gagasan Infrastruktur sebagai Kode, Anda dapat menggunakan apa pun mulai dari AWS CloudFormation dan Terraform hingga Chef-Ansible-Puppet. Anda perlu mengetahui dan mampu melakukan semua ini, dan ini sudah merupakan disiplin ilmu teknik. Penting untuk tidak mengacaukan sebab dan akibat: pertama Anda bekerja berdasarkan prinsip SRE dan baru kemudian menerapkan prinsip-prinsip ini dalam bentuk beberapa solusi teknis tertentu. Pada saat yang sama, SRE adalah metodologi yang sangat komprehensif yang tidak memberi tahu Anda cara menyiapkan Jenkins, tetapi tentang lima prinsip dasar:
- Peningkatan komunikasi antar peran dan departemen
- Menerima kesalahan sebagai bagian integral dari pekerjaan
- Melakukan perubahan secara bertahap
- Menggunakan perkakas dan otomatisasi lainnya
- Mengukur segala sesuatu yang dapat diukur
Ini bukan hanya serangkaian pernyataan, tetapi pernyataan yang spesifik . Misalnya, dalam proses menerima kesalahan, Anda perlu memahami risikonya, mengukur ketersediaan dan tidak tersedianya layanan menggunakan sesuatu seperti SLI () dan lambat (), belajar menulis postmortem dan membuat penulisannya tidak menakutkan.
Dalam disiplin SRE, penggunaan alat hanyalah salah satu bagian dari kesuksesan, meskipun merupakan bagian yang penting. Kita perlu terus berkembang secara teknis, melihat apa yang terjadi di dunia dan bagaimana hal itu dapat diterapkan dalam pekerjaan kita.
Pada gilirannya, solusi Cloud Native kini menjadi sangat populer. Sebagaimana didefinisikan oleh Cloud Native Computing Foundation saat ini, teknologi Cloud Native memungkinkan organisasi untuk mengembangkan dan menjalankan aplikasi yang dapat diskalakan di lingkungan dinamis saat ini, seperti cloud publik, privat, dan hybrid. Contohnya termasuk container, mesh layanan, layanan mikro, infrastruktur yang tidak dapat diubah, dan API deklaratif. Semua teknik ini memungkinkan sistem yang digabungkan secara longgar tetap elastis, dapat dikelola, dan sangat mudah diamati. Otomatisasi yang baik memungkinkan para insinyur membuat perubahan besar secara sering dan dengan hasil yang dapat diprediksi tanpa menjadikannya sebuah tugas. Semua ini didukung oleh serangkaian alat terkenal seperti Docker dan Kubernetes.
Definisi yang agak rumit dan luas ini disebabkan karena wilayahnya juga cukup kompleks. Di satu sisi, ada pendapat bahwa perubahan baru pada sistem ini harus dilakukan dengan cukup sederhana. Di sisi lain, untuk mengetahui cara menciptakan semacam lingkungan yang terkontainerisasi di mana layanan yang digabungkan secara longgar berada pada infrastruktur yang ditentukan perangkat lunak dan dikirimkan ke sana menggunakan CI/CD yang berkelanjutan, dan membangun praktik DevOps di sekitar semua ini - semua ini memerlukan lebih banyak hal. daripada seseorang yang memakan anjing itu.
Apa yang harus dilakukan dengan semua ini
Setiap orang memecahkan masalah ini dengan caranya sendiri: misalnya, Anda dapat mempublikasikan lowongan normal untuk memutus lingkaran setan. Anda dapat memahami arti dari kata-kata seperti DevOps dan Cloud Native dan menggunakannya dengan benar dan langsung pada sasaran. Anda dapat mengembangkan di DevOps dan mendemonstrasikan pendekatan yang tepat melalui contoh Anda.
Kami sedang mengadakan konferensi , yang memberikan kesempatan untuk mempelajari lebih dalam hal-hal yang baru saja kita bicarakan. Ada beberapa kelompok laporan untuk ini:
- Proses dan budaya;
- Rekayasa Keandalan Situs;
- Cloud Asli;
Bagaimana cara memilih ke mana harus pergi? Ada poin halus di sini. Di satu sisi, DevOps adalah tentang interaksi, dan kami sangat ingin Anda menghadiri presentasi dari berbagai blok. Di sisi lain, jika Anda seorang manajer pengembangan yang datang ke konferensi untuk berkonsentrasi pada satu tugas tertentu, maka tidak ada yang membatasi Anda - jelas, ini akan menjadi hambatan dalam hal proses dan budaya. Jangan lupa bahwa Anda akan memiliki rekamannya setelah konferensi (setelah mengisi formulir umpan balik), sehingga Anda selalu dapat menonton presentasi yang kurang penting nanti.
Tentunya, pada konferensi itu sendiri Anda tidak dapat mengikuti tiga lagu sekaligus, jadi kami mengatur program sedemikian rupa sehingga setiap slot waktu memiliki topik untuk setiap selera.
Yang tersisa hanyalah 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 mengerjakan infrastruktur. Kelompok laporan tentang SRE dan Cloud Native paling cocok untuk Anda.
- Administrator sistem. Ini lebih rumit di sini. DevOops bukan tentang administrasi sistem. Untungnya, ada banyak konferensi, buku, artikel, video bagus di Internet, dll. tentang topik administrasi sistem. Di sisi lain, jika Anda tertarik untuk mengembangkan diri dalam hal memahami budaya dan proses, mempelajari teknologi cloud, dan detail kehidupan dengan Cloud Native, kami akan senang melihat Anda! Coba pikirkan: Anda mengurus administrasi, lalu apa yang akan Anda lakukan? Untuk menghindari tiba-tiba Anda berada dalam situasi yang tidak menyenangkan, Anda harus belajar sekarang.
Ada pilihan lain: Anda bertahan dan terus mengklaim bahwa Anda memang benar khususnya seorang insinyur DevOps dan tidak ada yang lain, apa pun artinya. Maka kami harus mengecewakan Anda, DevOops bukanlah konferensi untuk para insinyur DevOps!
Geser dari di Munich
DevOops 2020 Moscow akan diadakan pada 29-30 April di Moskow, tiket sudah tersedia .
Atau, Anda bisa hingga 8 Februari. Harap dicatat bahwa saat mengisi formulir, Anda harus memilih target audiens yang paling mendapat manfaat dari laporan Anda (ada kejutan yang terkubur di dalam daftar).
Sumber: www.habr.com