Mengapa saya tidak mencoba mempekerjakan seorang 'Insinyur DevOps'?


32

Gagasan memiliki Insinyur DevOps telah menjadi sangat populer baru-baru ini , dan tampaknya menarik untuk memiliki seseorang yang dapat masuk dan memberikan banyak manfaat DevOps, seperti yang dijelaskan dalam blog Wayang :

Organisasi yang menggunakan praktik DevOps sangat berfungsi tinggi: Mereka menyebarkan kode hingga 30 kali lebih sering daripada pesaing mereka, dan 50 persen lebih sedikit dari penyebaran mereka gagal, menurut laporan State of DevOps 2015 kami.

Namun, saya telah memperhatikan banyak oposisi vokal terhadap ide seorang Insinyur DevOps untuk mencoba dan melakukan perbaikan ini:

Bahkan dengan persetujuan luas tentang atribut DevOps inti, kontroversi mengelilingi istilah "insinyur DevOps." Beberapa mengatakan istilah itu sendiri bertentangan dengan nilai-nilai DevOps. Jez Humble, co-penulis Continuous Delivery, menunjukkan bahwa hanya memanggil seseorang insinyur DevOps dapat membuat silo ketiga di samping dev dan ops - "... jelas cara yang buruk (dan ironis) untuk mencoba dan menyelesaikan masalah ini . "

Mengapa mungkin bukan ide yang bagus untuk bisnis untuk menyewa seorang Insinyur DevOps untuk mencoba dan 'mengimplementasikan DevOps', yang bertentangan dengan perubahan organisasi yang dianjurkan oleh blog-blog seperti ini ? Apakah manfaatnya akan diniadakan dengan hanya memiliki peran DevOps yang terisolasi?


Anda harus melakukan apa pun yang paling efektif untuk bisnis, tim, dan proyek Anda. Anda harus bereksperimen untuk mencari tahu apa yang paling efektif. Kelincahan memengaruhi perubahan yang sesuai dengan situasi spesifik Anda. Seperti yang dikatakan Kent Beck, "setiap jawaban yang layak untuk pertanyaan yang menarik dimulai, 'itu tergantung ...'"
Adrian

Jawaban:


24

TL; DR : Anda sebaiknya tidak pernah mencoba menyewa Tim DevOps


Pada dasarnya ada tiga peran paling umum untuk disewa:

  1. DevOps Architect / Evangelist
  2. Insinyur DevOps
  3. Insinyur CI / CD

Peran-peran ini berbeda dari 6 peran pengembangan perangkat lunak penting Anda yang secara tradisional membentuk organisasi rekayasa perangkat lunak:

  1. Manajemen Produk
  2. Pengembangan perangkat lunak
  3. Pengembangan Alat
  4. Keamanan dan Kepatuhan
  5. Kualitas dan Pengujian
  6. Operasi Sistem (SRE)

Mari kita pergi melalui tiga peran satu per satu dan melihat bagaimana mereka cocok


DevOps Architect atau Evangelist

  • Mengapa : Jika Anda tersesat, lambat, rusak dan tidak tahu harus berbuat apa.
  • Kapan : Pada awal proses dalam tahap perencanaan.
  • Apa : Peran tingkat manajemen untuk memandu semua manajer dan pemimpin dalam keseluruhan Rekayasa Perangkat Lunak. Orang ini akan merencanakan seluruh transformasi organisasi teknik Anda ke kondisi yang sangat berfungsi.
  • Siapa : Anggota konsultan yang berpengalaman dalam teori, praktik manajemen, topik budaya, dan operasi yang melapor langsung ke Wakil Presiden Rekayasa Perangkat Lunak.

Dalam beberapa kasus dan untuk perusahaan kecil dan menengah, Anda dapat memulai proses alih-alih dengan menyewa organisasi konsultan, seperti DORA.

Insinyur DevOps

  • Mengapa :
    1. Untuk menjembatani kesenjangan antara tim jika mereka diorganisir sepanjang peran fungsional yang disebutkan di atas untuk memastikan kerjasama tingkat lintas fungsional.
    2. Untuk menanamkan diri dengan tim yang berorientasi produk, yang masing-masing memiliki 6 peran tradisional yang termasuk dalam tim, untuk membantu menjembatani kesenjangan pengetahuan dan untuk membantu dengan implementasi dan adopsi praktik dan alat baru.
  • Kapan : Setelah Anda menyusun rencana dan transformasi organisasi dimulai dan seluruh tim manajemen ada di dalamnya.
  • Apa : Aktifkan kerja sama lintas fungsi, pastikan batas-batas tim dipecah, bahwa optimisasi lokal di dalam tim tidak menciptakan penghalang untuk throughput kerja yang tinggi di seluruh rantai nilai, mulai dari keinginan pelanggan hingga pengiriman pelanggan.
  • Siapa : Insinyur berpengalaman dengan keterampilan baik dalam pengembangan perangkat lunak dan operasi sistem. Ia harus terampil dalam praktik-praktik terbaik, perubahan proses dan budaya yang terkait dengan transformasi DevOps.

Insinyur CI / CD

  • Mengapa : Untuk membantu mengimplementasikan jaringan pipa CI / CD, mengintegrasikan rantai alat Anda, bawa alat yang akan memungkinkan kerja perusahaan yang lebih baik.
  • Ketika : Selama transisi dalam organisasi yang lebih besar, sementara peran di atas telah diisi.
  • Apa : Insinyur, yang pada dasarnya merupakan bagian dari tim alat yang akan dapat mengatur pipa CI / CD dan mulai mengintegrasikan sistem internal dengan cara yang akan menghilangkan gesekan dari throughput pekerjaan.
  • Siapa : Insinyur berpengalaman dengan Alat, proses Integrasi, Manajemen Rilis, dan praktik DevOps. Seseorang yang mengerti bahwa mereka mengganti gerbang manusia dalam proses pelepasan oleh Automation.

11
Saya kesulitan menghubungkan tl; dr ke sisa jawaban tempat Anda memberikan alasan untuk mempekerjakan ...
Tensibai

Sisa jawaban menjelaskan bagaimana tidak ada peran yang terkait dengan DevOps yang konduktif untuk menciptakan tim orang-orang itu. Jangan rekrut tim baru, sematkan individu ke tempat-tempat tertentu di organisasi Anda berdasarkan kebutuhan.
Jiri Klouda

5
@JiriKlouda jawaban yang sangat baik, saya hampir 100% setuju, singkat dari istilah "Sistem Operasi (SRE)" - Sistem Operasi! = Insinyur Keandalan Situs, yang terakhir adalah model Google untuk DevOps yang masih mewujudkan prinsip-prinsip inti DevOps tetapi mempertahankan beberapa keuntungan memiliki tim operator spesialis.
Richard Slater

Yang saya maksud adalah tim operasi dalam bentuk apa pun, baik tradisional atau SRE atau segala bentuk infrastruktur atau manajemen platform lainnya. Dan percayalah, Anda dapat memiliki tim Site Reliabikity tanpa sepenuhnya mengadopsi DevOps :)
Jiri Klouda

1
Jujur saja tidak cukup di sana. Insinyur CI / CD harus cukup tahu untuk merancang jaringan pipa. Arsitek DevOps dapat melakukan pekerjaan tingkat tinggi di tingkat organisasi. Saya telah memisahkan peran dari insinyur DevOps karena memiliki karakteristik yang berbeda. Ini adalah pekerjaan teknik berorientasi alat, dapat dengan mudah menjadi bagian dari tim (alat / integrasi / tim aplikasi internal). Ini akan menjadi kesalahan sebagian besar orang terhadap insinyur DevOps. Ini adalah evolusi dari insinyur rilis, tetapi dengan otomatisasi. Alih-alih gerbang, mereka sekarang hanya membangun dan memantau otomatisasi.
Jiri Klouda

10

Saya berpendapat Ahli Teknik seperti yang dijelaskan dalam tautan pertanyaan Anda terutama merupakan peran sysadmin. Mengutip keterampilan di sini sebagai latar belakang untuk jawaban ini:

Perlengkapan panjat Anda.

  • Latar belakang yang kuat dalam pengalaman Linux / Unix Administration dengan manajemen otomatisasi / konfigurasi menggunakan Wayang, Chef atau yang setara
  • Kemampuan untuk menggunakan beragam teknologi sumber terbuka dan layanan cloud (diperlukan pengalaman dengan AWS)
  • Pengalaman yang kuat dengan SQL dan MySQL (pengalaman NoSQL juga merupakan nilai tambah, karena kami juga menggunakan Redis)
  • Pemahaman kode dan skrip yang berfungsi (PHP, Python, Perl, dan / atau Ruby)
  • Pengetahuan tentang praktik terbaik dan operasi TI dalam layanan yang selalu tersedia dan selalu tersedia

Dalam contoh ini, deskripsi pekerjaan DevOps Engineer hanyalah kata yang populer untuk sysadmin yang nyaman dengan infrastruktur berbasis cloud, otomatisasi, dapat membaca kode untuk membantu diagnostik, dan mengetahui praktik dan solusi ketersediaan tinggi.

Ini terkait longgar dengan praktik DevOps dan budaya melanggar silo antara dev dan ops seperti yang terlihat dalam pertanyaan ini. Apa perbedaan antara Sysadmin dan DevOps Engineer?

Itu bukan ide yang baik karena seorang sysadmin, betapa nyamannya dia dengan praktik dan budaya devops, bukan orang yang tepat untuk mendorong transformasi perusahaan. Anda tidak akan mempekerjakan orang ini dengan perubahan budaya tetapi dengan tampilan konfigurasi alat, yang tidak akan benar-benar membantu memecahkan proses. Ini juga mungkin diterima dengan buruk oleh rekan-rekannya dan Anda hanya akan membawa perlawanan terhadap perubahan jika tidak ada perubahan budaya yang direncanakan sebelumnya

Untuk pola yang sukses menuju keuntungan para devops, jawaban @ Jiri Klouda memberikan gambaran yang bagus tentang peran Insinyur Engineer yang dapat diterima bersama dengan langkah dalam perubahan itu akan membawa nilai dan membantu menuju kesuksesan.


1
Bagaimana Anda menyarankan seseorang membedakan antara sysadmin yang nyaman membaca kode untuk mendiagnosis masalah, infrastruktur cloud dan otomasi, dan sysadmin tradisional yang memiliki banyak pengalaman tetapi tidak ada keterampilan itu?
avi

@avi dengan resume mereka, milik saya sebagai contoh saya lebih nyaman untuk membandingkan, memiliki mereka sementara masih berjudul Net / Sysadmin. Saya memiliki referensi ke organisasi devops untuk beberapa proyek yang telah saya kerjakan. Dan saya biasanya tidak menjalankan proposal menggunakan devops sebagai kata kunci karena peringatan yang saya sebutkan dalam jawaban ini (dipukul sekali selama kontrak)
Tensibai

@Vi jika Anda maksud dalam proposal pekerjaan, dalam rincian proposal, kualifikasi yang diperlukan jauh berbeda dari yang ada di pertanyaan dan yang ada di jawaban Jiri untuk menjaga judul pekerjaan sesuai dengan IMHO
Tensibai

1
Saya cenderung mengatakan bahwa sysadmin yang tidak nyaman dengan otomasi hanyalah sysadmin yang kurang terampil, bukan jabatan yang berbeda. Lihat juga esai karya John Allspaw ini .
Xiong Chiamiov

6

Saya menyadari jawaban ini mungkin tidak cocok untuk Anda, tetapi inilah yang saya lakukan

Saya adalah pengembang pertama yang bekerja pada startup e-commerce yang sangat sibuk, dengan lalu lintas yang sangat tinggi. Saya menyadari perusahaan itu masih muda, dan bahwa, untuk sementara waktu, saya akan menjadi satu-satunya sumber daya teknis di rumah.

Mengetahui hal ini, saya memutuskan untuk menyusun infrastruktur saya sedemikian rupa, sehingga saya harus melakukan administrasi sistem NOL.

Saya memutuskan untuk menjadi tuan rumah di cloud, karena hal itu melegakan saya terhadap pemeliharaan sistem. Saya mencari insinyur AWS, dengan pengalaman boneka. Bersama-sama, kami merancang infrastruktur yang autoscalable, ditulis sebagai kode dalam cloudformation. Semua file konfigurasi diversi dalam boneka.

Ini memungkinkan saya, sebagai pengembang, untuk memainkan peran ini. Saya membangun alat rilis kode, dengan python, fabric. Saya menggunakan skrip yang sama untuk mem-bootstrap aplikasi saya ke server baru yang di-autoscaled.

Ini bekerja dengan sangat baik, dan hari ini, 3 tahun kemudian, saya masih tidak melakukan pemeliharaan sistem. Kami memiliki admin sistem (insinyur AWS yang sama) selama 10 jam sebulan, dan saya mencoba menyusun sprintnya sedemikian rupa sehingga saya tidak menjadi gangguan baginya. Dengan cara itu saya menghargai waktunya, dan mengelola sprintnya dengan cara terbaik yang saya bisa.

Jika suatu sistem memiliki kinerja yang terdegradasi, saya cukup menghentikannya, dan yang lainnya berputar menggantikannya.

Saya berharap jawaban ini entah bagaimana dapat bermanfaat bagi Anda


Sangat membantu, terima kasih. Sangat menarik untuk mendengar bagaimana Anda pada dasarnya menjadi apa yang orang lain sebut sebagai 'Insinyur DevOps' secara tidak langsung, dan saya pikir (dari apa yang dikatakan jawaban lain) bahwa cara Anda lebih sesuai dengan filosofi DevOps tentang tidak memiliki 'DevOps yang sepenuhnya terpisah' 'departemen. Kedengarannya itu bekerja dengan baik untuk Anda sejauh ini!
Aurora0001

Jadi pada dasarnya Anda mengelola semuanya sendiri? Apa yang terjadi jika Anda meninggalkan perusahaan? Apakah bisnis akan dapat bertahan? Apa sudut pandang manajemen Anda dalam hal ini?
030

Infrastruktur mengelola sendiri. Ini sepenuhnya didokumentasikan, dan kami menggunakan Terraform & Puppet untuk mengatur infrastruktur dan mengelola konfigurasi server. Jadi pada kenyataannya, setiap insinyur wayang / terraform dengan pengalaman AWS dapat langsung masuk. Saya sekarang adalah pemegang saham dalam bisnis ini, dan tim pengembang kami telah tumbuh secara signifikan. Untungnya sekarang semua orang tahu bagaimana infrastruktur mengalir
user2965205

4

Anda tidak boleh menyewa seorang insinyur DevOps karena DevOps mencakup begitu banyak disiplin ilmu sehingga satu orang tidak mungkin menjadi ahli dalam semua aspek disiplin ilmu ini. Dengan menyewa jack semua perdagangan, Anda akan menyewa seorang master tidak ada.

DevOps selalu merupakan upaya berbasis tim dan Anda tidak mungkin mengharapkan satu individu untuk mendukung harapan seluruh tim. Pertimbangkan ruang lingkup DevOps. Satu orang tidak mungkin:

  • Jadilah pengembang rockstar dalam [bahasa]
  • Jadilah guru jaringan, mengetahui semua RFC yang diperlukan
  • Menjadi Administrator Sistem yang aktif
  • Jadilah penguji QA ahli
  • Jadilah Administrator Database
  • Mengkhususkan dalam penyimpanan dan cadangan
  • Ketahui Rekayasa Keandalan Situs
  • Berpotensi disiplin lain juga

Beberapa di atas bahkan memiliki sub disiplin ilmu, seperti Windows System Admin vs Linux / Unix System admin atau mungkin Anda menggunakan lebih dari satu bahasa pengkodean di komputer Anda.

Tidak ada orang yang bisa menjadi ahli dalam semua ini yang berarti bahwa jika Anda beriklan untuk insinyur DevOps, ketika area terlemah di tim DevOps Anda adalah Networking, Anda tidak melakukan pekerjaan yang sangat baik dalam mengiklankan kebutuhan Anda akan spesialis jaringan untuk tim DevOps Anda . Meskipun tidak ada individu yang harus diasingkan ke peran tertentu dalam tim DevOps, Anda akan merugikan tim Anda dengan berpura-pura tidak ada spesialis atau ahli materi pelajaran (UKM) dalam lingkup DevOps. Mengayunkan pendulum dari satu ekstrem ke ekstrem yang lain - dari silo ke ing berpura-pura seperti setiap peran di tim DevOps Anda adalah sama - dapat menyebabkan banyak masalah.

Walaupun memiliki anggota tim lintas-kereta dalam lebih dari satu disiplin - khususnya di bidang yang tumpang tindih itu baik, mengharapkan mereka untuk menjadi mahir dalam volume pengetahuan yang begitu luas sama sekali bukan praktik.

Ini berarti bahwa siapa pun yang memberi tahu Anda bahwa mereka tahu semua aspek DevOps mungkin berbohong kepada Anda. Menyewa seorang spesialis di bidang di mana Anda paling lemah dalam bekerja di tim DevOps - bukan "Insinyur DevOps."


Jadi semua deskripsi pekerjaan itu hanya bulu untuk melihat siapa yang berlaku? Mereka sepertinya menginginkan segalanya di dunia. Saya melihatnya dan berpikir, saya tahu ini, ini, itu, dan bukan itu, bukan itu, bukan itu .... Mungkin semua bisnis menempatkan dunia dalam deskripsi dan melihat apa yang mereka dapatkan.
johnny

1
@ Johnny Saya telah mendengar kisah bisnis yang membutuhkan 7 tahun pengalaman dalam teknologi yang dibuat hanya 5 tahun yang lalu ... ya, itu adalah daftar harapan. Persyaratan tidak sulit.
James Shewey

Terima kasih. Daftar keinginan adalah frasa yang saya cari.
johnny

3

Saya memiliki tantangan yang tepat ketika menerapkan di ASOS. Tujuannya bagi kami adalah memiliki tim yang mandiri dan memiliki peran khusus dapat menjadi anti-pola, namun kami hidup di dunia nyata dan bagi banyak pengembang berpikir tentang praktik DevOps yang baik bukanlah hal utama mereka sehingga mereka membutuhkan bantuan hampir disana.

Apa yang kami lakukan adalah:

  • Kehilangan insinyur DevOps, DevOps adalah sesuatu yang harus kita semua lakukan, bukan jabatan kita sehingga kita menyebutnya sesuatu yang berbeda.

  • meluncurkan mereka ke tim tetapi hanya 1 per 3, ini berarti mereka tidak bisa menjadi pelaku tetapi harus dilihat sebagai kompetensi untuk membantu tim mendapatkan diri mereka lebih baik dan menyelesaikan masalah mereka sendiri (dengan bimbingan)

  • mempertahankan fungsi sentral juga untuk bertindak sebagai pusat kompetensi dan menangani pertimbangan perusahaan, apa pun yang mempengaruhi semua tim

Ketika kami berevolusi, kami meninjau model ini, tetapi bagi kami itu bekerja efektif sejauh ini


3

Saya tidak berpikir Anda akan bisa mendapatkan jawaban yang pasti untuk ini karena sepertinya ada banyak hal di dalamnya.

  • Bagaimana di papan perusahaan dengan praktik DevOps
  • Jenis aplikasi atau layanan apa yang disediakan perusahaan
  • Struktur perusahaan Anda

Saya baru saja selesai melakukan wawancara untuk posisi dan berakhir dengan gelar insinyur DevOps, tetapi beberapa yang saya lakukan adalah pekerjaan Sys Admin. Itu hanya karena kebutuhan karena ukuran perusahaan dan sifat apa yang dikelola aplikasi bijaksana. Beberapa posisi yang saya wawancarai memiliki judul yang sama dan mereka lebih mencari seseorang dari sisi pengembangan hal-hal yang bijaksana. Mereka mengharapkan lebih banyak penulisan kode dan bukan admin sistem yang melakukan otomatisasi. SRE tampaknya menjadi judul yang mulai populer sehingga mungkin menjadi jalan yang harus ditempuh. Saya menjadikan diri saya sebagai Administrator Sistem dan Insinyur Otomasi sebagai pekerjaan terakhir saya karena saya menulis sesuatu yang mungkin dan koki menumpuk sebagian waktu. Perusahaan ini mengikuti model devops yang cukup bagus di mana semua orang di dalamnya dan devs bekerja bersama ops tapi saya pikir masa depan mereka tidak

Sekarang saya berada di posisi ini, saya mencoba untuk melakukan klakson di beberapa otomatisasi dan kami memiliki beberapa masalah orang yang harus diselesaikan. Orang-orang datang dan pergi dan beberapa alur kerja dirancang karena orang lain merancangnya seperti itu dan bukan karena itu cocok dengan cara orang bekerja.

Jadi pada dasarnya saya pikir Anda harus mencari tahu deskripsi pekerjaan dan tidak terlalu khawatir tentang judul kecuali jika terikat untuk membayar entah bagaimana atau Anda pikir satu atau yang lain akan menarik orang-orang yang tepat.


1

Jika Anda peduli dengan arti DevOps, dan mengikuti "satu jalan yang benar". Anda tidak harus menyewa Insinyur DevOps. Anda harus menyewa Insinyur Otomasi, atau insinyur Penerapan, atau Arsitek Platform, atau sejumlah peran lain yang melakukan apa yang Anda butuhkan.

Jika menjadi praktisi DevOps sejati tidak penting bagi Anda, maka Anda dapat menyebutnya apa pun yang Anda inginkan.


1
Harap sedikit memperluas posisi Anda, jawaban ini agak terlalu pendek untuk masalah dalam pertanyaan ini.
Tensibai

1
@Tensibai - Satu-satunya poin saya adalah hanya judul saja. Memanggil seseorang sebagai insinyur DevOps tidak masalah jika Anda tidak benar-benar mengikuti prinsip DevOps
Erik Funkenbusch
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.