Apa perbedaan antara DevOps dan Automation?


42

Saya melihat bahwa setiap kali seseorang melakukan DevOps, sebagian besar tentang mengotomatisasi hal-hal seperti penyebaran dll.

Tetapi di mana otomasi berakhir dan DevOps dimulai?


Hai @punkpanther jika jawaban ini atau jawaban apa pun telah menyelesaikan pertanyaan Anda, harap pertimbangkan untuk menerimanya dengan mengeklik tanda centang. Ini menunjukkan kepada komunitas yang lebih luas bahwa Anda telah menemukan solusi dan memberikan reputasi kepada penjawab dan diri Anda sendiri. Tidak ada kewajiban untuk melakukan ini. Jika Anda tidak merasa bahwa pertanyaan Anda telah dijawab, jangan ragu untuk terlibat dengan penulis dalam komentar.
Richard Slater

Mungkin pertanyaan yang lebih baik adalah di mana DevOps berakhir dan otomatisasi dimulai? Tidak semua yang dilakukan dengan DevOps adalah tentang otomatisasi; sebagian besar, ya, tetapi tidak semua ... Orang bisa mengatakan DevOps adalah segalanya kecuali otomatisasi - itu adalah sysadmin cultrue, standar arsitektur umum, standar penerbitan umum (katakanlah GitHub) dari bidang teknologi tertentu ... Di mana apakah otomatisasi dalam bidang tertentu itu dimulai adalah pertanyaan yang bagus, saya kira ...
JohnDoea

Jawaban:


45

Sebagian besar DevOps memungkinkan rilis sangat sering. Itu datang dengan pembuatan otomatis, pengujian otomatis, dll. Anda dapat mengatakan bahwa untuk mencapai tujuannya, DevOps perlu menggunakan otomatisasi agar menjadi efisien.

Begini cara DevOps dan otomasi saling berhubungan. DevOps bukan hanya otomatisasi, ada lebih dari itu. Sebaliknya, otomasi tidak secara eksklusif digunakan oleh "orang-orang DevOps". Banyak otomatisasi terjadi di TI sebelum DevOps muncul.

DevOps dalam kaitannya dengan otomatisasi

Tolong jangan mempertimbangkan diagram di atas untuk mewakili semua yang DevOps, atau semua ini adalah otomatisasi. Ini untuk membantu pembaca menggambarkan bagaimana kedua konsep itu terkait.


1
Persis apa yang saya katakan tentang masalah ini :)
Tensibai

Mengapa "tiket workflow" tidak ada di DevOps?
Nakilon

15

Otomasi adalah atribut utama DevOps, tetapi ini bukan cerita lengkapnya. Pertanyaannya adalah seperti "Apa perbedaan antara tinju waktu dan Scrum?".

Anda akan mendengar DevOps disebut 'budaya', 'gerakan', 'metodologi', dan segala macam hal yang tidak akan cukup baik bagi Anda untuk memahaminya, meskipun deskripsi itu akurat. Singkatnya, DevOps adalah tentang pertemuan metodologi Agile, otomatisasi, dan virtualisasi yang memungkinkan loop umpan balik baru dalam manajemen / kontrol / kemudi proyek perangkat lunak.

Dengan otomatisasi yang agresif, hal-hal yang dulu memakan waktu lama dan menjadi subyek kesalahan manusia sekarang terjadi dengan cepat dan tanpa insiden. Akibatnya, kita cenderung melakukannya lebih sering. Contoh utama dari ini adalah 'deploy to production'. Kami dulu menghemat banyak pekerjaan dan menyebarkannya di luar jam kalau-kalau 'ada yang salah'. Tapi sekarang kita bisa menerapkan perubahan beberapa kali sehari, dengan cara peluang 'sesuatu yang salah' berkurang secara dramatis, dan dengan cara itu dampak sesuatu yang salah jauh lebih kecil ketika itu terjadi.

Setelah kami memiliki proses berulang ini, kami mulai melihatnya sebagai 'pipa'. Persyaratan masuk, kode yang digunakan untuk produksi keluar. Kami mengotomatiskan segala sesuatu di sepanjang jalur pipa ini - tes, dokumentasi, penggabungan, penyebaran, dan lebih banyak tes, dan seterusnya ... Karena orang-orang fokus pada otomatisasi, mereka tidak melihat 'mentalitas pipa' yang mendorongnya. Ini adalah metodologi manajemen - perhatian dibayarkan pada pipa - yang membuat DevOps lebih dari Otomasi.

Setelah kami memiliki otomasi itu, loop umpan balik masuk. Kami mulai mengukur hal-hal seperti waktu siklus sehingga kami dapat mengetahui hal-hal yang sebelumnya kami coba tebak dengan perkiraan. Hal-hal tentang arsitektur yang membuat otomatisasi / pengiriman terus-menerus sulit cenderung diganti dengan pola arsitektur alternatif yang membuat otomatisasi / pengiriman terus-menerus lebih mudah (beberapa contoh besar dari ini didokumentasikan dalam buku 'Basis Data Evolusi'. 'Penyebaran Hijau / Biru' adalah hal lain. ).

Perhatikan bahwa saya dapat memberikan deskripsi ini tanpa membicarakan tentang Jenkins, Check, Puppet, Ansible, Vagrant, AWS, atau alat lainnya yang mendukungnya. Inilah yang kami maksud dengan kata kunci tingkat lebih besar seperti 'metodologi'. Pada akhirnya, setiap set alat dapat diganti ... Yang tersisa adalah prinsip manajemen inti yang diaktifkan oleh otomatisasi dan fokus pada pipa.


1
Saya minta maaf, tetapi ini terdengar seperti manifestasi Agile lebih dari informasi budaya devops untuk perasaan saya. Metodologi gesit / iteratif / siklus pendek bahkan jika sering digunakan tidak wajib untuk organisasi devops. Anda dapat memiliki tim devops di proyek air terjun dan Anda dapat mengotomatiskan pengiriman berbasis silo, karena saya merasa jawaban ini menjawab sebagian pertanyaan.
Tensibai

2
@Tensibai Saya harus agak tidak setuju - Anda tidak mengotomatiskan proses yang tidak sering dijalankan. DevOps tanpa Agile seperti mengotomatisasi pembangunan supercar bernilai jutaan dolar.
Dave Swersky

Jawaban ini sangat bertele-tele dan sulit untuk menyaring perbedaan, atau pro / kontra yang berhubungan dengan OP Q.
Evgeny

@Dave Anda kehilangan poin, saya pasti tidak jelas, apa yang saya maksud adalah bahwa budaya devops adalah tentang menghancurkan tim silo, otomatisasi atau siklus pendek tidak berhubungan bahkan jika biasanya, saya tidak melihat poin penting ini dalam jawaban Anda
Tensibai

13

DevOps benar-benar merupakan perubahan budaya - ini dimaksudkan untuk meruntuhkan penghalang tradisional antara operasi dan pengembangan (dan juga dengan QA dan bisnis lainnya!). Idenya adalah bahwa daripada memiliki 'silo' departemen Anda dapat bekerja secara langsung dengan tim lain untuk menyelesaikan sesuatu lebih cepat dan lebih efisien.

Ini semua tentang menghilangkan kendala dan merampingkan proses. Otomasi menjadi sangat berat karena proses berulang yang membantu menghilangkan kendala. Sebagai contoh: jika seseorang dari ops harus melakukan proses rilis manual untuk mendapatkan kode ke lingkungan, ada beberapa hal yang dapat menghalangi - satu adalah bahwa harus ada seseorang di ops yang bebas untuk melakukan penyebaran, dan kedua, ada kurang percaya diri dalam proses rilis karena pekerjaan manual rawan kesalahan.


4

DevOps mencakup otomatisasi tetapi itu hanya sebagian saja. DevOps adalah perubahan budaya untuk memecah silo antara berbagai bagian organisasi untuk memberikan aliran nilai yang lengkap. Memberikan budaya di mana bisnis, pengembangan, jaminan kualitas, infrastruktur, keamanan, ops, dll semuanya bekerja sama untuk memberikan nilai kepada siapa yang pernah menjadi pengguna akhir. DevOps bukan alat, Anda tidak bisa membelinya, Anda harus mengubah budaya Anda.

Otomasi adalah bagian penting dari DevOps karena memungkinkan kecepatan pengiriman dengan kualitas. Otomasi untuk proses penyebaran adalah salah satu bidang yang banyak orang fokuskan terlebih dahulu karena merupakan salah satu cara terbaik untuk mendapatkan nilai dengan cepat dan memberikan pengembalian investasi yang tinggi melalui tidak hanya mengurangi waktu untuk penempatan tetapi juga menstandarisasi proses dan menghapus kesalahan.


1

Saya ingin menambahkan 2 sen:
1) Otomasi :
     Sesuatu yang saat ini harus kita hadapi. Ini telah menjadi lebih dari keharusan di mana cara yang lebih disukai adalah mengotomatisasi potongan, jika tidak seluruh proses. Pendekatan ini memberikan pengguna (pengembang) fleksibilitas untuk menggunakan langkah tetap bersama dengan kemampuan untuk menyesuaikan sesuai kebutuhan.
     Keuntungan dalam pendekatan ini adalah kita dapat mengotomatisasi bagian yang kita inginkan sementara proses individu dapat diikat bersama oleh pengembang. Semakin rinci langkah-langkah otomatisasi, semakin baik kontrol yang mereka miliki.
     Juga, ada banyak alat untuk otomatisasi di ruang seperti otomatisasi robot, otomatisasi SOP (untuk industri servis), otomasi laporan (seperti Splunk), dll.
2) DevOps:
     Mengingat kualitas pengiriman dan ketepatan waktu yang diharapkan dari dunia saat ini, ada kebutuhan untuk memperpanjang otomatisasi proses pengiriman perangkat lunak. Untuk mengaktifkan ini dan memberikan nilai kepada pelanggan dengan cara tercepat yang mungkin, DevOps secara ekstensif bergantung pada alat otomatisasi.
     Keuntungan dalam pendekatan ini adalah bahwa, langkah-langkah individual dapat diotomatisasi untuk menghasilkan konsistensi di seluruh perusahaan sementara keseluruhan orkestrasi dapat dimodifikasi agar sesuai dengan proses yang dibutuhkan oleh proyek tersebut.
     Alat otomasi individu (dengan cara) seperti Chef untuk ditempatkan, Docker melalui Dockerfile, Maven untuk build, dll. Dapat diikat bersama mungkin melalui Jenkins untuk memberikan solusi yang diperlukan sementara pada saat yang sama menurunkan waktu yang diperlukan untuk implementasi atau penggunaan .
Semoga ini membantu menambah nilai apa pun pada proses pemikiran yang mungkin sudah Anda miliki.

Sunting: Lupa untuk menambahkan bahwa saya telah berbicara tentang Proses dan Alat - 2 dari 3 aspek di DevOps. Seperti yang disebutkan oleh yang lain, aspek ke-3 dan sama pentingnya adalah People. Salah satu perbedaan utama yang saya asumsikan antara ini dan otomatisasi adalah bahwa orang lebih rentan untuk menyerap otomasi lebih sering daripada menolak DevOps. Saya merasa bahwa ini disebabkan oleh sifat DevOps itu sendiri, karena otomasi biasanya dikaitkan dengan membuat segalanya menjadi lebih mudah bagi mereka, sementara mereka merasa bahwa DevOps mengubah cara mereka merasa nyaman.


1

Gerakan DevOps terdiri dari empat area utama yang disingkat CAMS :

  1. Budaya
  2. Otomatisasi
  3. Pengukuran
  4. Berbagi

Ini adalah postingan pendefinisian awal dari 2010.

Di setiap bidang ada beberapa alat, proses dan praktik yang secara umum diterima, meskipun subjek tidak didefinisikan dengan baik untuk Praktik Terbaik, dalam banyak kasus ada beberapa Praktik Baik untuk diikuti.

Otomasi dengan sendirinya adalah subjek yang sedikit lebih luas, tetapi dalam konteks DevOps itu hanya sebagian dari apa yang dibahas. Catat bahwa kita memimpin dengan budaya, meskipun banyak praktisi DevOps yang baru di lapangan sering mengabaikannya dengan risiko sendiri dan langsung beralih ke otomatisasi.


-2

Otomasi dan DevOps tidak terkait. DevOps lebih seperti rekayasa gabungan di mana Pengembang situs atau layanan adalah semua Operator situs atau layanan itu. Kenapa novel ini? Dalam pengalaman saya, hal pertama yang dilakukan tim Ops ketika sesuatu yang lebih menarik daripada blip jaringan terjadi adalah memanggil tim Dev. Mengapa mereka melakukan itu? Karena semua yang dilakukan tim Ops adalah memantau dan menyimpan daftar nomor telepon pengembang untuk dihubungi.

Perhatikan saya tidak mengatakan apa pun tentang otomatisasi.

Otomasi adalah pengulangan kesuksesan. Jika saya melakukan langkah a, b dan c dan proses X selalu berhasil, maka langkah a, b dan c adalah kandidat yang baik untuk otomatisasi. Kemudian saya dapat menggunakan waktu untuk apa yang dulunya merupakan proses manual untuk melakukan hal-hal yang membuat saya lebih banyak uang. Otomasi berhasil ketika sederhana. Menyebarkan rilis baru, menjalankan tes integrasi, membuat mur pada baut, mencadangkan data, menyeimbangkan kredit vs debet, dll. Semuanya adalah kandidat yang hebat untuk otomatisasi karena langkah-langkahnya diulangi baik oleh orang atau robot.

Catatan : Apa yang baru adalah bahwa Pengembang juga operator. Tidak ada grup lain. Kerja sama dalam kasus saya jarang terjadi. Jika tidak ada dalam Panduan Pemecahan Masalah (alias TSG) maka Anda dijamin akan menerima panggilan telepon. Dalam pengalaman saya, Ops adalah panggilan pertama dalam hal backhoe. Masalah antara layanan keluar dari ruang kemudi mereka.


Tapi, onething, kerja sama itu selalu ada kan? Komunikasi antara dev dan ops, apakah ini sesuatu yang baru? Apa yang dibawa para devosan baru?
pinkpanther

Apa yang baru adalah bahwa Pengembang juga operator. Tidak ada grup lain. Kerja sama dalam kasus saya jarang terjadi. Jika tidak ada dalam Panduan Pemecahan Masalah (alias TSG) maka Anda dijamin akan menerima panggilan telepon. Dalam pengalaman saya, Ops adalah panggilan pertama dalam hal backhoe. Masalah antara layanan keluar dari ruang kemudi mereka.
Tanpa Pengembalian Uang Tanpa Pengembalian

3
Otomasi dan DevOps "tidak terkait"? Dengan hormat, saya tidak bisa tidak setuju lagi. Integrasi Berkelanjutan, Penyebaran Berkelanjutan, Pengujian Otomatis, dan lainnya merupakan bagian integral dari komponen teknologi DevOps. Tanpa otomatisasi, DevOps hanya budaya. Budaya itu penting, tentu saja, tetapi hanya satu kaki dari bangku DevOps tiga kaki (Budaya, Proses, Teknologi)
Dave Swersky

@NoRefundsNoReturns Devs adalah operater. Dalam arti bahwa tidak ada kebutuhan untuk tim devop?
pinkpanther

Jangan ragu untuk tidak setuju. Kami memiliki banyak otomatisasi ketika kami berdua merupakan tim "pengembang" dan dan "operasi". Itu sebabnya saya katakan mereka tidak berhubungan. Otomasi dapat kurang peduli tentang struktur organisasi Anda. Jika pengembang Anda juga operator, maka kemungkinan besar otomatisasi akan terjadi karena sebagian besar pengembang malas dan cenderung mengotomatiskan tugas yang berulang. Saya bingung dengan respons Anda @pinkpanther
No Refunds No Returns
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.