Berdasarkan perbincangan sembang
Baru-baru ini, pertempuran sebenar telah berlaku mengenai definisi DevOps dan SRE.
Walaupun pada hakikatnya dalam banyak cara perbincangan mengenai topik ini telah membimbangkan saya, termasuk saya, saya memutuskan untuk membawa pandangan saya mengenai topik ini ke mahkamah komuniti Habra. Bagi yang berminat, selamat datang ke kucing. Dan biarkan semuanya bermula baru!
prasejarah
Jadi, pada zaman dahulu, satu pasukan pembangun perisian dan pentadbir pelayan hidup secara berasingan. Yang pertama berjaya menulis kod, yang kedua, menggunakan pelbagai kata-kata mesra dan mesra yang ditujukan kepada yang pertama, menyediakan pelayan, secara berkala datang kepada pembangun dan menerima sebagai tindak balas komprehensif "semuanya berfungsi pada mesin saya." Perniagaan sedang menunggu perisian, semuanya terbiar, ia rosak secara berkala, semua orang gugup. Terutamanya yang membayar semua kekacauan ini. Zaman lampu gemilang. Nah, anda sudah tahu dari mana asalnya DevOps.
Lahirnya amalan DevOps
Kemudian lelaki yang serius datang dan berkata - ini bukan industri, anda tidak boleh bekerja seperti itu. Dan mereka membawa masuk model kitaran hayat. Di sini, sebagai contoh, ialah model V.
Jadi apa yang kita nampak? Perniagaan datang dengan konsep, penyelesaian reka bentuk arkitek, pembangun menulis kod, dan kemudian gagal. Seseorang entah bagaimana menguji produk, seseorang entah bagaimana menyampaikannya kepada pengguna akhir, dan di suatu tempat pada output model ajaib ini duduk seorang pelanggan perniagaan yang kesepian menunggu cuaca yang dijanjikan di tepi laut. Kami sampai pada kesimpulan bahawa kami memerlukan kaedah yang membolehkan kami mewujudkan proses ini. Dan kami memutuskan untuk mencipta amalan yang akan melaksanakannya.
Penyimpangan lirik mengenai subjek apakah itu amalan
Dengan amalan yang saya maksudkan adalah gabungan teknologi dan disiplin. Contohnya ialah amalan menerangkan infrastruktur menggunakan kod terraform. Disiplin ialah cara untuk menerangkan infrastruktur dengan kod, ia berada dalam kepala pembangun, dan teknologi ialah terraform itu sendiri.
Dan mereka memutuskan untuk memanggil mereka amalan DevOps - saya rasa mereka maksudkan daripada Pembangunan kepada Operasi. Kami datang dengan pelbagai perkara yang bijak - amalan CI/CD, amalan berdasarkan prinsip IaC, beribu-ribu daripadanya. Dan seterusnya, pembangun menulis kod, jurutera DevOps mengubah penerangan sistem dalam bentuk kod menjadi sistem yang berfungsi (ya, kod itu, malangnya, hanya penerangan, tetapi bukan penjelmaan sistem), penghantaran diteruskan, dan sebagainya. Pentadbir semalam, setelah menguasai amalan baharu, dengan bangganya melatih semula sebagai jurutera DevOps, dan semuanya bermula dari situ. Dan ada petang, dan ada pagi... maaf, bukan dari sana.
Semuanya tak baik lagi, alhamdulillah
Sebaik sahaja semuanya reda, dan pelbagai "ahli metodologi" yang licik mula menulis buku tebal tentang amalan DevOps, pertikaian secara senyap-senyap timbul tentang siapa jurutera DevOps yang terkenal itu dan bahawa DevOps ialah budaya pengeluaran, rasa tidak puas hati timbul lagi. Tiba-tiba ternyata bahawa penghantaran perisian adalah tugas yang sama sekali tidak remeh. Setiap infrastruktur pembangunan mempunyai timbunan sendiri, di suatu tempat anda perlu memasangnya, di suatu tempat anda perlu menggunakan persekitaran, di sini anda memerlukan Tomcat, di sini anda memerlukan cara yang licik dan rumit untuk melancarkannya - secara umum, kepala anda berdebar-debar. Dan masalahnya, cukup aneh, ternyata terutamanya dalam organisasi proses - fungsi penghantaran ini, seperti halangan, mula menyekat proses. Di samping itu, tiada siapa yang membatalkan Operasi. Ia tidak kelihatan dalam model V, tetapi masih terdapat keseluruhan kitaran hayat di sebelah kanan. Akibatnya, adalah perlu untuk mengekalkan infrastruktur, memantau pemantauan, menyelesaikan insiden, dan juga menangani penghantaran. Itu. duduk dengan satu kaki dalam kedua-dua pembangunan dan operasi - dan tiba-tiba ia ternyata menjadi Pembangunan & Operasi. Dan kemudian terdapat gembar-gembur umum untuk perkhidmatan mikro. Dan dengan mereka, pembangunan dari mesin tempatan mula beralih ke awan - cuba nyahpepijat sesuatu secara tempatan, jika terdapat berpuluh-puluh dan beratus-ratus perkhidmatan mikro, maka penghantaran berterusan menjadi cara untuk bertahan. Untuk "syarikat kecil sederhana" tidak mengapa, tetapi masih? Bagaimana dengan Google?
SRE oleh Google
Google datang, makan kaktus terbesar dan memutuskan - kami tidak memerlukan ini, kami memerlukan kebolehpercayaan. Dan kebolehpercayaan mesti diuruskan. Dan saya memutuskan bahawa kami memerlukan pakar yang akan menguruskan kebolehpercayaan. Saya memanggil mereka jurutera SR dan berkata, itu sahaja untuk anda, lakukan dengan baik seperti biasa. Ini SLI, ini SLO, inilah pemantauan. Dan dia mencucuk hidungnya untuk melakukan pembedahan. Dan dia memanggil "Develop yang boleh dipercayai" SRE. Segala-galanya nampaknya baik-baik saja, tetapi terdapat satu penggodaman kotor yang Google mampu - untuk jawatan jurutera SR, mengupah orang yang merupakan pembangun yang berkelayakan dan juga melakukan sedikit kerja rumah dan memahami fungsi sistem kerja. Lebih-lebih lagi, Google sendiri mempunyai masalah dengan mengupah orang sedemikian - terutamanya kerana di sini ia bersaing dengan dirinya sendiri - adalah perlu untuk menerangkan logik perniagaan kepada seseorang. Penghantaran telah ditugaskan untuk melepaskan jurutera, SR - jurutera menguruskan kebolehpercayaan (sudah tentu, tidak secara langsung, tetapi dengan mempengaruhi infrastruktur, mengubah seni bina, menjejaki perubahan dan penunjuk, menangani insiden). Bagus, boleh . Tetapi bagaimana jika anda bukan Google, tetapi kebolehpercayaan masih menjadi kebimbangan?
Pembangunan idea DevOps
Sejurus kemudian Docker tiba, yang berkembang daripada lxc, dan kemudian pelbagai sistem orkestra seperti Docker Swarm dan Kubernetes, dan jurutera DevOps menghembuskan nafas - penyatuan amalan memudahkan penyampaian. Ia memudahkannya sehingga satu tahap yang memungkinkan untuk menyalurkan penghantaran kepada pembangun - apakah itu deployment.yaml. Kontena menyelesaikan masalah. Dan kematangan sistem CI/CD sudah berada pada tahap menulis satu fail dan kami pergi - pembangun boleh mengendalikannya sendiri. Dan kemudian kita mula bercakap tentang bagaimana kita boleh membuat SRE kita sendiri, dengan... atau sekurang-kurangnya dengan seseorang.
SRE tiada di Google
Baiklah, ok, kami menghantar penghantaran, nampaknya kami boleh menghembus nafas, kembali ke zaman dahulu yang indah, apabila admin melihat pemproses dimuatkan, menala sistem dan secara senyap-senyap menghirup sesuatu yang tidak dapat difahami dari mug dengan tenang dan tenang... Berhenti. Ini bukan sebab kami memulakan segala-galanya (sayangnya!). Tiba-tiba ternyata bahawa dalam pendekatan Google kita boleh menggunakan amalan cemerlang dengan mudah - bukan beban pemproses yang penting, dan bukannya kekerapan kita menukar cakera di sana, atau mengoptimumkan kos dalam awan, tetapi metrik perniagaan adalah sama terkenal. SLx. Dan tiada siapa yang telah mengalih keluar pengurusan infrastruktur daripada mereka, dan mereka perlu menyelesaikan insiden, dan bertugas secara berkala, dan secara amnya sentiasa berada di atas proses perniagaan. Dan kawan-kawan, mulakan pengaturcaraan sedikit demi sedikit pada tahap yang baik, Google sudah menunggu untuk anda.
Untuk Meringkaskan. Tiba-tiba, tetapi anda sudah bosan membaca dan anda tidak sabar untuk meludah dan menulis kepada penulis dalam ulasan pada artikel itu. DevOps sebagai amalan penyampaian sentiasa dan akan berlaku. Dan ia tidak akan ke mana-mana. SRE sebagai satu set amalan operasi menjadikan penyampaian ini berjaya.
Sumber: www.habr.com