Apa perbedaan antara Sysadmin dan DevOps Engineer?

Saat melamar pekerjaan, biasanya Anda dapat menemukan dua jenis pekerjaan serupa: Sysadmin Engineer dan DevOps Engineer .

Keduanya menangani konfigurasi server dan memastikan operasi sistem komputer yang andal. Sulit untuk membedakan keduanya. Apa perbedaan utama di antara mereka?

Terutama DevOps bukan peran (bila digunakan seperti itu lebih banyak kata kunci dari peran nyata).

DevOps kira-kira merupakan pola organisasi yang bertujuan untuk memecahkan silo antara pengembang dan sysadmin.
Tujuan utama adalah untuk membangun tim dengan devs dan sysadmin (bersama dengan penguji biasanya) yang bertanggung jawab untuk suatu produk (aplikasi) dari definisi, keputusan arsitektur hingga pemeliharaan dalam menjalankan produk ini.
Setiap anggota tim akan menjadi bagian dari keputusan pada seluruh siklus hidup produk, seorang pengembang akan melakukan beberapa tugas sysadmin dalam produksi, dan seorang sysadmin akan berpartisipasi dalam fase desain produk untuk menghindari peringatan dari perspektif infrastruktur. sebagai contoh.

Idealnya, sysadmin juga akan menjadi bagian dari tim pengembangan untuk produk, dalam kode sysadmin dunia nyata lebih pada konfigurasi di sekitar produk dan solusi pemantauan, tetapi mampu menyuarakan keprihatinan kepada anggota tim lainnya menghindari banyak kesalahpahaman pada proses penyebaran.

Versi pendek

DevOps kombinasi budaya organisasi, Agile / Lean cara kerja dan otomatisasi perangkat lunak yang ketika diterapkan pada Sistem Administrasi dan Operasi memungkinkan fungsi-fungsi ini untuk beroperasi dengan tingkat Agility yang sama dengan Agile atau Lean Development Tim.

Versi Panjang

Gagasan di balik DevOps keluar dari sistem Administrasi, Operasi dan komunitas Agile, khususnya, Patrick Debois memberikan presentasi di Agile2008 berjudul 'Agile Infrastructure' di mana ia menyoroti perbedaan antara cara tiga fungsi dalam suatu organisasi beroperasi:

1. Agile Development Teams - Agile tim menulis kode.
2. Tim Sistem Administrasi - Membangun infrastruktur untuk menjalankan perangkat lunak.
3. Tim Operasi - Mendukung aplikasi dan infrastruktur di Produksi / Langsung.

Usulan Debois adalah untuk menyatukan tiga cara bekerja bersama, khususnya memindahkan tim Administrasi Sistem dan tim Operasi dari Model Air Terjun ke Model Agile. Untuk itu, Debois menyiapkan DevOpsDays 2009 di Ghent, Belgia tanpa sengaja menciptakan frase DevOps .

Gagasan DevOps selaras dengan seri buku Penulis: VisibleOps: Gene Kim, George Spafford dan Kevin Behr; yang kemudian menulis The Phoenix Project dan The DevOps Handbook . Kedua buku mengeksplorasi bagaimana Agile dan Lean dapat berdampak positif terhadap tim Administrasi dan Operasi Sistem.

Sebagai seorang DevOps Engineer yang berasal dari latar belakang Operasi, Anda akan pindah dari membangun dan menggunakan server dan perangkat lunak secara manual ke skrip instalasi perangkat lunak ke server Anda dengan orang-orang seperti BASH, PowerShell, Python dll. Setelah beberapa saat, Anda akan menyadari betapa skrip keren adalah dan mulailah menjelajahi cara yang lebih canggih untuk mengotomatiskan penerapan .

Pada akhirnya, Anda akan memilih Chef, Puppet, Ansible atau alat manajemen konfigurasi lainnya untuk membantu mengelola keadaan armada sistem Anda. Ketika keterampilan Anda dengan otomatisasi penyebaran aplikasi dan manajemen sistem menjadi matang, bersama dengan alat-alat Anda, Anda baru saja pindah ke ranah ' Infrastruktur sebagai Kode ' dan menggunakannya untuk tidak hanya mengotomatiskan penyebaran perangkat lunak tetapi juga infrastruktur dan lingkungan yang diperlukan untuk menggerakkan perangkat lunak selama pergeseran bisnis ke Cloud.

Sekarang Anda memasak dengan gas. Seiring waktu, Anda telah diperkenalkan tentang manfaat menggunakan perkakas sentris pengembang seperti kontrol sumber untuk mengelola modul, resep, dan templat yang membentuk gudang peralatan penyebaran dan manajemen Anda.

Ketika Anda beralih ke tim DevOps Anda terkena siklus hidup pengembangan perangkat lunak dan konsep integrasi berkelanjutan . Boy pengembang itu merilis perubahan dengan cepat dan untuk mengikutinya Anda menemukan diri Anda bekerja lebih dekat dengan para devs! Anda mengalami urgensi yang ditempatkan pada tim pengembangan untuk mengubah hal-hal ALL-THE-TIME yang bertentangan dengan paradigma operasional lama " jika tidak rusak, jangan memperbaikinya ". Tidak ada lagi membual tentang sistem uptime lagi, Anda menjadi infrastruktur sekali pakai .

Anda memperhatikan bahwa pindah ke DevOps lebih dari bekerja dengan para devs , atau menggunakan alat dan teknik baru , tetapi ada perubahan budaya yang berbeda dalam tim, yang meresap melalui organisasi pada umumnya. Anda bekerja sebagai tim yang saling berhubungan erat dengan tanggung jawab bersama , peralatan bersama , dan tujuan bersama .

Anda mengambil keahlian Anda dalam penerapan otomatis dan memijat mereka ke dalam pipa " CICD " yang diatur oleh " server integrasi berkelanjutan " seperti Jenkins , Bamboo atau Code Pipeline . Sekarang, ketika pengembang mendorong kode baru, skrip, alat, dan templat Anda mendukung lingkungan baru sesuai permintaan, memicu kerangka kerja pengujian untuk melakukan tugas mereka dan meruntuhkan lingkungan pra-produksi setelah lampu hijau menyala pada rilis, mengikuti ide " pengiriman terus menerus ".

Ketika kode baru ini melalui tahapan CICD, Anda, para pengembang dan bisnis mendapatkan kepercayaan bahwa pembaruan tidak akan pecah ketika dirilis ke produksi. Ada beberapa cara yang harus dilakukan sebelum tim mencapai " penyebaran berkelanjutan ", Anda masih perlu menentukan titik-titik yang lebih baik untuk mengotomatiskan kemampuan penerapan biru / hijau , dan keputusannya sebagian besar adalah keputusan bisnis. Untuk saat ini Anda puas bahwa jumlah panggilan jam 3 pagi telah surut dan menyusut sev-1 dan sev-2.

Bahkan jika Anda mendapatkan sev-1, Anda tidak lagi menarik semua malam dengan manajer yang menahan punggung - Anda dapat dengan mudah melepaskan versi sebelumnya melalui pipa CICD dan membuat sistem online lagi dalam waktu singkat. Bisnis telah memperhatikan bahwa stabilitas sistem TI telah meningkat terlepas dari kecepatan perubahan .

Anda kagum dengan cara Anda mengelola sumber daya yang diperlukan untuk mengarahkan perangkat lunak dalam bisnis Anda, terutama ketika Anda mengingat kembali bagaimana dulu dan jumlah darah yang Anda tinggalkan di rel di pusat data ...

Sysadmin vs DevOps (tampilan pribadi)

Beberapa perusahaan berbicara tentang Dev, Ops, dan Test. Jika sesuatu perlu diuji maka mereka berkata: "Tes harus melakukan itu". Jika sesuatu perlu dikembangkan, Dev akan melakukan itu dan jika perangkat lunak perlu digunakan, Ops akan melakukannya.

Menurut pendapat saya dan apa yang saya alami di beberapa perusahaan adalah bahwa ini menghasilkan pola pikir "melemparkannya di atas tembok" yang menghasilkan gesekan antara orang-orang dan tim. Secara pribadi, kadang-kadang saya merasa bahwa orang-orang bekerja secara individual dan mengatakan ini adalah apa yang saya lakukan, saya tidak punya pekerjaan selain bekerja sebagai tim.

Menurut saya, DevOps berarti bahwa setiap orang dalam tim bertanggung jawab dan sibuk dengan pengembangan, pengujian, dan operasi. Tidak ada saya di tim dan tidak ada departemen yang terpisah. Semua orang harus bebas. Tentu saja ada spesialisasi, tetapi menurut saya setiap orang harus dapat melakukan setidaknya 25% dari beberapa pekerjaan di setiap bidang. Misalnya, jika seseorang adalah seorang Pengembang pada hari itu maka seseorang harus dapat mengubah beberapa kode manajemen konfigurasi, misalnya koki dan menggunakan perangkat lunak.

Referensi

Sysadmin

Menurut Wikipedia :

Administrator sistem, atau sysadmin, adalah orang yang bertanggung jawab atas pemeliharaan, konfigurasi, dan pengoperasian sistem komputer yang andal; khususnya komputer multi-pengguna, seperti server.

Administrator sistem berupaya memastikan bahwa waktu aktif, kinerja, sumber daya, dan keamanan komputer yang ia kelola memenuhi kebutuhan pengguna, tanpa melebihi anggaran.

Untuk memenuhi kebutuhan ini, administrator sistem dapat memperoleh, menginstal, atau memutakhirkan komponen dan perangkat lunak komputer; menyediakan otomatisasi rutin; menjaga kebijakan keamanan; memecahkan masalah; melatih atau mengawasi staf; atau menawarkan dukungan teknis untuk proyek.

DevOps

Menurut Wikipedia :

DevOps (senyawa terpotong dari "pengembangan" dan "operasi") adalah proses pengembangan dan pengiriman perangkat lunak yang menekankan komunikasi dan kolaborasi antara manajemen produk, pengembangan perangkat lunak, dan profesional operasi. Ini mendukung ini dengan mengotomatisasi dan memantau proses integrasi perangkat lunak, pengujian, penyebaran, dan perubahan infrastruktur dengan membangun budaya dan lingkungan di mana membangun, menguji, dan merilis perangkat lunak dapat terjadi dengan cepat, sering, dan lebih andal.

DevOps

DevOps Toolchain

Seorang administrator sistem bertanggung jawab untuk memelihara dan mengkonfigurasi server dan tanggung jawab mereka adalah untuk memastikan pengguna dengan kinerja, waktu kerja dan keamanan yang mereka cari. Mendefinisikan peran seorang insinyur DevOps sedikit lebih sulit karena tidak ada jalur karier formal dan DevOps sendiri dapat memiliki banyak bentuk.

Seorang insinyur DevOps dapat, misalnya, seorang pengembang yang tertarik dalam operasi jaringan dan penyebaran atau administrator sistem yang memiliki hasrat untuk pengkodean dan skrip. Transisi dari administrator sistem ke insinyur DevOps tidak terlalu sulit, pada kenyataannya, artikel ini melakukan pekerjaan yang sangat baik untuk menjelaskan prosesnya.

Banyak orang bahkan berpendapat bahwa transisi dari administrator sistem ke insinyur DevOps ini penting karena posisi administrator sistem akan menjadi usang di masa depan. Meskipun ada banyak server lama yang membutuhkan pemeliharaan dan administrator sistem memiliki banyak "pengetahuan suku", posisi sysadmin akan menjadi lebih langka di masa depan.

Akan ada server yang Anda tidak dengar menjalankannya di pusat data. Semuanya akan menjadi perangkat lunak. Penyimpanan, jaringan, sistem, keamanan, pusat data; SDN, firewall, NFV, penyimpanan, server, dll. Sysadmin tanpa latar belakang pengembangan perangkat lunak, pengalaman SDLC (saya bahkan tidak bermaksud membuat skrip Perl, Powershell, dll.) Mungkin akan hilang. Lingkungan terdistribusi, skalabel, dan tervirtualisasi, yang sebagian besar cloud, tumbuh horisontal bukan vertikal.

Saya berani mengatakan Sysadmin tumbuh vertikal, DevOps (atau OpsDev) tumbuh horisontal. Anda dapat melihat pola yang sama bagaimana microservices berevolusi dari monolith. Saya lebih suka memilih insinyur DevOps dari tim perangkat lunak bukan dari tim operasi / sistem.

Karena tim operasi / sistem hanya menjalankan apa yang dibangun oleh tim perangkat lunak.

• Sysadmin tidak membangun / mengkompilasi kernel Linux / FreeBSD / windows dll. Sama seperti insinyur perangkat lunak membangun / mengkompilasi aplikasi.
• Sysadmin tidak melalui siklus hidup pengembangan perangkat lunak (SDLC).
• Sysadmin bukan bagian dari jalur produksi (proses CI / CD).

• Sysadmin mulai bekerja setelah CI / Pengiriman Berkelanjutan / Penempatan berakhir.

  Dan jika Anda melanggar dan menetapkan Penyebaran / Pengiriman, itu bisa menjadi saluran pipa yang rusak
  , tim perangkat lunak adalah sistem pencipta / tim operasi yang kebanyakan pelari / pengasuh.

Kedengarannya seperti tidak ada server / sistem untuk dikelola, tidak perlu sysadmin.

Komputasi tanpa server adalah model eksekusi komputasi awan di mana penyedia cloud bertindak sebagai server, mengelola alokasi sumber daya mesin secara dinamis. Harga didasarkan pada jumlah aktual sumber daya yang dikonsumsi oleh suatu aplikasi, dan bukan pada unit-unit yang sebelumnya dibeli dengan kapasitas komputasi tanpa server

Seseorang dari tim perangkat lunak sudah tahu bagaimana membangun, memelihara bahkan bagaimana kode (SRE vs DevOps / OpsDev).

Saya bertanya-tanya mengapa ini disebut DevOps tetapi bukan OpsDev? apakah itu terkait dengan arah antara keduanya?

* Di tengah-tengah dari mana, saya tidak mulai menulis tentang penyimpanan yang ditentukan perangkat lunak, ini sebagai reaksi terhadap komentar yang sekarang dihapus tentang hal itu *

Tentang penyimpanan yang ditentukan perangkat lunak

• Penyimpanan yang ditentukan perangkat lunak (SDS) adalah istilah pemasaran untuk perangkat lunak penyimpanan data komputer untuk penyediaan berbasis kebijakan dan manajemen penyimpanan data terlepas dari perangkat keras yang mendasarinya. Penyimpanan yang ditentukan perangkat lunak

• EMC mengumumkan produk open source pertamanya: Project CoprHD. CoprHD adalah pengontrol otomatisasi dan manajemen manajemen Penyimpanan yang Ditentukan Perangkat Lunak, dan keputusan EMC baru-baru ini untuk membuka sumbernya adalah inti dari strategi kami untuk memberikan nilai yang lebih besar kepada bisnis global saat kami memasuki bidang pertumbuhan dan perubahan ekstrem. Sebagai pemimpin dunia dalam manajemen penyimpanan dan informasi, EMC harus memimpin untuk memimpin pada Software Defined Storage (SDS) .

• CoprHD adalah pengendali penyimpanan yang ditentukan perangkat lunak sumber terbuka dan platform API. Ini memungkinkan manajemen berbasis kebijakan dan otomatisasi cloud sumber daya penyimpanan untuk penyedia penyimpanan blok, objek, dan file CoprHD