Apa itu DevOps

Mendefinisikan DevOps sangat rumit, jadi Anda harus memulai kembali diskusi tentang hal itu setiap saat. Hanya di Habré seribu publikasi tentang hal ini. Tetapi jika Anda membaca ini, Anda mungkin tahu apa itu DevOps. Karena saya tidak. Hai, nama saya Alexander Titov (@ osminog ) dan kita akan berbicara tentang DevOps saja dan saya akan membagikan pengalaman saya.



Saya sudah lama berpikir bagaimana membuat cerita saya berguna, jadi akan ada banyak pertanyaan di sini - pertanyaan yang saya tanyakan pada diri saya dan pertanyaan yang saya tanyakan kepada klien perusahaan kami. Dengan menjawab pertanyaan-pertanyaan ini, pemahaman menjadi lebih baik. Saya akan memberi tahu Anda mengapa DevOps diperlukan dari sudut pandang saya, apa itu, sekali lagi, dari posisi saya, dan bagaimana memahami bahwa Anda pindah ke DevOps lagi dari sudut pandang saya. Item terakhir akan melalui pertanyaan. Dengan menjawabnya sendiri, Anda dapat memahami apakah perusahaan Anda bergerak ke arah DevOps atau jika ada masalah dalam sesuatu.


Pada suatu waktu saya berjalan di sepanjang gelombang merger dan akuisisi. Pada awalnya saya bekerja di sebuah startup kecil Qik, kemudian dibeli oleh perusahaan Skype yang sedikit lebih besar, yang kemudian dibeli oleh perusahaan Microsoft yang sedikit lebih besar. Pada saat itu, sebuah visi menjadi tersedia bagi saya bagaimana ide DevOps ditransformasikan di berbagai perusahaan. Setelah itu, menjadi menarik bagi saya untuk melihat DevOps dari sudut pandang pasar, dan rekan-rekan saya dan saya mengatur perusahaan Express 42. Selama 6 tahun kami telah bergerak di dalamnya di sepanjang gelombang pasar.

Antara lain, saya adalah salah satu penyelenggara komunitas DevOps Moscow dan penyelenggara DevOps -Hari 2017, tetapi saya tidak mengatur 2018. Express 42 bekerja dengan banyak perusahaan. Kami berkecambah DevOps di sana, melihat bagaimana ini terjadi, menarik kesimpulan, menganalisis, memberi tahu temuan kami kepada semua orang, mengajari orang-orang praktik DevOps. Secara umum, dalam segala hal kami menumbuhkan pengalaman dan keahlian.

Mengapa DevOps

Pertanyaan pertama yang menghantui semua orang dan selalu - mengapa? Banyak orang berpikir bahwa DevOps hanyalah otomatisasi atau hal serupa yang sudah dimiliki setiap perusahaan.

- Kami memiliki Integrasi Berkelanjutan - itu berarti, sudah ada DevOps, dan mengapa semua ini diperlukan? Mereka bersenang-senang di luar negeri, tetapi mereka mengganggu pekerjaan kami!

Selama 9 tahun pengembangan komunitas dan metodologi, sudah menjadi jelas bahwa ini bukan spangle pemasaran, tetapi masih belum sepenuhnya jelas mengapa itu diperlukan. Seperti alat dan proses apa pun, DevOps memiliki tujuan spesifik yang akhirnya dipecahkan.

Semua ini disebabkan oleh kenyataan bahwa dunia sedang berubah. Dia bergerak menjauh dari pendekatan perusahaan, ketika perusahaan langsung menuju impian, seperti yang dinyanyikan klasik St. Petersburg kami, dari titik A ke titik B sesuai dengan strategi tertentu, dengan struktur tertentu yang dibangun untuk ini.

Pada prinsipnya, dalam TI semuanya harus dibangun untuk pendekatan ini. Di sini TI digunakan secara eksklusif untuk otomatisasi proses.

Otomasi tidak sering berubah, karena ketika perusahaan berguling di sepanjang jalur yang macet - apa yang bisa diubah? Berhasil - jangan sentuh. Sekarang di dunia, pendekatan berubah, dan yang disebut kata Agile mengatakan bahwa titik akhir B tidak segera terlihat.



Ketika sebuah perusahaan bergerak di sekitar pasar, bekerja dengan klien, ia terus-menerus meneliti pasar dan mengubah titik akhirnya B. Selain itu, semakin sering perusahaan mengubah arah, semakin sukses akhirnya, karena ia memilih lebih banyak ceruk pasar.

Strategi ini ditunjukkan oleh perusahaan yang menarik, yang baru-baru ini saya pelajari. One Box Shave - Layanan pengiriman untuk alat cukur dan alat cukur per kotak. Mereka tahu bagaimana menyesuaikan "kotak" mereka untuk pelanggan yang berbeda. Ini dilakukan oleh perangkat lunak tertentu, yang kemudian mengirimkan pesanan ke pabrik Korea yang memproduksi barang.

Produk ini dibeli oleh Unilever dengan harga $ 1 miliar. Sekarang dia bersaing dengan Gillette dan telah merampas banyak konsumen di pasar AS. Satu Kotak Bercukur mengatakan:

- 4 bilah? Apakah kamu serius? Mengapa Anda memerlukan ini - ini tidak meningkatkan kualitas alat cukur. Krim yang dipilih secara khusus, parfum, dan pisau cukur berkualitas tinggi dengan dua bilah menyelesaikan lebih banyak pertanyaan daripada 4 bilah Gillette bodoh ini! Begitu cepat kita akan mencapai 10?

Jadi dunia berubah. Unilever mengklaim memiliki sistem TI keren yang memungkinkannya. Pada akhirnya, sepertinya konsep Time-to-market yang belum pernah dibicarakan orang.



Maksud dari Time-to-market bukanlah seberapa sering kita menyebarkan. Anda sering dapat menggunakan, tetapi siklus rilis akan lama. Jika siklus rilis tiga bulan saling tumpang tindih, bergeser seminggu, ternyata perusahaan tampaknya dikerahkan seminggu sekali. Dan dari ide hingga implementasi akhir, 3 bulan berlalu.

Waktu-ke-pasar adalah tentang meminimalkan waktu dari ide hingga implementasi akhir.

Dalam hal ini, perangkat lunak berinteraksi dengan pasar. Ini adalah cara One Box Shave berinteraksi dengan situs. Mereka tidak memiliki penjual - hanya situs tempat pengunjung mengklik dan meninggalkan keinginan. Karenanya, situs harus terus-menerus memposting sesuatu yang baru, memperbaruinya sesuai dengan keinginan. Misalnya, di Korea Selatan, mereka bercukur berbeda dari di Rusia, dan mereka menyukai aroma pinus, tetapi, misalnya, wortel vanila dalam wangi.

Karena Anda perlu dengan cepat mengubah konten situs, pengembangan perangkat lunak sangat berubah. Melalui perangkat lunak, kita harus mencari tahu apa yang diinginkan klien. Sebelumnya, kami mempelajari ini dengan beberapa solusi, misalnya, melalui manajemen bisnis. Kemudian mereka merancang, meletakkan persyaratan dalam sistem TI, dan semuanya keren. Sekarang berbeda - perangkat lunak dirancang oleh semua orang yang terlibat dalam proses, termasuk insinyur, karena mereka belajar melalui spesifikasi teknis bagaimana pasar bekerja, dan juga berbagi wawasan mereka dengan bisnis.

Sebagai contoh, di Qik, kami tiba-tiba menemukan bahwa orang-orang sangat suka mengunggah daftar kontak ke server, dan mereka memasukkan kami aplikasi. Awalnya, kami tidak memikirkan hal ini. Dalam sebuah perusahaan klasik, semua orang akan memutuskan bahwa itu adalah bug, karena spesifikasi tidak mengatakan bahwa itu harus bekerja dengan baik dan secara umum diterapkan pada lutut, mereka akan mematikan fitur dan berkata: "Ini tidak memerlukan siapa pun, yang paling penting adalah bahwa fungsi utamanya berfungsi" . Dan perusahaan teknologi melihat ini sebagai peluang dan mulai mengubah perangkat lunak sesuai dengan ini.



Pada tahun 1968, pria visioner Melvin Conway merumuskan ide berikut.

Organisasi yang menciptakan sistem terbatas pada desain yang menyalin struktur komunikasi di organisasi itu.

Secara lebih rinci, untuk menghasilkan sistem dari jenis yang berbeda, kita juga harus memiliki struktur komunikasi dalam perusahaan dari jenis lain. Jika struktur komunikasi Anda hierarkis teratas, ini tidak akan memungkinkan Anda untuk membuat sistem yang dapat memberikan indikator Time-to-market yang sangat tinggi.

Anda dapat membaca tentang hukum Conway dengan mengikuti tautan . Penting untuk memahami budaya atau filosofi DevOps, karena satu - satunya hal yang berubah secara mendasar di DevOps adalah struktur komunikasi antara tim .

Dari sudut pandang proses, sebelum DevOps, semua tahapan: analitik, pengembangan, pengujian, operasi, adalah linier.
Dalam kasus DevOps, semua proses ini berjalan secara bersamaan.



Waktu-ke-pasar hanya bisa dilakukan dengan cara ini. Bagi orang yang bekerja di proses lama, itu terlihat agak kosmik, dan umumnya biasa saja.

Jadi mengapa Anda membutuhkan DevOps?

Untuk pengembangan produk digital . Jika Anda tidak memiliki produk digital di perusahaan Anda, DevOps tidak diperlukan - ini sangat penting.

DevOps mengatasi batas kecepatan skema produksi perangkat lunak yang konsisten . Di dalamnya, semua proses terjadi secara bersamaan.

Meningkatkan kesulitan. Ketika penginjil DevOps memberi tahu Anda bahwa akan lebih mudah bagi Anda untuk merilis perangkat lunak dengannya, ini tidak masuk akal.

Dengan DevOps, segalanya hanya akan menjadi lebih rumit.

Pada konferensi di stan Avito, orang dapat melihat apa artinya menggunakan wadah Docker - tugas yang tidak realistis. Kompleksitas menjadi penghalang, Anda harus menyulap dengan banyak bola pada saat yang sama.

DevOps sepenuhnya mengubah proses dan organisasi di perusahaan - lebih tepatnya, itu tidak mengubah DevOps, tetapi produk digital. Untuk datang ke DevOps, Anda masih perlu mengubah proses ini sepenuhnya.

Pertanyaan untuk seorang spesialis

Bagaimana dengan kamu? Pertanyaan yang bisa Anda tanyakan pada diri sendiri ketika bekerja di perusahaan dan berkembang sebagai spesialis.

Apakah Anda memiliki strategi produk digital? Jika ada, itu sudah bagus. Ini berarti bahwa perusahaan Anda bergerak menuju DevOps.

Apakah perusahaan Anda sudah membuat produk digital? Ini berarti Anda dapat naik takik lagi dan melakukan hal-hal yang lebih menarik - sekali lagi, dari sudut pandang DevOps. Saya hanya berbicara dari sudut pandang ini.

Apakah perusahaan Anda salah satu pemimpin pasar dalam ceruk dengan produk digital? Spotify, Yandex, Uber - perusahaan yang berada di puncak kemajuan teknologi sekarang.

Tanyakan kepada diri Anda pertanyaan-pertanyaan ini, dan jika semua jawaban negatif, maka mungkin Anda tidak boleh berurusan dengan DevOps di perusahaan ini. Jika tema DevOps benar-benar menarik bagi Anda, mungkin ... haruskah Anda pindah ke perusahaan lain? Jika perusahaan Anda ingin mengunjungi DevOps, tetapi Anda menjawab "Tidak" untuk semua pertanyaan, maka itu menyerupai badak cantik yang tidak akan pernah berubah.

Organisasi

Seperti yang saya katakan, menurut hukum Conway, sebuah organisasi berubah di sebuah perusahaan. Untuk mulai dengan, apa yang mencegah DevOps memasuki perusahaan dari sudut pandang organisasi.

Masalah "sumur"

Kata bahasa Inggris "Silo" diterjemahkan di sini ke dalam bahasa Rusia sebagai "juga". Arti masalah ini adalah bahwa antara tim tidak ada pertukaran informasi . Setiap tim menggali keahliannya jauh ke dalam, sementara tidak membangun peta umum di mana Anda dapat menavigasi.

Dalam beberapa hal, ini menyerupai seseorang yang baru saja tiba di Moskow dan masih tidak tahu bagaimana menavigasi peta metro. Moskow biasanya tahu daerah mereka dengan sangat baik, dan di seluruh Moskow mereka dipandu oleh peta metro. Ketika Anda datang ke Moskow untuk pertama kalinya, tidak ada keterampilan ini, dan Anda hanya bingung.

DevOps menawarkan untuk melewatkan momen disorientasi ini dan kepada semua departemen bersama-sama untuk membangun peta interaksi yang sama.

Dua faktor mengganggu ini.

Konsekuensi dari sistem manajemen perusahaan. Itu dibangun oleh "sumur" hierarkis terpisah. Misalnya, ada KPI tertentu di perusahaan yang mendukung sistem ini. Di sisi lain, otak seseorang yang sulit untuk melampaui batas keahlian mereka dan bernavigasi di seluruh sistem ikut campur. Itu hanya tidak nyaman. Bayangkan Anda sampai di bandara Bangkok - di sana Anda tidak akan menemukan bantalan dengan cepat. DevOps juga sulit dinavigasi, dan oleh karena itu orang mengatakan bahwa Anda perlu menemukan panduan untuk mencarinya di sana.

Tetapi yang paling penting, masalah "sumur" untuk seorang insinyur yang terinspirasi oleh semangat DevOps, dibaca oleh Fowler dan banyak buku lainnya, diungkapkan dalam kenyataan bahwa "sumur" tidak memungkinkan Anda untuk melakukan hal-hal yang "jelas" . Kami sering berkumpul setelah DevOps Moscow, berbicara satu sama lain, dan orang-orang mengeluh:

- Kami hanya ingin meluncurkan CI, tetapi ternyata manajemen tidak membutuhkannya.

Ini justru karena fakta bahwa CI dan proses Pengiriman Berkelanjutan berada di perbatasan banyak pemeriksaan. Hanya saja tidak mengatasi masalah "sumur" di tingkat organisasi, Anda tidak akan bisa maju lebih jauh, apa pun yang Anda lakukan dan betapa sedihnya itu.



Setiap peserta dalam proses di perusahaan: pengembang backend dan frontend, pengujian, DBA, operasi, jaringan, menggali dalam arahannya sendiri, dan tidak ada yang memiliki kartu bersama kecuali seorang manajer yang entah bagaimana mengamati dan mengendalikan metode pembagian dan menaklukkan.

Orang-orang berjuang untuk beberapa bintang kecil atau bendera, masing-masing menggali keahliannya sendiri.

Akibatnya, ketika tugas muncul untuk menghubungkan semua ini bersama-sama dan membangun saluran pipa bersama, dan tidak perlu berjuang untuk bintang-bintang dan bendera, muncul pertanyaan - apa yang harus saya lakukan? Kita harus setuju, tetapi tidak ada yang mengajari kita bagaimana melakukan ini. Kami telah diajarkan dari sekolah: kelas delapan - wow! - Dibandingkan dengan kelas tujuh! Itu sama di sini.

Apakah sama di perusahaan Anda?

Untuk memeriksanya, Anda bisa bertanya pada diri sendiri pertanyaan-pertanyaan berikut.

Apakah tim menggunakan alat umum, apakah mereka berkontribusi pada perubahan alat umum ini?

Seberapa sering tim melakukan reformasi? Apakah beberapa spesialis dari satu tim pindah ke tim lain? Di lingkungan DevOps inilah hal ini menjadi normal, karena kadang-kadang 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 membuat komite tentang perubahan dan mengubah sesuatu? Atau apakah ini membutuhkan tangan yang kuat dari kepemimpinan dan arahan tertinggi? Baru-baru ini saya menulis di Facebook bagaimana satu bank yang kurang dikenal mengimplementasikan alat melalui pesanan: kami menulis pesanan, kami telah menerapkannya selama setahun, dan kami akan melihat apa yang terjadi. Ini, tentu saja, panjang dan menyedihkan.

Seberapa pentingkah bagi manajer untuk menerima prestasi pribadi tanpa memperhitungkan pencapaian perusahaan?

Jika Anda menjawab pertanyaan-pertanyaan ini untuk diri Anda sendiri, akan menjadi lebih jelas jika Anda memiliki masalah seperti itu di perusahaan.

Infrastruktur sebagai kode

Setelah masalah ini diselesaikan, praktik penting pertama, yang tanpanya sulit untuk bergerak lebih jauh ke DevOps, adalah infrastruktur sebagai kode .

Paling sering, infrastruktur sebagai kode dianggap sebagai berikut:

- Mari kita mengotomatisasi semua yang ada di bash, tutupi diri kita dengan skrip sehingga area admin memiliki lebih sedikit pekerjaan manual!

Tapi ini tidak benar.

Infrastruktur sebagai kode menyiratkan bahwa Anda menggambarkan sistem TI tempat Anda bekerja agar dapat terus memahami statusnya.

Bersama dengan tim lain, Anda membuat peta dalam bentuk kode yang dipahami semua orang, yang dapat Anda navigasikan dan navigasikan. Tidak masalah apa yang dilakukan - file Chef, Ansible, Salt, atau YAML digunakan di Kubernetes - tidak ada perbedaan.

Pada konferensi tersebut, seorang kolega dari 2GIS berbicara tentang bagaimana mereka membuat hal internal mereka sendiri untuk Kubernetes, yang menggambarkan struktur sistem individu. Untuk menggambarkan 500 sistem, mereka membutuhkan alat terpisah yang menghasilkan deskripsi ini. Ketika ada deskripsi ini, semua orang dapat mengecek satu sama lain, memantau perubahan, bagaimana mengubah dan memperbaikinya, yang hilang.

Setuju, skrip bash yang terpisah biasanya tidak memberikan pemahaman ini. Di salah satu perusahaan tempat saya bekerja, bahkan ada nama "tulis saja" - sebuah skrip - ketika skrip ditulis, dan sudah tidak mungkin untuk membacanya. Saya pikir ini juga akrab bagi Anda.

Infrastruktur sebagai kode adalah kode yang menggambarkan keadaan infrastruktur saat ini . Banyak produk, infrastruktur, dan tim layanan bekerja bersama dalam kode ini, dan yang paling penting, mereka semua perlu memahami cara kerja kode ini secara umum.

Kode disertai dengan praktik terbaik dari bekerja dengan kode : pengembangan bersama, tinjauan kode, pemrograman XP, pengujian, pull-quests, CI untuk infrastruktur kode - semua ini cocok dan dapat digunakan.

Kode menjadi bahasa yang umum untuk semua insinyur.

Mengubah infrastruktur dalam kode tidak membutuhkan banyak waktu . Ya, mungkin juga ada utang teknis dalam kode infrastruktur. Biasanya, tim bertemu satu setengah tahun setelah mereka mulai menerapkan "infrastruktur sebagai kode" dalam bentuk sekelompok skrip atau bahkan Ansible, yang mereka tulis sebagai kode spageti, dan bahkan skrip bash memasukkannya ke dalam kotak api!

Penting : jika Anda belum mencoba hal ini, ingatlah bahwa Ansible bukan bash ! Baca dokumentasi dengan seksama, pelajari apa yang umumnya mereka tulis tentang itu.

Infrastruktur sebagai kode adalah pembagian kode infrastruktur menjadi beberapa lapisan yang terpisah.

Di perusahaan kami, kami membedakan 3 lapisan dasar, yang sangat jelas dan sederhana, tetapi mungkin ada lebih banyak. Anda dapat melihat kode infrastruktur Anda dan mengatakan apakah Anda memiliki kondisi ini atau tidak. Jika tidak ada layer yang disorot, maka Anda perlu mengalokasikan waktu dan sedikit refactor.


Lapisan dasar adalah bagaimana OS, cadangan, dan hal-hal tingkat rendah lainnya dikonfigurasikan, misalnya, bagaimana Kubernet digunakan pada tingkat dasar.

Tingkat layanan 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 - sekelompok layanan yang dapat dikembangkan oleh masing-masing tim. Semua ini harus dijelaskan sebagai modul terpisah dalam sistem manajemen konfigurasi Anda.

Lapisan tempat aplikasi dibuat dan bagaimana mereka akan ditempatkan di atas dua lapisan sebelumnya.

Pertanyaan keamanan

Apakah Anda memiliki repositori infrastruktur umum di perusahaan Anda? Apakah Anda mengendalikan utang teknis dalam infrastruktur? Apakah Anda menggunakan praktik pengembangan di repositori infrastruktur? Apakah infrastruktur Anda diiris? Anda dapat memeriksa skema Base-service-APP. Seberapa sulitkah untuk melakukan perubahan?

Jika Anda dihadapkan dengan kenyataan bahwa pengenalan perubahan membutuhkan waktu satu setengah hari, ini berarti Anda memiliki hutang teknis dan Anda harus bekerja dengannya. Anda baru saja menemukan rake utang teknis dalam kode infrastruktur. Saya ingat banyak cerita seperti itu ketika untuk mengubah CCTL, perlu untuk menulis ulang setengah dari kode infrastruktur, karena kreativitas dan keinginan untuk mengotomatisasi semuanya mengarah pada fakta bahwa di mana-mana semuanya dipersingkat, semua pena dihapus, dan Anda perlu refactor.

Pengiriman terus menerus

Debit serupa dengan pinjaman. Pertama, deskripsi infrastruktur muncul, yang bisa sangat mendasar. Anda tidak perlu mendeskripsikan semuanya secara terperinci, tetapi diperlukan beberapa deskripsi dasar agar Anda dapat menggunakannya. Kalau tidak, tidak jelas apa yang harus dilakukan lebih lanjut. Semua praktik ini terbuka pada saat yang sama ketika Anda datang ke DevOps, tetapi Anda harus mulai dengan memahami apa yang Anda miliki dan bagaimana cara mengelolanya. Ini hanya praktik infrastruktur sebagai kode.

Setelah menjadi jelas bahwa Anda memiliki cara mengelola ini, Anda mulai berpikir bagaimana cara mengirim kode pengembang ke produksi secepat mungkin. Maksud saya, bersama-sama dengan pengembang - kita ingat masalah "sumur", yaitu, bukan individu yang muncul dengan ini, tetapi oleh tim.

Ketika Vanya Yevtukhovich dan saya melihat buku pertama Jes Hamble dan kelompok penulis "Continuous Delivery" , yang dirilis pada 2009, kami berpikir lama bagaimana menerjemahkan namanya ke dalam bahasa Rusia. Mereka ingin menerjemahkannya sebagai "Pengiriman yang konsisten", tetapi, sayangnya, diterjemahkan sebagai "Pengiriman yang berkelanjutan". Tampak bagi saya bahwa ada sesuatu Rusia di gelar kami dengan tekanan.

Secara konstan memberikan - itu artinya

Kode yang terletak di repositori grosir selalu dapat diunduh saat diproduksi . Mungkin tidak dikempiskan, tetapi selalu siap untuk itu. Oleh karena itu, Anda selalu menulis kode dengan perasaan yang sulit untuk dijelaskan tentang kekhawatiran di bawah tulang ekor. Ini sering muncul ketika Anda meluncurkan kode infrastruktur. — , -. .

, , . « », , , . — : , .

- . , - , , , . , , DevOps- : - , — Kubernetes- , - , .

- — - . , - . Continuous Delivery : , - , . , . , .

. , AB- , - «» , , , , 100 .

« » .

Dev, CI, Test, PreProd, Prod — , , .

, Base Service APP, , , .

95 % ? ? , ? ?

, ! — ).

Umpan balik

. DevOpsConf Infobip, , , , !



, -, Qik , . , Zabbix 150 000 items, . , :

— , ?

, , .

. , , , , - — . 4 , «Segmentation fault».

, Zabbix, , , , API-, . , . , android-. :

— , ?

, UI. , HTTP-. android- — . , 40 , , - HTTP-, . , API , , , .

. «», , . , . , , , , — , , ( ), . .

, — .

CI, - . Test, PredProd, . , , , : , — .

. , DevOps — . , .

— ? , , , , ?

? ? ? , , , 3 ?

, , .

, , .

, .

, , . , , . .

, IDE . IDE , , . Sublime, Atom Visual Studio Code, , , IDE.

. , - , , . - — , pull request — , . .

. , . , — .

, , . , Time-to-market. vendor lock : , , , . , . , , vendor lock . .

, DevOps-.



, .

, CPU, , . — : , , CI/CD Engine, , .

: , , , Load Balance , resizing , Big Data . — , .

, , , , — , .

delivery pipeline . , — . , — : , , , , .

, , — , , . , Okmeter? , , . — , , Prometheus .

. , , , . , DevOps.


— , , . rocket science — , . , — .

?

, .

? ? ?

. - — , , .

, DevOps...

… , :

• .
  
• , .
  
• , .
  
• Continuous Delivery.
  
• .
  
• .
  
• .
  
• , DevOps.
  
• , .
  

Anda dapat menggunakan skema ini dengan mewarnai apa yang sudah Anda miliki di perusahaan Anda dalam beberapa bentuk: sudah dikembangkan atau masih perlu dikembangkan.

Dalam beberapa minggu, DevOpsConf 2019 akan diadakan . sebagai bagian dari RIT ++. Datanglah ke konferensi, di mana Anda akan menemukan banyak laporan keren tentang pengiriman berkelanjutan, infrastruktur sebagai kode dan transformasi DevOps. Pesan tiket Anda , batas waktu terakhir untuk harga adalah 20 Mei