Takrif DevOps adalah sangat kompleks, jadi kita perlu memulakan perbincangan tentangnya sekali lagi setiap kali. Terdapat seribu penerbitan mengenai topik ini mengenai Habré sahaja. Tetapi jika anda membaca ini, anda mungkin tahu apa itu DevOps. Kerana saya tidak. Hello nama saya ialah Alexander Titov (@), dan kita hanya akan bercakap tentang DevOps dan saya akan berkongsi pengalaman saya.
Saya telah lama berfikir tentang cara menjadikan cerita saya berguna, jadi akan ada banyak soalan di sini - soalan yang saya tanyakan kepada diri sendiri dan soalan yang saya tanyakan kepada pelanggan syarikat kami. Dengan menjawab soalan-soalan ini, pemahaman menjadi lebih baik. Saya akan memberitahu anda mengapa DevOps diperlukan dari sudut pandangan saya, apakah itu, sekali lagi, dari sudut pandangan saya, dan bagaimana untuk memahami bahawa anda sedang bergerak ke arah DevOps sekali lagi dari sudut pandangan saya. Perkara terakhir akan melalui soalan. Dengan menjawabnya sendiri, anda boleh memahami sama ada syarikat anda bergerak ke arah DevOps atau sama ada terdapat masalah dalam beberapa cara.
Pada satu ketika saya sedang mengharungi gelombang penggabungan dan pengambilalihan. Mula-mula, saya bekerja untuk syarikat permulaan kecil bernama Qik, kemudian ia dibeli oleh syarikat yang lebih besar sedikit bernama Skype, yang kemudiannya dibeli oleh syarikat yang lebih besar sedikit bernama Microsoft. Pada masa itu, saya mula melihat bagaimana idea DevOps berubah dalam syarikat saiz yang berbeza. Selepas itu, saya mula berminat untuk melihat DevOps dari sudut pasaran, dan rakan sekerja saya dan saya mengasaskan syarikat Express 42. Selama 6 tahun sekarang kami telah bergerak di sepanjang gelombang pasaran.
Antara lain, saya adalah salah seorang penganjur komuniti DevOps Moscow dan penganjur DevOps-Days 2017, tetapi saya tidak menganjurkan 2018. Express 42 bekerja dengan banyak syarikat. Kami mengembangkan DevOps di sana, melihat bagaimana ia berlaku, membuat kesimpulan, menganalisis, memberitahu semua orang kesimpulan kami dan melatih orang dalam amalan DevOps. Secara umum, kami melakukan yang terbaik untuk meningkatkan pengalaman dan kepakaran kami dalam hal ini.
Mengapa DevOps
Soalan pertama yang menghantui semua orang dan selalu - kenapa? Ramai orang berfikir bahawa DevOps hanyalah automasi atau perkara serupa yang telah dimiliki oleh setiap syarikat.
— Kami mempunyai Integrasi Berterusan - ini bermakna kami sudah mempunyai DevOps, dan mengapa semua perkara ini diperlukan? Mereka berseronok di luar negara, tetapi mereka menghalang kami daripada bekerja!
Lebih 9 tahun pembangunan komuniti dan metodologi, telah menjadi jelas bahawa ini masih bukan kilauan pemasaran, tetapi masih belum jelas sepenuhnya mengapa ia diperlukan. Seperti mana-mana alat dan proses, DevOps mempunyai matlamat khusus yang akhirnya dicapai.
Semua ini disebabkan oleh fakta bahawa dunia sedang berubah. Dia beralih daripada pendekatan perusahaan, apabila syarikat bergerak terus ke arah impian, seperti nyanyian klasik St. Petersburg kami, dari titik A ke titik B mengikut strategi tertentu, dengan struktur tertentu dibina untuk ini.
Pada dasarnya, segala-galanya dalam IT harus dibina mengikut pendekatan ini. Di sini IT digunakan secara eksklusif untuk mengautomasikan proses.
Automasi tidak selalunya berubah, kerana apabila syarikat mengalami masalah yang teruk, apakah yang perlu diubah? Ia berfungsi - jangan sentuh. Kini pendekatan di dunia sedang berubah, dan pendekatan yang dipanggil Agile menunjukkan bahawa titik akhir B tidak dapat dilihat dengan serta-merta.
Apabila syarikat melalui pasaran, bekerja dengan pelanggan, ia sentiasa meneroka pasaran dan mengubah titik akhir B. Lebih-lebih lagi, semakin kerap syarikat itu menukar arahnya, semakin berjaya pada akhirnya, kerana ia memilih lebih banyak pasaran ceruk.
Strategi ini ditunjukkan oleh sebuah syarikat yang menarik yang saya pelajari baru-baru ini. One Box Shave ialah perkhidmatan penghantaran langganan untuk pencukur dan aksesori pencukur dalam kotak. Mereka tahu cara menyesuaikan "kotak" mereka untuk pelanggan yang berbeza. Ini dilakukan oleh perisian tertentu, yang kemudiannya menghantar pesanan ke kilang Korea yang menghasilkan produk tersebut.
Produk ini dibeli oleh Unilever dengan harga $1 bilion. Ia kini bersaing dengan Gillette dan telah mengambil sebahagian besar pengguna dalam pasaran Amerika. Satu Box Shave berkata:
- 4 bilah? Adakah kamu serius? Mengapa anda memerlukan ini - ia tidak meningkatkan kualiti pencukuran. Krim, pewangi dan pencukur berkualiti tinggi yang dipilih khas dengan dua bilah menyelesaikan lebih banyak masalah daripada 4 bilah Gillette yang bodoh itu! Adakah kita akan sampai ke 10 tidak lama lagi?
Ini adalah bagaimana dunia berubah. Unilever mendakwa bahawa mereka mempunyai sistem IT yang hebat yang membolehkan anda melakukan ini. Pada akhirnya ia kelihatan seperti satu konsep Masa ke pasaran, yang belum pernah dibincangkan oleh sesiapa pun.
Titik Masa-ke-pasaran bukanlah seberapa kerap kami menggunakan. Anda selalunya boleh menggunakan, tetapi kitaran keluaran akan menjadi panjang. Jika kitaran keluaran tiga bulan ditindih antara satu sama lain, mengalihkannya selama seminggu, ternyata syarikat itu nampaknya menggunakan seminggu sekali. Dan dari idea hingga pelaksanaan akhir mengambil masa 3 bulan.
Masa ke pasaran adalah mengenai meminimumkan masa daripada idea kepada pelaksanaan akhir.
Dalam kes ini, perisian berinteraksi dengan pasaran. Beginilah cara laman web One Box Shave berinteraksi dengan pelanggan. Mereka tidak mempunyai jurujual - hanya tapak web di mana pelawat mengklik dan meninggalkan keinginan. Sehubungan itu, sesuatu yang baru mesti sentiasa disiarkan di laman web dan dikemas kini mengikut kehendak. Sebagai contoh, di Korea Selatan mereka mencukur secara berbeza daripada di Rusia, dan mereka menyukai bau bukan pain, tetapi, sebagai contoh, lobak merah dan vanila.
Memandangkan anda perlu menukar kandungan tapak dengan cepat, pembangunan perisian berubah dengan ketara. Melalui perisian kita mesti mengetahui apa yang pelanggan inginkan. Sebelum ini, kami mempelajari perkara ini melalui beberapa cara bulat, contohnya, melalui pengurusan perniagaan. Kemudian kami mereka bentuknya, meletakkan keperluan ke dalam sistem IT, dan semuanya hebat. Kini ia berbeza - perisian direka oleh semua orang yang terlibat dalam proses tersebut, termasuk jurutera, kerana melalui spesifikasi teknikal mereka mempelajari cara pasaran berfungsi dan turut berkongsi pandangan mereka dengan perniagaan.
Sebagai contoh, di Qik kami tiba-tiba mengetahui bahawa orang sangat suka memuat naik senarai kenalan ke pelayan, dan mereka membekalkan kami dengan aplikasi. Pada mulanya kami tidak memikirkannya. Dalam syarikat klasik, semua orang akan memutuskan bahawa ini adalah pepijat, kerana spesifikasi tidak mengatakan bahawa ia sepatutnya berfungsi dengan baik dan secara amnya dilaksanakan pada lutut, mereka akan mematikan ciri tersebut dan berkata: "Tiada sesiapa yang memerlukan ini, yang paling penting ialah fungsi utama berfungsi.” . Dan syarikat teknologi melihat ini sebagai peluang dan mula mengubah perisian mengikut ini.
Pada tahun 1968, seorang lelaki berwawasan, Melvin Conway, merumuskan idea berikut.
Organisasi yang mencipta sistem dikekang oleh reka bentuk yang mereplikasi struktur komunikasi organisasi tersebut.
Secara lebih terperinci, untuk menghasilkan sistem jenis yang berbeza, anda juga mesti mempunyai struktur komunikasi dalam syarikat daripada jenis yang berbeza. Jika struktur komunikasi anda adalah atas hierarki, maka ini tidak akan membenarkan anda mencipta sistem yang boleh memberikan penunjuk Masa ke Pasaran yang sangat tinggi.
Baca seseorang boleh . Ia penting untuk memahami budaya atau falsafah DevOps kerana satu-satunya perkara yang secara asasnya berubah dalam DevOps ialah struktur komunikasi antara pasukan.
Dari sudut pandangan proses, sebelum DevOps, semua peringkat: analisis, pembangunan, ujian, operasi, adalah linear.
Dalam kes DevOps, semua proses ini berlaku serentak.
Masa ke pasaran adalah satu-satunya cara ia boleh dilakukan. Bagi orang yang bekerja dalam proses lama, ini kelihatan agak kosmik, dan biasanya begitu-begitu.
Jadi mengapa anda memerlukan DevOps?
Untuk pembangunan produk digital. Jika syarikat anda tidak mempunyai produk digital, DevOps tidak diperlukan - ia sangat penting.
DevOps mengatasi had kelajuan pengeluaran perisian berjujukan. Di dalamnya semua proses berlaku serentak.
Kesukaran bertambah. Apabila penginjil DevOps memberitahu anda bahawa ia akan memudahkan anda mengeluarkan perisian, ini adalah karut.
Dengan DevOps, perkara akan menjadi lebih rumit.
Pada persidangan di gerai Avito, anda dapat melihat bagaimana rasanya menggunakan bekas Docker - tugas yang tidak realistik. Kerumitan menjadi terlarang; anda perlu mengimbangi banyak bola pada masa yang sama.
DevOps mengubah sepenuhnya proses dan organisasi dalam syarikat — lebih tepat lagi, bukan DevOps yang berubah, tetapi produk digital. Untuk datang ke DevOps, anda masih perlu mengubah sepenuhnya proses ini.
Soalan untuk pakar
Apa yang kamu ada? Soalan yang boleh anda tanya sendiri semasa bekerja di syarikat dan berkembang sebagai pakar.
Adakah anda mempunyai strategi untuk mencipta produk digital? Jika ada, itu sudah bagus. Ini bermakna syarikat anda sedang menuju ke arah DevOps.
Adakah syarikat anda sudah mencipta produk digital? Ini bermakna anda boleh naik ke tahap yang lain dan melakukan perkara dengan lebih menarik – sekali lagi dari sudut DevOps. Saya hanya bercakap dari sudut ini.
Adakah syarikat anda salah satu peneraju pasaran dalam niche produk digital? Spotify, Yandex, Uber ialah syarikat yang berada di kemuncak kemajuan teknologi sekarang.
Tanya diri anda soalan ini, dan jika semua jawapannya tidak, maka mungkin anda tidak sepatutnya melakukan DevOps di syarikat ini. Jika topik DevOps benar-benar menarik untuk anda, mungkin... anda perlu berpindah ke syarikat lain? Jika syarikat anda mahu masuk ke DevOps, tetapi anda menjawab "Tidak" untuk semua soalan, maka ia adalah seperti badak sumbu yang cantik itu yang tidak akan pernah berubah.
Pertubuhan
Seperti yang saya katakan, mengikut Undang-undang Conway, organisasi syarikat berubah. Saya akan mulakan dengan perkara yang menghalang DevOps daripada menembusi dalam syarikat dari sudut pandangan organisasi.
Masalah "telaga"
Perkataan Inggeris "Silo" diterjemahkan di sini ke dalam bahasa Rusia sebagai "well". Inti masalah ini ialah tiada pertukaran maklumat antara pasukan. Setiap pasukan mendalami kepakaran mereka, tanpa membina peta yang sama untuk dilayari.
Dalam beberapa cara ini mengingatkan saya kepada seseorang yang baru tiba di Moscow dan belum tahu cara menavigasi peta metro. Muscovite biasanya mengetahui kawasan mereka dengan baik, dan di seluruh Moscow mereka boleh menavigasi menggunakan peta metro. Apabila anda datang ke Moscow buat kali pertama, anda tidak mempunyai kemahiran ini, dan anda hanya keliru.
DevOps mencadangkan untuk melalui detik kekeliruan ini dan semua jabatan bekerjasama untuk membina peta interaksi yang sama.
Dua faktor menghalang ini.
Akibat sistem pengurusan korporat. Ia dibina dalam "telaga" hierarki berasingan. Sebagai contoh, terdapat KPI tertentu dalam syarikat yang menyokong sistem ini. Sebaliknya, otak seseorang yang sukar untuk melampaui batas kepakaran mereka dan mengemudi seluruh sistem menghalangnya. Ia hanya tidak selesa. Bayangkan anda berada di lapangan terbang Bangkok - anda tidak akan menemui jalan anda dengan cepat. DevOps juga sukar untuk dinavigasi, dan itulah sebabnya orang berkata anda perlu mencari panduan untuk ke sana.
Tetapi perkara yang paling penting ialah masalah "telaga" untuk seorang jurutera yang disemai dengan semangat DevOps, telah membaca Fowler dan sekumpulan buku lain, dinyatakan dalam fakta bahawa "telaga" tidak membenarkan anda melakukan perkara yang "jelas".. Kami sering berkumpul selepas DevOps Moscow, bercakap antara satu sama lain, dan orang ramai mengadu:
— Kami hanya mahu melancarkan CI, tetapi ternyata pengurusan tidak memerlukannya.
Ini berlaku tepat kerana CI и Proses Penghantaran Berterusan berada di sempadan banyak peperiksaan. Semata-mata tanpa mengatasi masalah "telaga" di peringkat organisasi, anda tidak akan dapat bergerak ke hadapan, tidak kira apa yang anda lakukan dan tidak kira betapa sedihnya.
Setiap peserta dalam proses dalam syarikat: pembangun backend dan frontend, ujian, DBA, operasi, rangkaian, menggali ke arah mereka sendiri, dan tiada siapa yang mempunyai peta yang sama kecuali pengurus, yang entah bagaimana memantau mereka dan mengurus mereka menggunakan "bahagi dan menakluki” kaedah.
Orang ramai berjuang untuk beberapa bintang atau bendera, semua orang sedang menggali kepakaran mereka.
Akibatnya, apabila timbul tugas untuk menghubungkan semua ini bersama-sama dan membina saluran paip yang sama, dan tidak ada lagi keperluan untuk memperjuangkan bintang dan bendera, persoalan timbul - apa yang perlu dilakukan? Kami perlu mencapai persetujuan entah bagaimana, tetapi tiada siapa yang mengajar kami cara melakukan ini di sekolah. Kami telah diajar sejak sekolah: darjah lapan - wow! - berbanding dengan darjah tujuh! Kat sini pun sama.
Adakah ia sama di syarikat anda?
Untuk menyemak ini, anda boleh bertanya kepada diri sendiri soalan berikut.
Adakah pasukan menggunakan alatan biasa dan menyumbang kepada perubahan kepada alatan biasa tersebut?
Berapa kerapkah pasukan menyusun semula—sesetengah pakar daripada satu pasukan berpindah ke pasukan lain? Ia adalah dalam persekitaran DevOps bahawa ini menjadi normal, kerana kadang-kadang seseorang tidak dapat memahami apa yang dilakukan oleh bidang kepakaran lain. Dia berpindah ke jabatan lain, bekerja di sana selama dua minggu untuk mencipta sendiri peta orientasi dan interaksi dengan jabatan ini.
Adakah mungkin untuk membentuk jawatankuasa perubahan dan mengubah keadaan? Atau adakah ia memerlukan tangan kuat pengurusan dan arahan tertinggi? Saya baru-baru ini menulis di Facebook bagaimana sebuah bank yang kurang dikenali melaksanakan alat melalui pesanan: kami menulis pesanan, kami melaksanakannya selama setahun, dan lihat apa yang berlaku. Ini, tentu saja, panjang dan menyedihkan.
Sejauh manakah pentingnya pengurus menerima pencapaian peribadi tanpa mengambil kira pencapaian syarikat?
Jika anda menjawab sendiri soalan ini, ia akan menjadi lebih jelas sama ada anda mempunyai masalah sedemikian dalam syarikat anda.
Infrastruktur sebagai kod
Selepas masalah ini berlalu, amalan penting pertama, yang tanpanya sukar untuk maju lebih jauh dalam DevOps, ialah infrastruktur sebagai kod.
Selalunya, infrastruktur sebagai kod dilihat seperti berikut:
— Mari kita mengautomasikan segala-galanya dalam bash, tutup diri kita dengan skrip supaya pentadbir mempunyai kurang kerja manual!
Tetapi itu tidak benar.
Infrastruktur sebagai kod bermakna anda menerangkan sistem IT yang anda bekerjasama dalam bentuk kod untuk sentiasa memahami keadaannya.
Bersama-sama dengan pasukan lain, anda membuat peta dalam bentuk kod yang semua orang boleh fahami dan boleh menavigasi serta menavigasi. Tidak kira apa yang dilakukan - Chef, Ansible, Salt atau menggunakan fail YAML dalam Kubernetes - tiada perbezaan.
Pada persidangan itu, rakan sekerja dari 2GIS memberitahu bagaimana mereka membuat perkara dalaman mereka sendiri untuk Kubernetes, yang menerangkan struktur sistem individu. Untuk menerangkan 500 sistem, mereka memerlukan alat berasingan yang menjana penerangan ini. Apabila ada penerangan ini, semua orang boleh menyemak antara satu sama lain, memantau perubahan, cara mengubahnya dan memperbaikinya, apa yang kurang.
Setuju, skrip bash individu biasanya tidak memberikan pemahaman ini. Di salah satu syarikat tempat saya bekerja, terdapat nama untuk skrip "tulis sahaja" - apabila skrip ditulis, tetapi tidak lagi boleh membacanya. Saya rasa ini sudah biasa kepada anda juga.
Infrastruktur sebagai kod kod yang menerangkan keadaan semasa infrastruktur. Banyak produk, infrastruktur dan pasukan perkhidmatan bekerjasama dalam kod ini, dan yang paling penting, mereka semua perlu memahami cara kod ini sebenarnya berfungsi.
Kod ini dikekalkan mengikut amalan kod terbaik: pembangunan bersama, semakan kod, pengaturcaraan XP, ujian, permintaan tarik, CI untuk infrastruktur kod - semua ini sesuai dan boleh digunakan.
Kod menjadi bahasa biasa untuk semua jurutera.
Menukar infrastruktur dalam kod tidak mengambil banyak masa. Ya, kod infrastruktur juga boleh mempunyai hutang teknikal. Biasanya pasukan menghadapinya setahun setengah selepas mereka mula melaksanakan "infrastruktur sebagai kod" dalam bentuk sekumpulan skrip atau bahkan Ansible, yang mereka tulis seperti kod spageti, dan mereka juga membuang skrip bash ke dalam campuran!
Ia adalah penting: Jika anda belum mencuba barangan ini, ingat itu Ansible bukan bash! Baca dokumentasi dengan teliti, kaji apa yang mereka tulis mengenainya.
Infrastruktur sebagai kod ialah pengasingan kod infrastruktur ke dalam lapisan yang berasingan.
Dalam syarikat kami, kami membezakan 3 lapisan asas, yang sangat jelas dan mudah, tetapi mungkin terdapat lebih banyak daripada mereka. Anda boleh melihat kod infrastruktur anda dan memberitahu sama ada anda mempunyai keadaan ini atau tidak. Jika tiada lapisan diserlahkan, maka anda perlu mengambil sedikit masa dan memfaktorkan semula sedikit.
lapisan asas - beginilah cara OS, sandaran dan perkara peringkat rendah lain dikonfigurasikan, contohnya, cara Kubernetes digunakan pada peringkat asas.
Tahap servis - ini ialah perkhidmatan yang anda sediakan kepada pembangun: pengelogan sebagai perkhidmatan, pemantauan sebagai perkhidmatan, pangkalan data sebagai perkhidmatan, pengimbang sebagai perkhidmatan, baris gilir sebagai perkhidmatan, Penghantaran Berterusan sebagai perkhidmatan - sekumpulan perkhidmatan yang pasukan individu boleh memberi kepada pembangunan. Ini semua perlu diterangkan dalam modul berasingan dalam sistem pengurusan konfigurasi anda.
Lapisan tempat aplikasi dibuat dan menerangkan cara ia akan terbentang di atas dua lapisan sebelumnya.
Soalan kawalan
Adakah syarikat anda mempunyai repositori infrastruktur biasa? Adakah anda menguruskan hutang teknikal dalam infrastruktur anda? Adakah anda menggunakan amalan pembangunan dalam repositori infrastruktur? Adakah infrastruktur anda dihiris ke dalam lapisan? Anda boleh menyemak gambar rajah Base-service-APP. Betapa sukarnya untuk membuat perubahan?
Jika anda pernah mengalami bahawa ia mengambil masa satu setengah hari untuk membuat perubahan, ini bermakna anda mempunyai hutang teknikal dan perlu menyelesaikannya. Anda baru sahaja terjumpa hutang teknikal dalam kod infrastruktur anda. Saya masih ingat banyak cerita sedemikian apabila, untuk menukar beberapa CCTL, anda perlu menulis semula separuh daripada kod infrastruktur, kerana kreativiti dan keinginan untuk mengautomasikan segala-galanya membawa kepada fakta bahawa semuanya terhakis di mana-mana, semua pemegang telah dikeluarkan, dan ia adalah perlu untuk refactor.
Penghantaran Berterusan
Mari bandingkan debit dengan kredit. Pertama sekali ialah penerangan tentang infrastruktur, yang boleh menjadi agak asas. Anda tidak perlu menerangkan segala-galanya secara terperinci, tetapi beberapa penerangan asas diperlukan supaya anda boleh bekerja dengannya. Jika tidak, tidak jelas apa yang perlu dilakukan dengan penghantaran berterusan seterusnya. Semua amalan ini berlaku serentak apabila anda datang ke DevOps, tetapi ia bermula dengan memahami perkara yang anda miliki dan cara mengurusnya. Ini adalah tepat amalan infrastruktur sebagai kod.
Setelah menjadi jelas bahawa anda memilikinya dan cara mengurusnya, anda mula memikirkan cara menghantar kod pembangun ke pengeluaran secepat mungkin. Maksud saya bersama-sama dengan pemaju - kita masih ingat tentang masalah "telaga", iaitu, bukan orang individu yang membuat ini, tetapi satu pasukan.
Apabila kita bersama Vanya Evtukhovich melihat buku pertama Jez Humble dan kumpulan pengarang "Penghantaran Berterusan", yang dikeluarkan pada tahun 2009, kami berfikir untuk masa yang lama tentang cara menterjemahkan tajuknya ke dalam bahasa Rusia. Mereka ingin menterjemahkannya sebagai "Serahkan secara berterusan", tetapi, malangnya, ia diterjemahkan sebagai "Penghantaran berterusan". Nampaknya saya ada sesuatu bahasa Rusia dalam nama kami, dengan tekanan.
Sentiasa menyampaikan cara
Kod yang terdapat dalam repositori produk sentiasa boleh dimuat turun ke pengeluaran. Dia mungkin tidak kempis, tetapi dia sentiasa bersedia untuk itu. Oleh itu, anda sentiasa menulis kod dengan perasaan kebimbangan yang sukar dijelaskan di bawah tulang ekor anda. Ia sering muncul apabila anda melancarkan kod infrastruktur. Perasaan kebimbangan ini harus ada - ia mencetuskan proses otak yang membolehkan anda menulis kod sedikit berbeza. Ini harus direkodkan dalam peraturan dalam pembangunan.
Untuk menyampaikan secara konsisten, anda memerlukan format artifak yang merentasi platform infrastruktur. Jika anda membuang "sisa hayat" dengan format yang berbeza merentasi platform infrastruktur, maka ia menjadi bersatu, sukar untuk dikekalkan, dan masalah hutang teknikal timbul. Format artifak perlu diselaraskan - ini juga merupakan tugas kolektif: kita semua perlu berkumpul, berdesir otak kita dan menghasilkan format ini.
Artifak itu terus ditambah baik dan berubah untuk disesuaikan dengan persekitaran pengeluaran semasa ia bergerak melalui saluran paip penghantaran. Apabila artifak bergerak di sepanjang saluran paip, ia sentiasa menghadapi beberapa perkara yang menyusahkan untuknya, yang serupa dengan artifak yang anda masukkan ke dalam pengeluaran. Jika dalam pembangunan klasik ini dilakukan oleh pentadbir sistem yang melakukan pelancaran, maka dalam proses DevOps ini berlaku sepanjang masa: di sini mereka mengujinya dengan beberapa ujian, di sini mereka melemparkannya ke dalam kelompok Kubernetes, yang lebih kurang serupa kepada pengeluaran, kemudian tiba-tiba mereka memulakan ujian beban.
Ini agak mengingatkan permainan Pac-Man - artifak itu melalui beberapa jenis cerita. Pada masa yang sama, adalah penting untuk mengawal sama ada kod itu benar-benar melalui cerita dan sama ada ia berkaitan dengan pengeluaran anda. Cerita daripada pengeluaran boleh diseret ke dalam proses Penghantaran Berterusan: ia adalah seperti ini apabila sesuatu jatuh, sekarang mari kita memprogramkan senario ini di dalam sistem. Setiap kali kod akan melalui senario ini juga, dan anda tidak akan menghadapi masalah ini pada masa akan datang. Anda akan mempelajarinya lebih awal daripada ia sampai kepada pelanggan anda.
Strategi penyebaran yang berbeza. Sebagai contoh, anda menggunakan ujian AB atau penggunaan kenari untuk menguji kod secara berbeza pada klien yang berbeza, mendapatkan maklumat tentang cara kod tersebut berfungsi dan lebih awal daripada apabila ia dilancarkan kepada 100 juta pengguna.
"Serahkan secara konsisten" kelihatan seperti ini.
Proses penghantaran Dev, CI, Test, PreProd, Prod bukanlah persekitaran yang berasingan, ini adalah peringkat atau stesen dengan jumlah kalis api yang melaluinya artifak anda.
Jika anda mempunyai kod infrastruktur yang diterangkan sebagai APP Perkhidmatan Asas maka ia membantu jangan lupa semua skrip, dan tuliskannya sebagai kod untuk artifak ini, mempromosikan artifak dan ubahnya semasa anda pergi.
Soalan ujian kendiri
Masa dari perihalan ciri untuk dikeluarkan ke dalam pengeluaran dalam 95% kes adalah kurang daripada seminggu? Adakah kualiti artifak bertambah baik pada setiap peringkat saluran paip? Adakah kisah yang dilaluinya? Adakah anda menggunakan strategi penyebaran yang berbeza?
Jika semua jawapan adalah ya, maka anda sangat hebat! Tulis jawapan anda dalam komen - Saya akan gembira).
maklum balas
Ini adalah amalan yang paling sukar. Pada persidangan DevOpsConf, rakan sekerja dari Infobip, bercakap mengenainya, agak keliru dalam kata-katanya, kerana ini benar-benar amalan yang sangat kompleks tentang hakikat bahawa anda perlu memantau segala-galanya!
Sebagai contoh, suatu masa dahulu, ketika saya bekerja di Qik dan kami menyedari bahawa kami perlu memantau segala-galanya. Kami melakukan ini, dan kami kini mempunyai 150 item dalam Zabbix, yang sentiasa dipantau. Ia menakutkan, pengarah teknikal memutar jarinya ke pelipisnya:
- Lelaki, mengapa anda merogol pelayan dengan sesuatu yang tidak jelas?
Tetapi kemudian satu insiden berlaku yang menunjukkan bahawa ini adalah strategi yang sangat hebat.
Salah satu perkhidmatan mula ranap secara berterusan. Pada mulanya, ia tidak ranap, yang menarik, kod itu tidak ditambah di sana, kerana ia adalah broker asas, yang hampir tidak mempunyai fungsi perniagaan - ia hanya menghantar mesej antara perkhidmatan individu. Perkhidmatan tidak berubah selama 4 bulan, dan tiba-tiba ia mula ranap dengan ralat "Segmentasi kesalahan".
Kami terkejut, membuka carta kami di Zabbix, dan ternyata seminggu setengah yang lalu, tingkah laku permintaan dalam perkhidmatan API yang digunakan oleh broker ini berubah dengan ketara. Seterusnya kita melihat bahawa kekerapan menghantar jenis mesej tertentu telah berubah. Kemudian kami mendapati bahawa ini adalah pelanggan android. Kami tanya:
— Kawan-kawan, apa yang berlaku kepada kamu seminggu setengah yang lalu?
Sebagai tindak balas, kami mendengar cerita menarik tentang cara mereka mereka bentuk semula UI. Tidak mungkin sesiapa akan segera mengatakan bahawa mereka telah menukar perpustakaan HTTP. Untuk pelanggan Android, ia seperti menukar sabun di bilik mandi - mereka tidak ingat. Akibatnya, selepas 40 minit perbualan, kami mendapati bahawa mereka telah menukar perpustakaan HTTP dan pemasaan lalainya telah berubah. Ini membawa kepada tingkah laku trafik pada pelayan API berubah, yang membawa kepada situasi yang menyebabkan perlumbaan dalam broker, dan ia mula ranap.
Tanpa pemantauan mendalam, secara amnya mustahil untuk membukanya. Jika organisasi masih mempunyai masalah "telaga", apabila semua orang melemparkan wang antara satu sama lain, ini boleh hidup selama bertahun-tahun. Anda hanya perlu memulakan semula pelayan kerana ia adalah mustahil untuk menyelesaikan masalah. Apabila anda memantau, menjejaki, menjejaki semua peristiwa yang anda miliki, dan menggunakan pemantauan sebagai ujian - tulis kod dan serta-merta menunjukkan cara memantaunya, juga dalam bentuk kod (kami sudah mempunyai infrastruktur sebagai kod), semuanya menjadi jelas bagaimana pada tapak tangan. Malah masalah kompleks seperti itu mudah dikesan.
Kumpulkan semua maklumat tentang perkara yang berlaku kepada artifak pada setiap peringkat proses penghantaran - bukan dalam pengeluaran.
Muat naik pemantauan ke CI, dan beberapa perkara asas akan kelihatan di sana. Kemudian anda akan melihatnya dalam Ujian, PredProd dan ujian beban. Kumpul maklumat pada semua peringkat, bukan sahaja metrik, statistik, tetapi juga log: cara aplikasi dilancarkan, anomali - kumpulkan segala-galanya.
Jika tidak, sukar untuk memikirkannya. Saya sudah mengatakan bahawa DevOps lebih kompleks. Untuk mengatasi kerumitan ini, anda perlu mempunyai analisis biasa.
Soalan untuk mengawal diri
Adakah pemantauan dan pengelogan anda alat pembangunan untuk anda? Semasa menulis kod, adakah pembangun anda, termasuk anda, memikirkan cara untuk memantaunya?
Adakah anda mendengar masalah daripada pelanggan? Adakah anda lebih memahami pelanggan daripada memantau dan mengelog? Adakah anda lebih memahami sistem daripada pemantauan dan pengelogan? Adakah anda menukar sistem hanya kerana anda melihat trend dalam sistem semakin berkembang dan anda faham bahawa dalam 3 minggu lagi semuanya akan mati?
Sebaik sahaja anda mempunyai tiga komponen ini, anda boleh memikirkan jenis platform infrastruktur yang anda ada dalam syarikat anda.
Platform infrastruktur
Maksudnya bukanlah bahawa ia adalah satu set alat yang berbeza yang dimiliki oleh setiap syarikat.
Inti dari platform infrastruktur ialah semua pasukan menggunakan alat ini dan membangunkannya bersama-sama.
Adalah jelas bahawa terdapat pasukan berasingan yang bertanggungjawab untuk pembangunan kepingan individu platform infrastruktur. Tetapi pada masa yang sama, setiap jurutera memikul tanggungjawab untuk pembangunan, prestasi dan promosi platform infrastruktur. Pada peringkat dalaman ia menjadi alat biasa.
Semua pasukan membangunkan platform infrastruktur dan memperlakukannya dengan berhati-hati sebagai IDE mereka sendiri. Dalam IDE anda, anda memasang pemalam yang berbeza untuk menjadikan semuanya bagus dan pantas, serta mengkonfigurasi kekunci pintas. Apabila anda membuka Kod Sublime, Atom atau Visual Studio, ralat kod mencurah-curah dan anda menyedari bahawa ia adalah mustahil untuk berfungsi sama sekali, anda serta-merta berasa sedih dan anda berlari untuk membetulkan IDE anda.
Layan platform infrastruktur anda dengan cara yang sama. Jika anda memahami bahawa terdapat masalah dengannya, tinggalkan permintaan jika anda tidak dapat membetulkannya sendiri. Jika ada sesuatu yang mudah, edit sendiri, hantar permintaan tarik, lelaki akan mempertimbangkannya dan menambahnya. Ini adalah pendekatan yang sedikit berbeza untuk alat kejuruteraan dalam kepala pembangun.
Platform infrastruktur memastikan pemindahan artifak daripada pembangunan kepada pelanggan dengan peningkatan berterusan dalam kualiti. IP diprogramkan dengan satu set cerita yang berlaku pada kod dalam pengeluaran. Sepanjang tahun pembangunan, terdapat banyak cerita ini, sesetengah daripadanya unik dan hanya berkaitan dengan anda - ia tidak boleh Googled.
Pada ketika ini, platform infrastruktur menjadi kelebihan daya saing anda, kerana ia mempunyai sesuatu yang terbina di dalamnya yang tidak terdapat dalam alat pesaing. Lebih mendalam IP anda, lebih besar kelebihan daya saing anda dari segi Masa ke pasaran. Muncul di sini masalah kunci vendor: Anda boleh mengambil platform orang lain, tetapi menggunakan pengalaman orang lain, anda tidak akan memahami sejauh mana ia berkaitan dengan anda. Ya, tidak setiap syarikat boleh membina platform seperti Amazon. Ini adalah garis sukar di mana pengalaman syarikat adalah berkaitan dengan kedudukannya dalam pasaran, dan anda tidak boleh menggunakan kunci vendor di sana. Perkara ini juga penting untuk difikirkan.
Skim ini
Ini ialah rajah asas platform infrastruktur yang akan membantu anda menyediakan semua amalan dan proses dalam syarikat DevOps.
Mari lihat apa yang terdiri daripadanya.
Sistem orkestrasi sumber, yang menyediakan CPU, memori, cakera kepada aplikasi dan perkhidmatan lain. Di atas ini - perkhidmatan peringkat rendah: pemantauan, pembalakan, Enjin CI/CD, penyimpanan artifak, infrastruktur sebagai kod sistem.
Perkhidmatan peringkat lebih tinggi: pangkalan data sebagai perkhidmatan, baris gilir sebagai perkhidmatan, Muatkan Baki sebagai perkhidmatan, saiz semula imej sebagai perkhidmatan, kilang Data Besar sebagai perkhidmatan. Di atas ini - saluran paip yang menyampaikan kod yang sentiasa diubah suai kepada pelanggan anda.
Anda menerima maklumat tentang cara perisian anda berfungsi untuk pelanggan, menukarnya, membekalkan kod ini sekali lagi, menerima maklumat - dan oleh itu anda sentiasa membangunkan platform infrastruktur dan perisian anda.
Dalam rajah, saluran paip penghantaran terdiri daripada banyak peringkat. Tetapi ini adalah gambar rajah skematik yang diberikan sebagai contoh - tidak perlu mengulanginya satu persatu. Peringkat berinteraksi dengan perkhidmatan seolah-olah ia adalah perkhidmatan—setiap bata platform membawa ceritanya sendiri: cara sumber diperuntukkan, cara aplikasi dilancarkan, berfungsi dengan sumber, dipantau dan berubah.
Adalah penting untuk memahami bahawa setiap bahagian platform membawa cerita, dan tanya diri anda cerita apa yang dibawa oleh bata ini, mungkin ia harus dibuang dan digantikan dengan perkhidmatan pihak ketiga. Sebagai contoh, adakah mungkin untuk memasang Okmeter dan bukannya batu bata? Mungkin mereka telah mengembangkan kepakaran ini lebih daripada yang kita ada. Tetapi mungkin tidak - mungkin kami mempunyai kepakaran unik, kami perlu memasang Prometheus dan mengembangkannya lagi.
Penciptaan platform
Ini adalah proses komunikasi yang kompleks. Apabila anda mempunyai amalan asas, anda memulakan komunikasi antara jurutera dan pakar yang berbeza yang membangunkan keperluan dan piawaian, dan sentiasa menukarnya kepada alatan dan pendekatan yang berbeza. Budaya yang kita ada dalam DevOps adalah penting di sini.
Dengan budaya semuanya sangat mudah - ia mengenai kerjasama dan komunikasi, iaitu keinginan untuk bekerja dalam bidang yang sama antara satu sama lain, keinginan untuk menggunakan satu instrumen bersama-sama. Tiada sains roket di sini - semuanya sangat mudah, cetek. Sebagai contoh, kita semua tinggal di pintu masuk dan menjaga kebersihan - tahap budaya sedemikian.
Apa yang kamu ada?
Sekali lagi, soalan yang anda boleh tanya sendiri.
Adakah platform infrastruktur didedikasikan? Siapa yang bertanggungjawab untuk pembangunannya? Adakah anda memahami kelebihan daya saing platform infrastruktur anda?
Anda perlu sentiasa bertanya kepada diri sendiri soalan-soalan ini. Jika sesuatu boleh dipindahkan ke perkhidmatan pihak ketiga, ia harus dipindahkan; jika perkhidmatan pihak ketiga mula menyekat pergerakan anda, maka anda perlu membina sistem dalam diri anda.
Jadi, DevOps...
... ini adalah sistem yang kompleks, ia mesti mempunyai:
- Produk digital.
- Modul perniagaan yang membangunkan produk digital ini.
- Pasukan produk yang menulis kod.
- Amalan Penghantaran Berterusan.
- Platform sebagai perkhidmatan.
- Infrastruktur sebagai perkhidmatan.
- Infrastruktur sebagai kod.
- Amalan berasingan untuk mengekalkan kebolehpercayaan, terbina dalam DevOps.
- Amalan maklum balas yang menerangkan semuanya.
Anda boleh menggunakan rajah ini, menyerlahkan di dalamnya perkara yang anda sudah ada dalam syarikat anda dalam beberapa bentuk: adakah ia telah dibangunkan atau masih perlu dibangunkan.
Ia akan berakhir dalam beberapa minggu . sebagai sebahagian daripada RIT++. Datang ke persidangan itu, di mana anda akan menemui banyak laporan hebat tentang penghantaran berterusan, infrastruktur sebagai kod dan transformasi DevOps. , tarikh akhir harga terakhir ialah 20 Mei
Sumber: www.habr.com