🖖🏼 👨🏽‍🎤 🌘 Pengalaman pribadi: bagaimana membangun karier di departemen DevOps 👸🏾 🐡 🍼

Halo semuanya! Nama saya Timur Gilmullin, saya adalah wakil kepala departemen teknologi dan proses pengembangan di Positive Technologies, saya terlibat dalam otomatisasi dan mengimplementasikan ide-ide DevOps. Hari ini saya akan memberi tahu Anda bagaimana saya memasuki profesi ini, bagaimana di departemen kami, kami melihat karier seorang insinyur DevOps, peta kompetensi apa, dan bagaimana hal itu membantu memastikan pertumbuhan karyawan.

Penolakan

Artikel ini bukan upaya untuk menggambarkan jalur karier ideal seorang insinyur DevOps. Tujuan kami adalah berbagi pengalaman dan memberi tahu cara kerjanya. Ada perusahaan khusus ( ekspres 42 , flant ) dan komunitas ( devops deflope ) yang memberikan kontribusi signifikan terhadap pengembangan ide-ide DevOps di Rusia, dan kami telah memilih setumpuk teknologi dan teknik yang cocok untuk kami.

Tentang bagaimana kami mengembangkan ide-ide DevOps di departemen kami dan di perusahaan, Anda dapat membaca di Habré:

Dan sekarang, ayo pergi!

Mengapa kita membutuhkan DevOps

Setiap perusahaan memiliki spesifikasi departemen otomasi sendiri. Sebagai aturan, tugas-tugas yang sulit atau terlalu mahal untuk dilakukan pada tingkat beberapa departemen terpisah dipindahkan ke grup terpusat atau departemen otomatisasi. Di perusahaan kami, tujuan global dari penerapan ide-ide DevOps adalah untuk memastikan pengurangan yang konsisten dalam biaya produksi dan dukungan produk secara kuantitatif (jam kerja atau jam kerja, CPU, RAM).

Berdasarkan tujuan ini, peran departemen otomasi di tingkat seluruh perusahaan disorot - ini adalah untuk meminimalkan biaya melakukan tugas-tugas serial khas pada semua tahap produksi.

Bagaimana itu bekerja

Tanggung jawab fungsional departemen otomatisasi juga sangat tergantung pada spesifikasi perusahaan tertentu. Perusahaan kami adalah pengembang dan vendor solusi keamanan informasi, dan departemen otomasi bertanggung jawab atas konveyor produksi - mulai dari merakit komponen produk individu hingga mengirimkannya untuk pengujian dan mengirimkan pembaruan ke infrastruktur pelanggan. Kami membantu mengotomatiskan proses pengembangan utama dalam tim dan memastikan kinerja sistem kami (integrasi berkelanjutan dan pengiriman berkelanjutan (CI / CD)).

Pekerjaan kami dibagi menjadi beberapa area fungsional. Arah integrasi berkelanjutan mendukung perakitan dan pengujian pipa untuk pengembang dan penguji. Arah infrastruktur terlibat dalam operasi dan optimalisasi penggunaan semua sumber daya "besi" departemen, serta otomatisasi penyebaran mesin virtual dan lingkungannya (infrastruktur sebagai kode). Arah pemantauan memberikan kontrol terhadap ketersediaan layanan harian. Kami juga menyediakan pemantauan sebagai layanan untuk pengembang (pemantauan sebagai layanan).

Arah alur kerja memberi tim alat untuk mengelola proses pengembangan dan pengujian, menganalisis status kode, dan mendapatkan analisis proyek. Dan akhirnya, webdev menyediakan rilis penerbitan pada server pembaruan perusahaan (GUS dan FLUS), serta produk lisensi menggunakan layanan Lab Lisensi.

Untuk mendukung jalur produksi, kami menyiapkan dan mengelola berbagai layanan dukungan untuk pengembang. Cerita tentang beberapa dari mereka dapat didengar di mitaps lama kami: Op! DevOps! 2016 dan Op! DevOps! 2017 . Kami juga mengembangkan alat otomasi internal, termasuk DevOpsHQ .

Pengalaman teknisi kami

Orang-orang dari departemen otomatisasi kami (untuk kesederhanaan, secara informal disebut departemen DevOps) memiliki latar belakang yang sama sekali berbeda: ada mantan penguji, programmer, insinyur dan administrator TI. Saya seorang guru diploma dalam matematika dan ilmu komputer. Ternyata, berkat keragaman pengalaman, kami dapat mengatasi tugas-tugas semua wilayah kami.

Tidak ada seorang insinyur pun di departemen kami yang dapat menyelesaikan sendiri semua masalah di semua bidang. Tetapi bersama-sama kita, sebagai unit administratif, dengan demikian SRE(Hanya bukan situs, insinyur keandalan layanan, karena kami mendukung layanan untuk pengembang), yang spesialis SDM secara pribadi salah satu insinyur tidak berhasil cari. Kami percaya bahwa berbagai tugas produk perusahaan dapat diselesaikan hanya sebagai bagian dari tim insinyur yang beragam.

Kami memiliki banyak sekali kasus teknis untuk menerapkan otomatisasi. Tetapi hal utama adalah menjelaskan kepada orang-orang mengapa mereka membutuhkan otomatisasi ini. Cara termudah adalah ketika tugas teknis berasal dari bisnis, yaitu ketika orang yang membawa uang ke perusahaan memiliki pemahaman yang jelas: apa, bagaimana dan kapan harus melakukan atau mengoptimalkan. Saya sarankan Anda melihat kasus otomatisasi kami: " Pengalaman pribadi: seperti apa sistem Integrasi Berkelanjutan kami ."

Tentang karier di departemen DevOps kami

Saya ingin mengatakan bahwa semuanya sudah siap dan direncanakan sebelumnya, tetapi ini tidak benar. Pada awalnya, kami tidak memiliki apa pun dalam rencana kami untuk tumbuh dan berkembang. Pada 2014, ketika saya pindah ke departemen teknologi dan proses pengembangan, pengembangan produk hidup dalam semangat startup: semuanya perlu dilakukan di sini dan sekarang, rencana jangka panjang tidak diterima, ada banyak "warisan". Ada empat insinyur pada waktu itu, dan kami memiliki banyak tugas teknis: kami sangat perlu melakukan CI, mengukur pipa perakitan, sebelum itu, tentu saja, membuat pipa ini, dan juga membangun interaksi dengan pelanggan internal kami - programmer dari departemen pengembangan.

Namun, seiring waktu, proses membaik, departemen tumbuh. Bersama dengannya, ada pemahaman yang berkembang tentang apa yang ingin diketahui oleh teknisi kami: apa prospek pengembangan mereka sebagai spesialis, apa yang bisa ditawarkan departemen untuk insinyur baru? Hal pertama yang secara logis mengikuti dari ini adalah bahwa kita akan memerlukan tabel pertumbuhan untuk posisi dan kategori insinyur. Seperti kata pepatah: Ketika masyarakat tidak memiliki perbedaan warna celana, maka tidak ada tujuan! Dan ketika tidak ada tujuan ...

Kami membuat semuanya sesederhana mungkin. Struktur organisasi internal departemen kami terdiri dari tiga posisi kepemimpinan (kepala departemen, wakil pemimpin dan pemimpin kelompok) dan empat posisi eksekutif (junior, reguler, senior dan insinyur perangkat lunak terkemuka), yang pada gilirannya dibagi menjadi tiga kategori masing-masing. Departemen sumber daya manusia sering menggunakan jabatan yang serupa, tetapi tanpa pembagian ke dalam kategori. Untuk departemen kami, kategori-kategori tersebut membantu memastikan pertumbuhan karyawan yang lebih lancar dan bertahap seiring dengan meningkatnya area tanggung jawab dan beban kerja mereka.

Untuk setiap kategori, kami mengembangkan dokumen dengan deskripsi pekerjaan, di mana fungsi dan peran karyawan ditentukan, dan juga bidang tanggung jawab karyawan untuk layanan dan bidang pekerjaan ditunjukkan.

Tapi karena kita, selain teknik, juga suka program, dan tidak ada dari kita yang suka membaca dokumen yang membosankan, di sini kita juga menyederhanakan hidup kita sedikit. Kami tidak menulis setiap instruksi dalam Word, tetapi dalam bentuk teks biasa, diformat oleh bahasa markup Markdown khusus . Pada saat yang sama, keterbacaannya oleh seseorang di editor mana pun tidak hilang. Setelah itu, kami menyimpan teks-teks ini di repositori GitLab kami. GitLab sendiri dapat dengan sangat indah menampilkan berbagai format dokumen, termasuk penarikan Markdown sehingga tidak dapat dibedakan dari Word. Dan klien Git standar memiliki banyak fitur tambahan, misalnya, dapat menunjukkan perbedaan (perbedaan) antara dua dokumen.

Ini sangat menyederhanakan kehidupan seorang insinyur yang ingin mengetahui persyaratan formal apa yang perlu dia ikuti untuk pindah ke langkah berikutnya (kategori) pertumbuhan pribadi di departemen kami. Untuk mengetahui perbedaan antara persyaratan formal dari dua deskripsi pekerjaan, Anda perlu melakukan beberapa langkah sederhana: unduh repositori dengan deskripsi pekerjaan dari GitLab kami, temukan dokumen, jalankan perintah Git di konsol untuk menampilkan perbandingan kedua file. Misalnya, Anda dapat melihat perbedaan antara insinyur senior kategori 2 dan 1 sebagai berikut:

git --no-pager diff --no-index 
level_08__DevOps_Senior_Software_Engineer_2nd_category.md
level_09__DevOps_Senior_Software_Engineer_1st_category.md

Di konsol, yang biasa digunakan oleh semua insinyur perangkat lunak, tanda minus dan warna merah menonjol untuk persyaratan yang telah berubah atau telah dihapus, dan garis yang ditambahkan menonjol dengan tanda plus dan warna hijau: setiap baris ditambah satu persyaratan baru.

Ya, kami adalah maniak teknisi kecil, tetapi bagi kami tampaknya ini adalah solusi hebat:

Peta Kompetensi Insinyur DevOps

Seiring berkembangnya departemen kami dan jumlah konveyor produk yang didukung oleh kami meningkat, kami menyadari bahwa untuk setiap bidang pekerjaan yang kami tangani, tidak mungkin untuk menggambarkan peran yang unik dan menemukan insinyur yang cocok di pasar. Kami memiliki spesifikasi pekerjaan kami sendiri dan, misalnya, kami tidak memerlukan pengembang perangkat lunak programmer mahir untuk memecahkan masalah CI, namun demikian, insinyur CI harus dapat memprogram modul kecil dan skrip dalam Python pada tingkat yang dapat diterima. Demikian juga, kita tidak memerlukan administrator Linux yang berkualitas besar, tetapi kita membutuhkan seseorang dengan pengetahuan yang cukup tentang Debian atau OS Ubuntu sehingga dia dapat menginstal agen pembangun GitLab CI, dan bahkan lebih baik, mengotomatiskan pekerjaan ini melalui SaltStack, Ansible atau alat lainnya.

Jadi apa yang harus dilakukan oleh seorang insinyur DevOps yang bekerja di departemen kami? Untuk melakukan ini, pertama-tama Anda perlu menentukan apa pengetahuan, keterampilan dan kemampuan (disingkat ZUN ) dalam arti umum.

Pengetahuan adalah hukum utama dari area subjek, yang memungkinkan seseorang untuk menyelesaikan produksi spesifik, masalah ilmiah dan lainnya, yaitu, fakta, konsep, penilaian, gambar, hubungan, perkiraan, aturan, algoritma, heuristik, serta strategi pengambilan keputusan di area ini. Pengetahuan juga merupakan elemen informasi yang terhubung satu sama lain dan dengan dunia luar.
Keterampilan - mereka dipahami sebagai dikuasai oleh seseorang bagaimana melakukan suatu tindakan, diberikan dengan tubuh pengetahuan tertentu. Kemampuan diekspresikan dalam kemampuan menerapkan pengetahuan secara sadar dalam praktik.
— , . , , , , .

Jika kita mendefinisikan ZUN lebih spesifik dalam kaitannya dengan produk yang dikembangkan di perusahaan, maka kita akan mendapatkan daftar kompetensi secara umum. Tanpa menguasai kompetensi ini, insinyur tidak akan dapat bekerja secara kualitatif di departemen kami. Daftar ini ternyata sangat panjang, karena memperhitungkan spesifik pekerjaan segera di semua bidang, teknologi, dan produk.

Dengan demikian, kami sampai pada kebutuhan untuk menggambarkan dan mengklasifikasikan semua persyaratan kami untuk seorang insinyur dalam bentuk tabel, dan kami memiliki " Peta Kompetensi DevOps Engineers 1.0 ". Ini terlihat seperti ini: Tabel ini dibagi menjadi empat bagian besar:

Deskripsi kompetensi umum karyawan dari departemen DevOps kami, yang diperlukan untuk solusi sukses tugas sehari-hari.
Pengetahuan adalah pengetahuan spesifik yang berorientasi produk dari para insinyur DevOps.
— ; .
— ; , .

Dalam sel tabel, penilaian kualitatif ditunjukkan: pada tingkat apa seorang insinyur kira-kira memiliki satu atau beberapa kompetensi lain. Sayangnya, saya tidak dapat membayangkan versi lengkap dari tabel di sini, tetapi ini tidak perlu, karena setiap perusahaan dan masing-masing departemen harus membuat tabel sendiri yang serupa, dengan mempertimbangkan spesifikasi pekerjaan.

Pada tahun 2018, saya dan rekan-rekan kerja saya mengembangkan dan menciptakan apa yang disebut peta teknologi dari proses produksi (baca artikel tentang Habr “ Manajemen Kekacauan: kami mengatur berbagai hal menggunakan peta teknologi ”). Berkat dia, kami telah hampir menciptakan vektor pertumbuhan dan pengembangan kompetensi para insinyur DevOps tergantung pada produk, teknologi yang digunakan di dalamnya, dan tahap-tahap dari konveyor produk.

Peta tersebut menggambarkan semua tahapan dan langkah yang membentuk teknologi konveyor untuk produksi produk kami. Hal utama, dari sudut pandang produk, adalah untuk memahami berapa banyak insinyur, kualifikasi apa dan dengan kompetensi apa yang kita butuhkan untuk memastikan operasi berkelanjutan konveyor ini. Lebih baik lagi, merencanakan dan mengamankan orang-orang sehingga, terlepas dari dukungan layanan kritis, mereka dapat, misalnya, pergi berlibur dengan tenang, mengetahui bahwa ada seseorang di departemen yang memiliki kompetensi lintas dan yang dapat menggantikannya.

Secara keseluruhan, ini harus membawa kita ke "Peta Kompetensi DevOps Engineers 2.0", yang akan dengan jelas menggambarkan ZUN tergantung pada produk dan pada kompetensi yang diperlukan untuk pekerjaan otomasi dalam produk ini. Artinya, beberapa pengikatan tahapan pada peta teknologi dengan peta kompetensi insinyur harus muncul. Pada artikel selanjutnya saya akan mencoba memberi tahu Anda apa yang terjadi.

NB. Artikel ini ditulis berdasarkan cerita untuk pertemuan bulan Januari, dimana rekan-rekan dari Hays mengundang kami untuk bertukar pengalaman (Anda dapat melihat presentasi dan teks ).

Penulis : Timur Gilmullin- wakil. Kepala Teknologi dan Proses Pengembangan (DevOps), Teknologi Positif.