DevOps, SRE, jurutera platform, penjelasan peranan awan

Ringkasan artikel Apabila konsep DevOps berkembang, terdapat peningkatan kesamaran di sekitar tanggungjawab peranan yang berkaitan seperti DevOps, Jurutera Kebolehpercayaan Tapak (SRE), Jurutera Awan dan Jurutera Platform. Walaupun peranan ini bertindih, mereka mempunyai perbezaan yang ketara dalam fokus dan kemahiran. DevOps menekankan kerjasama antara pembangunan dan pasukan operasi, manakala SRE menggunakan amalan kejuruteraan perisian pada operasi, memfokuskan pada kebolehpercayaan sistem. Jurutera awan memberi tumpuan kepada pengurusan infrastruktur awan, manakala jurutera platform mencipta platform pembangun dalaman untuk menyediakan keupayaan operasi layan diri untuk pembangun. Spesifikasi peranan masih tidak jelas disebabkan oleh kepelbagaian dalam amalan DevOps dan rintangan organisasi. Oleh itu, adalah penting untuk menjadi jelas tentang jangkaan peranan dan konteks organisasi semasa merekrut. Memastikan semua keperluan operasi dipenuhi adalah penting untuk menyokong pembangun dan merealisasikan potensi penuh DevOps.

Seperti yang difikirkan pada asalnya, DevOps lebih kepada falsafah daripada satu set amalan, dan ia pastinya bukan tajuk pekerjaan atau spesifikasi peranan. Namun hari ini, Jurutera DevOps, Jurutera Kebolehpercayaan Tapak, Jurutera Awan dan Jurutera Platform semuanya mendapat permintaan tinggi—kemahiran mereka bertindih dan perekrut menaburkan kata kunci yang berkaitan secara longgar seperti “ Talian Paip CI/CD, Kejuruteraan Penerapan, Konfigurasi Awan dan Kubernetes

Apabila Saya mengasaskan Kubiya.ai, pelabur saya mendorong saya untuk menentukan pasaran sasaran saya dengan lebih baik, contohnya, adakah ia hanya DevOps, Jurutera Awan dan Platform, dan pengguna akhir yang lain? minat daripada pencari kerja dan perekrut dalam menentukan peranan ini Dari siaran Reddit ke webinar, ini adalah topik yang hangat diperkatakan

Dalam artikel ini, saya membentangkan pemikiran saya, tetapi juga menyedari bahawa terdapat banyak ruang untuk tafsiran Topik pembakar untuk ramai orang - jadi dengan risiko memulakan kebakaran, mari teruskan

Pertama, ringkasan ringkas peranan berbeza ini

Pandangan peringkat tinggi peranan DevOps, SRE, Cloud dan Platform

.

Peranan DevOps adalah mengenai kerja berpasukan dan menggunakan alatan untuk bekerja dengan lebih bijak , bukan lebih sukar Ia membawa pembangun dan operasi bersama-sama untuk mempercepatkan keluaran, meningkatkan kestabilan sistem dan memastikan semua orang berada di halaman yang sama

SRE sistem boleh dipercayai dan berskala. Mereka seperti jurutera yang memastikan semuanya berjalan lancar di belakang tabir, bekerja rapat dengan pembangun untuk mengautomasikan proses dan bertindak balas dengan cepat kepada sebarang isu

Peranan jurutera awan adalah seperti arkitek awan. Mereka menumpukan pada menyediakan dan mengurus infrastruktur awan, memastikan ia cekap, selamat dan menjimatkan kos. Mereka menggunakan alat seperti AWS atau Azure untuk mencipta persekitaran di mana aplikasi boleh berkembang maju

Peranan seorang jurutera platform platform mesra pembangun. Mereka mereka bentuk dan menyelenggara sistem yang membolehkan pembangun mengurus aplikasi mereka dengan mudah, daripada menyediakan aliran kerja hingga memantau prestasi, semuanya untuk manfaat semua orang yang terlibat

Evolusi DevOps dan Norma Kerja Baharu

Amalan DevOps berkembang pada tahun 2000-an untuk memenuhi keperluan untuk meningkatkan kelajuan keluaran dan mengurangkan masa ke pasaran sambil mengekalkan kestabilan sistem Selain itu, seni bina berorientasikan perkhidmatan membolehkan pasukan pembangunan yang berasingan bekerja secara bebas pada perkhidmatan dan aplikasi individu, membolehkan prototaip dan lelaran berbanding sebelum ini Pasukan pembangunan menumpukan pada keluaran perisian dan pasukan operasi unik yang berasingan memfokuskan pada kestabilan dan keselamatan sistem Ini menghalang kepantasan yang diidamkan oleh banyak perniagaan, dan pembangun tidak selalu dapat mencegah masalah prestasi sebelum ia timbul. pada asalnya dibayangkan, DevOps lebih kepada falsafah daripada satu set amalan preskriptif—sehingga tidak ada kata sepakat tentang kuantiti dan sifat amalan tersebut. Sesetengah orang memetik "empat tiang DevOps," ada yang memetik "lima tiang," dan ada yang memetik enam, tujuh, lapan atau sembilan tiang. awak boleh pilih.

Organisasi yang berbeza melaksanakan DevOps dengan cara yang berbeza (banyak yang tidak sama sekali). Di sini kita boleh menjangkakan dilema norma kerja yang kita hadapi. Seperti yang dinyatakan oleh pengasas DevOpsDays Patrick Debois, "Tidak mempunyai definisi adalah baik atau buruk. Orang ramai...sangat bergelut sekarang dengan maksud DevOps. Tetapi, sebaliknya, tidak mempunyai semua yang ditulis bermakna ia akan dibuka sehingga Bergerak dalam pelbagai arah.”

Jawapan kepada DevOps adalah untuk memecahkan silo dan menggalakkan kerjasama yang lebih luas melalui perkakasan, perubahan budaya dan metrik yang dikongsi. Pembangun akan memiliki apa yang mereka bina - mereka akan dapat menggunakan, memantau dan menyelesaikan masalah dari hujung ke hujung. Operasi akan lebih memahami keperluan pembangun terlibat pada awal kitaran hayat produk dan menyediakan pendidikan, alatan dan pagar untuk mempromosikan layan diri pembangun.

Satu perkara yang DevOps tidak ada ialah spesifikasi peranan. Cepat ke hari ini, dan banyak organisasi sedang giat merekrut "jurutera DevOps." Lebih teruk lagi, sedikit yang diketahui tentang apa yang mentakrifkan kedudukan—set kemahiran yang dicari berbeza-beza secara meluas dari satu jawatan ke kedudukan seterusnya. Peranan yang berkaitan dan bertindih seperti "Jurutera Kebolehpercayaan Tapak", "Jurutera Platform" dan "Jurutera Awan" adalah air yang sudah keruh.

Bagaimana kita sampai ke tahap ini? Apakah perbezaan sebenar (jika ada) antara peranan ini?

Kemunculan peranan IT baharu

Apabila DevOps semakin menarik, peranan dan tanggungjawab dalam ekosistem DevOps menjadi semakin kabur. Kekaburan ini telah membawa kepada kemunculan peranan yang berkaitan seperti jurutera kebolehpercayaan tapak (SRE), jurutera awan dan jurutera platform. Setiap watak mempunyai fokus dan kemahiran tersendiri.

Diinspirasikan oleh pendekatan Google untuk mengurus sistem besar, SRE menggabungkan amalan kejuruteraan perisian dengan operasi untuk memastikan kebolehpercayaan dan prestasi perkhidmatan. Jurutera awan menumpukan pada mengatur dan mengurus infrastruktur awan, memanfaatkan platform seperti AWS, Azure atau Google Cloud untuk mengoptimumkan kebolehskalaan dan kecekapan. Jurutera platform, sebaliknya, menumpukan pada mereka bentuk dan menyelenggara platform pembangun dalaman, menyediakan pembangun dengan keupayaan layan diri untuk mengurus aspek operasi kitaran hayat aplikasi.

Walaupun terdapat pertindihan antara peranan ini, masing-masing mempunyai bidang kepakaran dan tumpuan yang berbeza. SRE mengutamakan kebolehpercayaan dan daya tahan, jurutera awan menumpukan pada pengurusan infrastruktur awan, dan jurutera platform menumpukan pada mencipta platform tertumpu kepada pembangun. Memahami nuansa peranan ini adalah penting bagi organisasi untuk menstruktur pasukan mereka dengan berkesan dan memanfaatkan potensi penuh prinsip DevOps dalam saluran penghantaran perisian mereka.

Tentangan dan Kekeliruan DevOps

Menurut pengalaman saya, mencapai visi asal DevOps—iaitu, mencapai keseimbangan optimum antara pengkhususan dan kerjasama serta perkongsian—telah menjadi cabaran bagi banyak organisasi.

Laporan DevOps 2021 Puppet mendapati bahawa hanya 18% responden menganggap diri mereka sebagai pengamal DevOps yang "sangat maju". Seperti yang diterangkan oleh pasukan Topologi DevOps, beberapa faedah ini datang daripada keadaan istimewa. Sebagai contoh, organisasi seperti Netflix dan Facebook boleh dikatakan mempunyai satu produk berasaskan web, yang mengurangkan perbezaan antara aliran produk dan dengan itu memaksa pemisahan lebih lanjut antara pembangun dan kakitangan operasi.

Yang lain mengenakan syarat dan piawaian kerjasama yang ketat, seperti pasukan SRE Google (lebih lanjut mengenainya nanti!), yang juga mempunyai kuasa untuk menolak perisian yang menjejaskan prestasi sistem.

Ramai orang di peringkat rendah pembangunan DevOps sedang bergelut untuk merealisasikan janji DevOps sepenuhnya disebabkan oleh rintangan organisasi terhadap perubahan, kekurangan kemahiran, kekurangan automasi atau seni bina warisan. Oleh itu, kumpulan itu akan menggunakan pelbagai pendekatan berbeza untuk pelaksanaan DevOps, termasuk beberapa "anti-jenis" DevOps yang diterangkan dalam Topologi DevOps.

Bagi ramai orang, pembangunan dan operasi masih diam. Bagi yang lain, DevOps akan menjadi pasukan alat yang berada dalam pembangunan dan bertanggungjawab untuk saluran paip penempatan, pengurusan konfigurasi, dsb., tetapi tetap terpencil daripada operasi. Bagi yang lain, DevOps akan menjadi ciptaan semula mudah SysAdmin, dengan jurutera DevOps diupah ke dalam pasukan operasi dan jangkaan kemahiran mereka diperluaskan, tetapi tiada perubahan budaya sebenar berlaku.

Penggunaan pesat penggunaan awan awam juga telah meningkatkan keyakinan terhadap prospek pendekatan DevOps layan diri. Tetapi keupayaan untuk menyediakan dan menyediakan infrastruktur atas permintaan adalah jauh daripada membolehkan pembangun untuk menggunakan dan menjalankan aplikasi dan perkhidmatan dari hujung ke hujung. Malangnya, tidak semua organisasi memahami perkara ini, jadi automasi dalam banyak organisasi terhenti di peringkat automasi infrastruktur dan pengurusan konfigurasi.

DevOps mempunyai begitu banyak penjelmaan yang berbeza sehingga tidak menghairankan bahawa spesifikasi peranan DevOps tidak ditakrifkan dengan jelas. Untuk satu organisasi, ia mungkin sinonim dengan kejuruteraan penggunaan dalam erti kata yang paling sempit—mungkin hanya mencipta saluran paip CI/CD—sementara sebaliknya, ia mungkin pada asasnya merupakan ciptaan semula operasi, dengan keupayaan untuk menulis infrastruktur Kemahiran tambahan untuk pengekodan , automasi penggunaan dan perkakas dalaman. Bagi yang lain, ia boleh menjadi sebarang warna kelabu di antaranya, jadi di sini kami mempunyai senarai yang memeningkan peranan kerja DevOps.

SRE, Jurutera Awan dan Jurutera Platform berperanan

Jadi, bergantung pada organisasi pengambilan pekerja, jurutera DevOps boleh menjadi jurutera yang berfokus sepenuhnya pada penempatan atau pentadbir sistem yang lebih moden.

Bagaimana pula dengan peranan lain yang berkaitan: SRE, jurutera awan dan jurutera platform? Berikut adalah pendapat saya tentang setiap soalan:

Jurutera Kebolehpercayaan Tapak

Konsep SRE diperkenalkan oleh Ben Traynor di Google, yang menyifatkannya sebagai "Apabila anda menganggap operasi sebagai masalah perisian dan kakitangannya dengan jurutera perisian Apa yang boleh dilakukan awak dapat bila awak buat macam tu?" Ideanya adalah untuk meminta orang ramai menggabungkan kemahiran operasi dan pembangunan perisian untuk mereka bentuk dan menjalankan sistem pengeluaran.

Site Reliability Engineers (SREs) menggabungkan amalan kejuruteraan perisian dengan tanggungjawab operasi untuk memastikan kebolehpercayaan, skalabiliti dan prestasi sistem dan perkhidmatan. Mereka pakar dalam mereka bentuk dan melaksanakan penyelesaian automatik untuk mengurus dan memantau infrastruktur, menggunakan perisian dan bertindak balas secara proaktif terhadap insiden. SRE bekerja rapat dengan pasukan pembangunan untuk mewujudkan dan menguatkuasakan piawaian kebolehpercayaan, mentakrifkan objektif tahap perkhidmatan (SLO), dan melaksanakan amalan seperti belanjawan ralat untuk mengimbangi inovasi dengan kestabilan sistem. Matlamat mereka adalah untuk memastikan persekitaran pengeluaran sentiasa tersedia dan berdaya tahan melalui penambahbaikan dan lelaran berterusan.

Kebolehpercayaan Perkhidmatan Takrif Perjanjian Tahap Perkhidmatan (SLA) adalah penting untuk memastikan pasukan pembangunan menyediakan bukti awal bahawa perisian itu memenuhi piawaian operasi yang ketat sebelum ia diterima untuk digunakan. Selain itu, SRE berusaha untuk menjadikan sistem infrastruktur lebih berskala dan boleh diselenggara, termasuk mereka bentuk dan mengendalikan saluran paip CI/CD piawai dan platform infrastruktur awan untuk digunakan oleh pembangun untuk tujuan ini.

Seperti yang anda lihat, ini bertindih dengan ketara dengan definisi sesetengah orang tentang seorang jurutera DevOps. Jadi mungkin satu cara untuk memikirkan perbezaannya ialah ini. Sebaliknya, tujuan asal DevOps adalah untuk meningkatkan kelajuan keluaran, manakala matlamat SRE adalah untuk membina sistem yang lebih dipercayai dalam konteks saiz sistem yang semakin meningkat dan kerumitan produk. Jadi dalam satu cara, kedua-duanya bertemu di tengah-tengah.

Cloud Engineer

Memandangkan keupayaan awan terus berkembang, sesetengah organisasi telah mewujudkan peranan khusus untuk jurutera awan. Begitu juga, walaupun tiada peraturan yang keras dan pantas, jurutera awan biasanya menumpukan pada mengatur dan mengurus infrastruktur awan dan mengetahui cara membina persekitaran untuk aplikasi asli awan. Mereka akan menjadi pakar dalam AWS/Azure/Google Cloud Platform. Bergantung pada tahap pertindihan tanggungjawab dengan jurutera DevOps, mereka juga mungkin mahir dalam Terraform, Kubernetes, dsb.

Selain itu, jurutera awan menggunakan kepakaran mereka dalam teknologi awan untuk mereka bentuk, melaksanakan dan menyelenggara seni bina awan berskala dan anjal, memastikan aplikasi dan sistem berjalan dengan cekap dan selamat dalam persekitaran awan. Jurutera awan juga boleh mengusahakan strategi automasi, pemantauan dan pengoptimuman kos untuk memaksimumkan faedah pengkomputeran awan untuk organisasi mereka.

Memandangkan penggunaan awan terus berkembang, peranan jurutera awan merangkumi apa yang sebelum ini dikenali sebagai jurutera infrastruktur, dengan tumpuan awal pada awan dan pengurusan infrastruktur di premis.

Jurutera Platform

Platform Pembangun Dalaman (IDP) telah muncul sebagai penyelesaian terkini kepada cabaran mengimbangi produktiviti pembangun dengan kawalan dan kestabilan sistem. Jurutera Platform mereka bentuk dan menyelenggara IDP untuk menyediakan pembangun dengan keupayaan layan diri untuk mengurus aspek operasi keseluruhan kitaran hayat aplikasi - daripada peruntukan infrastruktur CI/CD dan orkestrasi kontena;

Ramai pembangun tidak mahu melakukan operasi - sekurang-kurangnya tidak dalam erti kata tradisional. Sebagai artis kreatif, pembangun tidak mahu bimbang tentang cara infrastruktur berfungsi. Oleh itu, adalah penting bahawa platform itu dilihat sebagai produk yang membolehkan kawalan dengan mencipta pengalaman pembangun layan diri yang menarik, dan bukannya dengan menguatkuasakan piawaian dan proses.

Nyahkekaburan: Menjelaskan Jangkaan Peranan

Jadi, di manakah calon untuk semua peranan yang berbeza ini? Mungkin buat masa ini (sekurang-kurangnya sehingga kaedah pelaksanaan DevOps menjadi lebih biasa), satu-satunya jawapan yang realistik ialah memastikan anda bertanya semua yang anda perlukan semasa temu duga, dengan jelas tentang jangkaan peranan dan konteks organisasi di mana anda akan diupah.

Untuk perekrut, anda boleh membuat keputusan untuk membuat jaringan yang luas dan mengisi siaran kerja anda dengan kata kunci popular atas pelbagai sebab. Tetapi akhirnya, butiran tentang pengalaman dan kebolehan calon mesti muncul semasa proses temu duga dan perbualan dengan rujukan.

Pada pendapat saya, sama ada anda seorang DevOps, jurutera platform, jurutera awan, atau pun SRE, memastikan anda menyokong semua keperluan operasi pembangun anda akan membantu mereka menumpukan pada mencipta produk terbaik seterusnya.

Atas ialah kandungan terperinci DevOps, SRE, jurutera platform, penjelasan peranan awan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!