Baru-baru ini, iklan sedemikian telah membanjiri Internet. Walaupun gaji yang menyenangkan, seseorang tidak boleh tidak malu kerana ajaran sesat liar tertulis di dalamnya. Pada mulanya diandaikan bahawa "DevOps" dan "jurutera" entah bagaimana boleh dilekatkan menjadi satu perkataan, dan kemudian terdapat senarai keperluan rawak, beberapa daripadanya disalin dengan jelas daripada kekosongan sysadmin.
Dalam siaran ini saya ingin bercakap sedikit tentang bagaimana kami sampai ke tahap kehidupan ini, apakah DevOps sebenarnya dan apa yang perlu dilakukan dengannya sekarang.
Kekosongan sedemikian boleh dikutuk dalam setiap cara yang mungkin, tetapi hakikatnya tetap: terdapat banyak daripada mereka, dan inilah cara pasaran berfungsi pada masa ini. Kami mengadakan persidangan devops dan secara terbuka mengisytiharkan: “ - bukan untuk jurutera DevOps." Ini akan kelihatan pelik dan liar kepada ramai: mengapa orang yang melakukan acara komersial sepenuhnya menentang pasaran. Sekarang kami akan menerangkan semuanya.
Mengenai budaya dan proses
Mari kita mulakan dengan fakta bahawa DevOps bukanlah disiplin kejuruteraan. Semuanya bermula dengan fakta bahawa pembahagian peranan yang ditubuhkan secara sejarah tidak berfungsi untuk kualiti produk. Apabila pengaturcara hanya memprogram, tetapi tidak mahu mendengar apa-apa tentang ujian, perisian itu penuh dengan pepijat. Apabila pentadbir tidak peduli bagaimana atau mengapa perisian itu ditulis, sokongan bertukar menjadi neraka.
Sebagai contoh, menerangkan perbezaan antara pentadbir sistem dan pendekatan SRE kepada pengurusan perkhidmatan . Kajian menarik telah dijalankan dalam — jelas bahawa pembangun terbaik entah bagaimana berjaya menggunakan perubahan baharu pada pengeluaran lebih cepat daripada sekali sejam. Mereka menguji dengan tangan mereka tidak lebih daripada 10% (ini boleh dilihat dari ). Bagaimana mereka melakukan ini? "Excel or die" kata salah satu tajuk laporan. Untuk perbincangan terperinci tentang statistik ini dalam konteks ujian, anda boleh merujuk kepada ucaptama Baruch Sadogursky pada persidangan kami yang lain, Heisenbug.
“Apabila tidak ada kesepakatan di antara kawan-kawan,
Perkara tidak akan berjalan lancar untuk mereka,
Dan tiada apa yang akan keluar daripadanya, hanya siksaan.
Suatu ketika dahulu Angsa, Udang dan Pike..."
Apakah bahagian pengaturcara web yang anda fikir benar-benar memahami keadaan di mana aplikasi mereka digunakan dalam pengeluaran? Berapa ramai daripada mereka akan pergi ke pentadbir dan cuba memikirkan apa yang akan berlaku jika pangkalan data ranap? Dan yang mana antara mereka akan pergi ke penguji dan meminta mereka mengajar mereka cara menulis ujian dengan betul? Dan terdapat juga pengawal keselamatan, pengurus produk, dan sekumpulan orang lain.
Idea keseluruhan DevOps adalah untuk mewujudkan kerjasama antara peranan dan jabatan. Pertama sekali, ini dicapai bukan oleh beberapa perisian yang dikonfigurasikan dengan bijak, tetapi dengan amalan komunikasi. DevOps adalah mengenai budaya, amalan, metodologi dan proses. Tiada kepakaran kejuruteraan yang boleh menjawab soalan ini.
Lingkaran jahat
Dari mana datangnya disiplin "devops engineering" ketika itu? Kami mempunyai versi! Idea DevOps bagus—sangat bagus sehingga menjadi mangsa kejayaan mereka sendiri. Beberapa perekrut teduh dan pemerdagang manusia, yang mempunyai suasana mereka sendiri, mula berputar di sekitar topik ini.
Bayangkan: semalam anda membuat shawarma di Khimki, dan hari ini anda sudah menjadi orang besar, seorang perekrut kanan. Terdapat keseluruhan proses mencari dan memilih calon, semuanya tidak mudah, anda perlu faham. Katakan ketua jabatan berkata: cari pakar dalam X. Kami menetapkan perkataan "jurutera" kepada X, dan kami telah selesai. Perlukan Linux? Nah, ini pasti jurutera Linux, jika anda mahukan DevOps, maka jurutera DevOps. Kekosongan itu bukan sahaja terdiri daripada tajuk, tetapi juga beberapa teks mesti dimasukkan ke dalam. Cara paling mudah ialah memasukkan set kata kunci daripada Google, bergantung pada imaginasi anda. DevOps terdiri daripada dua perkataan - "Dev" dan "Ops", yang bermaksud bahawa kita perlu menggabungkan kata kunci yang berkaitan dengan pembangun dan pentadbir, semuanya menjadi satu longgokan. Ini adalah bagaimana kekosongan muncul tentang kemahiran dalam 42 bahasa pengaturcaraan dan 20 tahun menggunakan Kubernetes dan Swarm secara serentak. Gambar rajah kerja.
Beginilah imej tidak bermakna dan tanpa belas kasihan seorang wira-wira "devops" tertentu telah berakar umbi dalam fikiran orang ramai, yang akan mengkonfigurasi semua orang untuk digunakan ke Jenkins, dan kebahagiaan akan datang. Oh, kalaulah semuanya begitu mudah. "Dan ini juga cara anda boleh memburu pentadbir sistem," fikir HR, "ia adalah perkataan yang bergaya, kata kuncinya sama, mereka harus mengambil umpan."
Permintaan mencipta bekalan, dan semua kekosongan sampah ini telah diisi dengan bilangan pentadbir sistem yang tidak siuman yang menyedari: anda boleh melakukan segala-galanya sama seperti sebelumnya, tetapi mendapat beberapa kali lebih banyak dengan memanggil diri anda "devops." Sama seperti anda mengkonfigurasi pelayan melalui SSH secara manual satu demi satu, anda akan terus mengkonfigurasinya, tetapi kini ini sepatutnya menjadi amalan devops. Ini adalah sejenis fenomena kompleks, sebahagiannya berkaitan dengan memandang rendah pentadbir klasik dan gembar-gembur di sekitar DevOps, tetapi secara umum, apa yang berlaku, telah berlaku.
Jadi kita mempunyai bekalan dan permintaan. Lingkaran ganas yang memakan dirinya sendiri. Inilah yang kami lawan (termasuk dengan mencipta persidangan DevOops).
Sudah tentu, selain pentadbir sistem yang telah menamakan semula diri mereka sebagai "devops," terdapat peserta lain - contohnya, SRE profesional atau pembangun Infrastruktur-sebagai-Kod.
Perkara yang orang lakukan dalam DevOps (benar-benar)
Jadi anda ingin maju dalam mempelajari dan menggunakan amalan DevOps. Tetapi bagaimana untuk melakukan ini, ke arah mana untuk melihat? Jelas sekali, anda tidak seharusnya bergantung pada kata kunci popular secara membuta tuli.
Jika ada pekerjaan, seseorang harus melakukannya. Kami telah mengetahui bahawa ini bukan "jurutera devops", maka siapa? Nampaknya lebih tepat untuk merumuskan ini bukan dari segi jawatan, tetapi dari segi bidang kerja tertentu.
Pertama, anda boleh menangani inti DevOps—proses dan budaya. Budaya adalah perniagaan yang perlahan dan sukar, dan walaupun secara tradisinya tanggungjawab pengurus, semua orang terlibat dalam satu atau lain cara, daripada pengaturcara kepada pentadbir. Beberapa bulan yang lalu Tim Lister :
“Budaya ditentukan oleh nilai teras organisasi. Biasanya orang tidak perasan perkara ini, tetapi setelah bekerja dalam perundingan selama bertahun-tahun, kami sudah biasa menyedarinya. Anda memasuki sebuah syarikat dan dalam beberapa minit anda mula merasakan apa yang sedang berlaku. Kami memanggil ini "rasa". Kadang-kadang bau ni memang sedap. Kadang-kadang ia menyebabkan loya. (...) Anda tidak boleh mengubah budaya sehingga nilai dan kepercayaan di sebalik tindakan tertentu difahami. Tingkah laku mudah diperhatikan, tetapi mencari kepercayaan adalah sukar. DevOps hanyalah contoh yang bagus tentang bagaimana keadaan menjadi semakin kompleks.”
Terdapat juga bahagian teknikal dalam isu itu, sudah tentu. Jika kod baharu anda diuji dalam sebulan, tetapi dikeluarkan hanya setahun kemudian, dan secara fizikal mustahil untuk mempercepatkan semuanya, anda mungkin tidak mematuhi amalan yang baik. Amalan yang baik disokong oleh alat yang baik. Sebagai contoh, dengan memikirkan idea Infrastructure-as-Code, anda boleh menggunakan apa sahaja daripada AWS CloudFormation dan Terraform kepada Chef-Ansible-Puppet. Anda perlu tahu dan boleh melakukan semua ini, dan ini sudah menjadi satu disiplin kejuruteraan. Adalah penting untuk tidak mengelirukan sebab dengan kesan: mula-mula anda bekerja mengikut prinsip SRE dan hanya kemudian melaksanakan prinsip ini dalam bentuk beberapa penyelesaian teknikal tertentu. Pada masa yang sama, SRE ialah metodologi yang sangat komprehensif yang tidak memberitahu anda cara menyediakan Jenkins, tetapi kira-kira lima prinsip asas:
- Meningkatkan komunikasi antara peranan dan jabatan
- Menerima kesilapan sebagai bahagian penting dalam pekerjaan
- Membuat perubahan secara beransur-ansur
- Menggunakan perkakasan dan automasi lain
- Mengukur segala yang boleh diukur
Ini bukan hanya beberapa set pernyataan, tetapi khusus . Sebagai contoh, dalam laluan untuk menerima ralat, anda perlu memahami risiko, mengukur ketersediaan dan ketiadaan perkhidmatan menggunakan sesuatu seperti SLI () dan SLO (), belajar menulis postmortem dan jadikan penulisannya tidak menakutkan.
Dalam disiplin SRE, penggunaan alat hanyalah sebahagian daripada kejayaan, walaupun penting. Kita perlu sentiasa membangun secara teknikal, melihat apa yang berlaku di dunia dan bagaimana ia boleh digunakan dalam kerja kita.
Sebaliknya, penyelesaian Cloud Native kini telah menjadi sangat popular. Seperti yang ditakrifkan oleh Yayasan Pengkomputeran Asli Awan hari ini, teknologi Cloud Native membolehkan organisasi membangunkan dan menjalankan aplikasi berskala dalam persekitaran dinamik hari ini, seperti awan awam, peribadi dan hibrid. Contohnya termasuk bekas, jaringan perkhidmatan, perkhidmatan mikro, infrastruktur tidak boleh diubah dan API pengisytiharan. Kesemua teknik ini membenarkan sistem yang digandingkan secara longgar untuk kekal elastik, terurus dan sangat boleh diperhatikan. Automasi yang baik membolehkan jurutera membuat perubahan besar dengan kerap dan dengan hasil yang boleh diramal tanpa menjadikannya satu tugas. Semua ini disokong oleh timbunan alatan yang terkenal seperti Docker dan Kubernetes.
Takrifan yang agak rumit dan luas ini adalah disebabkan kawasan itu juga agak kompleks. Di satu pihak, ia dikatakan bahawa perubahan baru kepada sistem ini harus ditambah dengan agak mudah. Sebaliknya, untuk memikirkan cara untuk mencipta sejenis persekitaran kontena di mana perkhidmatan gandingan longgar hidup pada infrastruktur yang ditentukan perisian dan dihantar ke sana menggunakan CI/CD berterusan, dan membina amalan DevOps di sekeliling semua ini - semua ini memerlukan lebih banyak daripada seseorang memakan anjing itu.
Apa nak jadi dengan semua ni
Semua orang menyelesaikan masalah ini dengan cara mereka sendiri: sebagai contoh, anda boleh menerbitkan kekosongan biasa untuk memecahkan lingkaran setan. Anda boleh mengetahui maksud perkataan seperti DevOps dan Cloud Native dan menggunakannya dengan betul dan tepat. Anda boleh membangunkan dalam DevOps dan menunjukkan pendekatan yang betul melalui contoh anda.
Kami sedang mengadakan persidangan , yang memberi peluang untuk mendalami perkara yang baru kita bincangkan. Terdapat beberapa kumpulan laporan untuk ini:
- Proses dan budaya;
- Kejuruteraan Kebolehpercayaan Tapak;
- Asli Awan;
Bagaimana untuk memilih ke mana hendak pergi? Terdapat titik halus di sini. Di satu pihak, DevOps adalah mengenai interaksi, dan kami benar-benar mahu anda menghadiri pembentangan daripada blok yang berbeza. Sebaliknya, jika anda seorang pengurus pembangunan yang datang ke persidangan untuk menumpukan perhatian pada satu tugas tertentu, maka tiada siapa yang mengehadkan anda - jelas sekali, ini akan menjadi sekatan tentang proses dan budaya. Jangan lupa bahawa anda akan mempunyai rakaman selepas persidangan (selepas mengisi borang maklum balas), jadi anda sentiasa boleh menonton pembentangan yang kurang penting kemudian.
Jelas sekali, pada persidangan itu sendiri anda tidak boleh pergi pada tiga trek sekaligus, jadi kami menganjurkan program sedemikian rupa sehingga setiap slot masa mempunyai topik untuk setiap selera.
Yang tinggal hanyalah memahami perkara yang perlu dilakukan jika anda seorang jurutera DevOps! Pertama, cuba tentukan apa yang anda lakukan sebenarnya. Biasanya mereka suka memanggil perkataan ini:
- Pemaju yang mengusahakan infrastruktur. Kumpulan laporan tentang SRE dan Cloud Native adalah paling sesuai untuk anda.
- Pentadbir sistem. Ia lebih rumit di sini. DevOops bukan mengenai pentadbiran sistem. Nasib baik, terdapat banyak persidangan, buku, artikel, video yang sangat baik di Internet, dan lain-lain mengenai topik pentadbiran sistem. Sebaliknya, jika anda berminat untuk membangunkan diri anda dari segi memahami budaya dan proses, mempelajari tentang teknologi awan dan butiran kehidupan dengan Cloud Native, maka kami ingin berjumpa dengan anda! Fikirkan tentang ini: anda sedang menjalankan pentadbiran, dan kemudian apa yang akan anda lakukan? Untuk mengelakkan tiba-tiba mendapati diri anda dalam situasi yang tidak menyenangkan, anda harus belajar sekarang.
Terdapat satu lagi pilihan: anda berterusan dan terus mendakwa bahawa anda adalah khususnya seorang jurutera DevOps dan tidak ada yang lain, apa pun maksudnya. Kemudian kami perlu mengecewakan anda, DevOops bukan persidangan untuk jurutera DevOps!
Slaid dari di Munich
DevOops 2020 Moscow akan diadakan pada 29-30 April di Moscow, tiket sudah tersedia .
Sebagai alternatif, anda boleh sehingga 8 Februari. Sila ambil perhatian bahawa semasa mengisi borang, anda mesti memilih khalayak sasaran yang paling mendapat manfaat daripada laporan anda (ada kejutan yang terkubur di dalam senarai).
Sumber: www.habr.com