Saat ini, ini mungkin merupakan posisi termahal di pasar. Keributan seputar para insinyur “DevOps” berada di luar batas yang dapat dibayangkan, dan bahkan lebih buruk lagi dengan para insinyur Senior DevOps.
Saya bekerja sebagai kepala departemen integrasi dan otomasi, tebak decoding bahasa Inggris - Manajer DevOps. Transkrip bahasa Inggris sepertinya tidak mencerminkan aktivitas kita sehari-hari, tetapi versi Rusia dalam hal ini lebih akurat. Karena sifat aktivitas saya, wajar jika saya perlu mewawancarai anggota tim saya di masa depan, dan selama setahun terakhir, sekitar 50 orang telah melewati saya, dan jumlah yang sama telah dipotong pada tahap awal dengan karyawan saya.
Kami masih mencari rekan, karena di balik label DevOps ada banyak sekali lapisan insinyur berbeda yang bersembunyi.
Semua yang tertulis di bawah ini adalah pendapat pribadi saya, Anda tidak harus setuju, tapi saya akui itu akan menambah warna pada sikap Anda terhadap topik tersebut. Meskipun ada risiko tidak disukai, saya mempublikasikan pendapat saya karena saya yakin pendapat tersebut ada tempatnya.
Perusahaan memiliki pemahaman berbeda tentang siapa insinyur DevOps dan, demi merekrut sumber daya dengan cepat, mereka menggantungkan label ini pada semua orang. Situasinya cukup aneh, karena perusahaan siap membayar remunerasi yang tidak realistis kepada orang-orang ini, dengan menerima, dalam banyak kasus, administrator alat untuk mereka.
Jadi siapa insinyur DevOps?
Mari kita mulai dengan sejarah kemunculannya - Operasi Pengembangan muncul sebagai langkah lain menuju optimalisasi interaksi dalam tim kecil guna 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 mengetahui cara kerja produknya dalam kondisi tertentu, harus memahami cara menyebarkan produknya, karakteristik lingkungan apa yang dapat disesuaikan untuk meningkatkan kinerja. Jadi, untuk beberapa waktu, pengembang dengan pendekatan DevOps muncul. Pengembang DevOps menulis skrip pembuatan dan pengemasan untuk menyederhanakan aktivitas mereka dan kinerja lingkungan produksi. Namun, kompleksitas arsitektur solusi dan pengaruh timbal balik komponen infrastruktur dari waktu ke waktu mulai memperburuk kinerja lingkungan; dengan setiap iterasi, diperlukan pemahaman yang semakin mendalam tentang komponen tertentu, sehingga mengurangi produktivitas pengembang karena tambahan biaya pemahaman komponen dan sistem penyetelan untuk tugas tertentu. . Biaya pengembang sendiri meningkat, biaya produk bersamaan dengan itu, persyaratan untuk pengembang baru dalam tim melonjak tajam, karena mereka juga perlu menanggung tanggung jawab "bintang" pengembangan dan, tentu saja, "bintang" menjadi lebih sedikit. dan lebih sedikit tersedia. Perlu juga dicatat bahwa, menurut pengalaman saya, hanya sedikit pengembang yang tertarik dengan spesifikasi pemrosesan paket oleh kernel sistem operasi, aturan perutean paket, dan aspek keamanan host. Langkah logisnya adalah dengan menarik seorang administrator yang memahami hal ini dan memberikan tanggung jawab serupa kepadanya, yang berkat pengalamannya, memungkinkan tercapainya indikator yang sama dengan biaya lebih rendah dibandingkan dengan biaya pengembangan “bintang”. Administrator tersebut ditempatkan dalam sebuah tim dan tugas utamanya adalah mengelola lingkungan pengujian dan produksi, sesuai dengan aturan tim tertentu, dengan sumber daya yang dialokasikan untuk tim khusus ini. Faktanya, beginilah DevOps muncul di benak sebagian besar orang.
Sebagian atau seluruhnya, seiring berjalannya waktu, para administrator sistem ini mulai memahami kebutuhan tim khusus ini di bidang pengembangan, bagaimana membuat hidup lebih mudah bagi pengembang dan penguji, bagaimana meluncurkan pembaruan dan tidak perlu bermalam pada hari Jumat di kantor, memperbaiki kesalahan penerapan. Waktu berlalu, dan sekarang “bintang”nya adalah administrator sistem yang memahami apa yang diinginkan pengembang. Untuk meminimalkan dampaknya, utilitas manajemen mulai bermunculan; semua orang mengingat metode lama dan andal dalam mengisolasi tingkat OS, yang memungkinkan meminimalkan persyaratan keamanan, pengelolaan bagian jaringan, dan konfigurasi host sebagai secara keseluruhan dan, sebagai hasilnya, mengurangi persyaratan untuk “bintang” baru.
Suatu hal yang "luar biasa" telah muncul - buruh pelabuhan. Mengapa luar biasa? Ya, hanya karena membuat isolasi di chroot atau jail, serta OpenVZ, memerlukan pengetahuan OS yang tidak sepele, sebaliknya, utilitas ini memungkinkan Anda untuk dengan mudah membuat lingkungan aplikasi yang terisolasi pada host tertentu dengan semua yang diperlukan di dalam dan di tangan. mengambil alih kendali pengembangan lagi, dan administrator sistem hanya dapat mengelola hanya dengan satu host, memastikan keamanan dan ketersediaan tinggi - sebuah penyederhanaan logis. Namun kemajuan tidak berhenti dan sistem kembali menjadi semakin kompleks, komponen menjadi semakin banyak, satu host tidak lagi memenuhi kebutuhan sistem dan perlu untuk membangun cluster, kami kembali lagi ke administrator sistem yang mampu membangun sistem ini.
Siklus demi siklus, muncul berbagai sistem yang menyederhanakan pengembangan dan/atau administrasi, muncul sistem orkestrasi, yang, hingga Anda perlu menyimpang dari proses standar, mudah digunakan. Arsitektur layanan mikro juga muncul dengan tujuan menyederhanakan semua yang dijelaskan di atas - lebih sedikit hubungan, lebih mudah dikelola. Dalam pengalaman saya, saya tidak menemukan arsitektur layanan mikro sepenuhnya, menurut saya 50 hingga 50 - 50 persen layanan mikro, kotak hitam, masuk, keluar diproses, 50 lainnya adalah monolit yang robek, layanan tidak dapat bekerja secara terpisah dari yang lain komponen. Semua ini sekali lagi memberlakukan batasan pada tingkat pengetahuan pengembang dan administrator.
“Perubahan” serupa dalam tingkat pengetahuan ahli tentang sumber daya tertentu berlanjut hingga hari ini. Tapi kami ngelantur sedikit, ada banyak poin yang perlu disoroti.
Insinyur Bangun/Insinyur Pelepasan
Insinyur yang sangat terspesialisasi yang muncul sebagai sarana standarisasi proses dan rilis pembuatan perangkat lunak. Dalam proses memperkenalkan Agile secara luas, tampaknya permintaan mereka tidak lagi sama, tetapi kenyataannya tidak demikian. Spesialisasi ini muncul sebagai sarana standarisasi perakitan dan pengiriman perangkat lunak pada skala industri, yaitu. menggunakan teknik standar untuk semua produk perusahaan. Dengan munculnya DevOps, sebagian pengembang kehilangan fungsinya, karena pengembanglah yang mulai mempersiapkan produk untuk pengiriman, dan mengingat perubahan infrastruktur dan pendekatan untuk pengiriman secepat mungkin tanpa memperhatikan kualitas, seiring waktu mereka berubah menjadi penghambat perubahan, karena kepatuhan terhadap standar kualitas pasti akan memperlambat pengiriman. Jadi, secara bertahap, sebagian fungsi insinyur Build/Release berpindah ke pundak administrator sistem.
Ops sangat berbeda
Kami terus bergerak, kehadiran berbagai macam tanggung jawab dan kurangnya personel yang berkualifikasi mendorong kami menuju spesialisasi yang ketat, seperti jamur setelah hujan, berbagai Operasi muncul:
- TechOps - administrator sistem enikey alias HelpDesk Engineer
- LiveOps - administrator sistem yang terutama bertanggung jawab atas lingkungan produksi
- CloudOps - administrator sistem yang berspesialisasi dalam cloud 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, patching, dll.
DevOps (secara teori) adalah orang yang memahami secara langsung semua proses siklus pengembangan - pengembangan, pengujian, memahami arsitektur produk, mampu menilai risiko keamanan, akrab dengan pendekatan dan alat otomatisasi, setidaknya pada tingkat tinggi tingkat, selain itu, juga memahami dukungan rilis produk sebelum dan sesudah pemrosesan. Seseorang yang mampu bertindak sebagai pendukung Operasional dan Pembangunan, yang memungkinkan terjalinnya kerja sama yang menguntungkan antara kedua pilar ini. Memahami proses perencanaan kerja oleh tim dan mengelola harapan pelanggan.
Untuk melakukan pekerjaan dan tanggung jawab semacam ini, orang ini harus memiliki sarana untuk mengelola tidak hanya proses pengembangan dan pengujian, namun juga pengelolaan infrastruktur produk, serta perencanaan sumber daya. DevOps dalam pemahaman ini tidak dapat ditempatkan di TI, atau di R&D, atau bahkan di PMO; ia harus memiliki pengaruh di semua bidang ini - direktur teknis perusahaan, Chief Technical Officer.
Apakah hal ini benar terjadi di perusahaan Anda? - Saya ragu. Dalam kebanyakan kasus, ini adalah IT atau R&D.
Kurangnya dana dan kemampuan untuk mempengaruhi setidaknya satu dari tiga bidang kegiatan ini akan mengalihkan beban masalah ke arah yang lebih mudah untuk menerapkan perubahan ini, seperti penerapan pembatasan teknis pada rilis sehubungan dengan kode “kotor” menurut statis sistem penganalisis. Artinya, ketika PMO menetapkan tenggat waktu yang ketat untuk rilis fungsionalitas, R&D tidak dapat memberikan hasil berkualitas tinggi dalam tenggat waktu tersebut dan memproduksinya sebaik mungkin, meninggalkan pemfaktoran ulang untuk nanti, DevOps yang terkait dengan TI memblokir rilis dengan cara teknis . Kurangnya wewenang untuk mengubah situasi, dalam kasus karyawan yang bertanggung jawab, mengarah pada manifestasi tanggung jawab yang berlebihan atas apa yang tidak dapat mereka pengaruhi, terutama jika karyawan tersebut memahami dan melihat kesalahan, dan bagaimana memperbaikinya - “Kebahagiaan adalah ketidaktahuan”, dan sebagai konsekuensi dari kelelahan dan kehilangan karyawan tersebut.
Pasar sumber daya DevOps
Mari kita lihat beberapa lowongan posisi DevOps dari berbagai perusahaan.
Kami siap bertemu dengan Anda jika Anda:
- Anda memiliki Zabbix dan mengetahui apa itu Prometheus;
- tabel ip;
- Mahasiswa PhD BASH;
- Profesor Ansible;
- Guru Linux;
- Mengetahui cara menggunakan debugging dan menemukan masalah aplikasi bersama dengan pengembang (php/java/python);
- Perutean tidak membuat Anda histeris;
- Memberikan perhatian yang signifikan terhadap keamanan sistem;
- Cadangkan "apa saja dan segalanya", dan juga berhasil memulihkan "apa saja" ini;
- Anda tahu cara mengkonfigurasi sistem sedemikian rupa untuk mendapatkan hasil maksimal dari minimum;
- Siapkan replikasi sebelum tidur di Postgres dan MySQL;
- Menyiapkan dan menyesuaikan CI/CD sama pentingnya bagi Anda seperti sarapan/makan siang/makan malam.
- Memiliki pengalaman dengan AWS;
- Siap berkembang bersama perusahaan;
Jadi:
- dari 1 hingga 6 - administrator sistem
- 7 - sedikit administrasi jaringan, yang juga cocok untuk administrator sistem, tingkat menengah
- 8 - sedikit keamanan, yang wajib bagi administrator sistem tingkat menengah
- 9-11 – Administrator Sistem Tengah
- 12 — Tergantung pada tugas yang diberikan, baik Administrator Sistem Tengah atau Insinyur Pembangun
- 13 - Virtualisasi - Administrator Sistem Tengah, atau yang disebut CloudOps, pengetahuan tingkat lanjut tentang layanan situs hosting tertentu, untuk penggunaan dana yang efisien dan mengurangi beban pemeliharaan
Merangkum lowongan ini, kita dapat mengatakan bahwa Administrator Sistem Menengah/Senior sudah cukup untuk mereka.
Omong-omong, Anda tidak boleh terlalu membagi administrator di Linux/Windows. Tentu saja, saya memahami bahwa layanan dan sistem dari kedua dunia ini berbeda, tetapi dasar dari semuanya adalah sama dan setiap admin yang menghargai diri sendiri akrab dengan yang satu dan yang lain, dan bahkan jika dia tidak terbiasa, itu akan terjadi. tidak sulit bagi admin yang kompeten untuk mengenalnya.
Mari pertimbangkan lowongan lain:
- Pengalaman dalam membangun sistem beban tinggi;
- Pengetahuan yang sangat baik tentang OS Linux, perangkat lunak sistem umum dan web stack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Pengalaman dengan sistem virtualisasi (KVM, VMWare, LXC/Docker);
- Kemahiran dalam bahasa scripting;
- Pemahaman tentang prinsip pengoperasian jaringan protokol jaringan;
- Pemahaman tentang prinsip-prinsip membangun sistem yang toleran terhadap kesalahan;
- Kemandirian dan inisiatif;
Mari lihat:
- 1 – Administrator Sistem Senior
- 2 - Tergantung pada arti yang dimasukkan ke dalam tumpukan ini - Administrator Sistem Menengah/Senior
- 3 - Pengalaman kerja, termasuk, dapat berarti - “Cluster tidak membesarkan, tetapi membuat dan mengelola mesin virtual, hanya ada satu host Docker, akses ke container tidak tersedia” - Administrator Sistem Tengah
- 4 - Administrator Sistem Junior - ya, admin yang tidak tahu cara menulis skrip otomatisasi dasar, apa pun bahasanya, bukan admin - enikey.
- 5 - Administrator Sistem Tengah
- 6 – Administrator Sistem Senior
Untuk meringkas - Administrator Sistem Menengah/Senior
Satu lagi:
- Mengembangkan pengalaman;
- Pengalaman menggunakan satu atau lebih produk untuk membuat proses CI/CD. Gitlab CI akan menjadi keuntungan;
- Bekerja dengan container dan virtualisasi; Jika Anda menggunakan buruh pelabuhan, bagus, tetapi jika Anda menggunakan k8s, bagus!
- Pengalaman bekerja dalam tim yang gesit;
- Pengetahuan tentang bahasa pemrograman apa pun;
Ayo lihat:
- 1 - Hmm... Apa maksud mereka? =) Kemungkinan besar mereka sendiri tidak mengetahui apa yang tersembunyi di baliknya
- 2 - Insinyur Bangunan
- 3 - Administrator Sistem Tengah
- 4 - Soft skill, kami tidak akan mempertimbangkannya untuk saat ini, meskipun Agile adalah hal lain yang ditafsirkan dengan cara yang nyaman.
- 5 - Terlalu bertele-tele - bisa jadi bahasa skrip atau bahasa kompilasi. Saya ingin tahu apakah menulis dalam Pascal dan Basic di sekolah cocok untuk mereka? =)
Saya juga ingin meninggalkan catatan mengenai poin 3 untuk memperkuat pemahaman mengapa poin ini dicakup oleh administrator sistem. Kubernetes hanyalah sebuah orkestrasi, alat yang menggabungkan perintah langsung ke driver jaringan dan host virtualisasi/isolasi dalam beberapa perintah dan memungkinkan Anda membuat komunikasi dengan mereka menjadi abstrak, itu saja. Sebagai contoh, mari kita ambil 'build framework' Make, yang, omong-omong, saya tidak menganggap kerangka kerja. Ya, saya tahu tentang cara mendorong Make ke mana pun, jika perlu dan tidak diperlukan - membungkus Maven dengan Make, misalnya, serius?
Pada dasarnya, Make hanyalah pembungkus shell, menyederhanakan perintah lingkungan kompilasi, penautan, dan kompilasi, seperti halnya k8s.
Suatu kali, saya mewawancarai seorang pria yang menggunakan k8s dalam pekerjaannya di atas OpenStack, dan dia berbicara tentang bagaimana dia menerapkan layanan di dalamnya, namun, ketika saya bertanya tentang OpenStack, ternyata itu dikelola, serta dibesarkan oleh sistem administrator. Apakah Anda benar-benar berpikir bahwa seseorang yang telah menginstal OpenStack, apa pun platform yang ia gunakan, tidak dapat menggunakan k8s? =)
Pemohon ini sebenarnya bukan seorang DevOps, melainkan seorang Administrator Sistem dan, lebih tepatnya, seorang Administrator Kubernetes.
Mari kita rangkum sekali lagi - Administrator Sistem Menengah/Senior sudah cukup untuk mereka.
Berapa beratnya dalam gram?
Kisaran gaji yang diusulkan untuk lowongan yang ditunjukkan adalah 90k-200k
Sekarang saya ingin menarik persamaan antara imbalan uang dari Administrator Sistem dan Insinyur DevOps.
Pada prinsipnya, untuk mempermudah, Anda dapat menyebarkan nilai berdasarkan pengalaman kerja, meskipun ini tidak tepat, tetapi untuk keperluan artikel itu sudah cukup.
Sebuah pengalaman:
- hingga 3 tahun – Junior
- hingga 6 tahun – Tengah
- lebih dari 6 – Senior
Situs pencarian karyawan menawarkan:
Administrator Sistem:
- Junior - 2 tahun - 50k gosok.
- Tengah - 5 tahun - 70k gosok.
- Senior - 11 tahun - 100k gosok.
Insinyur DevOps:
- Junior - 2 tahun - 100k gosok.
- Tengah - 3 tahun - 160k gosok.
- Senior - 6 tahun - 220k gosok.
Menurut pengalaman "DevOps", pengalaman digunakan yang setidaknya mempengaruhi SDLC.
Dari penjelasan di atas dapat disimpulkan bahwa sebenarnya perusahaan tidak memerlukan DevOps, dan mereka juga dapat menghemat setidaknya 50 persen dari biaya yang direncanakan semula dengan menyewa seorang Administrator; terlebih lagi, mereka dapat lebih jelas mendefinisikan tanggung jawab orang yang mereka cari. dan memenuhi kebutuhan lebih cepat. Kita juga tidak boleh lupa bahwa pembagian tanggung jawab yang jelas memungkinkan kita mengurangi kebutuhan personel, serta menciptakan suasana yang lebih menguntungkan dalam tim, karena tidak adanya tumpang tindih. Sebagian besar lowongan penuh dengan utilitas dan label DevOps, namun tidak didasarkan pada persyaratan aktual untuk Insinyur DevOps, hanya permintaan untuk administrator alat.
Proses pelatihan para insinyur DevOps juga terbatas hanya pada serangkaian pekerjaan tertentu, utilitas, dan tidak memberikan pemahaman umum tentang proses dan ketergantungannya. Tentu saja bagus ketika seseorang dapat menerapkan AWS EKS menggunakan Terraform, bersama dengan sidecar Fluentd di cluster ini dan tumpukan AWS ELK untuk sistem logging dalam 10 menit, hanya menggunakan satu perintah di konsol, tetapi jika dia tidak memahaminya prinsip memproses log itu sendiri dan untuk apa log tersebut diperlukan, jika Anda tidak tahu cara mengumpulkan metrik pada log tersebut dan melacak degradasi layanan, maka tetap saja enikey yang sama yang tahu cara menggunakan beberapa utilitas.
Permintaan, bagaimanapun, menciptakan pasokan, dan kami melihat pasar yang sangat panas untuk posisi DevOps, di mana persyaratannya tidak sesuai dengan peran sebenarnya, tetapi hanya memungkinkan administrator sistem untuk mendapatkan penghasilan lebih banyak.
Jadi siapa mereka? DevOps atau administrator sistem yang serakah? =)
Bagaimana cara melanjutkan hidup?
Pengusaha harus merumuskan persyaratan dengan lebih tepat dan mencari persyaratan yang dibutuhkan, dan tidak membuang-buang label. Anda tidak tahu apa yang dilakukan DevOps - Anda tidak memerlukannya dalam hal ini.
Pekerja - Belajar. Tingkatkan pengetahuan Anda secara terus-menerus, lihat gambaran keseluruhan proses dan lacak jalan menuju tujuan Anda. Anda bisa menjadi siapa pun yang Anda inginkan, Anda hanya perlu mencobanya.
Sumber: www.habr.com