DevOps Bukan Kaedah atau Alat, itu Budaya



DevOps adalah amalan operasi dan jurutera pembangunan yang turut serta dalam keseluruhan kitaran hayat perkhidmatan, dari reka bentuk hingga proses pembangunan hingga sokongan pengeluaran. Membawa ketangkasan dalam sistem boleh dianggap sebagai budaya DevOps.

Budaya sering diabaikan dan disalahpahami, namun ia adalah faktor utama yang bertanggungjawab terhadap prestasi syarikat. Sekiranya kita tidak menguruskan budaya kita, kita akhirnya akan melakukan amalan yang salah yang akhirnya akan mempengaruhi matlamat perniagaan kita.

Memahami budaya organisasi semasa

Budaya memberitahu kita tentang nilai dan norma dalam kumpulan atau syarikat. Ini mengenal pasti apa yang penting serta bagaimana orang mendekati dan bekerja antara satu sama lain.





BUDAYA = 'Bagaimana sesuatu dapat dilakukan dengan bijak untuk berjaya'

Mari kita ambil contoh pasukan sokongan pelanggan. Budaya pasukan itu harus sedemikian rupa sehingga akhirnya mereka mencapai 97-98% kepuasan pelanggan.



Mengingat kesenangan pelanggan, pertama-tama mereka harus bersikap sopan, bahkan dalam situasi sukar mereka harus menjadi pendengar yang baik untuk mengelakkan kekeliruan mereka perlu mengutamakan pekerjaan mengikut keperluan.

Mari berhenti sebentar dan tanyakan beberapa soalan kepada diri kita sendiri:

  • Apakah budaya syarikat saya sekarang?
  • Sejauh mana budaya ini sesuai dengan matlamat perniagaan saya atau KRA?
  • Masalah apa yang boleh saya jangkakan kerana ketidakseimbangan?

Untuk setiap organisasi, 4C memainkan peranan penting



4C organisasi

soalan temu bual loader kelas java

Sekarang, mari kita lihat budaya organisasi pengembangan perisian. Terdapat banyak pasukan yang terlibat untuk membina dan menyelenggara satu unit perisian. Semua pasukan ini mempunyai tujuan dan budaya yang terpisah.

Proses ini bermula setelah syarat disahkan oleh pelanggan.

Pembangun mengikuti garis panduan pengekodan yang ditentukan oleh organisasi mereka dan alat pengaturcaraan seperti penyusun, jurubahasa, debuger dll digunakan untuk menghasilkan kod tersebut. Bahasa pengaturcaraan peringkat tinggi yang berbeza seperti C, C ++, Pascal, Java, dan PHP digunakan untuk pengekodan.

Mereka membahagikan paket lengkap ke dalam folder kecil dan kemudian mengembangkan kod kecil dengan sewajarnya.

Tahap 1 : Unit kod kecil ini kemudian digumpal untuk membentuk unit besar. Semasa mengintegrasikan cip yang lebih kecil, pengujian peringkat projek harus dilakukan yang dikenali sebagai pengujian integrasi.

Tahap 2 : Setelah integrasi berjaya, ia disebarkan ke dalam sistem dummy. Sistem dummy ini mempunyai konfigurasi yang serupa dengan mesin pelanggan atau mesin di mana projek ini akhirnya mesti digunakan.

Tahap 3 : Akhirnya, setelah menguji semua ciri dalam sistem dummy, projek ini disebarkan ke pelayan pengeluaran atau mesin pelanggan.

Walaupun proses ini nampaknya sangat lancar dan mudah dengan kata-kata, dari segi teknikal sangat sukar untuk dicapai.

Mari kita lihat apa masalah yang mungkin kita hadapi:

Tahap 1 :

Pelanggan sentiasa mencari perubahan untuk meningkatkan kualiti produk. Sebilangan besar masa ketika lelaran pertama dilakukan, pelanggan akan mencadangkan beberapa perubahan. Apabila pembangun menerima perubahan, mereka mula memasukkannya yang mempengaruhi integrasi yang membawa kepada binaan yang rosak.

Tahap 2:

Sebilangan besar masa, penguji atau orang operasi lain tidak akan mengetahui perubahan baru yang akan dibuat. Sebaik sahaja mereka mendapat kod dari pembangun, mereka mula mengujinya. Semasa di bahagian belakang, pemaju masih membuat perubahan.

Oleh kerana mereka tidak mendapat cukup waktu untuk melaksanakan perubahan baru, mereka akhirnya mengembangkan kod yang tidak cekap sehingga mereka menghadapi masalah rangkaian dan pangkalan data lain yang sekali lagi menunda waktu penghantarannya.

Apabila mereka akhirnya memberikan kod tersebut kepada pasukan operasi, mereka akan mempunyai waktu yang sangat minimum untuk membuat dan melaksanakan kes ujian baru. Oleh itu, mereka melangkau banyak kes ujian yang mereka sedar kemudian bahawa itu adalah keutamaan tinggi.

Tahap 3:

cara mengatur jalan java

Walaupun secara langsung bangunannya sudah siap untuk siap, tetapi hasilnya sama sekali tidak dijangka. Pembinaan gagal dan sejumlah bug berlaku.

Kemudian untuk setiap bug yang terjadi, mereka harus mengesan mengapa hal itu terjadi, di mana ia terjadi, perubahan apa yang perlu dilakukan untuk mengatasinya, akan ada perubahan pada kod orang lain untuk menjadikannya serasi dengan yang sebelumnya. Akhirnya, untuk semua pepijat ini, laporan pepijat harus dihasilkan.

Kegagalan itu disebabkan oleh kesalahan sistem kerana ketidaktahuan pembangun pangkalan data dalam kecekapan kod, ketidaktahuan penguji dalam jumlah kes ujian, dll.

Oleh kerana pelanggan selalu membuat tarikh akhir yang ketat, pekerja yang terlibat dalam mencapainya hanya menumpukan perhatian pada pelepasan akhir walaupun mereka harus menjejaskan kualiti keseluruhan.

Walaupun ini nampaknya menjadi masalah dalam penyelarasan kerja, ini sebenarnya adalah kegagalan budaya yang diamalkan.

Ini berlaku kerana banyak bergantung pada proses manual. Berlari ke sana ke mari dalam pasukan yang sama kerana kurangnya pengetahuan tentang bidang yang berbeza kekurangan akses atau mungkin kekurangan minat meningkatkan beban dan keperitan kita sendiri.

Sudah tiba masanya kita perlu serba boleh. Mungkin sukar untuk menguasai semua proses yang terlibat dalam sistem, tetapi kita boleh menjadi penyangga semua, menguasai salah satu di antaranya. Hanya dengan itu kita dapat mengotomatisasi sistem kita atau menjadikannya cukup cerdas untuk pulih dan bukannya mundur.

Sekarang, anda mungkin berfikir mengapa?

Ini kerana, yang anda kuasai sangat bergantung pada orang lain. Oleh itu, untuk mengetahui mengenai titik kebergantungan, kita perlu memahami keseluruhan sistem.

Oleh itu, mari kita fikirkan proses untuk mengubah budaya. Sebelum itu adakah anda mempunyai jawapan untuk soalan di bawah?

  • Di manakah budaya semasa anda gagal?
  • Mengapa anda mahu mengubah prosesnya?
  • Adakah anda telah mengenal pasti semua perubahan yang diperlukan?
  • Adakah anda mendapat maklum balas dan pembelian dari semua pemegang saham yang terlibat?
  • Adakah anda mengesahkan semula disiplin proses, data dan sistem pengukuran untuk perubahan tersebut?

Jadi, sekarang apabila kita mempunyai jawapan untuk semua, kita memikirkan revolusi ke dalam sistem kita. Bagaimana revolusi ini akan berlaku? Ia hanya dapat dicapai apabila kita membunuh diri kita sekarang. Banyak masa terbuang dalam penghijrahan kod di antara pasukan. Kita harus membawa proses di mana kita dapat melakukan integrasi dan penyebaran berterusan.

Proses integrasi dan penyebaran berterusan menjadikannya lebih tangkas. Membawa ketangkasan ini dianggap sebagai budaya DevOps.

DevOps adalah amalan operasi dan jurutera pembangunan yang turut serta dalam keseluruhan kitaran hayat perkhidmatan, dari reka bentuk hingga proses pembangunan hingga sokongan pengeluaran.

Tidak mudah mengubah sistem kerja dari masa ke masa. Melakukan peralihan yang berjaya adalah mengubahsuai sistem, bukannya membina semula.

Sekarang mari kita lihat bagaimana kita dapat mencapainya. Terdapat dua cara untuk mendekati.

1) Atas ke bawah

2) Bawah ke atas

Selami teknik ini dengan lebih mendalam, kita akan menyedari yang paling sesuai untuk organisasi kita.

Dalam pendekatan atas ke bawah, kita dapat pergi ke pihak pengurusan yang lebih tinggi dan meminta mereka membuat perubahan di semua pasukan. Sekiranya pihak pengurusan yakin, kita boleh mula mengusahakannya.

Tetapi kebarangkalian untuk mendapatkan jawapan sebagai “TIDAK” cukup tinggi. Ini kerana mengubah sistem dapat menyebabkan organisasi menjadi tidak stabil.

Mereka mesti melihat struktur organisasi, pendapatan, tahap minat pelanggan, dan lain-lain. Tetapi faktor terpenting yang menarik mereka kembali daripada keluar dari sistem lama ialah mereka tidak dapat melihat gambaran besar tentang apa yang dapat dicapai dan betapa lancarnya ia dapat dicapai dengan yang baru.

Dalam kes ini, kita dapat mencari pendekatan kedua untuk mendapatkan gambaran besar ini.

Pendekatan bawah ke atas memerlukan sukarelawan. Di sini kita harus mengambil pasukan kecil dan tugas kecil dan melaksanakannya dalam Model DevOps.

Melihat dari sisi teknikal model ini, kami mempunyai pelbagai set alat canggih yang menjadikan kerja lebih efisien dan pantas. Tetapi, alat sahaja tidak cukup mampu untuk mewujudkan persekitaran kolaboratif yang disebut sebagai DevOps.

Membuat persekitaran seperti itu memerlukan anda berfikir di luar kotak mis. menilai dan menyusun semula bagaimana orang berfikir tentang pasukan mereka, perniagaan dan pelanggannya.

Menyusun sekumpulan alat baru lebih mudah daripada mengubah budaya organisasi. Dengan mempromosikan pembangun induk anti-sosial, membiarkan kod yang tidak cekap disatukan, menggunakan kod yang tidak diuji dengan betul, saling menyalahkan, menganggap pasukan operasi bodoh bukanlah amalan terbaik yang kita ikuti untuk membolehkan perniagaan dan mencipta nilai untuk pelanggan kami.

menggabungkan pelaksanaan semacam c ++

Ini bukan alat, orang yang menggunakannya menjadikan prosesnya rumit. Untuk mengatakan pada tahap abstrak daripada mengumpulkan idea dan tingkah laku, bersikap terbuka kepada mereka membawa kita ke jalan yang cerah.

Mari kita mulakan dengan pasukan yang terdiri daripada 6 ahli dan cerita 3 mata. Pertama, kita mesti memecahkan pasukan yang kita panggil sebagai pembangun, operasi, penguji, dan lain-lain. Kita menganggap semuanya sebagai satu, katakan 'DevOps'. Apabila kita menerima syarat, kita perlu menganalisis zon risiko. Mengingat bahagian laut & neraka yang lebih dalam .. Kami mula belayar.

Sekarang, anda mesti memikirkan 'apakah faktor-x dari integrasi berterusan dan penyebaran berterusan yang mengurangkan kemungkinan kegagalan'.

Dengan visi dan proses yang lebih baik, kita dapat mendekati pihak manajemen dengan memberikan gambaran yang jelas mengenai hasilnya seperti bagaimana kelancaran prosesnya, bagaimana risiko kegagalan dikurangkan, bagaimana tugas diselesaikan sebelum garis waktu, dll.

Sekarang, kita dapat menggambarkan dengan jelas bagaimana keseluruhan proses dioptimumkan di landasan teknikal dan budaya dengan melakukan retrospeksi setelah setiap lelaran.

Edureka telah memilih khas yang membantu anda menguasai konsep di sekitar Puppet, Jenkins, Ansible, SaltStack, Chef antara lain.

Ada soalan untuk kami? Sebutkannya di bahagian komen dan kami akan menghubungi anda.

Catatan berkaitan: