Get best of the week

Siapa DevOps dan kapan itu tidak dibutuhkan



Tema DevOps telah menjadi sangat populer selama beberapa tahun terakhir. Banyak yang bermimpi bergabung dengannya, tetapi, seperti yang ditunjukkan oleh latihan, seringkali hanya karena tingkat gaji.

Beberapa menunjukkan DevOps di CV mereka, meskipun mereka tidak selalu tahu dan memahami esensi dari istilah tersebut. Seseorang percaya bahwa setelah mempelajari Ansible, GitLab, Jenkins, Terraform dan sejenisnya (daftar dapat dilanjutkan sesuai dengan keinginan Anda), itu akan segera menjadi "devoop". Tentu saja tidak demikian.

Selama beberapa tahun terakhir, saya terutama terlibat dalam penerapan DevOps di berbagai perusahaan. Sebelum itu, ia bekerja selama lebih dari 20 tahun di posisi dari administrator sistem hingga direktur TI. Sekarang - DevOps Lead Engineer di Playgendary.

Siapa itu DevOps


Gagasan untuk menulis artikel muncul setelah pertanyaan lain: "siapa itu DevOps?". Masih belum ada ketentuan tentang siapa atau siapa. Beberapa jawaban sudah ada di video ini . Pertama, saya akan menjelaskan poin-poin utama darinya, dan kemudian saya akan membagikan pengamatan dan pemikiran saya.

DevOps bukan spesialis yang bisa Anda pekerjakan, bukan seperangkat utilitas, dan bukan departemen pengembangan dengan insinyur.

DevOps adalah filosofi dan metodologi.

Dengan kata lain, ini adalah serangkaian praktik yang membantu pengembang berinteraksi secara aktif dengan administrator sistem. Yaitu, untuk menghubungkan dan mengintegrasikan proses kerja satu sama lain.

Dengan munculnya DevOps, struktur dan peran spesialis tetap sama (ada pengembang, ada insinyur), tetapi aturan interaksi telah berubah. Mengaburkan batas antar departemen.

Tujuan DevOps dapat dijelaskan dalam tiga cara:

  • Perangkat lunak harus diperbarui secara berkala.
  • Perangkat lunak harus dilakukan dengan cepat.
  • Perangkat lunak harus digunakan dengan mudah dan dalam waktu singkat.

DevOps tidak memiliki alat tunggal. Mengkonfigurasi, mengirim, dan menjelajahi beberapa produk tidak berarti bahwa DevOps telah muncul di perusahaan. Ada banyak alat dan semua orang terlibat pada tahap yang berbeda, tetapi mereka melayani satu tujuan bersama.


Dan ini hanya bagian dari alat DevOps

Selama lebih dari 2 tahun saya telah mewawancarai orang-orang untuk posisi insinyur DevOps dan saya menyadari betapa pentingnya memahami dengan jelas esensi dari istilah tersebut. Saya telah mengumpulkan pengalaman, pengamatan, dan pemikiran khusus yang ingin saya bagikan.

Dari pengalaman wawancara, saya melihat gambar berikut: spesialis yang menganggap pekerjaan DevOps biasanya memiliki kesalahpahaman dengan rekan kerja .

Ada contoh nyata. Seorang pria muda datang ke wawancara dengan banyak kata-kata cerdas di resume. Di tiga tempat kerja terakhir, ia memiliki pengalaman 5-6 bulan. Dia meninggalkan dua startup karena mereka "tidak lepas landas". Tetapi untuk perusahaan ketiga, ia mengatakan bahwa tidak ada yang memahaminya: pengembang menulis kode pada Windows, dan direktur memaksa kode ini untuk "dibungkus" dalam Docker biasa dan tertanam dalam pipa CI / CD. Pria itu mengatakan banyak hal negatif tentang pekerjaannya saat ini dan rekan-rekannya - saya ingin menjawab: "Jadi, Anda tidak akan menjual gajah."

Lalu saya mengajukan pertanyaan kepadanya, yang merupakan salah satu yang pertama dalam daftar saya untuk setiap kandidat.

- Apa arti DevOps bagi Anda secara pribadi?
- Secara umum atau bagaimana saya melihatnya?

Saya tertarik dengan pendapat pribadinya. Dia tahu teori dan asal istilah itu, tetapi sangat tidak setuju dengan mereka. Dia pikir DevOps adalah posting. Di sinilah letak akar masalahnya. Seperti profesional lain dengan pendapat yang sama.

Pengusaha, setelah mendengar tentang "keajaiban DevOps", ingin mencari seseorang yang akan datang dan menciptakan "keajaiban" ini. Dan pelamar dari kategori "DevOps - posisi ini" tidak mengerti bahwa dengan pendekatan ini mereka tidak akan dapat memenuhi harapan. Dan, secara umum, DevOps menulis dalam resume mereka, karena ini adalah tren dan mereka membayar banyak untuk itu.

Metodologi dan Filsafat DevOps


Metodologi ini teoretis dan praktis. Dalam kasus kami, yang kedua. Seperti yang saya sebutkan di atas, DevOps adalah serangkaian praktik dan strategi yang digunakan untuk mencapai tujuan yang dinyatakan. Dan dalam setiap kasus, tergantung pada proses bisnis perusahaan, itu dapat berbeda secara signifikan. Yang tidak membuatnya lebih baik atau lebih buruk.

Metodologi DevOps hanyalah sarana untuk mencapai tujuan Anda.

Sekarang tentang apa filosofi DevOps. Dan ini mungkin pertanyaan yang paling sulit.

Cukup sulit untuk merumuskan jawaban yang singkat dan ringkas, karena belum diformalkan. Dan karena penganut filsafat DevOps lebih terlibat dalam praktik, tidak ada waktu untuk berfilsafat. Namun, ini adalah proses yang sangat penting. Dan terkait langsung dengan kegiatan rekayasa. Bahkan ada bidang pengetahuan khusus - filosofi teknologi .

Di universitas saya tidak ada subjek seperti itu, saya harus mempelajari semuanya sendiri berdasarkan bahan yang dapat saya temukan di tahun 90-an. Topiknya adalah opsional untuk pendidikan teknik, karenanya kurangnya formalisasi jawaban. Tetapi orang-orang yang benar-benar tenggelam dalam DevOps, mulai merasakan semacam "semangat" atau "kelengkapan tak sadar" dari semua proses perusahaan.

Saya mencoba memformalkan beberapa "postulat" filosofi ini. Ternyata yang berikut ini:

  • DevOps bukanlah sesuatu yang independen, yang dapat dibedakan menjadi bidang pengetahuan atau aktivitas yang terpisah.
  • Metodologi DevOps harus dipandu oleh semua karyawan perusahaan yang merencanakan kegiatan mereka.
  • DevOps mempengaruhi semua proses dalam perusahaan.
  • DevOps hadir untuk mengurangi waktu yang dihabiskan untuk setiap proses dalam perusahaan untuk memastikan pengembangan layanan dan kenyamanan pelanggan yang maksimal.
  • DevOps, dalam bahasa modern, adalah posisi proaktif dari setiap karyawan perusahaan, yang bertujuan mengurangi biaya waktu dan meningkatkan kualitas produk-produk TI di sekitar kita.

Saya pikir "postulat" saya adalah topik yang terpisah untuk diskusi. Tetapi sekarang ada sesuatu untuk dibangun.

Apa yang dilakukan DevOps


Kata kuncinya di sini adalah komunikasi. Ada banyak komunikasi, penggagasnya haruslah insinyur yang sangat pintar. Mengapa demikian? Karena itu adalah filosofi dan metodologi, dan baru kemudian rekayasa pengetahuan.

Saya tidak dapat berbicara tentang pasar tenaga kerja Barat dengan kepastian 100%. Tapi saya tahu banyak tentang pasar DevOps di Rusia. Selain ratusan wawancara, selama setengah tahun terakhir saya berpartisipasi dalam ratusan presales teknis untuk layanan "Implementasi DevOps" untuk perusahaan dan bank besar Rusia.

Di Rusia, DevOps masih sangat muda, tetapi sudah menjadi tren. Sejauh yang saya tahu, hanya di Moskow kekurangan spesialis seperti itu pada tahun 2019 berjumlah lebih dari 1000 orang. Dan kata Kubernet untuk majikan hampir seperti kain merah untuk banteng. Penganut alat ini siap untuk menggunakannya bahkan di tempat yang tidak perlu dan tidak ekonomis. Majikan tidak selalu memahami dalam kasus apa lebih tepat untuk menggunakannya, dan dengan penyebaran yang tepat, pemeliharaan kluster Kubernet lebih mahal 2-3 kali dari pada menggunakan aplikasi menggunakan skema klaster konvensional. Gunakan di mana Anda benar-benar membutuhkannya.



Menerapkan DevOps dalam hal uang itu mahal. Dan itu dibenarkan hanya jika membawa manfaat ekonomi di bidang lain, dan tidak dengan sendirinya.

Insinyur DevOps, pada kenyataannya, adalah pelopor - mereka adalah orang pertama yang memperkenalkan metodologi ini di perusahaan dan membangun proses. Agar ini berhasil, spesialis harus terus berinteraksi dengan karyawan dan kolega di semua tingkatan. Seperti yang biasa saya katakan, semua karyawan perusahaan harus terlibat dalam proses penerapan DevOps: dari wanita pembersih menjadi CEO. Dan ini merupakan prasyarat. Jika anggota termuda dari tim tidak tahu dan mengerti apa itu DevOps dan mengapa tindakan organisasi tertentu dilakukan, maka implementasi yang sukses akan gagal.

Insinyur DevOps juga perlu menggunakan sumber daya administratif dari waktu ke waktu. Misalnya, untuk mengatasi "perlawanan lingkungan" - ketika tim tidak siap untuk menerima alat dan metodologi DevOps.

Pengembang harus menulis hanya kode dan tes. Untuk melakukan ini, ia tidak memerlukan laptop super-kuat di mana ia akan menyebarkan dan mendukung secara lokal seluruh infrastruktur proyek. Misalnya, front-end menyimpan semua elemen aplikasi pada laptop Anda, termasuk basis data, emulator S3 (minio) dan banyak lagi. Artinya, dia menghabiskan banyak waktu untuk memelihara infrastruktur lokal ini dan berjuang sendirian dengan semua masalah dari solusi semacam itu. Alih-alih mengembangkan kode untuk bagian depan. Orang-orang seperti itu bisa sangat menentang perubahan apa pun.

Tetapi ada tim yang, sebaliknya, dengan senang hati memperkenalkan alat dan metode baru, dan secara aktif terlibat dalam proses ini. Meskipun dalam kasus ini, komunikasi antara insinyur DevOps dan tim belum dibatalkan.

Ketika DevOps tidak diperlukan


Ada situasi ketika DevOps tidak diperlukan. Ini adalah fakta - itu harus dipahami dan diterima.

Pertama-tama, ini berlaku untuk perusahaan mana pun (terutama bisnis kecil), ketika laba mereka tidak bergantung langsung pada ada atau tidak adanya produk-IT yang menyediakan layanan informasi kepada pelanggan. Dan di sini kita tidak berbicara tentang situs web perusahaan, apakah itu "kartu nama" statis atau dengan blok berita dinamis, dll.

DevOps diperlukan ketika kepuasan klien Anda dan keinginannya untuk kembali lagi kepada Anda tergantung pada ketersediaan layanan informasi ini untuk berinteraksi dengan klien, kualitas dan penargetan mereka.

Contoh yang mencolok adalah salah satu bank terkenal. Perusahaan tidak memiliki kantor klien yang biasa, alur kerjanya dilakukan melalui pos atau kurir, dan banyak karyawan bekerja dari rumah. Perusahaan tidak lagi menjadi bank dan, menurut pendapat saya, berubah menjadi perusahaan IT dengan teknologi DevOps yang dikembangkan.

Banyak contoh dan kuliah lain dapat ditemukan dalam rekaman pertemuan dan konferensi tematik. Saya pribadi mengunjungi beberapa di antaranya - ini adalah pengalaman yang sangat berguna bagi mereka yang ingin berkembang ke arah ini. Berikut ini tautan ke saluran YouTube dengan kuliah dan materi bagus tentang DevOps:


Sekarang lihat bisnis Anda dan pikirkan tentang ini: seberapa besar perusahaan Anda dan keuntungannya bergantung pada produk-IT yang menyediakan interaksi dengan klien?

Jika perusahaan Anda menjual ikan di toko kecil dan satu-satunya produk IT adalah dua konfigurasi 1C: Perusahaan (Akuntansi dan UNF), maka hampir tidak masuk akal untuk berbicara tentang DevOps.

Jika Anda bekerja di perusahaan komersial dan industri besar (misalnya, memproduksi senapan berburu), maka itu patut dipertimbangkan. Anda dapat mengambil inisiatif dan menyampaikan kepada prospek Anda prospek untuk mengimplementasikan DevOps. Nah, pada saat yang sama, pimpin proses ini. Sikap proaktif adalah salah satu postulat penting dari filosofi DevOps.

Ukuran dan volume perputaran keuangan tahunan bukan kriteria utama untuk menentukan apakah perusahaan Anda membutuhkan DevOps.

Bayangkan sebuah perusahaan industri besar yang tidak berinteraksi langsung dengan pelanggan. Misalnya, beberapa pembuat mobil dan perusahaan otomotif. Sekarang saya tidak yakin, tetapi, dari pengalaman masa lalu saya, selama bertahun-tahun semua interaksi dengan klien dilakukan melalui e-mail dan telepon.

Pelanggan mereka adalah daftar dealer mobil terbatas. Dan seorang spesialis dari produsen melekat pada masing-masing. Semua alur kerja internal terjadi melalui SAP ERP. Karyawan internal, pada kenyataannya, adalah pelanggan dari sistem informasi. Tetapi pengelolaan IP ini dilakukan dengan cara klasik mengelola sistem cluster. Yang mengecualikan kemungkinan menggunakan praktik DevOps.

Oleh karena itu kesimpulannya: untuk perusahaan semacam itu, penerapan DevOps bukanlah sesuatu yang sangat penting, jika kita mengingat tujuan metodologi dari awal artikel. Tetapi saya tidak mengecualikan bahwa beberapa alat DevOps digunakan oleh mereka hari ini.

Di sisi lain, ada banyak perusahaan kecil yang mengembangkan perangkat lunak menggunakan metodologi, filosofi, praktik, dan alat DevOps. Dan mereka percaya bahwa biaya implementasi DevOps adalah biaya yang memungkinkan mereka untuk bersaing secara efektif di pasar perangkat lunak. Contoh perusahaan tersebut dapat dilihat di sini .

Kriteria utama untuk memahami apakah DevOps diperlukan: seberapa penting produk TI Anda bagi perusahaan dan pelanggan.

Jika produk utama perusahaan yang menguntungkan adalah perangkat lunak, Anda memerlukan DevOps. Dan itu tidak begitu penting jika Anda menghasilkan uang nyata dengan bantuan barang-barang lainnya. Ini juga termasuk toko online atau aplikasi seluler dengan game.

Setiap permainan ada berkat pembiayaan: langsung atau tidak langsung dari para pemain. Di Playgendary, kami mengembangkan game seluler gratis yang melibatkan lebih dari 200 orang. Bagaimana kita menggunakan DevOps?

Ya, seperti dijelaskan di atas. Saya terus berkomunikasi dengan pengembang dan penguji, melakukan pelatihan internal untuk staf dan alat metodologi DevOps.

Sekarang kami secara aktif menggunakan Jenkins sebagai alat saluran pipa CI / CD untuk mengeksekusi semua pipa rakitan dengan Unity dan kemudian menyebar ke App Store dan Play Market. Lebih banyak dari kotak alat klasik:

  • Asana - untuk manajemen proyek. Integrasi yang terkonfigurasi dengan Jenkins.
  • Google Meet - untuk panggilan video.
  • Slack - untuk komunikasi dan berbagai peringatan, termasuk pemberitahuan dari Jenkins.
  • Atlassian Confluence - untuk dokumentasi dan kerja kelompok.

Dalam waktu dekat, kami akan memperkenalkan analisis kode statis menggunakan SonarQube dan melakukan pengujian UI otomatis dengan alat Selenium pada tahap Integrasi Berkelanjutan.

Alih-alih sebuah kesimpulan


Saya ingin mengakhiri dengan pemikiran berikut: untuk menjadi insinyur DevOps yang memiliki kualifikasi tinggi, penting untuk belajar bagaimana berkomunikasi dengan orang-orang secara aktif.

Insinyur DevOps adalah pemain tim. Dan tidak ada cara lain. Inisiatif dalam berkomunikasi dengan rekan kerja harus berasal dari dirinya sendiri, dan tidak di bawah pengaruh keadaan apa pun. Spesialis DevOps harus melihat dan menawarkan solusi terbaik untuk tim.

Dan ya, implementasi solusi apa pun akan membutuhkan banyak diskusi, dan pada akhirnya bahkan mungkin berubah. Dengan mengembangkan, menawarkan, dan mengimplementasikan ide-ide mereka secara mandiri, orang semacam itu memiliki nilai yang meningkat baik bagi tim maupun bagi pemberi kerja. Yang, pada akhirnya, tercermin dalam jumlah remunerasi bulanannya atau dalam bentuk bonus tambahan.

More articles:


All Articles