Bagaimana seorang Administrator Linux dapat meningkatkan keterampilan shell scripting dan otomatisasi mereka?

Di organisasi saya, saya bekerja dengan sekelompok staf NOC, insinyur muda pemula dan beberapa insinyur senior; semua dengan fokus di Linux. Satu langkah menarik dalam cara perusahaan menumbuhkan talenta adalah bahwa ada jalan dari NOC ke jajaran insinyur senior. Melihat kumpulan bakat sebagai pendatang baru, saya melihat bahwa ada perpecahan dalam rangkaian keterampilan yang cenderung tumbuh dari waktu ke waktu ...

• Ada insinyur yang mengetahui satu atau beberapa teknologi tertentu dengan baik dan terus-menerus terbenam ... misalnya MySQL, firewall, penyimpanan SAN, penyeimbang muatan ...
• Ada orang lain yang generalis dan dapat menavigasi beberapa teknologi.
• Semua cukup belajar Linux (perintah, proses) untuk melakukan apa yang mereka butuhkan dan gunakan setiap hari.

Faktor yang membedakan antara beberapa staf adalah seberapa baik mereka merangkul metodologi manajemen skrip, otomatisasi, dan konfigurasi. Sebagai contoh, kami memiliki dua insinyur yang mengerjakan sebagian besar pekerjaan Amazon AWS CloudFormation , dan yang lainnya menangani sebagian besar infrastruktur Wayang . Mungkin seperempat dari para insinyur mahir dalam skrip shell BASH.

Melihat ini dalam konteks permintaan yang sangat tinggi untuk keterampilan DevOps di pasar kerja , saya ingin tahu bagaimana organisasi lain mendorong pengembangan keterampilan ini dan menumbuhkan bakat internal mereka. Menulis naskah sepertinya bukan konsep yang bisa diajar.

• Bagaimana sysadmin meningkatkan scripting shell mereka?
• Apakah masih ada tempat bagi para insinyur yang tidak / tidak bisa mengikuti paradigma DevOps?
• Apakah kita hanya berasumsi bahwa beberapa orang akan tertinggal ketika teknologi ini berkembang? Apakah itu tidak apa apa?

Saya mendapat manfaat dari memahami ukuran dan kompleksitas lingkungan Anda. Melihat saat Anda bekerja untuk penyedia cloud / hosting, aman untuk berasumsi bahwa Anda memiliki sejumlah besar lingkungan berukuran kecil-menengah (10-100 server). Tentu ada tugas harian yang dilakukan oleh jr. insinyur dan staf NOC yang berulang (membuat akun pengguna, mengkonfigurasi agen cadangan, dll). Demikian pula, mungkin ada beberapa hal manual yang dilakukan oleh sr. insinyur suka menginstal ESXi pada perangkat keras baru atau mengkonfigurasi hal-hal seperti MPIO atau menginstal modul VMware untuk set perangkat keras tertentu. Semua hal ini dapat dan harus otomatis.

Jika staf Anda mampu melakukan sebagian besar beban kerja mereka tanpa mengotomatisasi, maka menurut Anda saya kelebihan pegawai. Setiap staf TI yang dapat bekerja sehari penuh yang sebagian besar terdiri dari proses manual tidak memiliki motivasi untuk mengotomatisasi. Mengapa mempelajari keterampilan baru yang tidak dianggap perlu dan bahkan menakutkan ? Bagaimanapun, kebutuhan adalah ibu jika inovasi.

Jadi, pada titik tertentu di organisasi Anda, Anda akan tumbuh ke ukuran di mana Anda akan menggelepar dan hancur, atau Anda akan mulai mengotomatisasi hampir semua hal dan unggul. Tentu saja, insinyur senior harus memimpin muatan di sini, dan mungkin bahkan bekerja dengan insinyur junior dan staf NOC untuk mengotomatisasi sebagian dari beban kerja mereka. Ini memberi jr. insinyur kesempatan untuk memiliki kerangka kerja banyak skrip untuk bekerja dengan, yang mereka dapat mengubah untuk setiap penyewa dan revisi perangkat keras baru yang diperlukan. Ini menghilangkan pikiran menakutkan dari "Ya Tuhan, di mana saya mulai?" dari persamaan dan memberi mereka awal untuk memecahkan masalah nyata . Yang membawa saya ke titik akhir saya. Buku dan contoh bagus dan bagus, tetapi adamasalah yang mereka hadapi. Beri mereka tujuan, seperti semua server baru untuk tenant x harus memiliki modul ESXi tertentu diinstal, dan kemudian bekerja dengan mereka untuk mencapainya. Kemudian sesuaikan skrip untuk bekerja di lingkungan multitenant.

Bagaimana sysadmin meningkatkan scripting shell mereka?

Dengan perlu , seperti dijelaskan di atas.

Apakah masih ada tempat bagi para insinyur yang tidak / tidak bisa mengikuti paradigma DevOps?

Tentu, ada banyak organisasi yang tidak dapat atau tidak akan beralih ke metodologi DevOps. Mereka tampaknya menjadi pilihan yang semakin membosankan , tetapi mereka tetap pilihan.

Apakah kita hanya berasumsi bahwa beberapa orang akan tertinggal ketika teknologi ini berkembang?

Seperti halnya teknologi baru - ya.

tl; dr Anda tidak akan pernah memiliki orang yang benar-benar berinvestasi dalam mempelajarinya sampai mereka melihat nilainya di dalamnya. Jika mereka dapat menyelesaikan tugas sehari-hari secara manual, maka Anda kelebihan pegawai dan tidak ada insentif.

• Bagaimana sysadmin meningkatkan scripting shell mereka?

Berlatih, dicampur dengan drive. Kedengarannya basi, tetapi Anda harus ingin menjadi lebih baik, selain berlatih. Jika Anda tidak benar-benar menikmati scripting, Anda dapat dipaksa untuk melakukannya selama bertahun-tahun ketika Anda harus dan tidak pernah benar-benar pandai melakukannya. Jika Anda tidak ingin menjadi lebih baik, Anda bisa duduk di sebelah penulis naskah terbaik di dunia setiap hari di tempat kerja dan tidak mengambil bagian dari keterampilan yang bisa Anda miliki.

Saya tahu orang-orang itu, meskipun bekerja di IT, dengan keras kepala menolak untuk belajar segala jenis penulisan naskah. Tidak akan ada lagi tempat bagi orang-orang di industri ini. Mereka adalah bagian dari generasi yang sekarat.

( Saya tidak berbicara tentang orang tua, maksud saya secara kiasan.: P )

• Apakah masih ada tempat bagi para insinyur yang tidak / tidak dapat mengikuti paradigma DevOps?

Nggak. Setiap hal yang mereka lakukan dapat dan pada akhirnya akan otomatis hilang.

Saya berpendapat bahwa mungkin kita seharusnya tidak memanggil mereka 'insinyur'. Sudah cukup buruk bahwa industri TI menggunakan kata 'insinyur' untuk diri kita sendiri, yang menurut saya agak menghina para insinyur aktual yang menghabiskan waktu bertahun-tahun dalam program pendidikan tinggi dan mendapatkan sertifikasi hukum sehingga mereka dapat merancang jembatan, pencakar langit, dan hadron colliders , dll ... mereka adalah insinyur nyata .

Tetapi ada kesamaan ... Jika Anda ingin menyebut diri Anda seorang 'insinyur' di industri TI, maka itu setidaknya berarti Anda menciptakan sesuatu. Anda inventif dan menghubungkan titik-titik dengan cara baru yang tidak pernah dipikirkan sebelumnya. Anda membangun hal-hal yang tidak ada orang lain tahu betapa berharganya itu sampai Anda berhasil.

Jika Anda tidak kode atau skrip, maka tidak ada cara Anda berbuat banyak dengan komputer selain hanya merawatnya, dan mungkin menginstal satu atau dua paket perangkat lunak. Mungkin membuang hard drive baru ke dalam MSA ol '. Dan dalam hal ini, saya akan memanggil Anda seorang administrator, tentu saja, tetapi tidak harus seorang insinyur. Dan saya akan mengatakan banyak pekerjaan Anda dalam bahaya diotomatiskan.

• Apakah kita hanya berasumsi bahwa beberapa orang akan tertinggal ketika teknologi ini berkembang?

Pasar akan beradaptasi. Mungkin beberapa orang tidak akan membuat gaji 6-digit ketika mereka tidak benar-benar layak mendapatkannya, yang terjadi cukup banyak di industri ini.

Saya menemukan bahwa kreativitas, dan bukan hanya keterampilan coding / scripting, adalah faktor kunci. Kreativitas itulah yang perlu Anda katakan pada diri sendiri, " Oh, hei, saya bisa mengotomatisasi ini! " Dan kemudian keterampilan itu baru muncul setelah itu. Jika Anda mendapati diri Anda menulis sesuatu hanya setelah bos Anda memberi tahu Anda, maka Anda mungkin tidak memiliki dorongan itu atau kreativitas yang saya bicarakan ... dan itu adalah dua kualitas yang sangat sulit, mungkin tidak mungkin, untuk diajarkan.

Bagaimana sysadmin meningkatkan scripting shell mereka?

Bagaimana seseorang menjadi lebih baik dalam hal apa pun? Baca buku, hadiri kelas, dan kemudian terapkan asas-asas yang dipelajari. (Atau kombinasi metode.) Ini disederhanakan disengaja karena tidak ada yang istimewa tentang belajar scripting daripada belajar cara memasak atau cara memperbaiki mobil.

Apakah masih ada tempat bagi para insinyur yang tidak / tidak bisa mengikuti paradigma DevOps?

Ini sulit dijawab dalam lingkup situs ini (di mana ada persyaratan untuk jawaban yang jelas / jelas untuk pertanyaan yang diajukan.) Kita dapat memperkirakan bahwa itu akan terjadi, tetapi ada masalah dengan model DevOps. Saya merasa bahwa sangat sulit bagi seseorang untuk menjadi sangat mahir dalam kedua disiplin ilmu tersebut. Penghematan biaya karyawan 2-untuk-1 sangat menarik bagi bisnis saat ini, tetapi sulit untuk mengatakan apakah tren ini akan tetap ada. Tentunya untuk jangka pendek.

Apakah kita hanya berasumsi bahwa beberapa orang akan tertinggal ketika teknologi ini berkembang?

Pada tingkat saat ini bagaimana keadaannya, ya. Sebagian besar dari Anda mungkin mengamatinya di tempat kerja Anda sendiri. Anda pasti harus mengikuti daftar pekerjaan dan tahu apa pasar saat ini menuntut. (Ada banyak daftar pekerjaan untuk Hadoop di daerah Anda? Pelajari Hadoop.) Jika Anda tidak mengikuti pasar, Anda berisiko ketinggalan.

Seseorang umumnya tidak mengirim insinyur yunior ke lingkungan produksi yang kompleks yang sangat penting bagi misi. Anda memiliki insinyur senior untuk itu. Peringkat junior harus diizinkan untuk bekerja di kotak pasir dev / test.

Jika Anda membutuhkan insinyur untuk Teknologi X dan ingin mengisi peran secara internal, cari seseorang yang mau mempelajarinya, temukan pelatihan terstruktur dan gabungkan keduanya.

Cari tahu keterampilan apa yang Anda butuhkan di suatu departemen. Temukan seseorang yang mau mempelajarinya. Ajarkan / Bagikan uang untuk pelatihan.

Apakah masih ada tempat bagi para insinyur yang tidak / tidak bisa mengikuti paradigma DevOps?

"devops" hanyalah kata baru untuk sesuatu yang sysadmin telah lakukan selama beberapa dekade.

Apakah kita hanya berasumsi bahwa beberapa orang akan tertinggal ketika teknologi ini berkembang?

Justru sebaliknya. Seiring berjalannya waktu, semakin banyak kebutuhan akan orang-orang teknis. Siapa pun yang memiliki pengetahuan teknik dan keterampilan teknis apa pun akan memiliki tempat untuk bekerja.