DevOps telah menjadi topik yang sangat popular sejak beberapa tahun kebelakangan ini. Ramai orang bermimpi untuk menyertainya, tetapi, seperti yang ditunjukkan oleh amalan, selalunya hanya kerana tahap gaji.
Sesetengah orang menyenaraikan DevOps pada resume mereka, walaupun mereka tidak selalu mengetahui atau memahami intipati istilah itu. Sesetengah orang berfikir bahawa selepas mempelajari Ansible, GitLab, Jenkins, Terraform dan seumpamanya (senarai boleh diteruskan mengikut citarasa anda), anda akan segera menjadi "devopsist". Ini, tentu saja, tidak benar.
Sejak beberapa tahun kebelakangan ini, saya telah terlibat terutamanya dalam pelaksanaan DevOps di pelbagai syarikat. Sebelum itu, beliau bekerja selama lebih 20 tahun dalam jawatan daripada pentadbir sistem hingga pengarah IT. Pada masa ini, Jurutera Utama DevOps di Playgendary.
Siapa DevOps
Idea untuk menulis artikel timbul selepas soalan lain: "siapa DevOps?" Masih belum ada istilah yang ditetapkan untuk apa atau siapa itu. Beberapa jawapan sudah ada dalam ini . Pertama, saya akan menyerlahkan perkara utama daripadanya, dan kemudian saya akan berkongsi pemerhatian dan pemikiran saya.
DevOps bukan pakar yang boleh diupah, bukan satu set utiliti, dan bukan jabatan pemaju dengan jurutera.
DevOps ialah falsafah dan metodologi.
Dalam erti kata lain, ia adalah satu set amalan yang membantu pembangun berinteraksi secara aktif dengan pentadbir sistem. Iaitu, untuk menghubungkan dan mengintegrasikan proses kerja antara satu sama lain.
Dengan kemunculan DevOps, struktur dan peranan pakar kekal sama (ada pembangun, ada jurutera), tetapi peraturan interaksi telah berubah. Sempadan antara jabatan telah kabur.
Matlamat DevOps boleh diterangkan dalam tiga perkara:
- Perisian mesti dikemas kini dengan kerap.
- Perisian mesti dilakukan dengan cepat.
- Perisian harus digunakan dengan mudah dan dalam masa yang singkat.
Tiada alat tunggal untuk DevOps. Mengkonfigurasi, menghantar dan mengkaji beberapa produk tidak bermakna DevOps telah muncul dalam syarikat. Terdapat banyak alat dan semuanya digunakan pada peringkat yang berbeza, tetapi mempunyai satu tujuan yang sama.
Dan ini hanya sebahagian daripada alat DevOps
Saya telah menemu bual orang untuk jawatan jurutera DevOps selama lebih daripada 2 tahun sekarang, dan saya telah menyedari betapa pentingnya untuk memahami dengan jelas intipati istilah tersebut. Saya telah mengumpul pengalaman, pemerhatian dan pemikiran tertentu yang ingin saya kongsikan.
Dari pengalaman temuduga, saya melihat gambar berikut: pakar yang menganggap DevOps sebagai tajuk pekerjaan biasanya mempunyai perselisihan faham dengan rakan sekerja.
Terdapat satu contoh yang menarik. Seorang lelaki muda datang ke temu bual dengan banyak kata-kata bijak pada resumenya. Pada tiga pekerjaan terakhirnya, dia mempunyai pengalaman 5-6 bulan. Saya meninggalkan dua syarikat permulaan kerana mereka "tidak berlepas." Tetapi mengenai syarikat ketiga, dia berkata bahawa tiada siapa yang memahaminya di sana: pemaju menulis kod pada Windows, dan pengarah memaksa kod ini untuk "dibungkus" dalam Docker biasa dan disepadukan ke dalam saluran paip CI/CD. Lelaki itu mengatakan banyak perkara negatif tentang tempat kerjanya sekarang dan rakan sekerjanya - Saya hanya mahu menjawab: "Jadi anda tidak akan menjual gajah."
Kemudian saya bertanya kepadanya soalan yang paling tinggi dalam senarai saya untuk setiap calon.
β Apakah maksud DevOps kepada anda secara peribadi?
- Secara umum atau bagaimana saya melihatnya?
Saya tertarik dengan pendapat peribadinya. Dia tahu teori dan asal usul istilah itu, tetapi dia sangat tidak bersetuju dengannya. Dia percaya DevOps adalah tajuk pekerjaan. Di sinilah punca masalahnya. Begitu juga dengan pakar lain yang mempunyai pendapat yang sama.
Majikan, setelah mendengar banyak tentang "sihir DevOps", ingin mencari orang yang akan datang dan mencipta "sihir" ini. Dan pemohon dari kategori "DevOps ialah pekerjaan" tidak memahami bahawa dengan pendekatan ini mereka tidak akan dapat memenuhi jangkaan. Dan, secara umum, mereka menulis DevOps pada resume mereka kerana ia adalah trend dan mereka membayar banyak untuknya.
Metodologi dan falsafah DevOps
Metodologi boleh menjadi teori dan praktikal. Dalam kes kami, ia adalah yang kedua. Seperti yang saya nyatakan di atas, DevOps ialah satu set amalan dan strategi yang digunakan untuk mencapai matlamat yang dinyatakan. Dan dalam setiap kes, bergantung pada proses perniagaan syarikat, ia mungkin berbeza dengan ketara. Yang tidak menjadikannya lebih baik atau lebih buruk.
Metodologi DevOps hanyalah satu cara untuk mencapai matlamat.
Sekarang tentang apa itu falsafah DevOps. Dan ini mungkin soalan yang paling sukar.
Agak sukar untuk merumuskan jawapan yang ringkas dan padat, kerana ia masih belum diformalkan. Dan oleh kerana penganut falsafah DevOps lebih terlibat dalam amalan, tiada masa untuk berfalsafah. Walau bagaimanapun, ini adalah proses yang sangat penting. Lebih-lebih lagi, ia berkaitan secara langsung dengan aktiviti kejuruteraan. Malah terdapat bidang pengetahuan khusus - .
Tidak ada subjek sebegitu di universiti saya, saya terpaksa belajar semuanya sendiri menggunakan bahan-bahan yang saya dapati pada tahun 90-an. Topik ini adalah pilihan untuk pendidikan kejuruteraan, oleh itu kekurangan pemformalkan jawapan. Tetapi orang-orang yang serius terlibat dalam DevOps mula merasakan "semangat" atau "keseluruhan tidak sedarkan diri" tertentu dari semua proses syarikat.
Menggunakan pengalaman saya sendiri, saya cuba memformalkan beberapa "postulat" falsafah ini. Hasilnya adalah seperti berikut:
- DevOps bukanlah sesuatu yang bebas yang boleh dipisahkan ke dalam bidang pengetahuan atau aktiviti yang berasingan.
- Semua pekerja syarikat harus dipandu oleh metodologi DevOps semasa merancang aktiviti mereka.
- DevOps mempengaruhi semua proses dalam syarikat.
- DevOps wujud untuk mengurangkan kos masa untuk sebarang proses dalam syarikat bagi memastikan pembangunan perkhidmatannya dan keselesaan pelanggan maksimum.
- DevOps, dalam bahasa moden, ialah kedudukan proaktif setiap pekerja syarikat, bertujuan untuk mengurangkan kos masa dan meningkatkan kualiti produk IT di sekeliling kita.
Saya berpendapat bahawa "postulatan" saya adalah topik yang berasingan untuk perbincangan. Tetapi kini ada sesuatu untuk dibina.
Apa yang DevOps Lakukan
Kata kunci di sini ialah komunikasi. Terdapat banyak komunikasi, pemula yang sepatutnya adalah jurutera DevOps yang sama. Kenapa begitu? Kerana ini adalah falsafah dan metodologi, dan barulah pengetahuan kejuruteraan.
Saya tidak boleh bercakap dengan keyakinan 100% tentang pasaran buruh Barat. Tetapi saya tahu banyak tentang pasaran DevOps di Rusia. Sebagai tambahan kepada ratusan wawancara, sepanjang tahun setengah yang lalu saya telah mengambil bahagian dalam ratusan prajualan teknikal untuk perkhidmatan "Pelaksanaan DevOps" untuk syarikat dan bank besar Rusia.
Di Rusia, DevOps masih merupakan topik yang sangat muda, tetapi sudah menjadi sohor kini. Setahu saya, di Moscow sahaja kekurangan pakar sedemikian pada 2019 adalah lebih 1000 orang. Dan perkataan Kubernetes untuk majikan hampir seperti kain merah untuk lembu jantan. Penganut alat ini bersedia untuk menggunakannya walaupun ia tidak perlu dan menguntungkan dari segi ekonomi. Majikan tidak selalu memahami dalam kes apa apa yang lebih sesuai untuk digunakan, dan dengan penggunaan yang betul, menyelenggara kluster Kubernetes kos 2-3 kali lebih tinggi daripada menggunakan aplikasi menggunakan skim kluster konvensional. Gunakan di mana anda benar-benar memerlukannya.
Melaksanakan DevOps adalah mahal dari segi wang. Dan ia dibenarkan hanya jika ia membawa faedah ekonomi di kawasan lain, dan bukan dengan sendirinya.
Jurutera DevOps, sebenarnya, perintis - merekalah yang sepatutnya menjadi yang pertama melaksanakan metodologi ini dalam syarikat dan membina proses. Untuk ini berjaya, pakar mesti sentiasa berinteraksi dengan pekerja dan rakan sekerja di semua peringkat. Seperti yang biasa saya katakan, semua pekerja syarikat harus terlibat dalam proses pelaksanaan DevOps: daripada wanita pembersihan kepada CEO. Dan ini adalah prasyarat. Jika ahli paling junior dalam pasukan tidak mengetahui dan memahami apa itu DevOps dan sebab tindakan organisasi tertentu dilakukan, maka pelaksanaan yang berjaya tidak akan berfungsi.
Selain itu, jurutera DevOps perlu menggunakan sumber pentadbiran dari semasa ke semasa. Contohnya, untuk mengatasi "rintangan persekitaran" - apabila pasukan tidak bersedia untuk menerima alatan dan metodologi DevOps.
Pembangun hendaklah hanya menulis kod dan ujian. Untuk melakukan ini, dia tidak memerlukan komputer riba yang sangat berkuasa di mana dia akan menggunakan dan menyokong keseluruhan infrastruktur projek secara tempatan. Contohnya, pembangun bahagian hadapan menyimpan semua elemen aplikasi pada komputer ribanya, termasuk pangkalan data, emulator S3 (minio), dsb. Iaitu, beliau menghabiskan banyak masa menyelenggara infrastruktur tempatan ini dan seorang diri bergelut dengan semua masalah penyelesaian sedemikian. Daripada membangunkan kod untuk bahagian hadapan. Orang sedemikian boleh menjadi sangat tahan terhadap sebarang perubahan.
Tetapi ada pasukan yang, sebaliknya, gembira untuk memperkenalkan alat dan kaedah baharu, dan mengambil bahagian secara aktif dalam proses ini. Walaupun dalam kes ini, komunikasi antara jurutera DevOps dan pasukan tidak dibatalkan.
Apabila DevOps tidak diperlukan
Terdapat situasi apabila DevOps tidak diperlukan. Ini adalah fakta - ia perlu difahami dan diterima.
Pertama sekali, ini terpakai kepada mana-mana syarikat (terutamanya perniagaan kecil), apabila keuntungan mereka tidak secara langsung bergantung kepada kehadiran atau ketiadaan produk IT yang menyediakan perkhidmatan maklumat kepada pelanggan. Dan di sini kita tidak bercakap tentang laman web syarikat, sama ada "kad perniagaan" statik atau dengan blok berita dinamik, dsb.
DevOps diperlukan apabila kepuasan pelanggan anda dan keinginannya untuk kembali kepada anda sekali lagi bergantung pada ketersediaan perkhidmatan maklumat ini untuk interaksi dengan pelanggan, kualiti dan penyasaran mereka.
Satu contoh yang menarik ialah sebuah bank yang terkenal. Syarikat itu tidak mempunyai pejabat pelanggan biasa, aliran dokumen dijalankan melalui surat atau kurier, dan ramai pekerja bekerja dari rumah. Syarikat itu tidak lagi menjadi sebuah bank dan, pada pendapat saya, telah bertukar menjadi sebuah syarikat IT dengan teknologi DevOps yang dibangunkan.
Banyak contoh dan kuliah lain boleh didapati dalam rakaman pertemuan dan persidangan bertema. Saya melawat sebahagian daripada mereka secara peribadi - ini adalah pengalaman yang sangat berguna bagi mereka yang ingin berkembang ke arah ini. Berikut ialah pautan ke saluran YouTube dengan kuliah dan bahan yang bagus tentang DevOps:
Sekarang lihat perniagaan anda dan fikirkan tentang perkara ini: Berapa banyak syarikat anda dan keuntungannya bergantung pada produk IT untuk membolehkan interaksi pelanggan?
Jika syarikat anda menjual ikan di kedai kecil dan satu-satunya produk IT ialah dua 1C: Konfigurasi Perusahaan (Perakaunan dan UNF), maka tidak masuk akal untuk bercakap tentang DevOps.
Jika anda bekerja di perusahaan perdagangan dan pembuatan yang besar (contohnya, anda menghasilkan senapang memburu), maka anda harus memikirkannya. Anda boleh mengambil inisiatif dan menyampaikan kepada pengurusan anda prospek untuk melaksanakan DevOps. Nah, dan pada masa yang sama, pimpin proses ini. Kedudukan proaktif ialah salah satu prinsip penting falsafah DevOps.
Saiz dan volum pusing ganti kewangan tahunan bukanlah kriteria utama untuk menentukan sama ada syarikat anda memerlukan DevOps.
Mari kita bayangkan perusahaan industri besar yang tidak berinteraksi secara langsung dengan pelanggan. Contohnya, beberapa pembuat kereta dan syarikat pembuatan kereta. Saya tidak pasti sekarang, tetapi dari pengalaman lepas saya, selama bertahun-tahun semua interaksi pelanggan dilakukan melalui e-mel dan telefon.
Pelanggan mereka adalah senarai pengedar kereta yang terhad. Dan setiap satu ditugaskan pakar dari pengilang. Semua aliran dokumen dalaman berlaku melalui SAP ERP. Pekerja dalaman pada asasnya adalah pelanggan sistem maklumat. Tetapi IS ini dikawal dengan cara klasik untuk menguruskan sistem kluster. Yang tidak termasuk kemungkinan menggunakan amalan DevOps.
Oleh itu kesimpulannya: untuk perusahaan sedemikian, pelaksanaan DevOps bukanlah sesuatu yang sangat penting, jika kita mengingati matlamat metodologi dari awal artikel. Tetapi saya tidak menolak bahawa mereka menggunakan beberapa alat DevOps hari ini.
Sebaliknya, terdapat banyak syarikat kecil yang membangunkan perisian menggunakan metodologi, falsafah, amalan dan alatan DevOps. Dan mereka percaya bahawa kos melaksanakan DevOps adalah kos yang membolehkan mereka bersaing secara berkesan dalam pasaran perisian. Contoh syarikat tersebut boleh dilihat .
Kriteria utama untuk memahami sama ada DevOps diperlukan: apakah nilai produk IT anda untuk syarikat dan pelanggan.
Jika produk utama syarikat yang menjana keuntungan ialah perisian, anda memerlukan DevOps. Dan ia tidak begitu penting jika anda memperoleh wang sebenar menggunakan produk lain. Ini juga termasuk kedai dalam talian atau aplikasi mudah alih dengan permainan.
Sebarang permainan wujud berkat pembiayaan: secara langsung atau tidak langsung daripada pemain. Di Playgendary, kami membangunkan permainan mudah alih percuma dengan lebih 200 orang yang terlibat secara langsung dalam penciptaan mereka. Bagaimanakah kita menggunakan DevOps?
Ya, sama seperti yang diterangkan di atas. Saya sentiasa berkomunikasi dengan pembangun dan penguji, serta menjalankan latihan dalaman untuk pekerja tentang metodologi dan alatan DevOps.
Kami kini secara aktif menggunakan Jenkins sebagai alat saluran paip CI/CD untuk melaksanakan semua saluran paip pemasangan dengan Unity dan penggunaan seterusnya ke App Store dan Play Market. Lagi daripada kit alat klasik:
- Asana - untuk pengurusan projek. Penyepaduan dengan Jenkins telah dikonfigurasikan.
- Google Meet - untuk mesyuarat video.
- Slack - untuk komunikasi dan pelbagai makluman, termasuk pemberitahuan daripada Jenkins.
- Atlassian Confluence - untuk dokumentasi dan kerja berkumpulan.
Pelan segera kami termasuk memperkenalkan analisis kod statik menggunakan SonarQube dan menjalankan ujian UI automatik menggunakan Selenium pada peringkat Integrasi Berterusan.
Daripada kesimpulan
Saya ingin mengakhiri dengan pemikiran berikut: untuk menjadi jurutera DevOps yang berkelayakan tinggi, adalah penting untuk mempelajari cara berkomunikasi secara langsung dengan orang ramai.
Jurutera DevOps ialah pemain pasukan. Dan tiada yang lain. Inisiatif dalam berkomunikasi dengan rakan sekerja harus datang darinya, dan bukan di bawah pengaruh beberapa keadaan. Pakar DevOps mesti melihat dan mencadangkan penyelesaian terbaik untuk pasukan.
Dan ya, pelaksanaan sebarang penyelesaian akan memerlukan banyak perbincangan, dan pada akhirnya ia mungkin berubah sama sekali. Membangunkan secara bebas, mencadangkan dan melaksanakan idea-ideanya, orang seperti itu meningkatkan nilai kepada pasukan dan majikan. Yang, akhirnya, dicerminkan dalam jumlah imbuhan bulanannya atau dalam bentuk bonus tambahan.
Sumber: www.habr.com