Saat ini, ini adalah posisi yang paling mahal di pasar. Keramaian dan hiruk pikuk di sekitar insinyur DevOps melebihi semua batas yang bisa dibayangkan, apalagi dengan insinyur Senior DevOps.
Saya bekerja sebagai kepala departemen integrasi dan otomasi, tebak dekripsi bahasa Inggris - Manajer DevOps. Apakah pendekodean bahasa Inggris mencerminkan aktivitas sehari-hari kita tidak mungkin, tetapi versi Rusia dalam kasus ini lebih akurat. Berdasarkan sifat pekerjaan saya, adalah wajar bahwa saya perlu mewawancarai anggota tim saya yang akan datang dan, selama tahun lalu, sekitar 50 orang melewati saya, dan jumlah yang sama terputus di layar dengan karyawan saya.
Kami masih mencari kolega, karena di belakang label DevOps adalah lapisan yang sangat besar dari berbagai jenis insinyur.
Segala sesuatu yang ditulis di bawah ini adalah pendapat pribadi saya, Anda tidak diwajibkan untuk menyetujuinya, tetapi saya akui itu akan memberi sentuhan pada sikap Anda terhadap topik tersebut. Meskipun ada risiko tidak disukai, saya menerbitkan pendapat saya, karena saya yakin dia punya tempat untuk menjadi.
Perusahaan berbeda memahami siapa insinyur DevOps dan demi merekrut sumber daya dengan cepat mereka menggantung label ini untuk semua orang. Situasinya agak aneh, karena perusahaan bersedia membayar imbalan yang tidak realistis kepada orang-orang ini, menerima, dalam banyak kasus, alat admin untuk mereka.
Jadi siapa insinyur DevOps?
Mari kita mulai dengan ceritanya - Operasi Pengembangan muncul sebagai langkah lain menuju mengoptimalkan interaksi dalam tim kecil untuk meningkatkan kecepatan produksi produk, sebagai konsekuensi yang diharapkan. Idenya adalah untuk memperkuat tim pengembangan dengan pengetahuan tentang prosedur dan pendekatan dalam mengelola lingkungan produk. Dengan kata lain, pengembang harus memahami dan tahu bagaimana produknya bekerja di bawah kondisi tertentu, harus memahami cara menggunakan produknya, karakteristik lingkungan mana yang harus diperketat, untuk meningkatkan produktivitas. Jadi, untuk beberapa waktu, pengembang muncul dengan pendekatan DevOps. Pengembang DevOps menulis skrip pembuatan dan pengemasan untuk menyederhanakan aktivitas mereka dan kinerja lingkungan yang produktif. Namun, kompleksitas arsitektur keputusan dan pengaruh timbal balik dari komponen infrastruktur dari waktu ke waktu mulai memperburuk kinerja lingkungan, dengan setiap iterasi, pemahaman yang lebih mendalam tentang komponen tertentu diperlukan, mengurangi produktivitas pengembang sendiri karena biaya tambahan untuk memahami komponen dan sistem tuning untuk tugas tertentu . Biaya pengembang sendiri tumbuh, biaya produk bersama dengannya, persyaratan untuk pengembang baru dalam tim melonjak tajam, karena mereka juga harus menanggung tanggung jawab "bintang" pembangunan dan, tentu saja, "bintang" menjadi kurang dapat diakses. Perlu juga dicatat bahwa, dalam pengalaman saya, beberapa pengembang tertarik pada spesifikasi pemrosesan paket oleh kernel sistem operasi, aturan routing paket, dan aspek keamanan host. Langkah logisnya adalah menarik seorang administrator yang terbiasa dengan tanggung jawab khusus ini dan memberikan tanggung jawab format yang serupa dengannya, yang, berkat pengalamannya, memungkinkan untuk mencapai indikator yang sama dengan biaya lebih rendah dibandingkan dengan biaya "bintang" pembangunan. Administrator semacam itu ditempatkan dalam tim dan tugas utamanya adalah mengelola lingkungan pengujian dan produktif, berdasarkan aturan tim tertentu, dengan sumber daya dialokasikan ke tim khusus ini. Jadi, pada kenyataannya, DevOps muncul di tampilan mayoritas.
Sebagian atau seluruhnya, seiring waktu, administrator sistem ini mulai memahami kebutuhan tim khusus ini dalam bidang pengembangan, bagaimana menyederhanakan kehidupan pengembang dan penguji, cara meluncurkan pembaruan dan tidak menginap di kantor pada hari Jumat, memperbaiki kesalahan penyebaran. Seiring berjalannya waktu, sekarang administrator sistem yang memahami apa yang diinginkan pengembang menjadi "bintang". Untuk meminimalkan dampak, utilitas manajemen mulai mengejar, semua orang ingat metode lama dan dapat diandalkan untuk mengisolasi tingkat OS, yang memungkinkan meminimalkan persyaratan keamanan, mengelola bagian jaringan, dan konfigurasi host secara keseluruhan dan, sebagai hasilnya, mengurangi persyaratan untuk "bintang" baru.
Suatu hal yang "luar biasa" telah muncul - buruh pelabuhan. Mengapa indah? Ya, hanya karena membuat isolasi di chroot atau jail, serta OpenVZ, diperlukan pengetahuan non-sepele dari OS, dalam utilitas penghitung yang memungkinkan Anda untuk dengan mudah membuat lingkungan aplikasi yang terisolasi pada host tertentu dengan semua yang Anda butuhkan di dalam dan mentransfer kendali ke pengembangan lagi, dan hanya mengelola administrator sistem hanya satu host, memastikan keamanannya dan ketersediaan tinggi - penyederhanaan yang logis. Tetapi kemajuan tidak berhenti dan sistem menjadi semakin rumit, semakin banyak komponen, satu host tidak lagi memenuhi kebutuhan sistem dan perlu untuk membangun cluster, kami kembali ke administrator sistem yang dapat membangun sistem ini.
Siklus demi siklus, berbagai sistem muncul yang menyederhanakan pengembangan dan / atau administrasi, sistem orkestrasi muncul, tepat hingga Anda perlu menjauh dari proses standar, mudah digunakan. Arsitektur microservice juga muncul untuk menyederhanakan semua yang dijelaskan di atas - hubungan yang lebih sedikit, lebih mudah dikelola. Dalam pengalaman saya, saya tidak menemukan arsitektur layanan sepenuhnya mikro, saya akan mengatakan 50 hingga 50 - 50 persen layanan mikro, kotak hitam, masuk, diproses, 50 lainnya - monolit yang terkoyak, layanan tidak dapat bekerja secara terpisah dari komponen lain. Semua ini sekali lagi memberlakukan pembatasan pada tingkat pengetahuan pengembang dan administrator.
"Ayunan" serupa dari tingkat pengetahuan pakar tentang sumber daya tertentu berlanjut hingga hari ini. Tapi kami sedikit terganggu, ada banyak poin yang patut disorot.
Build engineer / release engineer
Insinyur yang sangat terspesialisasi yang muncul sebagai cara untuk menstandarkan proses perakitan perangkat lunak dan rilisnya. Dalam proses memperkenalkan Agile massal, tampaknya mereka tidak lagi diminati, tetapi ini jauh dari kasus. Spesialisasi ini telah muncul sebagai sarana standarisasi perakitan dan pengiriman perangkat lunak pada skala industri, yaitu menggunakan teknik standar untuk semua produk perusahaan. Dengan munculnya DevOps, pengembang telah kehilangan sebagian fungsinya, karena itu adalah pengembang yang mulai menyiapkan produk untuk pengiriman, dan mengingat perubahan infrastruktur dan pendekatan untuk pengiriman tercepat tanpa memperhatikan kualitas, seiring waktu mereka berubah menjadi penghenti perubahan, karena kepatuhan terhadap standar kualitas tidak dapat dihindari memperlambat pengiriman. Jadi, secara bertahap, bagian dari fungsi Build / Release para insinyur bermigrasi ke pundak administrator sistem.
Ops sangat berbeda
Kami terus bergerak dan sekali lagi dengan hadirnya tanggung jawab yang luas dan kurangnya personel yang berkualifikasi mendorong kami untuk melakukan spesialisasi yang keras, seperti jamur setelah hujan, berbagai Operasi muncul:
- TechOps - seperti administrator sistem alias HelpDesk Engineer
- LiveOps - administrator sistem yang terutama bertanggung jawab untuk lingkungan produktif
- CloudOps - administrator sistem yang berspesialisasi dalam "awan" publik Azure, AWS, GCP, dll.
- PlatOps / InfraOps / SysOps - administrator sistem infrastruktur.
- NetOps - Administrator Jaringan
- SecOps - administrator sistem yang berspesialisasi dalam keamanan informasi - Kepatuhan PCI, Kepatuhan CIS, penambalan, dll.
DevOps - (dalam teori) seseorang yang tahu secara langsung semua proses siklus pengembangan - pengembangan, pengujian, pemahaman arsitektur produk, mampu menilai risiko keamanan, akrab dengan pendekatan dan cara otomatisasi, setidaknya pada tingkat tinggi, dan juga memahami pra dan pasca dukungan rilis produk. Seseorang dapat mengadvokasi baik Operasi dan Pengembangan, yang memungkinkan untuk membangun kerjasama yang menguntungkan antara kedua pilar. Memahami proses perencanaan tim dan mengelola harapan pelanggan.
Untuk melakukan pekerjaan dan tanggung jawab semacam ini, orang ini harus memiliki sarana untuk mengendalikan tidak hanya pengembangan, pengujian, tetapi juga pengelolaan infrastruktur produk, serta perencanaan sumber daya. DevOps dalam hal ini tidak dapat ditempatkan baik di IT, di R&D, atau bahkan di PMO, ia harus memiliki pengaruh di semua bidang ini - direktur teknis perusahaan, Kepala Pejabat Teknis.
Apakah ini demikian di perusahaan Anda? - Aku meragukannya. Dalam kebanyakan kasus, ini bisa IT atau R&D.
Kurangnya dana dan kemungkinan mempengaruhi setidaknya satu dari tiga lini bisnis ini akan menggeser bobot masalah ke sisi di mana perubahan ini lebih mudah diterapkan, seperti menerapkan batasan teknis pada rilis terkait dengan kode kotor menurut data dari sistem analisa statis. Yaitu, ketika PMO menetapkan tenggat waktu yang ketat untuk pelepasan fungsionalitas, R&D tidak dapat memberikan hasil berkualitas tinggi dalam tenggat waktu ini dan memberikannya sebaik mungkin, meninggalkan refactoring untuk nanti, DevOps yang terkait dengan IT, dengan cara teknis memblokir rilis. Kurangnya wewenang untuk mengubah situasi, dalam kasus karyawan yang bertanggung jawab, mengarah pada manifestasi tanggung jawab yang berlebihan untuk apa yang tidak dapat mereka pengaruhi, apalagi, jika karyawan ini memahami dan melihat kesalahan, dan bagaimana cara memperbaikinya adalah "Kebahagiaan dalam ketidaktahuan", dan sebagai hasilnya kelelahan dan kehilangan karyawan ini.
Sumber Daya DevOps Pasar
Mari kita lihat beberapa lowongan pekerjaan DevOps dari berbagai perusahaan.
Kami siap bertemu dengan Anda jika Anda:
- Miliki Zabbix dan ketahui apa itu Prometheus;
- Iptables;
- Mahasiswa Pascasarjana BASH;
- Profesor Ansible;
- Guru Linux
- Ketahui cara menggunakan debug dan temukan masalah aplikasi bersama dengan pengembang (php / java / python);
- Routing tidak menyebabkan Anda mengamuk;
- Perhatikan keamanan sistem secara signifikan;
- Cadangkan "segalanya dan segalanya", dan juga berhasil memulihkan "segalanya dan segalanya" ini;
- Anda tahu cara mengkonfigurasi sistem untuk keluar dari minimum - maksimum;
- Konfigurasikan replikasi sebelum tidur pada Postgres dan MySQL;
- Menyiapkan dan menyesuaikan CI / CD untuk Anda adalah suatu keharusan seperti sarapan / makan siang / makan malam.
- Memiliki pengalaman dengan AWS;
- Siap berkembang bersama perusahaan;
Jadi:
- 1 hingga 6 - administrator sistem
- 7 - sedikit administrasi jaringan, yang juga cocok dengan administrator sistem, tingkat menengah
- 8 - sedikit keamanan, yang wajib untuk administrator sistem tingkat menengah
- 9-11 - Administrator Sistem Tengah
- 12 - Bergantung pada tugas yang ditetapkan, baik Administrator Sistem Tengah atau Build Engineer
- 13 - Virtualisasi - Administrator Sistem Tengah, atau yang disebut CloudOps, pengetahuan lanjutan tentang layanan platform hosting tertentu, untuk penggunaan dana yang efisien dan mengurangi beban pada layanan
Meringkas kekosongan ini, kita dapat mengatakan bahwa Administrator Sistem Menengah / Senior sudah cukup untuk para pria.
By the way, jangan memisahkan admin di Linux / Windows. Tentu saja, saya mengerti bahwa layanan dan sistem dari dua dunia ini berbeda, tetapi setiap orang memiliki satu dasar dan setiap admin yang menghormati dirinya akrab dengan satu atau yang lain, dan bahkan jika dia tidak terbiasa, tidak akan sulit bagi admin yang kompeten untuk berkenalan dengan hal ini.
Pertimbangkan lowongan lainnya:
- Pengalaman dalam membangun sistem yang sangat dimuat;
- Pengetahuan yang sangat baik tentang OS Linux, perangkat lunak sistem-lebar dan tumpukan web (Nginx, PHP / Python, HAProxy, MySQL / PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Pengalaman dengan sistem virtualisasi (KVM, VMWare, LXC / Docker);
- Pengetahuan bahasa scripting;
- Memahami prinsip-prinsip jaringan protokol jaringan;
- Memahami prinsip-prinsip membangun sistem toleransi kesalahan;
- Kemandirian dan inisiatif;
Parse:
- 1 - Administrator Sistem Senior
- 2 - Bergantung pada makna yang diinvestasikan dalam tumpukan ini - Administrator Sistem Menengah / Senior
- 3 - Pengalaman, termasuk, dapat berarti - "Cluster tidak naik, tetapi menciptakan dan mengelola mesin virtual, ada satu host Docker, akses ke kontainer menjadi tegang" - Administrator Sistem Tengah
- 4 - Administrator Sistem Junior - ya, admin tidak dapat menulis skrip otomatisasi dasar, apa pun bahasanya, bukan adminnya.
- 5 - Administrator Sistem Tengah
- 6 - Administrator Sistem Senior
Meringkas - Administrator Sistem Menengah / Senior
Satu lagi:
- Pengalaman devops;
- Pengalaman dalam menggunakan satu atau lebih produk untuk membentuk proses CI / CD. Gitlab CI akan menjadi keuntungan;
- Bekerja dengan wadah dan virtualisasi; Jika Anda menggunakan buruh pelabuhan - baik-baik saja, tetapi jika k8s - hebat!
- Pengalaman dalam tim yang gesit;
- Pengetahuan tentang bahasa pemrograman apa pun;
Mari kita lihat:
- 1 - Hmm ... apa yang mereka maksud? =) Kemungkinan besar mereka sendiri tidak tahu apa yang ada di baliknya
- 2 - Build Engineer
- 3 - Administrator Sistem Tengah
- 4 - Soft-skill, kami belum akan mempertimbangkannya, meskipun Agile adalah satu hal lagi yang ditafsirkan sebagai nyaman.
- 5 - Terlalu tebal - bisa berupa bahasa skrip, atau dikompilasi. Menariknya, apakah dia menulis di sekolah tentang Pascal dan Dasar? =)
Saya juga ingin memberikan komentar mengenai 3 poin untuk memperkuat pemahaman tentang mengapa poin ini dicakup oleh administrator sistem. Kubernetes hanyalah sebuah orkestrasi, alat yang membungkus perintah langsung ke driver jaringan dan host virtualisasi / isolasi dalam beberapa perintah dan memungkinkan Anda untuk membuat komunikasi dengan mereka abstrak, itu saja. Misalnya, ambil Make 'build framework', yang, omong-omong, saya tidak anggap sebagai framework. Ya, saya tahu tentang mode mendorong Make di mana saja, di mana perlu dan tidak perlu - untuk membungkus Maven di Make, misalnya, dengan serius?
Intinya, Make hanyalah pembungkus di atas shell, yang menyederhanakan kompilasi, penautan, lingkungan kompilasi, serta k8s.
Suatu kali, saya mewawancarai seorang pria yang menggunakan k8 dalam karyanya di atas OpenStack, dan dia berbicara tentang bagaimana cara menyebarkan layanan di atasnya, namun, ketika saya bertanya tentang OpenStack, ternyata itu sedang dikelola, juga dibesarkan oleh administrator sistem. Apakah Anda benar-benar berpikir bahwa orang yang mengangkat OpenStack, terlepas dari platform apa yang ia gunakan di belakangnya, tidak dapat menggunakan k8s? =)
Pemohon ini sebenarnya bukan DevOps, tetapi Administrator Sistem yang sama dan, lebih tepatnya, Administrator Kubernetes.
Kami meringkas lagi - Administrator Sistem Menengah / Senior akan cukup untuk mereka.
Berapa banyak untuk digantung dalam gram
Sebaran gaji yang ditawarkan untuk lowongan yang ditunjukkan adalah 90rb-200rb
Sekarang saya ingin menggambar secara paralel antara imbalan uang dari Administrator Sistem dan Insinyur DevOps.
Pada prinsipnya, untuk menyederhanakan, Anda dapat menyebarkan nilai pengalaman, meskipun ini tidak akan akurat, untuk keperluan artikel ini sudah cukup.
Pengalaman:
- di bawah 3 tahun - Junior
- di bawah 6 tahun - Tengah
- lebih dari 6 - Senior
Situs pencarian karyawan menawarkan:
Administrator Sistem:
- Junior - 2 tahun - 50k gosok.
- Pertengahan - 5 tahun - 70k rubel.
- Senior - 11 tahun - 100rb rubel.
Insinyur DevOps:
- Junior - 2 tahun - 100k gosok.
- Pertengahan - 3 tahun - 160k gosok.
- Senior - 6 tahun - gosok 220k.
Menurut pengalaman "DevOps", kami menggunakan pengalaman itu, setidaknya entah bagaimana mempengaruhi SDLC.
Dari penjelasan di atas dapat disimpulkan bahwa pada kenyataannya, perusahaan tidak memerlukan DevOps, dan juga bahwa mereka dapat menghemat setidaknya 50 persen dari biaya yang direncanakan semula dengan mempekerjakan Administrator, terlebih lagi, mereka dapat lebih jelas menentukan tanggung jawab orang tersebut dan dengan cepat menutup kebutuhan. Jangan lupa bahwa pembagian tanggung jawab yang jelas memungkinkan Anda mengurangi persyaratan staf, serta menciptakan suasana yang lebih menguntungkan dalam tim, karena tidak adanya persimpangan. Sebagian besar lowongan penuh dengan label utilitas dan DevOps, namun, mereka tidak benar-benar memiliki persyaratan untuk DevOps Engineer, mereka hanya permintaan untuk administrator admin.
Proses pelatihan insinyur DevOps juga hanya dibatasi oleh serangkaian pekerjaan tertentu, utilitas, tidak memberikan pemahaman umum tentang proses dan ketergantungan mereka. Ini tentu saja baik ketika seseorang dapat menggunakan AWS EKS untuk bergabung dengan AWS EKS bersama dengan mobil samping Fluentd di kluster ini dan tumpukan AWS ELK untuk sistem logging dalam 10 menit, hanya menggunakan satu perintah di konsol, tetapi jika dia tidak mengerti prinsip pemrosesan, log dan mengapa diperlukan, bukan untuk mengetahui cara mengumpulkan metrik pada mereka dan melacak degradasi layanan, maka itu akan menjadi sama saja yang dapat menggunakan beberapa utilitas.
Permintaan, bagaimanapun, menciptakan pasokan, dan kami melihat pasar yang sangat panas untuk posisi DevOps, di mana persyaratan tidak sesuai dengan peran nyata, tetapi hanya memungkinkan administrator sistem untuk mendapatkan lebih banyak.
Jadi siapa mereka? Administrator sistem yang serakah atau serakah? =)
Bagaimana cara hidup lebih jauh?
Untuk majikan - lebih akurat untuk merumuskan persyaratan dan mencari mereka yang benar-benar dibutuhkan, dan tidak mencerai-beraikan label. Anda tidak tahu apa yang dilakukan DevOps - Anda tidak membutuhkannya dalam hal ini.
Pekerja - Belajar. Tingkatkan pengetahuan Anda secara terus-menerus, lihat keseluruhan gambaran proses dan lacak jalan menuju tujuan. Anda dapat menjadi apa pun yang Anda inginkan, Anda hanya perlu mencoba.