Get best of the week

Profesi DevOps-engineer: pandangan administrator sistem



Saya bekerja sebagai insinyur DevOps di Parallels. Saya mendukung pengembangan berbagai layanan, saya menulis skrip untuk penyebaran otomatis mereka, saya berkomunikasi erat dengan tim pengembangan. Saya akan memberi tahu Anda bagaimana pekerjaannya diatur, berapa bayarannya, dan apa gunanya pendekatan DevOps untuk pengembangan perangkat lunak.

Semuanya dimulai dengan fakta bahwa menjadi membosankan bagi saya untuk bekerja sebagai administrator sistem, saya menginginkan sesuatu yang baru. Saya mencoba mengembangkan 1C, tetapi cukup cepat menyadari bahwa ini bukan milik saya. Dia belajar Python, meningkatkan keterampilannya pada sistem Unix dan pergi untuk wawancara di Parallels. Lalu aku hampir tidak tahu apa-apa tentang DevOps, aku hanya datang dan berkata: Aku ingin bekerja untukmu. Dua bulan kemudian mereka membawa saya.

Apa itu DevOps?


Jika Anda bertanya kepada 5 orang tentang apa itu DevOps, Anda mendapatkan 5 jawaban berbeda. Bagi penginjil, ini adalah budaya, atau lebih tepatnya transformasi pemikiran. Untuk insinyur, satu set solusi dan alat. Bagi para manajer, sebuah metodologi. Untuk perekrut - sebuah profesi. Dan untuk semua orang, itu mungkin hanya kata kunci.

Kebenaran, seperti biasa, ada di antara keduanya. DevOps adalah semua hal di atas, disatukan. Tugas utamanya adalah mempercepat pengiriman produk dari bisnis ke konsumen. Istilah itu sendiri diciptakan oleh konsultan IT independen Patrick Debois sekitar dua belas tahun yang lalu. Dia ingin memecah dinding metaforis antara pengembang (dev) dan sysadmin (ops), menggabungkan mereka menjadi satu unit yang efektif, yang dapat membuat perangkat lunak lebih cepat, meluncurkan rilis lebih sering dan dengan lebih sedikit kesalahan.

Karena itu, di jantung DevOps adalah gagasan tentang tanggung jawab bersama, tidak ada pembagian kekuasaan. Programmer dapat berpartisipasi dalam konfigurasi jika dia lebih tahu cara menulis konfigurasi layanannya, dan administrator sistem dalam pengembangan. Ketika masalah muncul, itu tidak ditransfer dari satu karyawan ke yang lain, seperti bola di ping-pong, tetapi menjadi umum. Setiap orang terlibat dalam penghapusannya.



Satu menit statistik yang membosankan. Menurut penelitian DORA (DevOps Research and Assessment), tim lintas fungsi menggunakan pendekatan DevOps:

  • 208 kali lebih sering menyebarkan kode;
  • 106 kali mengurangi waktu dari komit ke penempatan;
  • 2.604 kali lebih cepat mengembalikan sistem setelah kegagalan;
  • 7 kali lebih rendah kemungkinan kegagalan itu sendiri sebagai akibat dari perubahan.

Tentu saja, menggabungkan dev dan ops saja tidak menyebabkan efisiensi seperti itu. Pendekatan DevOps mencakup penggunaan banyak pengembangan baru, pengujian dan alat penyebaran untuk mengatur CI \ CD (konsep integrasi dan pengiriman berkelanjutan). Di antara yang paling terkenal:

  • Git dan GitHub - sistem manajemen kode sumber;
  • Jenkins - server otomatisasi untuk membuat jalur pipa CI / CD;
  • Docker - perangkat lunak untuk mengotomatiskan penerapan dan manajemen aplikasi di lingkungan dengan dukungan untuk kontainerisasi;
  • Kubernetes - sistem orkestrasi wadah terbuka;
  • Chef, Boneka dan Ansible - alat untuk konfigurasi dan penyebaran otomatis;
  • Selenium - solusi otomatisasi uji;
  • Prometheus dan Nagios - perangkat lunak pemantauan server;
  • Grafana adalah solusi untuk mengumpulkan dan menganalisis metrik.

Pada saat yang sama, seperangkat alat universal yang cocok untuk setiap bisnis tidak ada, juga tidak ada jalan tunggal untuk DevOps. Hanya ada yang berfungsi atau, sebaliknya, tidak berfungsi di infrastruktur Anda. Saya secara teratur menghadiri konferensi dan berbagai acara, berkomunikasi dengan kolega dari perusahaan lain dan saya dapat mengatakan bahwa 80% hal yang mereka gunakan di Parallels tidak dapat diterapkan.

Setiap organisasi memiliki produknya sendiri, tumpukan teknologinya sendiri, dan kemacetannya. Karena itu, pendekatan untuk optimasi sangat berbeda. Kadang-kadang Anda harus mengubah arsitektur layanan itu sendiri, beberapa sangat kompleks atau tidak fleksibel sehingga sulit untuk mentransfer pendekatan DevOps kepada mereka.

Esensi dari insinyur DevOps


Pada tingkat dasar, seorang insinyur DevOps adalah seorang spesialis teknis yang memahami semua tahap utama siklus hidup pengembangan perangkat lunak, mengoreksi kemacetan dalam proses, dan menyesuaikan lingkungan:

  • Menulis kode untuk penyebaran aplikasi otomatis
  • sebagian bertanggung jawab atas ketersediaannya, bukan secara pribadi sebagai administrator sistem, tetapi dengan timnya;
  • membawa tugas pada infrastrukturnya (memahami kesalahan, terkadang bersama-sama dengan seorang programmer).

Otomasi adalah apa yang ada di pundak seorang insinyur DevOps sejak awal. Penciptaan produk IT dengan pendekatan tradisional adalah sebagai berikut: programmer menulis kodenya, mengkompilasinya dalam beberapa format, dan memberikannya kepada sysadmin. Dia pergi ke server, menginstal dan mengkonfigurasi semuanya dengan tangannya. Pada saat yang sama, mereka berjuang untuk hal-hal yang berbeda: administrator sistem - untuk stabilitas, programmer - untuk perubahan mereka, yang, tentu saja, mempersulit pekerjaan masing-masing.

Di DevOps, ini bekerja sedikit berbeda. Aplikasi ini digunakan menggunakan skrip. Insinyur DevOps menetapkan urutan tindakan tertentu yang membawa kode yang ditulis oleh programmer, pertama ke server uji, dan kemudian ke server pertempuran (jika diputuskan bahwa perubahan dapat dilepaskan). Dengan demikian, pengembang memiliki kesempatan untuk memeriksa kodenya setidaknya setiap 15 menit dan melakukannya bahkan pada pukul tiga pagi dengan satu klik tombol.

Tanggung jawab khusus, serta keterampilan yang diperlukan, sangat tergantung pada tempat kerja. Kami, di Parallels, memiliki banyak infrastruktur kami, bagian yang paling penting tidak berada di awan publik, tetapi di server fisik kami sendiri di beberapa pusat data. Dan kadang-kadang ada pembaruan besar mengenai perangkat keras dan perangkat lunak pada server ini, dan migrasi diperlukan secara berkala.

Ini juga pekerjaan saya.


Saya mencoba mengotomatiskan semuanya dengan maksimal sehingga prosesnya tidak terlalu menyakitkan. Terakhir kali, dalam rangka pengujian cross-backup dan toleransi kesalahan infrastruktur, dimungkinkan untuk mentransfer layanan dari AS ke Swiss dalam 10 menit dan memperbarui semua yang diperlukan di sepanjang jalan. Untuk teknologi modern, ini, tentu saja, bukan pencapaian besar. Tapi bagi kita - langkah besar ke depan.

Legacy juga merupakan tantangan yang pasti bagi para insinyur DevOps. Bahkan di perusahaan dengan alur kerja yang dibangun dengan baik, ada layanan yang telah ditulis untuk waktu yang sangat lama, dan tidak ada yang ingat sepenuhnya bagaimana mereka dikonfigurasikan, karena sering dilakukan secara manual, dan orang-orang yang mengerjakannya tidak lagi bekerja di organisasi. Jika ini adalah layanan yang penting, banyak penelitian dilakukan - Anda harus memikirkannya dengan sedikit nuansa cara kerjanya, menulis kode untuk penyebaran, menutupinya dengan pemantauan dan metrik.

Ini layak dilakukan, bahkan jika kode aplikasi tidak berubah dengan sangat aktif. Kenapa, jika semuanya bekerja seperti itu? Agar dapat mereproduksi jika terjadi kegagalan, instal pembaruan keamanan, temukan dan perbaiki masalah yang, mungkin, tidak ada yang tahu. Baru-baru ini, saya baru saja menulis skrip untuk layanan seperti itu dengan sejarah panjang. Diperlukan perubahan kodenya, pekerjaan belum selesai, tetapi kemajuannya besar. Sangat menarik untuk mengumpulkan gambar lengkap aplikasi dari potongan-potongan yang tersebar, senang melihat hasilnya nanti.

Dan, tentu saja, penerapan pendekatan DevOps terkait erat dengan pengukuran. Berapa waktu respons berubah? Seberapa sering kesalahan yang diinginkan terjadi? Sebelumnya, seorang administrator sistem sering tidak tahu bagaimana mengukur hal-hal ini. Aplikasi adalah kotak hitam, hanya karakteristik paling dasar yang tersisa: beban prosesor, konsumsi memori, lalu lintas. Dan ketika versi baru digunakan, baik administrator sistem maupun programmer tidak dapat dengan cepat menentukan bahwa semuanya tidak berjalan persis seperti yang direncanakan. Tetap menunggu panggilan marah untuk dukungan teknis.

Dengan pendekatan DevOps, ini adalah masa lalu. Anda dapat mengonfigurasikan kumpulan metrik aplikasi nyata, membandingkannya dengan konsumsi sumber daya, dan karena ini lebih baik dan lebih cepat untuk menemukan masalah, mengoptimalkan, meningkatkan kualitas produk, dan bukan hanya server uptime.

Berapa penghasilan para insinyur DevOps?


Gaji seorang insinyur DevOps tergantung pada keterampilan, tempat kerja dan wilayah tempat tinggal. Gaji seorang spesialis yang bekerja di Moskow adalah yang tertinggi di Rusia, 130-350 ribu rubel sebulan. Perusahaan St. Petersburg menawarkan 100–300 ribu rubel di posisi ini. Di wilayah lain di negara kita, mereka siap membayar 70-120 ribu rubel.

Pendapatan tahunan rata-rata di Amerika Serikat, seperti yang dikatakan beberapa HR, berkisar antara 100 hingga 125 ribu dolar AS, menurut data yang dirilis oleh Puppet. Di Australia dan Selandia Baru - 75-100 ribu dolar AS. Di Eropa - 50-75 ribu dolar AS. Di Asia, insinyur DevOps menerima tidak lebih dari 25 ribu dolar AS per tahun.

More articles:


All Articles