Mengapa saya tidak mencoba mempekerjakan seorang 'Insinyur DevOps'?

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?

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.

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.

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

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."

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

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.

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.