Berdasarkan diskusi obrolan
Baru-baru ini, perselisihan nyata telah berkobar mengenai definisi DevOps dan SRE.
Terlepas dari kenyataan bahwa dalam banyak hal diskusi tentang topik ini telah membuat saya gelisah, termasuk saya, saya memutuskan untuk membawa pandangan saya tentang topik ini ke pengadilan komunitas Habra. Bagi yang berminat, selamat datang di cat. Dan biarkan semuanya dimulai dari awal lagi!
prasejarah
Jadi, pada zaman dahulu, tim pengembang perangkat lunak dan administrator server hidup terpisah. Yang pertama berhasil menulis kode, yang kedua, menggunakan berbagai kata-kata hangat dan penuh kasih sayang yang ditujukan kepada yang pertama, mengatur server, secara berkala datang ke pengembang dan menerima tanggapan yang komprehensif "semuanya berfungsi di mesin saya". Bisnis sedang menunggu perangkat lunaknya, semuanya menganggur, rusak secara berkala, semua orang gugup. Terutama orang yang membayar seluruh kekacauan ini. Era lampu yang megah. Nah, Anda sudah tahu dari mana DevOps berasal.
Lahirnya praktik DevOps
Kemudian orang-orang yang serius datang dan berkata - ini bukan industri, Anda tidak bisa bekerja seperti itu. Dan mereka menghadirkan model siklus hidup. Di sini, misalnya, adalah model V.
Jadi apa yang kita lihat? Sebuah bisnis hadir dengan sebuah konsep, arsitek merancang solusi, pengembang menulis kode, dan kemudian gagal. Seseorang entah bagaimana menguji produknya, seseorang entah bagaimana mengirimkannya ke pengguna akhir, dan di suatu tempat pada keluaran model ajaib ini, duduklah seorang pelanggan bisnis yang kesepian menunggu cuaca yang dijanjikan di tepi laut. Kami sampai pada kesimpulan bahwa kami memerlukan metode yang memungkinkan kami melakukan proses ini. Dan kami memutuskan untuk menciptakan praktik yang dapat menerapkannya.
Penyimpangan liris tentang apa itu praktik
Yang saya maksud dengan praktik adalah kombinasi teknologi dan disiplin. Contohnya adalah praktik mendeskripsikan infrastruktur menggunakan kode terraform. Disiplin adalah bagaimana mendeskripsikan infrastruktur dengan kode, itu ada di kepala pengembang, dan teknologi adalah terraform itu sendiri.
Dan mereka memutuskan untuk menyebutnya praktik DevOps - menurut saya maksudnya dari Pengembangan hingga Operasi. Kami menemukan berbagai hal cerdas - praktik CI/CD, praktik berdasarkan prinsip IaC, ribuan di antaranya. Dan kita berangkat, pengembang menulis kode, insinyur DevOps mengubah deskripsi sistem dalam bentuk kode menjadi sistem yang berfungsi (ya, sayangnya, kode tersebut hanya deskripsi, tetapi bukan perwujudan sistem), pengiriman berlanjut, dan seterusnya. Administrator kemarin, setelah menguasai praktik baru, dengan bangga dilatih kembali sebagai insinyur DevOps, dan semuanya dimulai dari sana. Dan terjadilah petang, dan terjadilah pagi... maaf, bukan dari sana.
Tidak semuanya baik-baik saja lagi, alhamdulillah
Segera setelah semuanya menjadi tenang, dan berbagai “ahli metodologi” yang licik mulai menulis buku tebal tentang praktik DevOps, perselisihan diam-diam berkobar tentang siapa insinyur DevOps yang terkenal itu dan bahwa DevOps adalah budaya produksi, ketidakpuasan muncul lagi. Tiba-tiba ternyata pengiriman perangkat lunak adalah tugas yang tidak sepele. Setiap infrastruktur pengembangan memiliki tumpukannya sendiri, di suatu tempat Anda perlu merakitnya, di suatu tempat Anda perlu menerapkan lingkungan, di sini Anda memerlukan Tomcat, di sini Anda memerlukan cara yang licik dan rumit untuk meluncurkannya - secara umum, kepala Anda berdebar-debar. Dan masalahnya, anehnya, ternyata terutama terletak pada pengorganisasian proses - fungsi pengiriman ini, seperti hambatan, mulai memblokir proses. Selain itu, tidak ada yang membatalkan Operasi. Ini tidak terlihat pada model V, tetapi seluruh siklus hidup masih terlihat di sebelah kanan. Oleh karena itu, perlu dilakukan pemeliharaan infrastruktur, pemantauan, penyelesaian insiden, dan juga penanganan pengiriman. Itu. duduk dengan satu kaki dalam pengembangan dan pengoperasian - dan tiba-tiba berubah menjadi Pengembangan & Operasi. Dan kemudian muncul kehebohan umum mengenai layanan mikro. Dan bersama mereka, pengembangan dari mesin lokal mulai berpindah ke cloud - cobalah untuk men-debug sesuatu secara lokal, jika ada lusinan dan ratusan layanan mikro, maka pengiriman yang konstan menjadi sarana untuk bertahan hidup. Untuk “perusahaan kecil dan sederhana” semuanya baik-baik saja, tapi tetap saja? Dan Google?
SRE oleh Google
Google datang, memakan kaktus terbesar dan memutuskan - kami tidak membutuhkan ini, kami membutuhkan keandalan. Dan keandalan harus dikelola. Dan saya memutuskan bahwa kita membutuhkan spesialis yang akan mengelola keandalan. Saya menelepon mereka insinyur SR dan berkata, itu saja untuk Anda, lakukan dengan baik seperti biasa. Ini SLI, ini SLO, ini monitoringnya. Dan dia ikut serta dalam operasi. Dan dia menyebut SRE-nya sebagai “DevOps yang andal”. Segalanya tampak baik-baik saja, tetapi ada satu peretasan kotor yang mampu dilakukan Google - untuk posisi insinyur SR, pekerjakan orang-orang yang merupakan pengembang yang berkualifikasi dan juga melakukan sedikit pekerjaan rumah serta memahami fungsi sistem kerja. Selain itu, Google sendiri memiliki masalah dalam mempekerjakan orang-orang seperti itu - terutama karena di sini Google bersaing dengan dirinya sendiri - logika bisnis perlu dijelaskan kepada seseorang. Pengiriman ditugaskan untuk melepaskan insinyur, SR - insinyur mengelola keandalan (tentu saja, tidak secara langsung, tetapi dengan mempengaruhi infrastruktur, mengubah arsitektur, melacak perubahan dan indikator, menangani insiden). Bagus, kamu bisa . Namun bagaimana jika Anda bukan Google, namun keandalan masih menjadi perhatian?
Pengembangan ide DevOps
Saat itulah Docker tiba, yang tumbuh dari lxc, dan kemudian berbagai sistem orkestrasi seperti Docker Swarm dan Kubernetes, dan para insinyur DevOps menghembuskan napas - penyatuan praktik menyederhanakan pengiriman. Ini menyederhanakannya sedemikian rupa sehingga pengiriman bahkan dapat dialihdayakan ke pengembang - apa itu deployment.yaml. Kontainerisasi memecahkan masalah ini. Dan kematangan sistem CI/CD sudah berada pada level penulisan satu file dan kita berangkat - pengembang dapat menanganinya sendiri. Dan kemudian kita mulai berbicara tentang bagaimana kita dapat membuat SRE kita sendiri, dengan... atau setidaknya dengan seseorang.
SRE tidak ada di Google
Baiklah, kami mengirimkan pengirimannya, sepertinya kami bisa menghembuskan napas, kembali ke masa lalu yang indah, ketika admin memperhatikan beban prosesor, menyetel sistem dan diam-diam menyesap sesuatu yang tidak dapat dipahami dari mug dengan damai dan tenang... Berhenti. Ini bukan alasan kami memulai semuanya (sayangnya!). Tiba-tiba ternyata dalam pendekatan Google kita dapat dengan mudah mengadopsi praktik terbaik - yang penting bukanlah beban prosesor, dan bukan seberapa sering kita mengganti disk di sana, atau mengoptimalkan biaya di cloud, tetapi metrik bisnisnya juga sama terkenalnya. slx. Dan belum ada yang menghapuskan manajemen infrastruktur dari mereka, dan mereka perlu menyelesaikan insiden, dan bertugas secara berkala, dan secara umum selalu memantau proses bisnis. Dan teman-teman, mulailah pemrograman sedikit demi sedikit pada level yang baik, Google sudah menunggu Anda.
Untuk meringkas. Tiba-tiba, Anda sudah bosan membaca dan tidak sabar untuk meludah dan menulis kepada penulis di komentar artikel. DevOps sebagai praktik pengiriman selalu dan akan selalu ada. Dan itu tidak akan kemana-mana. SRE sebagai serangkaian praktik operasional membuat penyampaian ini berhasil.
Sumber: www.habr.com