Definisi DevOps sangat kompleks, jadi kita harus memulai pembahasannya lagi setiap saat. Ada ribuan publikasi mengenai topik ini di Habré saja. Namun jika Anda membaca ini, Anda mungkin tahu apa itu DevOps. Karena aku tidak. Halo, namaku adalah Alexander Titov (@), dan kita hanya akan membicarakan DevOps dan saya akan berbagi pengalaman saya.
Saya sudah lama berpikir tentang bagaimana membuat cerita saya bermanfaat, jadi akan ada banyak pertanyaan di sini - pertanyaan yang saya tanyakan pada diri saya sendiri dan pertanyaan yang saya tanyakan kepada klien perusahaan kami. Dengan menjawab pertanyaan-pertanyaan tersebut, pemahaman menjadi lebih baik. Saya akan memberi tahu Anda mengapa DevOps diperlukan dari sudut pandang saya, apa itu, sekali lagi, dari sudut pandang saya, dan bagaimana memahami bahwa Anda kembali beralih ke DevOps dari sudut pandang saya. Poin terakhir adalah melalui pertanyaan. Dengan menjawabnya sendiri, Anda dapat memahami apakah perusahaan Anda bergerak menuju DevOps atau ada masalah tertentu.
Pada suatu waktu saya sedang menghadapi gelombang merger dan akuisisi. Pertama, saya bekerja di sebuah startup kecil bernama Qik, kemudian dibeli oleh perusahaan yang sedikit lebih besar bernama Skype, yang kemudian dibeli oleh perusahaan yang sedikit lebih besar bernama Microsoft. Pada saat itu, saya mulai melihat bagaimana ide DevOps bertransformasi di berbagai ukuran perusahaan. Setelah itu, saya menjadi tertarik untuk melihat DevOps dari sudut pandang pasar, dan saya serta rekan-rekan mendirikan perusahaan Express 42. Selama 6 tahun sekarang kami telah bergerak mengikuti gelombang pasar.
Antara lain, saya adalah salah satu penyelenggara komunitas DevOps Moskow dan penyelenggara DevOps-Days 2017, tetapi saya tidak menyelenggarakan tahun 2018. Express 42 bekerja dengan banyak perusahaan. Kami mengembangkan DevOps di sana, mengamati bagaimana hal itu terjadi, menarik kesimpulan, menganalisis, menyampaikan kesimpulan kami kepada semua orang, dan melatih orang-orang dalam praktik DevOps. Secara umum, kami melakukan yang terbaik untuk meningkatkan pengalaman dan keahlian kami dalam hal ini.
Mengapa DevOps
Pertanyaan pertama yang selalu menghantui semua orang adalah - mengapa? Banyak orang mengira DevOps hanyalah otomatisasi atau sejenisnya yang sudah dimiliki setiap perusahaan.
— Kami memiliki Integrasi Berkelanjutan - ini berarti kami sudah memiliki DevOps, dan mengapa semua hal ini diperlukan? Mereka bersenang-senang di luar negeri, tapi mereka melarang kita bekerja!
Selama 9 tahun pengembangan komunitas dan metodologi, sudah menjadi jelas bahwa hal ini masih belum cemerlang dalam pemasaran, namun masih belum sepenuhnya jelas mengapa hal ini diperlukan. Seperti alat dan proses lainnya, DevOps memiliki tujuan spesifik yang pada akhirnya dapat dicapai.
Semua ini disebabkan oleh kenyataan bahwa dunia sedang berubah. Dia menjauh dari pendekatan perusahaan, ketika perusahaan bergerak langsung menuju mimpi, seperti yang dinyanyikan oleh karya klasik St. Petersburg kami, dari titik A ke titik B sesuai dengan strategi tertentu, dengan struktur tertentu yang dibangun untuk ini.
Pada prinsipnya, segala sesuatu di TI harus dibangun berdasarkan pendekatan ini. Di sini TI digunakan secara eksklusif untuk mengotomatisasi proses.
Otomatisasi tidak sering berubah, karena ketika sebuah perusahaan mengalami kemunduran, apa yang perlu diubah? Berhasil - jangan sentuh. Kini pendekatan di dunia sedang berubah, dan pendekatan yang disebut Agile menunjukkan bahwa titik akhir B tidak segera terlihat.
Ketika sebuah perusahaan melewati pasar, bekerja dengan klien, ia terus-menerus mengeksplorasi pasar dan mengubah titik akhir B. Selain itu, semakin sering perusahaan mengubah arahnya, semakin sukses pada akhirnya, karena lebih banyak memilih pasar. ceruk.
Strategi ini ditunjukkan oleh sebuah perusahaan menarik yang baru-baru ini saya pelajari. One Box Shave adalah layanan pengiriman langganan pisau cukur dan aksesoris cukur dalam kotak. Mereka tahu cara menyesuaikan “kotak” mereka untuk klien yang berbeda. Hal ini dilakukan oleh perangkat lunak tertentu, yang kemudian mengirimkan pesanan ke pabrik Korea yang memproduksi barang tersebut.
Produk ini dibeli oleh Unilever seharga $1 miliar. Kini perusahaan ini bersaing dengan Gillette dan telah mengambil alih sebagian besar konsumen di pasar Amerika. Satu Kotak Cukur katakan:
— 4 bilah? Apa kamu serius? Mengapa Anda memerlukannya - ini tidak meningkatkan kualitas pencukuran. Krim pilihan khusus, pewangi, dan pisau cukur berkualitas tinggi dengan dua bilah memecahkan lebih banyak masalah daripada 4 bilah Gillette yang bodoh itu! Akankah kita segera sampai ke 10?
Beginilah dunia berubah. Unilever mengklaim bahwa mereka memiliki sistem IT keren yang memungkinkan Anda melakukan hal ini. Pada akhirnya itu tampak seperti sebuah konsep Waktu-ke-pasar, yang belum pernah dibicarakan oleh siapa pun.
Inti dari Time-to-market bukanlah seberapa sering kita menerapkannya. Anda sering kali dapat menerapkannya, tetapi siklus rilisnya akan lama. Jika siklus rilis tiga bulan ditumpangkan satu sama lain, menggesernya seminggu, ternyata perusahaan tersebut tampaknya menerapkannya seminggu sekali. Dan dari ide hingga implementasi akhir membutuhkan waktu 3 bulan.
Time-to-market adalah tentang meminimalkan waktu mulai dari ide hingga implementasi akhir.
Dalam hal ini, perangkat lunak berinteraksi dengan pasar. Beginilah cara situs web One Box Shave berinteraksi dengan klien. Mereka tidak memiliki tenaga penjualan - hanya sebuah situs web tempat pengunjung mengeklik dan meninggalkan keinginan. Oleh karena itu, sesuatu yang baru harus terus-menerus diposting di situs dan diperbarui sesuai dengan keinginan. Misalnya, di Korea Selatan mereka bercukur dengan cara yang berbeda dibandingkan di Rusia, dan mereka tidak menyukai aroma pinus, tetapi, misalnya, wortel dan vanila.
Karena konten situs perlu diubah dengan cepat, pengembangan perangkat lunak banyak berubah. Melalui software kita harus mengetahui apa yang diinginkan klien. Sebelumnya kita mempelajarinya melalui beberapa cara tidak langsung, misalnya melalui manajemen bisnis. Lalu kami merancangnya, memasukkan persyaratan ke dalam sistem TI, dan semuanya baik-baik saja. Sekarang berbeda - perangkat lunak dirancang oleh semua orang yang terlibat dalam proses tersebut, termasuk para insinyur, karena melalui spesifikasi teknis mereka mempelajari cara kerja pasar dan juga berbagi wawasan mereka dengan bisnis.
Misalnya, di Qik kami tiba-tiba mengetahui bahwa orang-orang sangat suka mengunggah daftar kontak ke server, dan mereka memberi kami sebuah aplikasi. Awalnya kami tidak memikirkannya. Di perusahaan klasik, semua orang akan memutuskan bahwa ini adalah bug, karena spesifikasi tidak mengatakan bahwa itu harus berfungsi dengan baik dan umumnya diterapkan secara langsung, mereka akan mematikan fitur tersebut dan berkata: “Tidak ada yang membutuhkan ini, yang penting fungsi utamanya berfungsi.” . Dan perusahaan teknologi melihat ini sebagai peluang dan mulai mengubah perangkat lunaknya sesuai dengan hal tersebut.
Pada tahun 1968, seorang visioner, Melvin Conway, merumuskan gagasan berikut.
Organisasi yang menciptakan sistem dibatasi oleh desain yang mereplikasi struktur komunikasi organisasi tersebut.
Secara lebih rinci, untuk menghasilkan sistem dengan tipe yang berbeda, Anda juga harus memiliki struktur komunikasi dalam perusahaan dengan tipe yang berbeda. Jika struktur komunikasi Anda bersifat hierarkis teratas, maka hal ini tidak memungkinkan Anda membuat sistem yang dapat memberikan indikator Time-to-Market yang sangat tinggi.
Membaca satu bisa . Penting untuk memahami budaya atau filosofi DevOps karena satu-satunya hal yang berubah secara mendasar dalam DevOps adalah struktur komunikasi antar tim.
Dari sudut pandang proses, sebelum DevOps, semua tahapan: analitik, pengembangan, pengujian, operasi, bersifat linier.
Dalam kasus DevOps, semua proses ini terjadi secara bersamaan.
Time-to-market adalah satu-satunya cara yang bisa dilakukan. Bagi orang-orang yang bekerja dalam proses lama, ini terlihat agak kosmis, dan umumnya biasa saja.
Jadi mengapa Anda membutuhkan DevOps?
Untuk pengembangan produk digital. Jika perusahaan Anda tidak memiliki produk digital, DevOps tidak diperlukan - ini sangat penting.
DevOps mengatasi keterbatasan kecepatan produksi perangkat lunak sekuensial. Di dalamnya semua proses terjadi secara bersamaan.
Kesulitan meningkat. Ketika penginjil DevOps memberi tahu Anda bahwa ini akan memudahkan Anda merilis perangkat lunak, ini tidak masuk akal.
Dengan DevOps, segalanya akan menjadi lebih rumit.
Pada konferensi di stand Avito, Anda dapat melihat bagaimana rasanya menerapkan container Docker - sebuah tugas yang tidak realistis. Kompleksitasnya menjadi penghalang; Anda harus menyulap banyak bola secara bersamaan.
DevOps sepenuhnya mengubah proses dan organisasi di perusahaan — lebih tepatnya, bukan DevOps yang berubah, melainkan produk digitalnya. Untuk masuk ke DevOps, Anda masih perlu mengubah proses ini sepenuhnya.
Pertanyaan untuk seorang spesialis
Apa yang kamu punya? Pertanyaan yang dapat Anda tanyakan pada diri sendiri saat bekerja di sebuah perusahaan dan berkembang sebagai seorang spesialis.
Apakah Anda memiliki strategi untuk menciptakan produk digital? Kalau ada, itu sudah bagus. Ini berarti perusahaan Anda beralih ke DevOps.
Apakah perusahaan Anda sudah menciptakan produk digital? Ini berarti Anda dapat naik level lebih tinggi dan melakukan berbagai hal dengan lebih menarik – sekali lagi dari sudut pandang DevOps. Saya hanya berbicara dari sudut pandang ini.
Apakah perusahaan Anda salah satu pemimpin pasar di ceruk produk digital? Spotify, Yandex, Uber adalah perusahaan yang saat ini berada di puncak kemajuan teknologi.
Tanyakan pada diri Anda pertanyaan-pertanyaan ini, dan jika semua jawabannya tidak, mungkin Anda sebaiknya tidak melakukan DevOps di perusahaan ini. Jika topik DevOps benar-benar menarik bagi Anda, mungkin... sebaiknya Anda pindah ke perusahaan lain? Jika perusahaan Anda ingin terjun ke DevOps, tetapi Anda menjawab “Tidak” untuk semua pertanyaan, maka badak cantik itu seperti itu yang tidak akan pernah berubah.
Organisasi
Seperti yang saya katakan, menurut Hukum Conway, organisasi perusahaan berubah. Saya akan mulai dengan apa yang mencegah DevOps menembus perusahaan dari sudut pandang organisasi.
Masalah "sumur"
Kata bahasa Inggris "Silo" di sini diterjemahkan ke dalam bahasa Rusia sebagai "baik". Inti dari permasalahan ini adalah tidak ada pertukaran informasi antar tim. Setiap tim menggali lebih dalam keahliannya, tanpa membangun peta umum untuk dinavigasi.
Dalam beberapa hal, hal ini mengingatkan saya pada seseorang yang baru saja tiba di Moskow dan belum mengetahui cara menavigasi peta metro. Warga Moskow biasanya mengetahui wilayah mereka dengan baik, dan mereka dapat bernavigasi di seluruh Moskow menggunakan peta metro. Ketika Anda datang ke Moskow untuk pertama kalinya, Anda tidak memiliki keterampilan ini, dan Anda hanya mengalami disorientasi.
DevOps menyarankan untuk melewati momen disorientasi ini dan semua departemen bekerja sama untuk membangun peta interaksi bersama.
Ada dua faktor yang menghambat hal ini.
Konsekuensi dari sistem manajemen perusahaan. Itu dibangun dalam “sumur” hierarki yang terpisah. Misalnya ada KPI tertentu di perusahaan yang mendukung sistem ini. Di sisi lain, otak seseorang yang merasa sulit untuk melampaui batas keahliannya dan menavigasi seluruh sistem akan menghalanginya. Itu tidak nyaman. Bayangkan Anda berada di bandara Bangkok - Anda tidak akan menemukan jalan keluar dengan cepat. DevOps juga sulit dinavigasi, dan itulah mengapa orang mengatakan Anda perlu mencari panduan untuk mencapainya.
Namun yang paling penting adalah bahwa masalah “sumur” bagi seorang insinyur yang dijiwai dengan semangat DevOps, telah membaca Fowler dan banyak buku lainnya, terungkap dalam kenyataan bahwa "sumur" tidak mengizinkan Anda melakukan hal-hal yang "jelas".. Kami sering berkumpul setelah DevOps Moscow, berbicara satu sama lain, dan orang-orang mengeluh:
— Kami baru ingin meluncurkan CI, tapi ternyata manajemen tidak membutuhkannya.
Hal ini terjadi justru karena CI и Proses Pengiriman Berkelanjutan berada di perbatasan banyak ujian. Tanpa mengatasi masalah “sumur” di tingkat organisasi, Anda tidak akan bisa maju, apa pun yang Anda lakukan dan betapapun menyedihkannya.
Setiap peserta dalam proses di perusahaan: pengembang backend dan frontend, pengujian, DBA, operasi, jaringan, menggali ke arah mereka sendiri, dan tidak ada yang memiliki peta umum kecuali manajer, yang entah bagaimana memantau dan mengelolanya menggunakan “dibagi” dan menaklukkan”.
Orang-orang berebut bintang atau bendera, semua orang menggali keahliannya.
Akibatnya, ketika muncul tugas untuk menghubungkan semua ini dan membangun jalur pipa bersama, dan tidak ada lagi kebutuhan untuk memperjuangkan bintang dan bendera, muncul pertanyaan - apa yang harus dilakukan? Kami harus mencapai kesepakatan, tapi tidak ada yang mengajari kami cara melakukan ini di sekolah. Kami telah diajar sejak sekolah: kelas delapan - wow! - dibandingkan dengan kelas tujuh! Di sini sama saja.
Apakah hal yang sama terjadi di perusahaan Anda?
Untuk memeriksanya, Anda dapat bertanya pada diri sendiri pertanyaan-pertanyaan berikut.
Apakah tim menggunakan alat yang sama dan berkontribusi terhadap perubahan pada alat yang umum tersebut?
Seberapa sering tim melakukan reorganisasi—beberapa spesialis dari satu tim berpindah ke tim lain? Di lingkungan DevOps hal ini menjadi normal, karena terkadang seseorang tidak dapat memahami apa yang dilakukan bidang keahlian lain. Dia pindah ke departemen lain, bekerja di sana selama dua minggu untuk membuat sendiri peta orientasi dan interaksi dengan departemen ini.
Apakah mungkin untuk membentuk komite perubahan dan mengubah keadaan? Ataukah hal itu memerlukan tangan kuat dari manajemen dan pengarahan tertinggi? Saya baru-baru ini menulis di Facebook bagaimana sebuah bank yang kurang dikenal menerapkan alat melalui pesanan: kami menulis pesanan, kami menerapkannya selama satu tahun, dan lihat apa yang terjadi. Tentu saja hal ini sangat panjang dan menyedihkan.
Seberapa pentingkah manajer menerima prestasi pribadi tanpa mempertimbangkan prestasi perusahaan?
Jika Anda menjawab sendiri pertanyaan-pertanyaan ini, akan menjadi lebih jelas apakah Anda memiliki masalah seperti itu di perusahaan Anda.
Infrastruktur sebagai kode
Setelah masalah ini diatasi, praktik penting pertama, yang tanpanya sulit untuk maju lebih jauh dalam DevOps, adalah infrastruktur sebagai kode.
Paling sering, infrastruktur sebagai kode dianggap sebagai berikut:
— Mari kita otomatisasi semuanya di bash, tutupi diri kita dengan skrip sehingga admin memiliki lebih sedikit pekerjaan manual!
Tapi itu tidak benar.
Infrastruktur sebagai kode berarti Anda menggambarkan sistem TI tempat Anda bekerja dalam bentuk kode untuk terus memahami keadaannya.
Bersama dengan tim lain, Anda membuat peta dalam bentuk kode yang dapat dipahami dan dinavigasi oleh semua orang. Tidak peduli apa yang dilakukan – Chef, Ansible, Salt, atau menggunakan file YAML di Kubernetes – tidak ada perbedaan.
Pada konferensi tersebut, seorang kolega dari 2GIS menceritakan bagaimana mereka membuat internalnya sendiri untuk Kubernetes, yang menggambarkan struktur sistem individual. Untuk mendeskripsikan 500 sistem, mereka memerlukan alat terpisah yang menghasilkan deskripsi ini. Ketika ada gambaran ini, semua orang bisa saling mengecek, memantau perubahan, bagaimana cara mengubahnya dan memperbaikinya, apa saja yang kurang.
Setuju, skrip bash individual biasanya tidak memberikan pemahaman ini. Di salah satu perusahaan tempat saya bekerja, bahkan ada yang namanya skrip “write only” - ketika skrip sudah ditulis, tetapi sudah tidak bisa dibaca lagi. Saya rasa ini juga familiar bagi Anda.
Infrastruktur sebagai kode kode yang menggambarkan keadaan infrastruktur saat ini. Banyak tim produk, infrastruktur, dan layanan bekerja sama dalam kode ini, dan yang terpenting, mereka semua perlu memahami cara kerja sebenarnya kode ini.
Kode ini dikelola sesuai dengan praktik kode terbaik: pengembangan bersama, tinjauan kode, pemrograman XP, pengujian, permintaan tarik, CI untuk infrastruktur kode - semua ini cocok dan dapat digunakan.
Kode menjadi bahasa umum bagi semua insinyur.
Mengubah infrastruktur dalam kode tidak memakan banyak waktu. Ya, kode infrastruktur juga dapat memiliki utang teknis. Biasanya tim menghadapinya satu setengah tahun setelah mereka mulai menerapkan “infrastruktur sebagai kode” dalam bentuk sekumpulan skrip atau bahkan Ansible, yang mereka tulis seperti kode spageti, dan mereka juga memasukkan skrip bash ke dalam campuran!
Ini penting: Jika Anda belum mencoba hal ini, ingatlah itu Kemungkinan bukan bash! Baca dokumentasinya dengan cermat, pelajari apa yang mereka tulis tentangnya.
Infrastruktur sebagai kode adalah pemisahan kode infrastruktur menjadi beberapa lapisan terpisah.
Di perusahaan kami, kami membedakan 3 lapisan dasar, yang sangat jelas dan sederhana, tetapi mungkin ada lebih banyak lagi. Anda dapat melihat kode infrastruktur Anda dan mengetahui apakah Anda memiliki kondisi ini atau tidak. Jika tidak ada lapisan yang disorot, maka Anda perlu meluangkan waktu dan sedikit melakukan refaktorisasi.
lapisan dasar - ini adalah bagaimana OS, cadangan, dan hal-hal tingkat rendah lainnya dikonfigurasi, misalnya, bagaimana Kubernetes diterapkan pada tingkat dasar.
Tingkat layanan - ini adalah layanan yang Anda berikan kepada pengembang: logging sebagai layanan, pemantauan sebagai layanan, database sebagai layanan, penyeimbang sebagai layanan, antrian sebagai layanan, Pengiriman Berkelanjutan sebagai layanan - sekumpulan layanan yang masing-masing tim dapat memberikan kontribusi bagi pembangunan. Ini semua perlu dijelaskan dalam modul terpisah di sistem manajemen konfigurasi Anda.
Lapisan tempat aplikasi dibuat dan menjelaskan bagaimana lapisan tersebut akan terbuka di atas dua lapisan sebelumnya.
Kontrol pertanyaan
Apakah perusahaan Anda memiliki repositori infrastruktur umum? Apakah Anda mengelola utang teknis di infrastruktur Anda? Apakah Anda menggunakan praktik pengembangan di repositori infrastruktur? Apakah infrastruktur Anda terpecah-pecah? Anda dapat memeriksa diagram Base-service-APP. Seberapa sulitkah melakukan perubahan?
Jika Anda pernah mengalami bahwa perlu waktu satu setengah hari untuk melakukan perubahan, ini berarti Anda memiliki hutang teknis dan perlu mengatasinya. Anda baru saja menemukan utang teknis dalam kode infrastruktur Anda. Saya ingat banyak cerita seperti itu ketika, untuk mengubah beberapa CCTL, Anda perlu menulis ulang setengah dari kode infrastruktur, karena kreativitas dan keinginan untuk mengotomatiskan segalanya mengarah pada fakta bahwa semuanya terkorosi di mana-mana, semua pegangan telah dilepas, dan perlu dilakukan refaktorisasi.
Pengiriman Berkelanjutan
Mari kita bandingkan debit dengan kredit. Yang pertama adalah penjelasan tentang infrastruktur, yang mungkin cukup mendasar. Anda tidak harus menjelaskan semuanya secara detail, tetapi diperlukan beberapa deskripsi dasar agar Anda dapat mengerjakannya. Jika tidak, tidak jelas apa yang harus dilakukan selanjutnya dengan pengiriman berkelanjutan. Semua praktik ini terjadi secara bersamaan saat Anda menggunakan DevOps, namun hal ini dimulai dengan memahami apa yang Anda miliki dan cara mengelolanya. Inilah tepatnya praktik infrastruktur sebagai kode.
Setelah jelas bahwa Anda memilikinya dan cara mengelolanya, Anda mulai memikirkan cara mengirim kode pengembang ke produksi secepat mungkin. Maksud saya bersama dengan pengembang - kita ingat tentang masalah “sumur”, yaitu bukan individu yang mengemukakan hal ini, tetapi sebuah tim.
Saat kita bersama Vanya Evtukhovich melihat buku pertama Jez Rendah Hati dan kelompok penulis "Pengiriman Berkelanjutan", yang dirilis pada tahun 2009, kami sudah lama memikirkan bagaimana menerjemahkan judulnya ke dalam bahasa Rusia. Mereka ingin menerjemahkannya sebagai “Pengiriman terus-menerus”, tetapi sayangnya, diterjemahkan sebagai “Pengiriman berkelanjutan”. Bagi saya, sepertinya ada sesuatu yang Rusia dalam nama kami, dengan tekanan.
Terus-menerus memberikan sarana
Kode yang ada di repositori produk selalu dapat diunduh ke produksi. Dia mungkin tidak kecewa, tapi dia selalu siap menghadapinya. Oleh karena itu, Anda selalu menulis kode dengan perasaan cemas yang sulit dijelaskan. Ini sering muncul saat Anda meluncurkan kode infrastruktur. Perasaan cemas ini harus ada - ini memicu proses otak yang memungkinkan Anda menulis kode sedikit berbeda. Hal ini harus dicatat dalam peraturan dalam pembangunan.
Untuk menyampaikan secara konsisten, Anda memerlukan format artefak yang berjalan di seluruh platform infrastruktur. Jika Anda membuang “sampah kehidupan” dengan format berbeda ke seluruh platform infrastruktur, maka hal tersebut akan menjadi satu kesatuan, sulit untuk dikelola, dan timbullah masalah utang teknis. Format artefak perlu diselaraskan - ini juga merupakan tugas kolektif: kita semua harus berkumpul, menggerakkan otak, dan menghasilkan format ini.
Artefak terus ditingkatkan dan diubah agar sesuai dengan lingkungan produksi saat bergerak melalui jalur pengiriman. Saat artefak bergerak di sepanjang jalur pipa, artefak tersebut terus-menerus menemui beberapa hal yang tidak nyaman, yang mirip dengan apa yang ditemui artefak yang Anda masukkan ke dalam produksi. Jika dalam pengembangan klasik hal ini dilakukan oleh administrator sistem yang melakukan peluncuran, maka dalam proses DevOps hal ini selalu terjadi: di sini mereka mengujinya dengan beberapa tes, di sini mereka melemparkannya ke cluster Kubernetes, yang kurang lebih mirip ke produksi, lalu tiba-tiba mereka memulai pengujian beban.
Ini agak mengingatkan pada permainan Pac-Man - artefaknya melewati semacam cerita. Pada saat yang sama, penting untuk mengontrol apakah kode tersebut benar-benar berjalan dalam cerita dan apakah kode tersebut terkait dengan produksi Anda. Cerita dari produksi bisa diseret ke dalam proses Pengiriman Berkelanjutan: seperti ini ketika ada sesuatu yang jatuh, sekarang mari kita program skenario ini di dalam sistem. Setiap kali kode akan melewati skenario ini juga, dan Anda tidak akan mengalami masalah ini di lain waktu. Anda akan mempelajarinya jauh sebelum hal itu sampai ke klien Anda.
Strategi penerapan yang berbeda. Misalnya, Anda menggunakan pengujian AB atau penerapan canary untuk menguji kode secara berbeda pada klien yang berbeda, mendapatkan informasi tentang cara kerja kode, dan jauh lebih awal dibandingkan saat kode tersebut diluncurkan ke 100 juta pengguna.
“Memberikan secara konsisten” terlihat seperti ini.
Proses pengiriman Dev, CI, Test, PreProd, Prod bukanlah lingkungan yang terpisah, ini adalah tahapan atau stasiun dengan jumlah tahan api yang dilalui artefak Anda.
Jika Anda memiliki kode infrastruktur yang digambarkan sebagai Base Service APP maka itu membantu jangan lupa semua skripnya, dan tuliskan sebagai kode untuk artefak ini, mempromosikan artefak dan mengubahnya seiring berjalannya waktu.
Pertanyaan tes mandiri
Waktu dari deskripsi fitur hingga rilis ke produksi dalam 95% kasus kurang dari seminggu? Apakah kualitas artefak meningkat pada setiap tahap proses? Apakah ada cerita yang dilaluinya? Apakah Anda menggunakan strategi penerapan yang berbeda?
Jika semua jawabannya ya, maka Anda luar biasa keren! Tulis jawaban Anda di komentar - saya akan senang).
umpan balik
Ini adalah praktik yang paling sulit. Pada konferensi DevOpsConf, seorang rekan dari Infobip, membicarakannya, sedikit bingung dalam perkataannya, karena ini benar-benar praktik yang sangat kompleks tentang fakta bahwa Anda perlu memantau semuanya!
Misalnya, dulu sekali, ketika saya bekerja di Qik dan kami menyadari bahwa kami perlu memantau semuanya. Kami melakukan ini, dan sekarang kami memiliki 150 item di Zabbix, yang terus dipantau. Menakutkan, direktur teknis memutar jarinya di pelipisnya:
- Guys, kenapa kamu memperkosa server dengan sesuatu yang tidak jelas?
Namun kemudian terjadi sebuah kejadian yang menunjukkan bahwa ini memang strategi yang sangat keren.
Salah satu layanan mulai mogok terus-menerus. Awalnya, itu tidak crash, yang menarik, kodenya tidak ditambahkan di sana, karena itu adalah broker dasar, yang praktis tidak memiliki fungsi bisnis - hanya mengirim pesan antar layanan individual. Layanan tidak berubah selama 4 bulan, dan tiba-tiba mulai mogok dengan kesalahan “Kesalahan segmentasi”.
Kami terkejut, membuka grafik kami di Zabbix, dan ternyata satu setengah minggu yang lalu, perilaku permintaan pada layanan API yang digunakan broker ini banyak berubah. Selanjutnya kita melihat bahwa frekuensi pengiriman jenis pesan tertentu telah berubah. Kemudian kami mengetahui bahwa ini adalah klien Android. Kami bertanya:
— Teman-teman, apa yang terjadi padamu satu setengah minggu yang lalu?
Sebagai tanggapan, kami mendengar cerita menarik tentang bagaimana mereka mendesain ulang UI. Kecil kemungkinannya ada orang yang akan langsung mengatakan bahwa mereka mengubah pustaka HTTP. Untuk klien Android, ini seperti mengganti sabun di kamar mandi - mereka tidak ingat. Hasilnya, setelah 40 menit percakapan, kami menemukan bahwa mereka telah mengubah perpustakaan HTTP, dan pengaturan waktu defaultnya telah berubah. Hal ini menyebabkan perilaku lalu lintas di server API berubah, yang menyebabkan situasi yang menyebabkan perlombaan di dalam broker, dan mulai mogok.
Tanpa pemantauan mendalam, umumnya mustahil untuk membukanya. Jika organisasi masih mempunyai masalah “sumur”, yaitu ketika setiap orang saling melempar uang, masalah ini dapat bertahan bertahun-tahun. Anda cukup me-restart server karena tidak mungkin menyelesaikan masalah. Ketika Anda memantau, melacak, melacak semua peristiwa yang Anda miliki, dan menggunakan pemantauan sebagai pengujian - tulis kode dan segera tunjukkan cara memantaunya, juga dalam bentuk kode (kami sudah memiliki infrastruktur sebagai kode), semuanya menjadi jelas caranya di telapak tangan. Bahkan masalah rumit seperti itu pun mudah dilacak.
Kumpulkan semua informasi tentang apa yang terjadi pada artefak di setiap tahap proses pengiriman - bukan dalam produksi.
Unggah pemantauan ke CI, dan beberapa hal dasar sudah terlihat di sana. Nanti Anda akan melihatnya di Test, PredProd, dan pengujian beban. Kumpulkan informasi di semua tahap, tidak hanya metrik, statistik, tetapi juga log: bagaimana aplikasi diluncurkan, anomali - kumpulkan semuanya.
Kalau tidak, akan sulit untuk mengetahuinya. Saya sudah mengatakan bahwa DevOps lebih kompleks. Untuk mengatasi kompleksitas ini, Anda perlu memiliki analisis yang normal.
Pertanyaan untuk pengendalian diri
Apakah pemantauan dan pencatatan Anda merupakan alat pengembangan untuk Anda? Saat menulis kode, apakah pengembang Anda, termasuk Anda, memikirkan cara memantaunya?
Apakah Anda mendengar tentang masalah dari pelanggan? Apakah Anda lebih memahami klien dari pemantauan dan pencatatan? Apakah Anda memahami sistem dengan lebih baik dari pemantauan dan pencatatan? Apakah Anda mengubah sistem hanya karena Anda melihat tren dalam sistem sedang berkembang dan Anda memahami bahwa dalam 3 minggu ke depan semuanya akan mati?
Setelah Anda memiliki ketiga komponen ini, Anda dapat memikirkan jenis platform infrastruktur yang Anda miliki di perusahaan Anda.
Platform infrastruktur
Intinya bukanlah bahwa ini merupakan seperangkat alat berbeda yang dimiliki setiap perusahaan.
Inti dari platform infrastruktur adalah semua tim menggunakan alat ini dan mengembangkannya bersama.
Jelas bahwa terdapat tim terpisah yang bertanggung jawab atas pengembangan masing-masing bagian dari platform infrastruktur. Namun pada saat yang sama, setiap insinyur memikul tanggung jawab atas pengembangan, kinerja, dan promosi platform infrastruktur. Pada tingkat internal, hal ini menjadi alat yang umum.
Semua tim mengembangkan platform infrastruktur dan memperlakukannya dengan hati-hati sebagai IDE mereka sendiri. Di IDE Anda, Anda menginstal plugin yang berbeda untuk membuat semuanya bagus dan cepat, dan mengkonfigurasi hotkey. Saat Anda membuka Sublime, Atom, atau Visual Studio Code, kesalahan kode berdatangan dan Anda menyadari bahwa tidak mungkin berfungsi sama sekali, Anda langsung merasa sedih dan berlari untuk memperbaiki IDE Anda.
Perlakukan platform infrastruktur Anda dengan cara yang sama. Jika Anda memahami ada yang salah dengannya, tinggalkan permintaan jika Anda tidak dapat memperbaikinya sendiri. Kalau ada yang sederhana, edit sendiri, kirim pull request, teman-teman akan mempertimbangkannya dan menambahkannya. Ini adalah pendekatan yang sedikit berbeda terhadap alat teknik di kepala pengembang.
Platform infrastruktur memastikan transfer artefak dari pengembangan ke klien dengan peningkatan kualitas yang berkelanjutan. IP diprogram dengan serangkaian cerita yang terjadi pada kode dalam produksi. Selama bertahun-tahun pengembangan, ada banyak cerita seperti ini, beberapa di antaranya unik dan hanya berhubungan dengan Anda - tidak dapat dicari di Google.
Pada titik ini, platform infrastruktur menjadi keunggulan kompetitif Anda, karena ada sesuatu yang tertanam di dalamnya yang tidak ada pada alat pesaing. Semakin dalam IP Anda, semakin besar keunggulan kompetitif Anda dalam hal Time-to-market. Muncul di sini masalah kunci vendor: Anda dapat menggunakan platform orang lain, tetapi dengan menggunakan pengalaman orang lain, Anda tidak akan memahami betapa relevannya hal itu bagi Anda. Ya, tidak semua perusahaan bisa membangun platform seperti Amazon. Ini adalah garis yang sulit di mana pengalaman perusahaan relevan dengan posisinya di pasar, dan Anda tidak dapat menggunakan kunci vendor di sana. Hal ini juga penting untuk dipikirkan.
Skema itu
Ini adalah diagram dasar platform infrastruktur yang akan membantu Anda menyiapkan semua praktik dan proses di perusahaan DevOps.
Mari kita lihat apa isinya.
Sistem orkestrasi sumber daya, yang menyediakan CPU, memori, disk hingga aplikasi dan layanan lainnya. Selain itu - layanan tingkat rendah: pemantauan, logging, Mesin CI/CD, penyimpanan artefak, infrastruktur sebagai kode sistem.
Layanan tingkat yang lebih tinggi: database sebagai layanan, antrian sebagai layanan, Load Balance sebagai layanan, pengubahan ukuran gambar sebagai layanan, pabrik Big Data sebagai layanan. Selain itu - pipeline yang mengirimkan kode yang terus dimodifikasi ke klien Anda.
Anda menerima informasi tentang cara kerja perangkat lunak Anda untuk klien, mengubahnya, memberikan kode ini lagi, menerima informasi - sehingga Anda terus mengembangkan platform infrastruktur dan perangkat lunak Anda.
Pada diagram, delivery pipeline terdiri dari banyak tahapan. Tapi ini adalah diagram skematik yang diberikan sebagai contoh - tidak perlu mengulanginya satu per satu. Tahapan berinteraksi dengan layanan seolah-olah merupakan layanan—setiap bagian platform membawa ceritanya sendiri: bagaimana sumber daya dialokasikan, bagaimana aplikasi diluncurkan, bekerja dengan sumber daya, dipantau, dan berubah.
Penting untuk dipahami bahwa setiap bagian platform membawa cerita, dan tanyakan pada diri Anda cerita apa yang dibawa oleh batu bata ini, mungkin sebaiknya dibuang dan diganti dengan layanan pihak ketiga. Misalnya, apakah mungkin memasang Okmeter alih-alih batu bata? Mungkin orang-orang telah mengembangkan keahlian ini lebih dari yang kita miliki. Tapi mungkin juga tidak - mungkin kita punya keahlian unik, kita perlu menginstal Prometheus dan mengembangkannya lebih lanjut.
Pembuatan platform
Ini adalah proses komunikasi yang kompleks. Ketika Anda memiliki praktik dasar, Anda memulai komunikasi antara berbagai insinyur dan spesialis yang mengembangkan persyaratan dan standar, dan terus-menerus mengubahnya ke alat dan pendekatan yang berbeda. Budaya yang kami miliki di DevOps penting di sini.
Dengan budaya, semuanya sangat sederhana - ini tentang kolaborasi dan komunikasi, yaitu keinginan untuk bekerja di bidang yang sama satu sama lain, keinginan untuk menggunakan satu instrumen secara bersama-sama. Tidak ada ilmu roket di sini - semuanya sangat sederhana, dangkal. Misalnya, kita semua tinggal di pintu masuk dan menjaganya tetap bersih - ini adalah tingkat budaya.
Apa yang kamu punya?
Sekali lagi, pertanyaan yang bisa Anda tanyakan pada diri sendiri.
Apakah platform infrastruktur berdedikasi? Siapa yang bertanggung jawab atas pengembangannya? Apakah Anda memahami keunggulan kompetitif platform infrastruktur Anda?
Anda harus terus-menerus bertanya pada diri sendiri pertanyaan-pertanyaan ini. Jika sesuatu dapat ditransfer ke layanan pihak ketiga, maka itu harus ditransfer; jika layanan pihak ketiga mulai memblokir pergerakan Anda, maka Anda perlu membangun sistem di dalam diri Anda.
Jadi, DevOps...
... ini adalah sistem yang kompleks, harus memiliki:
- Produk digital.
- Modul bisnis yang mengembangkan produk digital ini.
- Tim produk yang menulis kode.
- Praktik Pengiriman Berkelanjutan.
- Platform sebagai layanan.
- Infrastruktur sebagai layanan.
- Infrastruktur sebagai kode.
- Praktik terpisah untuk menjaga keandalan, dibangun dalam DevOps.
- Sebuah praktik umpan balik yang menggambarkan semuanya.
Anda dapat menggunakan diagram ini, menyoroti di dalamnya apa yang sudah Anda miliki di perusahaan Anda dalam beberapa bentuk: apakah sudah berkembang atau masih perlu dikembangkan.
Ini akan berakhir dalam beberapa minggu . sebagai bagian dari RIT++. Datanglah ke konferensi tersebut, di mana Anda akan menemukan banyak laporan keren tentang pengiriman berkelanjutan, infrastruktur sebagai kode, dan transformasi DevOps. , batas waktu harga terakhir adalah 20 Mei
Sumber: www.habr.com