Pada masa ini, ini adalah hampir kedudukan paling mahal di pasaran. Kekecohan mengenai jurutera "DevOps" adalah di luar semua had yang boleh dibayangkan, dan lebih teruk lagi dengan jurutera Kanan DevOps.
Saya bekerja sebagai ketua bahagian integrasi dan automasi, teka penyahkod bahasa Inggeris - Pengurus DevOps. Tidak mungkin transkrip bahasa Inggeris menggambarkan aktiviti harian kami, tetapi versi Rusia dalam kes ini adalah lebih tepat. Disebabkan oleh sifat aktiviti saya, adalah wajar saya perlu menemu bual ahli pasukan saya yang akan datang, dan sepanjang tahun lalu, kira-kira 50 orang telah melalui saya, dan bilangan yang sama telah dipotong pada praskrin dengan pekerja saya.
Kami masih mencari rakan sekerja, kerana di sebalik label DevOps terdapat lapisan yang sangat besar dari pelbagai jenis jurutera yang bersembunyi.
Semua yang ditulis di bawah adalah pendapat peribadi saya, anda tidak perlu bersetuju dengannya, tetapi saya mengakui bahawa ia akan menambah sedikit warna kepada sikap anda terhadap topik tersebut. Walaupun berisiko untuk tidak disenangi, saya menerbitkan pendapat saya kerana saya percaya ia ada tempatnya.
Syarikat mempunyai pemahaman yang berbeza tentang siapa jurutera DevOps dan, demi untuk mengupah sumber dengan cepat, mereka menggantung label ini pada semua orang. Keadaan ini agak pelik, kerana syarikat bersedia untuk membayar imbuhan yang tidak realistik kepada orang-orang ini, menerima, dalam kebanyakan kes, pentadbir alat untuk mereka.
Jadi siapakah jurutera DevOps?
Mari kita mulakan dengan sejarah penampilannya - Operasi Pembangunan muncul sebagai satu lagi langkah ke arah mengoptimumkan interaksi dalam pasukan kecil untuk meningkatkan kelajuan pengeluaran produk, sebagai akibat yang dijangkakan. Ideanya adalah untuk mengukuhkan pasukan pembangunan dengan pengetahuan tentang prosedur dan pendekatan dalam menguruskan persekitaran produk. Dalam erti kata lain, pembangun mesti memahami dan mengetahui bagaimana produknya berfungsi dalam keadaan tertentu, mesti memahami cara menggunakan produknya, apakah ciri-ciri persekitaran yang boleh diselaraskan untuk meningkatkan prestasi. Jadi, untuk beberapa lama, pembangun dengan pendekatan DevOps muncul. Pembangun DevOps menulis skrip binaan dan pembungkusan untuk memudahkan aktiviti mereka dan prestasi persekitaran pengeluaran. Walau bagaimanapun, kerumitan seni bina penyelesaian dan pengaruh bersama komponen infrastruktur dari masa ke masa mula merosot prestasi persekitaran; dengan setiap lelaran, pemahaman yang lebih mendalam tentang komponen tertentu diperlukan, mengurangkan produktiviti pemaju disebabkan oleh tambahan kos memahami komponen dan sistem penalaan untuk tugas tertentu. . Kos pemaju sendiri meningkat, kos produk bersama-sama dengannya, keperluan untuk pembangun baharu dalam pasukan melonjak mendadak, kerana mereka juga perlu menampung tanggungjawab "bintang" pembangunan dan, secara semula jadi, "bintang" menjadi kurang dan kurang tersedia. Perlu juga diperhatikan bahawa, dalam pengalaman saya, beberapa pembangun berminat dengan spesifik pemprosesan paket oleh kernel sistem pengendalian, peraturan penghalaan paket, dan aspek keselamatan hos. Langkah logiknya adalah untuk menarik pentadbir yang biasa dengan ini dan memberikan tanggungjawab yang sama kepadanya, yang, berkat pengalamannya, memungkinkan untuk mencapai penunjuk yang sama pada kos yang lebih rendah berbanding dengan kos pembangunan "bintang". Pentadbir sedemikian diletakkan dalam satu pasukan dan tugas utamanya ialah mengurus persekitaran ujian dan pengeluaran, mengikut peraturan pasukan tertentu, dengan sumber diperuntukkan kepada pasukan tertentu ini. Beginilah, sebenarnya, DevOps muncul dalam fikiran majoriti.
Sebahagian atau sepenuhnya, dari masa ke masa, pentadbir sistem ini mula memahami keperluan pasukan khusus ini dalam bidang pembangunan, cara menjadikan kehidupan lebih mudah untuk pembangun dan penguji, cara melancarkan kemas kini dan tidak perlu bermalam pada hari Jumaat di pejabat, membetulkan ralat penempatan. Masa berlalu, dan kini "bintang" adalah pentadbir sistem yang memahami perkara yang dikehendaki oleh pembangun. Untuk meminimumkan kesan, utiliti pengurusan mula muncul; semua orang mengingati kaedah lama dan boleh dipercayai untuk mengasingkan tahap OS, yang memungkinkan untuk meminimumkan keperluan untuk keselamatan, pengurusan bahagian rangkaian, dan konfigurasi hos sebagai keseluruhan dan, sebagai hasilnya, mengurangkan keperluan untuk "bintang" baharu.
Satu perkara yang "indah" telah muncul - buruh pelabuhan. Mengapa indah? Ya, hanya kerana mencipta pengasingan dalam chroot atau penjara, serta OpenVZ, memerlukan pengetahuan OS yang tidak remeh, sebaliknya, utiliti membolehkan anda membuat persekitaran aplikasi terpencil pada hos tertentu dengan semua yang diperlukan di dalam dan tangan atas tampuk pembangunan sekali lagi, dan pentadbir sistem hanya boleh mengurus dengan hanya satu hos, memastikan keselamatan dan ketersediaan yang tinggi - pemudahan logik. Tetapi kemajuan tidak berhenti dan sistem sekali lagi menjadi lebih dan lebih kompleks, semakin banyak komponen, satu hos tidak lagi memenuhi keperluan sistem dan perlu untuk membina kluster, kami kembali semula kepada pentadbir sistem yang mampu membina sistem ini.
Kitaran demi kitaran, pelbagai sistem muncul yang memudahkan pembangunan dan/atau pentadbiran, sistem orkestrasi muncul, yang, sehingga anda perlu menyimpang daripada proses standard, mudah digunakan. Seni bina perkhidmatan mikro juga muncul dengan tujuan untuk memudahkan segala-galanya yang diterangkan di atas - lebih sedikit perhubungan, lebih mudah untuk diurus. Dalam pengalaman saya, saya tidak menemui seni bina perkhidmatan mikro sepenuhnya, saya akan mengatakan 50 hingga 50 - 50 peratus perkhidmatan mikro, kotak hitam, masuk, keluar diproses, 50 yang lain adalah monolit yang koyak, perkhidmatan tidak dapat berfungsi secara berasingan daripada yang lain komponen. Semua ini sekali lagi mengenakan sekatan pada tahap pengetahuan kedua-dua pemaju dan pentadbir.
"Perubahan" yang serupa dalam tahap pengetahuan pakar sumber tertentu berterusan sehingga hari ini. Tetapi kita menyimpang sedikit, terdapat banyak perkara yang patut diketengahkan.
Jurutera Bina/Jurutera Pelepas
Jurutera yang sangat khusus yang muncul sebagai cara menyeragamkan proses binaan perisian dan keluaran. Dalam proses memperkenalkan Agile yang meluas, nampaknya mereka tidak lagi mendapat permintaan, tetapi ini jauh dari kes itu. Pengkhususan ini muncul sebagai cara menyeragamkan pemasangan dan penyampaian perisian pada skala industri, i.e. menggunakan teknik standard untuk semua produk syarikat. Dengan kemunculan DevOps, pembangun kehilangan sebahagian fungsi mereka, kerana pembangunlah yang mula menyediakan produk untuk penghantaran, dan memandangkan perubahan infrastruktur dan pendekatan untuk menyampaikan secepat mungkin tanpa mengambil kira kualiti, dari masa ke masa mereka berubah menjadi penyumbat perubahan, kerana pematuhan kepada piawaian kualiti pasti memperlahankan penghantaran. Jadi, secara beransur-ansur, sebahagian daripada kefungsian jurutera Bina/Lepaskan berhijrah ke bahu pentadbir sistem.
Ops sangat berbeza
Kami meneruskan dan sekali lagi kehadiran pelbagai tanggungjawab dan kekurangan kakitangan yang berkelayakan mendorong kami ke arah pengkhususan yang ketat, seperti cendawan selepas hujan, pelbagai Operasi muncul:
- TechOps - pentadbir sistem enikey aka HelpDesk Engineer
- LiveOps - pentadbir sistem bertanggungjawab terutamanya untuk persekitaran pengeluaran
- CloudOps - pentadbir sistem yang pakar dalam awan awam Azure, AWS, GCP, dsb.
- PlatOps/InfraOps/SysOps - pentadbir sistem infrastruktur.
- NetOps - pentadbir rangkaian
- SecOps - pentadbir sistem pakar dalam keselamatan maklumat - pematuhan PCI, pematuhan CIS, tampalan, dsb.
DevOps ialah (dalam teori) orang yang memahami secara langsung semua proses kitaran pembangunan - pembangunan, pengujian, memahami seni bina produk, dapat menilai risiko keselamatan, biasa dengan pendekatan dan alat automasi, sekurang-kurangnya pada tahap yang tinggi. Tahap, sebagai tambahan kepada ini, juga memahami sokongan keluaran produk sebelum dan selepas pemprosesan. Seseorang yang mampu bertindak sebagai peguam bela untuk kedua-dua Operasi dan Pembangunan, yang membolehkan kerjasama yang baik antara kedua-dua tonggak ini. Memahami proses kerja perancangan oleh pasukan dan mengurus jangkaan pelanggan.
Untuk melaksanakan kerja dan tanggungjawab seperti ini, orang ini mesti mempunyai cara untuk mengurus bukan sahaja proses pembangunan dan ujian, tetapi juga pengurusan infrastruktur produk, serta perancangan sumber. DevOps dalam pemahaman ini tidak boleh ditempatkan sama ada dalam IT, atau dalam R&D, atau bahkan dalam PMO; ia mesti mempunyai pengaruh dalam semua bidang ini - pengarah teknikal syarikat, Ketua Pegawai Teknikal.
Adakah ini benar di syarikat anda? - Saya ragu. Dalam kebanyakan kes, ini sama ada IT atau R&D.
Kekurangan dana dan keupayaan untuk mempengaruhi sekurang-kurangnya satu daripada tiga bidang aktiviti ini akan mengalihkan berat masalah ke arah mana perubahan ini lebih mudah digunakan, seperti penggunaan sekatan teknikal pada keluaran berkaitan dengan kod "kotor" mengikut statik sistem penganalisis. Iaitu, apabila PMO menetapkan tarikh akhir yang ketat untuk mengeluarkan fungsi, R&D tidak dapat menghasilkan hasil yang berkualiti tinggi dalam tarikh akhir ini dan menghasilkannya sebaik mungkin, meninggalkan pemfaktoran semula untuk kemudian, DevOps yang berkaitan dengan IT menyekat keluaran melalui cara teknikal . Kekurangan kuasa untuk mengubah keadaan, dalam kes pekerja yang bertanggungjawab, membawa kepada manifestasi tanggungjawab berlebihan untuk apa yang tidak dapat mereka pengaruhi, terutamanya jika pekerja ini memahami dan melihat kesilapan, dan bagaimana untuk membetulkannya - "Bliss is ignorance", dan akibat daripada keletihan dan kehilangan pekerja ini.
Pasaran sumber DevOps
Mari lihat beberapa kekosongan jawatan DevOps daripada syarikat yang berbeza.
Kami bersedia untuk bertemu dengan anda jika anda:
- Anda memiliki Zabbix dan tahu apa itu Prometheus;
- Iptables;
- Pelajar PhD BASH;
- Profesor Ansible;
- Guru Linux;
- Mengetahui cara menggunakan penyahpepijatan dan mencari masalah aplikasi bersama-sama dengan pembangun (php/java/python);
- Penghalaan tidak membuat anda histeria;
- Beri perhatian penting kepada keselamatan sistem;
- Sandarkan "apa-apa sahaja dan segala-galanya", dan juga berjaya memulihkan "apa-apa sahaja dan segala-galanya" ini;
- Anda tahu bagaimana untuk mengkonfigurasi sistem sedemikian rupa untuk mendapatkan maksimum daripada minimum;
- Sediakan replikasi sebelum tidur pada Postgres dan MySQL;
- Menyediakan dan melaraskan CI/CD adalah seperti yang diperlukan untuk anda seperti sarapan/makan tengahari/makan malam.
- Mempunyai pengalaman dengan AWS;
- Bersedia untuk membangun bersama syarikat;
Jadi:
- dari 1 hingga 6 - pentadbir sistem
- 7 - sedikit pentadbiran rangkaian, yang juga sesuai dengan pentadbir sistem, peringkat pertengahan
- 8 - sedikit keselamatan, yang wajib untuk pentadbir sistem peringkat pertengahan
- 9-11 β Pentadbir Sistem Pertengahan
- 12 β Bergantung pada tugasan yang diberikan, sama ada Pentadbir Sistem Pertengahan atau Jurutera Binaan
- 13 - Maya - Pentadbir Sistem Tengah, atau apa yang dipanggil CloudOps, pengetahuan lanjutan tentang perkhidmatan tapak pengehosan tertentu, untuk penggunaan dana yang cekap dan mengurangkan beban penyelenggaraan
Merumuskan kekosongan ini, kita boleh mengatakan bahawa Pentadbir Sistem Tengah/Senior sudah cukup untuk lelaki.
Dengan cara ini, anda tidak sepatutnya membahagikan pentadbir dengan kuat pada Linux/Windows. Sudah tentu, saya faham bahawa perkhidmatan dan sistem kedua-dua dunia ini berbeza, tetapi asas untuk semua adalah sama dan mana-mana pentadbir yang menghormati diri sendiri biasa dengan kedua-dua satu dan yang lain, dan walaupun dia tidak biasa, ia akan tidak sukar bagi pentadbir yang cekap untuk membiasakannya.
Mari kita pertimbangkan satu lagi kekosongan:
- Pengalaman dalam membina sistem beban tinggi;
- Pengetahuan cemerlang tentang OS Linux, perisian sistem umum dan timbunan web (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Pengalaman dengan sistem virtualisasi (KVM, VMWare, LXC/Docker);
- Kemahiran dalam bahasa skrip;
- Pemahaman tentang prinsip operasi rangkaian protokol rangkaian;
- Memahami prinsip membina sistem toleransi kesalahan;
- Kemerdekaan dan inisiatif;
Mari lihat:
- 1 β Pentadbir Sistem Kanan
- 2 - Bergantung pada maksud yang dimasukkan ke dalam timbunan ini - Pentadbir Sistem Tengah/Kanan
- 3 - Pengalaman kerja, termasuk, mungkin bermaksud - "Kluster tidak timbul, tetapi mencipta dan mengurus mesin maya, terdapat satu hos Docker, akses kepada bekas tidak tersedia" - Pentadbir Sistem Tengah
- 4 - Pentadbir Sistem Junior - ya, pentadbir yang tidak tahu menulis skrip automasi asas, tanpa mengira bahasa, bukan pentadbir - enikey.
- 5 - Pentadbir Sistem Tengah
- 6 β Pentadbir Sistem Kanan
Untuk meringkaskan - Pentadbir Sistem Tengah/Kanan
Yang lagi satu:
- Devops pengalaman;
- Pengalaman menggunakan satu atau lebih produk untuk mencipta proses CI/CD. Gitlab CI akan menjadi kelebihan;
- Bekerja dengan bekas dan virtualisasi; Jika anda menggunakan docker, bagus, tetapi jika anda menggunakan k8s, hebat!
- Pengalaman bekerja dalam pasukan yang tangkas;
- Pengetahuan tentang mana-mana bahasa pengaturcaraan;
Mari lihat:
- 1 - Hmm... Apa maksud lelaki itu? =) Kemungkinan besar mereka sendiri tidak tahu apa yang tersembunyi di sebaliknya
- 2 - Jurutera Binaan
- 3 - Pentadbir Sistem Tengah
- 4 - Kemahiran lembut, kami tidak akan menganggapnya buat masa ini, walaupun Agile adalah satu lagi perkara yang ditafsirkan dengan cara yang mudah.
- 5 - Terlalu bertele-tele - ia boleh menjadi bahasa skrip atau bahasa yang disusun. Saya tertanya-tanya sama ada menulis dalam Pascal dan Asas di sekolah akan sesuai dengan mereka? =)
Saya juga ingin meninggalkan nota berkenaan perkara 3 bagi mengukuhkan pemahaman mengapa perkara ini dilindungi oleh pentadbir sistem. Kubernetes hanyalah orkestrasi, alat yang membungkus arahan terus kepada pemacu rangkaian dan hos virtualisasi/pengasingan dalam beberapa arahan dan membolehkan anda membuat komunikasi dengan mereka secara abstrak, itu sahaja. Sebagai contoh, mari kita ambil 'bina rangka kerja' Buat, yang, dengan cara itu, saya tidak menganggap rangka kerja. Ya, saya tahu tentang fesyen mendorong Make di mana-mana, di mana perlu dan tidak diperlukan - membungkus Maven dalam Make, contohnya, dengan serius?
Pada asasnya, Make hanyalah pembalut pada cangkerang, memudahkan kompilasi, pemautan dan arahan persekitaran kompilasi, sama seperti k8s.
Pernah, saya menemu bual seorang lelaki yang menggunakan k8 dalam kerjanya di atas OpenStack, dan dia bercakap tentang cara dia menggunakan perkhidmatan padanya, namun, apabila saya bertanya tentang OpenStack, ternyata ia ditadbir, serta dibangkitkan oleh sistem pentadbir. Adakah anda benar-benar berfikir bahawa seseorang yang telah memasang OpenStack, tanpa mengira platform apa yang dia gunakan di belakangnya, tidak dapat menggunakan k8s? =)
Pemohon ini sebenarnya bukan DevOps, tetapi Pentadbir Sistem dan, lebih tepat lagi, Pentadbir Kubernetes.
Mari kita ringkaskan sekali lagi - Pentadbir Sistem Pertengahan/Kanan sudah cukup untuk mereka.
Berapa banyak yang perlu ditimbang dalam gram
Julat gaji yang dicadangkan untuk kekosongan yang ditunjukkan ialah 90k-200k
Sekarang saya ingin membuat persamaan antara ganjaran kewangan Pentadbir Sistem dan Jurutera DevOps.
Pada dasarnya, untuk memudahkan perkara, anda boleh menyebarkan gred berdasarkan pengalaman kerja, walaupun ini tidak tepat, tetapi untuk tujuan artikel itu akan mencukupi.
Pengalaman:
- sehingga 3 tahun - Junior
- sehingga 6 tahun - Pertengahan
- lebih daripada 6 β Senior
Tapak carian pekerja menawarkan:
Pentadbir Sistem:
- Junior - 2 tahun - 50k gosok.
- Pertengahan - 5 tahun - 70k gosok.
- Senior - 11 tahun - 100k gosok.
Jurutera DevOps:
- Junior - 2 tahun - 100k gosok.
- Pertengahan - 3 tahun - 160k gosok.
- Senior - 6 tahun - 220k gosok.
Menurut pengalaman "DevOps", pengalaman telah digunakan yang sekurang-kurangnya mempengaruhi SDLC.
Daripada perkara di atas, sebenarnya syarikat tidak memerlukan DevOps, dan juga bahawa mereka boleh menjimatkan sekurang-kurangnya 50 peratus daripada kos yang dirancang pada mulanya dengan mengupah Pentadbir; lebih-lebih lagi, mereka boleh mentakrifkan dengan lebih jelas tanggungjawab orang yang mereka cari. dan memenuhi keperluan dengan lebih cepat. Kita juga tidak harus lupa bahawa pembahagian tanggungjawab yang jelas membolehkan kita mengurangkan keperluan untuk kakitangan, serta mewujudkan suasana yang lebih baik dalam pasukan, kerana ketiadaan pertindihan. Sebilangan besar jawatan kosong penuh dengan utiliti dan label DevOps, tetapi ia tidak berdasarkan keperluan sebenar untuk Jurutera DevOps, hanya permintaan untuk pentadbir alat.
Proses melatih jurutera DevOps juga terhad hanya kepada satu set kerja tertentu, utiliti, dan tidak memberikan pemahaman umum tentang proses dan kebergantungan mereka. Sudah tentu bagus apabila seseorang boleh menggunakan AWS EKS menggunakan Terraform, bersama-sama dengan sidecar Fluentd dalam kelompok ini dan timbunan AWS ELK untuk sistem pengelogan dalam masa 10 minit, menggunakan hanya satu arahan dalam konsol, tetapi jika dia tidak memahami prinsip memproses log itu sendiri dan apa yang diperlukan untuknya, jika anda tidak tahu cara mengumpul metrik padanya dan menjejaki kemerosotan perkhidmatan, maka ia masih akan menjadi enikey yang sama yang tahu cara menggunakan beberapa utiliti.
Permintaan, bagaimanapun, mencipta bekalan, dan kami melihat pasaran yang sangat panas untuk kedudukan DevOps, di mana keperluan tidak sepadan dengan peranan sebenar, tetapi hanya membenarkan pentadbir sistem memperoleh pendapatan yang lebih.
Jadi siapakah mereka? DevOps atau pentadbir sistem yang tamak? =)
Bagaimana untuk meneruskan hidup?
Majikan harus merumuskan keperluan dengan lebih tepat dan mencari dengan tepat mereka yang diperlukan, dan tidak membuang label. Anda tidak tahu apa yang DevOps lakukan - anda tidak memerlukannya dalam kes itu.
Pekerja - Belajar. Sentiasa tingkatkan pengetahuan anda, lihat gambaran keseluruhan proses dan jejaki laluan ke matlamat anda. Anda boleh menjadi sesiapa sahaja yang anda mahu, anda hanya perlu mencuba.
Sumber: www.habr.com