Sekali lagi tentang DevOps dan SRE

Berdasarkan diskusi dalam obrolan Komunitas AWS Minsk

Baru-baru ini, pertempuran nyata telah mengamuk untuk definisi DevOps dan SRE.
Terlepas dari kenyataan bahwa dalam banyak hal, diskusi tentang topik ini telah selesai, termasuk saya, saya memutuskan untuk membawa ke pengadilan komunitas habr dan pendapat saya tentang topik ini. Bagi yang berminat, selamat datang ke kucing. Dan biarkan semuanya dimulai lagi!

Latar belakang

Jadi, di zaman kuno, tim pengembang perangkat lunak dan administrator server terpisah hidup terpisah. Yang pertama berhasil menulis kode, yang terakhir, menggunakan berbagai kata-kata hangat, penuh kasih sayang yang ditujukan kepada yang pertama, mengatur server, secara berkala mendatangi para pengembang dan menerima balasan yang lengkap "semuanya bekerja pada mesin saya". Bisnis sedang menunggu perangkat lunak, semuanya diam, bangkrut secara berkala, semua orang gugup. Terutama orang yang membayar kekacauan ini. Era lampu yang mulia. Ya, Anda sudah tahu dari mana kaki DevOps tumbuh.

Praktek Kelahiran DevOps

Kemudian paman yang serius datang dan berkata bahwa ini bukan industri, tidak mungkin bekerja seperti itu. Dan menyeret model siklus hidup. Misalnya, model-V.


Jadi apa yang kita lihat? Bisnis hadir dengan konsep, solusi desain arsitek, pengembang menulis kode, lalu kegagalan. Seseorang sedang menguji produk entah bagaimana, seseorang mengirimkannya kepada pengguna akhir, entah bagaimana, dan di suatu tempat di output model keajaiban ini ada pelanggan bisnis yang kesepian menunggu cuaca yang dijanjikan oleh laut. Kami sampai pada kesimpulan bahwa kami membutuhkan metode yang memungkinkan proses ini ditetapkan. Dan mereka memutuskan untuk membuat praktik yang akan mengimplementasikannya.


Dan mereka memutuskan untuk menyebut mereka praktik DevOps - saya pikir maksud mereka dari Pengembangan hingga Operasi. Kami datang dengan hal-hal rumit yang berbeda - praktik CI / CD, praktik berdasarkan prinsip IaC, ribuan di antaranya. Dan itu dimulai, pengembang menulis kode, insinyur DevOps mengubah deskripsi sistem dalam bentuk kode menjadi sistem kerja (ya, kode tersebut, sayangnya, hanya deskripsi, tetapi bukan perwujudan sistem), pengiriman berputar, dan sebagainya dan seterusnya. Administrator kemarin, setelah menguasai praktik-praktik baru, dengan bangga dilatih kembali sebagai insinyur DevOps, dan semuanya dimulai. Jadilah petang dan jadilah pagi ... maaf, bukan dari sana.

Semua itu lagi bukan terima kasih Tuhan

Segera setelah semuanya tenang, dan berbagai "ahli metodologi" yang cerdik mulai menulis buku-buku tebal tentang praktik-praktik DevOps, perselisihan pecah dengan tenang, yang merupakan insinyur DevOps yang terkenal jahat dan bahwa DevOps adalah budaya produksi, ketidakpuasan telah matang kembali. Tiba-tiba, pengiriman perangkat lunak adalah tugas yang sama sekali tidak sepele. Setiap infrastruktur pengembangan memiliki tumpukannya sendiri, Anda perlu mengumpulkannya di suatu tempat, Anda perlu menyebarkan lingkungan di suatu tempat, di sini Anda perlu kucing jantan, Anda masih memerlukan cara yang rumit untuk memulainya - secara umum, kepalanya retak. Dan masalah lain, anehnya, ternyata terutama dalam organisasi proses - fungsi pengiriman ini, seperti hambatan, mulai menghalangi proses. Selain itu, operasi (Operasi) belum dibatalkan. Itu tidak terlihat dalam model-V, dan ada seluruh siklus hidup di sebelah kanan. Akibatnya, perlu untuk mendukung infrastruktur, dan melihat pemantauan, dan menyelesaikan insiden, dan bahkan menangani pengiriman. Yaitu untuk duduk dengan satu kaki baik dalam pengembangan dan dalam operasi - dan tiba-tiba Pembangunan & Operasi tersebut ternyata. Dan kemudian ada hype besar untuk layanan microser. Dan bersama mereka, pengembangan dari mesin-mesin lokal mulai pindah ke Cloud - cobalah untuk men-debug sesuatu secara lokal, jika ada puluhan dan ratusan layanan microser, di sini pengiriman yang konstan menjadi sarana bertahan hidup. Untuk "perusahaan kecil sederhana" itu masih tidak peduli di mana, tapi tetap saja? Bagaimana dengan Google?

Google SRE

Google datang, makan kaktus terbesar dan memutuskan - kami tidak membutuhkan ini, kami membutuhkan keandalan. Dan keandalan harus dikelola. Dan saya memutuskan - kami membutuhkan spesialis yang akan mengelola keandalan. Dia memanggil mereka insinyur-SR dan berkata, ini dia, lakukan seperti biasa, yah. Di sini Anda memiliki SLI, di sini Anda memiliki SLO, di sini Anda memiliki pemantauan. Dan menusuk hidungnya dalam operasi. Dan memanggilnya "DevOps andal" SRE. Segalanya tampak baik-baik saja, tetapi ada satu hack kotor yang mampu dilakukan Google - untuk merekrut orang-orang yang memiliki keterampilan pengembang dan sedikit lebih banyak menjahit di rumah, yang tahu fungsi sistem kerja, sebagai insinyur SR. Selain itu, mempekerjakan orang seperti itu dan Google sendiri memiliki masalah - terutama karena di sini ia bersaing dengan dirinya sendiri - perlu untuk menjelaskan logika bisnis kepada seseorang. Pengiriman digantung oleh insinyur rilis, SR - insinyur mengelola keandalan (tentu saja, tidak secara langsung, tetapi mempengaruhi infrastruktur, mengubah arsitektur, melacak perubahan dan indikator, berurusan dengan insiden). Bagus, kamu bisa menulis buku . Tetapi bagaimana jika Anda bukan Google, tetapi keandalan masih mengkhawatirkan entah bagaimana?

Mengembangkan Ide DevOps

Tepat pada waktunya bagi Docker, yang tumbuh dari lxc, dan kemudian berbagai sistem orkestrasi seperti Docker Swarm dan Kubernetes, dan para insinyur DevOps mengembuskan napas - penyatuan praktik menyederhanakan pengiriman. Disederhanakan sedemikian rupa sehingga menjadi mungkin untuk bahkan memberikan pengiriman kepada pengembang - penyebaran itu. Yaml ada di sana. Kontainerisasi memecahkan masalah. Dan kematangan sistem CI / CD sudah ditulis pada tingkat satu file dan semuanya dimulai - pengembang akan melakukannya sendiri. Dan kemudian kita mulai berbicara bagaimana kita bisa membuat SRE kita, dengan ... ya, setidaknya dengan seseorang.

SRE bukan di Google

Baiklah, ok, kami mengirim pengiriman, kami sepertinya bisa bernafas lega, kembali ke masa lalu yang indah, ketika admin melihat prosesor memuat, mengatur sistem dan dengan tenang menyesap sesuatu yang tidak dapat dipahami dari mug dengan tenang dan tenang ... Berhenti. Kami tidak melakukan apa pun untuk ini (maaf!). Tiba-tiba ternyata dalam pendekatan Google kami dapat melakukan praktik yang sangat baik - bukan beban prosesor yang penting, dan bukan seberapa sering kami mengganti drive di sana atau di cloud kami mengoptimalkan biaya, dan metrik bisnis adalah SLx yang terkenal jahat. Dan tidak ada yang melepas manajemen infrastruktur dari mereka, dan perlu untuk menyelesaikan insiden, dan bertugas secara berkala, dan secara umum berada dalam subjek proses bisnis. Dan teman-teman, mulailah memprogram sedikit pada tingkat yang baik, Google telah menunggu Anda.

Singkatnya. Tiba-tiba, tetapi Anda sudah bosan membaca dan Anda ingin meludah menulis kepada penulis dalam komentar pada artikel. DevOps sebagai praktik pengiriman, telah dan akan terjadi. Dan itu tidak ke mana-mana. SRE sebagai seperangkat praktik operasi membuat pengiriman ini berhasil.