Saya baru saja berbicara dengan seorang pria DevOps yang mengangkat beberapa poin yang sangat bagus tentang perjuangan menjadi Insinyur DevOps dan kadang-kadang merasa seperti pasukan satu orang, meskipun ia berada dalam tim 16 Insinyur.

Dia memakai banyak topi yang berbeda, tetapi duduk di tim Pengembangan melakukan pekerjaan infrastruktur. Dia menyukai teknologi keren yang dia dapat kerjakan dengan banyak otomatisasi, cloud, containerisasi dll. Tetapi dia berjuang bahwa dia adalah satu-satunya orang yang melakukannya ops, dalam sebuah devtim. Dia melapor kepada Manajer Pengembangan, tetapi bekerja lebih dekat dengan Manajer Infrastruktur.

Ini tampaknya menjadi masalah dengan banyak profesional DevOps yang saya ajak bicara. Apa yang bisa dilakukan untuk membantu Insinyur DevOps merasa kurang seperti serigala?

Pikiran pertama saya adalah "mengapa dia satu-satunya orang yang melakukan operasi, di tim pengembang, terutama ketika dia bekerja dengan banyak otomatisasi?". Saya pikir ada peluang di sana untuk mengatasi sindrom serigala tunggal; khususnya di lingkungan pengembang, infrastruktur-sebagai-kode menyediakan kerangka kerja yang bagus untuk berbagi beban. Orang-orang Ops harus menjadi ahli dalam menentukan dan mendefinisikan kebutuhan infrastruktur untuk aplikasi, tetapi mereka juga harus dapat membangun platform untuk membiarkan peran dev melakukan sebanyak yang mereka bisa secara mandiri.

Kedengarannya seperti silo di dalam tim; kebiasaan susah hilang. Seorang pengkode mungkin merasa tidak nyaman untuk memutar dan mengeraskan server, tetapi dalam model devops murni, mereka harus memiliki alat untuk melakukannya. Seorang ops person dalam tim devops seharusnya tidak bertanggung jawab untuk memberikan infrastruktur untuk aplikasi itu sendiri, tetapi mereka harus memberikan beberapa wawasan tentang apa yang dibutuhkan dan beberapa panduan tentang bagaimana pengembang aplikasi dapat melakukannya sendiri. Ini hampir merupakan model meta-infrastruktur; insinyur ops membangun infrastruktur yang dapat membangun infrastruktur sesuai permintaan ketika diminta oleh tim pengembangan.

Konsultasi, komunikasi, dan pencampuran tanggung jawab semuanya penting untuk keberhasilan tim devops.

Saya pikir cacat pertama ada dalam kalimat ini:

Dia melapor kepada Manajer Pengembangan, tetapi bekerja lebih dekat dengan Manajer Infrastruktur.

DevOps adalah perubahan budaya yang bertujuan menghilangkan silo. Jika silo tetap, maka insinyur ini adalah apa pun yang Anda ingin sebut namanya; seorang insinyur melakukan pengembangan operasional, seorang ahli otomatisasi, seorang pengembang mengotomatisasi infrastruktur - tetapi insinyur ini bukan seorang insinyur DevOps.
Sebenarnya, "Insinyur DevOps" bukanlah peran nyata , ini lebih merupakan 'chapeau' karena dapat mencakup pengembang, administrator sistem, penguji QA, dan arsitek yang bekerja dalam tim bersama.

Masalah yang sering saya lihat adalah bahwa orang-orang jatuh ke dalam penggunaan kata kunci DevOps, melihatnya sebagai jabatan, tetapi mereka tidak benar-benar mengerti apa itu DevOps. Dengan melihat DevOps dengan cara ini, mereka sering berakhir terisolasi dan merasa sendirian, menyalahkan kegagalan dan kekurangan sebagai "serigala tunggal" tanpa keterlibatan manajerial dan organisasi.

Seperti yang Anda gambarkan, insinyur ini adalah satu-satunya yang melakukan Ops dalam tim Pengembang. Itu tidak membuatnya menjadi "insinyur DevOps". (Apa pun artinya di organisasinya) Dia bekerja dalam isolasi karena pekerjaan itu disajikan sebagai "Insinyur DevOps" tetapi tampaknya orang lain di timnya tidak ingin bekerja pada operasi.

Jujur saja, selalu akan ada ops dan dev, ide utama di balik devops adalah berbagi tanggung jawab sehingga tidak ada serah terima produk dari dev ke ops atau hanya memasok platform dengan ops untuk dev. Tujuan utama adalah membawa lebih banyak kolaborasi ke dalam tim. Menyebut peran ini sebagai "Insinyur DevOps" melanggar ide ini dengan menyarankan Anda dapat melakukan keduanya pada tingkat keahlian yang sama - yang jarang benar.

Hal pertama yang harus dilakukan menurut saya adalah untuk menyajikan alat operasional kepada tim dan memberikan semua orang pengetahuan dasar tentang alat tersebut, kemudian mentransfer tanggung jawab untuk mengkonfigurasi / memberi kode alat operasional kepada seluruh tim. Gagasan utama di balik ini adalah bergerak dari "yang melakukan semua hal ops" ke "yang mendukung dan memberikan referensi implementasi ke tim".

Ini melengkapi jawaban lain dengan memberikan sesuatu yang dapat ditindaklanjuti dengan cara yang lebih sederhana sebagai langkah pertama dari reorganisasi manajemen.

Hal terpenting bagi Insinyur DevOps dalam situasi seperti ini, adalah untuk mendapatkan (a) Komitmen Manajemen dan (b) Anggaran yang Diperlukan . Baca terus untuk detail lebih lanjut tentang keduanya ...

Dapatkan Komitmen Manajemen

Begitu itu terjadi, segalanya menjadi mudah bagi para insinyur DevOps tersebut. Terutama setiap kali perlawanan (dari semua pihak) masuk ke dalam permainan. Percayalah, akan ada perlawanan seperti itu, yang menantang seperti:

• Kenapa kita harus berubah? Saya ingin terus melakukan apa yang telah saya lakukan selama X tahun!
• Saya tidak ingin kehilangan kekuatan (teknis) yang saya miliki, dan menyelesaikan segala macam prosedur alur kerja, untuk mendapatkan perbaikan konyol dalam produksi yang seharusnya membawa saya seperti 5 menit, bukannya 5 jam (atau hari ...).
• ... (Saya bisa menambahkan selusin peluru di sini ...).

Setiap kali tantangan itu muncul, semua insinyur DevOps harus katakan adalah seperti:

Maaf, saya hanya melakukan pekerjaan saya ... berdasarkan instruksi dari manajemen atas.

Dapatkan Anggaran yang Diperlukan

Cara efektif untuk mendapatkan Anggaran yang Dibutuhkan, adalah membuat / menyerahkan kasus bisnis yang sesuai yang menjelaskan manfaat nyata dan tidak berwujud dari berbagai praktik DevOps dengan menerapkannya pada beberapa kasus dunia nyata yang berlaku untuk perusahaan itu sendiri.

Berikut adalah beberapa kasus dunia nyata yang saya alami sendiri, sebagai konsultan SCM yang disewa oleh beberapa perusahaan di mana hal-hal ini terjadi. Saya tahu, SCM hanya bagian dari DevOps, tetapi ini adalah area di mana saya memiliki beberapa keahlian ...

1. Manfaat otomatisasi

Karena beberapa pemogokan hanya dari 2 (!!!) operator komputer (yang tidak mengetik perintah konsol lagi yang mereka ketik untuk mengetik), kereta harus dihentikan di suatu tempat setengah jalan antara 2 pabrik (karena sistem di pabrik di mana kereta menuju ke bawah, data penting tentang penanganan kereta tidak tersedia).

Dengan menerapkan sistem SCM, banyak perintah operator diotomatisasi.

2. Mengurangi biaya lisensi perangkat lunak

Beberapa vendor perangkat lunak telah memutuskan untuk menambah biaya tahunan untuk perangkat lunak SCM (yang sudah ketinggalan zaman), yang tidak disetujui manajemen. Karena itu mereka membuat proyek khusus untuk menggantikannya dengan beberapa perangkat lunak SCM alternatif.

Anggaran proyek sama dengan biaya tahunan yang tidak ingin mereka bayar. Itu termasuk terbang dalam insinyur dari benua lain (seperti saya) untuk membuat proyek ini berhasil.

3. Mengurangi biaya operasi

Beberapa perusahaan asuransi besar menggunakan beberapa perangkat lunak FTP untuk mentransfer perbaikan perangkat lunak ke sekitar 13.000 komputer kelas menengah (AS / 400) di seluruh negeri, dan ini setiap kali perbaikan "a" tersedia. Biaya 1 transfer tersebut adalah sekitar 4 USD (13.000 x 4 = 52.000 USD untuk satu transfer ...). Perangkat lunak ini terdiri dari 120.000 komponen, dikembangkan / dikelola oleh sekitar 150 pengembang. Lakukan perhitungan tentang kemungkinan bahwa 1 pengembang membuat 1 (kecil) kesalahan dalam salah satu dari 120.000 komponen ini, yang membuatnya menjadi produksi, dan membutuhkan perbaikan segera, yang akan menelan biaya lagi $ 52.000 (hanya untuk transfer!).

Dengan menerapkan sistem SCM yang memadai (dengan lingkungan pengujian terkelola, persetujuan, dll), perusahaan ini mencapai pengurangan biaya besar. Pikirkan tentang hal ini, jika sistem SCM dapat mencegah kebutuhan hanya 20 transfer perbaikan darurat, itu menghasilkan pengurangan biaya 52.000 x 20 = 1.040.000 USD (cukup anggaran untuk mengimplementasikan sistem SCM, mereka hanya membutuhkan sebagian kecil dari jumlah itu untuk menyelesaikan pekerjaan).

4. Mengurangi biaya ketidaktersediaan

Jika kasus di atas tidak cukup meyakinkan, maka pikirkan sistem perusahaan kartu kredit utama yang tidak tersedia di seluruh dunia. Saya telah diberitahu bahwa 1 detik tidak tersedianya biaya 1.000.000 USD.

Itu mungkin juga alasan mengapa, untuk waktu yang sangat lama, perusahaan semacam itu memiliki alat DevOps yang canggih, sudah puluhan tahun. Karena setiap detik mereka tidak berada dalam bisnis membuat mereka mahal.

TL; DR: Karena manajemen tingkat atas biasanya berubah-ubah dan rentan terhadap amarah, saya sarankan mencoba sedikit membengkokkan pikirannya untuk mendapatkan perspektif yang berbeda, sambil mengubah keadaan menjadi lebih baik, secara bertahap.

(Saya berasumsi bahwa masalahnya adalah terutama dengan devs enggan , bukan rekan ops lainnya yang tampaknya melakukan operasi klasik terutama.)

IMO, bahkan jika Anda memiliki DevOps, itu tidak berarti bahwa setiap pengembang harus menjadi guru DevOps yang lengkap. Saya merasa agak normal bahwa akan ada satu atau dua ahli nyata dalam kelompok orang tertentu, dan sisanya kurang lebih ikut serta. Selama beban kerjanya tidak terlalu besar untuk orang itu, dan selama dia berhasil merangkum pengetahuannya dalam skrip dll, alih-alih membangun silo sendiri, tidak masalah dengan saya.

Satu hal yang tidak boleh terjadi adalah bahwa orang DevOps melakukan otomasi, dan semua orang berusaha sekuat tenaga untuk menghindari otomatisasi tersebut (yaitu, melewati pipa CI / CD dan melakukan hal-hal secara manual di salah satu lingkungan). Ini, IMO adalah hal utama yang harus dihentikan. Salah satu solusi untuk itu adalah mendorong sangat keras untuk pendekatan ternak-bukan-hewan, yaitu tanpa henti merobohkan VMs atau wadah kiri dan kanan secepat Anda bisa, dan memutar yang baru terus menerus.

Kedua, tentu saja semua orang perlu menyadari apa yang dilakukan oleh otomasi, dan setidaknya secara teori, dengan beberapa penggalian di sekitar, dapat memulai mesin otomatisasi (yaitu, jika semuanya berjalan dari komit / dorongan, maka dev perlu menyadari dan sangat up to date dengan fakta bahwa akan ada hal-hal yang terjadi di latar belakang ketika mereka melakukan). Pipa CI (/ CD) harus cukup terlihat dan harus menjadi hal yang setiap orang selalu sadari (yaitu ketika seorang dev memecahnya).

Ketiga, "satu orang" tentu saja harus berhati-hati bahwa ia tidak melakukan tugas-tugas kasar sehari-hari untuk rekan-rekannya (misalnya, menciptakan Dockerfile setelah Dockerfile untuk artefak mereka ...).

Keempat, solusi yang diciptakan oleh DevOps tentu saja harus benar-benar lebih unggul daripada pendekatan manual di masa lalu dalam beberapa cara yang terukur. Dalam hal itu, mungkin baginya untuk menunjukkan perbaikannya; yaitu, mendemonstrasikan bagaimana hal-hal menjadi lebih mudah untuk semua orang, atau bagaimana tampaknya tidak mungkin untuk memperkenalkan bug pada tahap-tahap selanjutnya dari pipa dll. Jika ini tampaknya tidak mungkin, maka orang DevOps perlu melihat dengan seksama lama apa dia sedang melakukan. Jika mungkin, itu membutuhkan sesi brownbag dan banyak evangelisasi di timnya.

Jelas, dalam lingkungan yang enggan, Anda mungkin tidak akan tiba pada solusi CD yang sepenuhnya otomatis, atau pada pengembangan berbasis trunk dalam waktu dekat. Tetapi saya tidak akan terlalu khawatir tentang dipilih. Dia adalah ahli, dan jika dia melakukan pekerjaannya dengan baik, seluruh tim akan secara bertahap membaik.

Dan akhirnya, jika setelah bertahun-tahun bekerja keras tidak ada peningkatan yang terlihat dengan rekan-rekannya, selalu mungkin untuk mencari jalan lain (baik di dalam atau di luar perusahaan). Memiliki semua pengalaman DevOps di bawah ikat pinggangnya adalah dasar yang sangat baik untuk mencari pekerjaan, hari ini ...

Saya melihat banyak jawaban hebat di sini berbicara tentang DevOps sebagai budaya, saran tentang cara bekerja dengan manajemen, dan membantu mendefinisikan apa yang harus dan tidak dilakukan oleh tim atau insinyur DevOps. Saya pikir masing-masing hebat, dan benar-benar menggambarkan banyak jawaban bisa 100% benar, dan masih sangat berbeda, atau bahkan sangat ambigu, dari satu sama lain ... Itu DevOps!

Jawaban ini hanyalah perspektif unik saya dari pengalaman, dan mungkin bukan indikasi norma atau praktik terbaik ...

Tapi yang dikeluhkan rekan DevOps Anda adalah sifat yang membuat DevOps menantang dan sulit , terutama ketika ditunjuk sebagai peran insinyur DevOps, dan bukan sekadar menjadi pola pikir budaya.

Secara pribadi, saya suka menjadi serigala tunggal, karena saya masih memberikan kontribusi yang berharga, tetapi juga bisa menetapkan batas saya sendiri, sementara membujuk orang lain untuk membantu diri mereka sendiri, dengan demikian membantu saya, menghancurkan silo TI.

Beberapa silo tetap utuh , dan tidak apa-apa, itu adalah misi DevOps untuk mengatasinya dan mencoba untuk membuat silo itu tidak signifikan atau tidak terlihat mungkin.

Mungkin rekan kerja Anda menyadari, atau belum menyadari, bahwa ia tidak suka menjadi insinyur DevOps .

Secara relatif, konsep devops adalah baru dan masih mendefinisikan dirinya menurut saya. Saat ini saya memenuhi peran insinyur devops. Bagi saya, ini berarti saya memfasilitasi dan mengembangkan alat dan proses yang digunakan oleh tim pengembang dan ops kami membebaskan mereka untuk fokus pada produk yang menghasilkan pendapatan bagi perusahaan. Tim operasi dan pengembang memutar server mereka sendiri dan seperti yang diperlukan. Saya hanya menghubungkan CI untuk produk kami, memastikan proses kami masuk akal dan mencari tahu proses apa yang dapat ditingkatkan / otomatis. Saya bertemu dengan semua departemen kami, mulai dari penjualan, gudang, hingga pengembang dan operasi (QA dan manajer rilis) untuk melihat apa yang mereka lakukan dan bagaimana saya dapat meningkatkan proses mereka.

Bagi saya, DevOps berarti pengembangan dan pengoperasian sistem perangkat lunak menjadi tanggung jawab satu tim, bukan tim pengembang dan pengembang yang terpisah. Ini adalah jalan dua arah. Tim terbaik terdiri dari orang-orang " T-Shaped " yang ahli dalam satu bidang dan terbiasa dengan beberapa bidang terkait.

• Anggota tim dengan pengalaman Ops diharapkan untuk melakukan apa yang mereka lakukan terbaik (yaitu Ops), untuk mengajarkan dasar-dasar apa yang mereka lakukan terbaik (yaitu Ops) kepada yang lain, dan untuk belajar dan melakukan pekerjaan di bidang terkait (yaitu tugas Dev).
• Anggota tim dengan pengalaman Dev diharapkan untuk melakukan apa yang mereka lakukan terbaik (yaitu Dev), untuk mengajarkan dasar-dasar apa yang mereka lakukan terbaik (yaitu Dev) kepada yang lain, dan untuk belajar dan melakukan pekerjaan di bidang terkait (yaitu tugas Ops).

Jadi untuk membuat insinyur DevOps merasa kurang seperti serigala tunggal, undang dia untuk mengajari pengembang cara menjalankan sistem, sambil mengakui bahwa ia adalah pakar bagaimana merancang infrastruktur.

Buat dia terlibat dalam arsitektur tingkat tinggi sejak awal, sehingga dia dapat memperkenalkan masalah keahliannya. (Sebelum kami memiliki DevOps, gambar arsitektur kami selalu dipoles pada "hal-hal kecil" seperti load balancers dan server yang berlebihan. Sekarang hal-hal seperti itu adalah bagian dari sketsa pertama.)

Harapkan Devs untuk mengambil beberapa tugas rutin Ops harian, baik untuk membangun redundansi ke dalam tim dan untuk menyebarkan pekerjaan "membanting tulang" secara adil.

Harapkan dia untuk berkontribusi pada upaya Dev jika tidak ada tugas seperti Ops yang harus dilakukan. Beberapa DevOps yang saya tahu tampaknya menemukan pekerjaan basis data sebagai perpanjangan alami dari bidang keahlian mereka, tidak yakin apakah itu dapat digeneralisasi.

Apa yang bisa dilakukan untuk membantu Insinyur DevOps merasa kurang seperti serigala?

Mengutip - apa yang bisa Engineer DevOps melakukan dirinya / dirinya merasa kurang seperti serigala?

Kurangnya budaya dan dukungan manajemen hanya satu bagian dari persamaan. Bagian lain adalah menurut pendapat saya bahwa detail pengetahuan DevOps sering merujuk pada konteks yang kompleks dan penting untuk memiliki saran dan referensi ke contoh-contoh kerja.

Karena itu - jangan merasa seperti serigala; berpartisipasi dalam komunitas DevOps seperti ini di sini atau grup khusus alat dan GitHub - perasaannya paling tidak maka Anda bukan satu-satunya serigala ;-)