Dari administrator sistem ke orang tersebut

DevOps memiliki setidaknya dua pandangan mapan - dari sisi administrator sistem dan dari sisi pengembang. Yang pertama biasanya menyombongkan diri bahwa mereka telah menggunakan Chef / Puppet / Ansible / Docker sejak 200X, yang terakhir percaya bahwa DevOps telah hidup lebih lama dan mengarah ke NoOps, atau bahwa "Saya membungkus semuanya dalam sebuah wadah, dan kemudian bagaimana hasilnya."

Pada saat yang sama, bisnis membaca tentang DevOps dalam artikel dan berharap bahwa orang-orang di bawah ini akan mengetahui apa yang harus dilakukan dengannya. Pada saat yang sama, DevOps sendiri tidak terjadi, bisnisnya tidak seperti Google, perusahaan tidak menjadi pirus, orang tidak membuat pendekatan baru untuk menguji hipotesis di dunia.

Artikel ini adalah tentang DevOps sebagai suatu sistem. Bagaimana hal itu membantu bisnis, kompetensi apa yang harus muncul pada para insinyur untuk DevOps, tugas-tugas bisnis apa yang dapat diselesaikan dengan metode produksi perangkat lunak DevOps, dan juga kesalahan apa yang mungkin terjadi dalam perjalanan ke produksi-DevOps dan bagaimana menghindari atau menghentikannya. Bagaimana, pada akhirnya, bagaimana seorang insinyur bisa menjadi manusia dan menjadi pencipta di dunia ini, bagaimana membangun jalur karier untuk ini, dan bagaimana mulai melihat teknologi secara manusiawi.

Materi ini didasarkan pada transkrip laporan Alexander osminog Titov dari konferensi Oktober DevOops 2017 kami.



Bagi mereka yang terbiasa menonton laporan dari konferensi dalam rekaman, kami lampirkan video.



Saya bekerja untuk Express 42. Kisah saya adalah tentang jalur karier saya, tetapi saya akan memberinya tips dan kesimpulan menarik. Ini memiliki nama yang menarik "Dari administrator sistem ke orang." Saya memisahkan peran administrator sistem dari beberapa kondisi manusia. DevOps menggerakkan kita untuk tidak hanya menjadi seniman, tetapi juga pencipta produk digital baru dan banyak lagi.

Karena kisah saya didasarkan pada pengalaman saya, saya akan bercerita sedikit tentang diri saya. Saya mulai sebagai administrator sistem ketika saya masih di universitas. Dia bekerja pada shift malam, kemudian mulai bekerja pada shift siang hari, kemudian naik ke posisi administrator sistem utama. Kemudian saya bekerja di jejaring sosial connectect.ua dan fakultet.ru, kemudian sebagai direktur teknis di perusahaan Oversan-Skalaksi. Ini adalah salah satu upaya pertama untuk meluncurkan cloud hosting di Rusia, ternyata, upaya yang sangat awal. Kebutuhan cloud hosting di Rusia baru muncul sekarang. Kami hanya mengerti cara menggunakannya, menyadari bahwa ini adalah sumber daya yang fleksibel, bahwa mereka perlu menulis aplikasi secara berbeda, dan sebagainya. Pada masa itu, tidak ada yang mengerti ini sama sekali, jadi menjualnya sangat sulit.

Kemudian saya bekerja di sebuah startup Qik dari Silicon Valley, yang kantor pengembangannya ada di sini di Rusia. Di Qik, saya benar-benar merasakan manfaat dari konsep DevOps, karena dalam dua bulan kami membuat produk yang tumbuh dari 0 menjadi 5 juta pengguna. Jika di Oversan-Skalaxi, dari sudut pandang layanan, saya merasa bahwa DevOps diperlukan dan orang-orang perlu memahami apa DevOps adalah menggunakan cloud hosting, maka di Qik saya merasakan ini sebagai administrator sistem dan sebagai kepala departemen administrator sistem. Kemudian kami dibeli oleh Skype, dan kami mulai berintegrasi di sana, dan juga mengintegrasikan perkembangan di bidang DevOps di sana, karena itu tidak ada di Skype. Dan kemudian Skype membeli Microsoft. Sepertinya dia datang ke perusahaan tempat sekitar 40 orang, dan setelah beberapa tahun Anda bekerja di perusahaan besar dengan 100 ribu karyawan. Itu adalah pengalaman yang sangat menarik.

Akibatnya, saya tidak menemukan tempat untuk bergerak lebih jauh di perusahaan-perusahaan ini, dan kolega saya dan saya membuka Express 42, yang membawa DevOps ke massa. Gagasan ini berasal dari Oversan-Skalaksi, dan itu mendorong saya. Antara lain, saya sangat mendukung komunitas DevOps di Rusia. Saya penyelenggara pertemuan DevOpsDays Moscow dan Moscow DevOps.

Saya telah lama khawatir bahwa menggunakan Ansible bisa menjadi buruk atau baik. Alat secara keseluruhan tidak menyelesaikan apa pun. Anda dapat menggunakan Docker, Kubernetes, menginstal Prometheus terbaru, tetapi pada saat yang sama apa yang Anda lakukan tidak akan berbeda dari apa yang dimiliki orang yang menggunakan skrip bash. Saya akan mencoba menjawab mengapa ini terjadi. Dalam banyak hal, jawaban ini ada di dalam diri kita, sehingga artikel itu disebut demikian. Administrator sistem berpikir bagaimana menulis skrip bash untuknya, dan orang tersebut berpikir sedikit berbeda.

Bagaimana DevOps muncul di perusahaan?

Pengembang DevOps

Ada beberapa cara DevOps dapat muncul di perusahaan. Salah satu cara ini adalah ketika pengembang, bosan meminta administrator sistem untuk melakukan sesuatu, dan setelah mendengar tentang DevOps, cobalah untuk mengimplementasikannya. Tetapi pada saat yang sama mereka memiliki pemahaman yang aneh tentang DevOps. Mereka berpikir bahwa mereka dapat menggunakan teknologi apa pun, membungkus semuanya dalam wadah Docker dan mengirimkannya ke administrator sistem, tetapi mereka tidak berpikir sama sekali tentang bagaimana kode mereka akan bekerja dalam produksi. Mereka tidak mengubah apa pun di kepala mereka untuk beralih ke DevOps, tetapi pada saat yang sama mereka mulai menggunakan teknologi baru.

Saya telah melihat banyak perusahaan seperti itu. Anda datang kepada mereka - mereka memiliki empat departemen pengembangan. Setiap departemen menulis microservice sendiri, masing-masing departemen memiliki database sendiri. Seseorang Redis, seseorang PostgreSQL, seseorang PostgreSQL dan MySQL secara bersamaan. Dan mereka menyertai ini, sampai database tumbuh dengan ukuran sedemikian rupa sehingga mereka tidak bisa lagi.

Pada titik ini, semuanya mulai runtuh dan berantakan, dan konsekuensi mengerikan muncul. Ini adalah kebun binatang teknologi yang tidak jelas apa yang harus dilakukan. Selain itu, kekhasan pengembang adalah bahwa ia memecahkan masalah dengan menyeret perpustakaan baru. Saya pikir mereka yang bekerja dengan pengembang Node.js sudah familiar dengan ini. Ketika pengembang Node.js melihat bahwa database tidak berfungsi dengan baik, mereka dapat melompat dari PostgreSQL ke beberapa versi, menambahkan beberapa ekstensi, atau mulai menggunakan beberapa JSONB. Akibatnya, muncul kondisi arsitektur yang mengerikan, tetapi secara keseluruhan mereka puas dengan segalanya. Aplikasi ini sulit dikelola, Anda tidak dapat mengetahui apa yang terjadi di sana, memiliki stabilitas rendah, selalu macet. Menanggapi aplikasi yang macet, pengembang menempel sesuatu di sana, dan itu terus jatuh lebih jauh, dan sebagai hasilnya, tidak ada yang dipahami sama sekali.

Sysadmin DevOps

Ada yang namanya DevOps-sysadmin. Biasanya ini adalah orang-orang yang sangat kuat yang telah membuktikan diri dengan baik. Mereka datang dan berkata: "Kalian, kamu tidak bisa hidup seperti itu, kami bosan menarik cairan ini, Kami sekarang mengotomatisasi segalanya, kami akan membuat pipa pengiriman, seperti yang manis, indah, yang bekerja dengan baik. Kami tahu betul bagaimana aplikasi harus bekerja dalam produksi. Jauh lebih baik daripada boobies ini menulis di Node.js. Dan kami tahu apa yang perlu digunakan agar semuanya sempurna. ”

Beberapa kali saya menemukan fakta bahwa orang-orang seperti itu membangun DevOps di FreeBSD. Hasilnya adalah sistem tertutup, yang mereka tulis sendiri, dan hanya mereka yang mengerti cara kerjanya. Terlepas dari pengalaman sysadmin saya, saya tidak bisa mengetahuinya, tetapi jika saya tidak bisa, maka bagaimana seharusnya pengembang memahami cara menggunakan melalui sistem CI ini? Sebagai hasilnya, saya secara administratif melarang penggunaan FreeBSD di perusahaan, meskipun saya dengan tulus mencintai dan menghormati sistem itu sendiri, terutama saya suka OpenBSD. Tetapi seminggu kemudian, di antara server Linux, server FreeBSD mulai muncul lagi, seperti fly agarics.

Administrator sistem DevOps, serta pengembang, berpikir bahwa teknologi adalah hal yang paling penting, tidak ada yang dapat dilakukan tanpa mereka. Jika mereka menyukai teknologinya, mereka mencoba menempel di mana-mana.
Di Oversan-Skalaxi kami menciptakan istilah konfigurasi dan skrip tulis saja. Ini adalah saat seseorang bisa menulis, tetapi tidak ada yang bisa membaca.

Pada saat yang sama, administrator sistem terus memperbaiki sesuatu di sabun. Anda datang kepadanya dan menawarkan bantuan, dan dia memberi Anda sesuatu dengan tikar tiga lantai. Anda tidak mengerti apa-apa, karena Anda harus mencari tahu apa yang dia lakukan. Nah, jika pengembang datang dan berkata, misalnya, bahwa ia membutuhkan database yang toleran terhadap kesalahan? Dia akan diberikan sesuatu dengan tikar tiga lantai ini, dia akan duduk dan tidak mengerti apa yang harus dilakukan dengannya. Semua berlayar, para pengembang dan administrator sistem tidak berkomunikasi. Meskipun di dalamnya digunakan semua yang paling modern, canggih.

Dari sini muncul ide tradisional sysadmin: ini adalah orang yang bersenjata lengkap yang melakukan sesuatu, tetapi Anda tidak akan mengerti apa sebenarnya. Ngomong-ngomong, sebagian besar SDM sekarang mencari yang seperti itu. Saya dapat memberitahu Anda bahwa menemukan orang seperti itu di perusahaan tidak akan menyelamatkan Anda 100% dari masalah.

DevOps untuk bisnis

Cara lain untuk munculnya DevOps adalah dari sisi bisnis. Beberapa manajer puncak Anda pergi ke beberapa konferensi bisnis, misalnya, ke lembah, di mana mereka mengatakan kepadanya bahwa jika Anda tidak memiliki Docker, beberapa integrasi berkelanjutan (CI) dan sesuatu yang lain, maka Anda tidak dapat dianggap perusahaan teknologi. Manajer kembali, mengumpulkan karyawan dan membaca kata-kata dari buku catatan: DevOps, Docker, Concourse CI. Orang-orang mulai memahami, dan kemudian skenario campuran yang disebutkan di atas terjadi: Pengembang DevOps, DevOps-sysadmin, dan ini semua menyebabkan kekacauan yang tidak dapat Anda lihat.

Bahkan, saya terus-menerus melihat situasi seperti itu. Mengapa ini terjadi: Anda datang ke konferensi, semua orang memiliki pandangan rasional dan normal - lalu Anda pergi ke parit, berproduksi, dan kemudian ada sampah dan asap? Artinya, semua orang mengerti segalanya, tetapi karena alasan tertentu mereka tidak bekerja. Saya memiliki hipotesis bahwa setiap orang memahami sebagian, tidak semuanya. Dan sekarang saya akan mencoba untuk berbicara secara holistik tentang DevOps.

Dari Enterprise ke Agile

Pertama, dari sudut pandang bisnis, kami mengalami titik balik: kami menjauh dari perusahaan yang menerapkan proyek monumental untuk mentransfer bisnis itu sendiri dari titik A ke titik B (misalnya, strategi lima tahun untuk menangkap 70% pasar) ...

... dan datang ke dunia Agile. Titik Agile tidak fleksibel, tetapi titik A diketahui dan B tidak. Dan inilah yang paling mendalam yang bisa terjadi. Karena kita maupun bisnis tidak terbiasa bekerja dengan ini. Bayangkan Anda tidak tahu apa yang akan terjadi dalam seminggu atau dua minggu, bahwa pemimpin datang kepada Anda dan berkata: "Jadi, cobalah untuk mendapatkan sesuatu yang tidak mungkin, tuliskan nama Anda sehingga Anda tidak lupa terburu-buru . " Dan Anda tidak tahu apa yang harus dilakukan, tetapi dunia dan bisnis menjadi seperti itu, dan Anda harus terbiasa dengannya. Dan semua praktik ini, seperti Agile, Scrum, Kanban, bukan tentang bagaimana hidup dengannya.


Kami bergerak dari cara perusahaan-perusahaan dan perusahaan ke cara teknologi. Beberapa perangkat lunak mulai berinteraksi dengan kami di pasar. Jika orang-orang sebelumnya, perusahaan berinteraksi dengan kami, penjual menelepon dan sebagainya, sekarang untuk memanggil taksi, memesan pizza, mendengarkan musik, kami pergi ke aplikasi. Dan aplikasi adalah perangkat lunak yang seseorang perlu tulis dan terus beradaptasi dengan pasar. Dan kami, insinyur dan mereka yang terlibat dalam bisnis, harus memahami dari aplikasi apa yang terjadi dengan pasar. Dan pada akhirnya, itu menggerakkan kita ke arah DevOps.

DevOps tidak muncul karena salah satu dari Anda harus merasa nyaman, dan bukan karena Anda perlu menggunakan teknologi yang lebih dingin. NoSQL tidak lebih dingin dari SQL, apalagi, jauh lebih buruk daripada SQL oleh negara 3-4 tahun yang lalu. Database SQL telah dikembangkan selama 20 tahun, dan database NoSQL selama 1 tahun. Dan kita ingat keadaan MongoDB yang menyedihkan 4 tahun lalu, padahal itu bukan basis data sama sekali.


DevOps sama dengan sebelumnya, hanya sekarang kami melakukan semuanya pada saat yang sama. Jika Anda seorang pengembang, Anda menulis kode dan segera menulis tes, pembungkus untuk Kubernetes, atau hanya wadah Docker, bagaimana cara kerjanya dalam produksi. Dan dengan melakukan itu, Anda harus memenuhi satu syarat minimum - jalankan kode ini. Karena banyak pengembang di era sebelumnya tidak melakukan ini: kompiler dikompilasi, dan apa yang dimulai di sana dan mulai bekerja dalam wadah aplikasi sudah merupakan hal yang kesepuluh. Pada saat yang sama, tulis metrik, log yang harus dikumpulkan. Dan kemudian Anda kehilangan semuanya di Delivery Pipeline, Jenkins, TeamCity atau yang lainnya. Ini adalah perbedaan mendasar antara pengembang di perusahaan dan pengembang di perusahaan teknologi. Di sini, pengembang mulai menulis tidak hanya algoritma, tetapi seluruh produk.

Sejarah DevOps

Inilah saatnya untuk beralih ke sejarah DevOps. Bagaimana semua ini terjadi? Saya menjalani ini, terus membaca berita, mengikuti rantai sejarah, bagaimana semuanya muncul. Dan sekarang orang yang berbeda dari tahun yang berbeda memberi tahu saya versi berbeda tentang apa itu DevOps dan bagaimana hal itu terjadi. Dan sepertinya penting bagi saya untuk kembali ke akarnya.

Pada tahun 2003, Ben Trainor di Google menciptakan tim SRE. Google adalah perusahaan digital besar pertama di dunia. Sudah pada tahun 2003, mereka dihadapkan dengan masalah yang dalam cara klasik bahwa semua pengembang perangkat lunak terbiasa, mereka tidak dapat melakukan apa yang mereka inginkan. Dan mereka berinovasi dengan memperkenalkan tim SRE, dan sejak itu mengembangkan praktik ini.

Pada tahun 2009, John Alspaw dan Paul Hammond memberi ceramah tentang bekerja bersama di dalam Flickr dan bagaimana mereka berbagi 10 kali sehari. Saat itu sensasi dan ledakan. Dan Patrick Deboit memata-matai laporan ini dan menciptakan istilah DevOps, mengorganisir komunitas dunia untuk mengembangkan praktik ini lebih lanjut.

Muncul perusahaan-perusahaan teknologi yang perlu berbagi dengan cepat. Pendekatan lama tidak cocok, dan mereka mulai menemukan yang baru. Dan lancar, secara alami, mereka diatur ulang sehingga mereka memiliki praktik baru dalam membuat perangkat lunak.

Kami berada dalam situasi yang sangat sulit, karena kami tidak memiliki perubahan alami ini. Teknologi seperti itu datang kepada kita ketika sesuatu telah terjadi di sana, tetapi kita masih tidak tahu bagaimana menggunakannya. Di sana, orang-orang secara evolusi sampai pada hal ini, dan kita harus membuat revolusi, memikirkan kembali semua ini dan entah bagaimana mengubahnya ke tanah mereka sendiri.

Bagaimana cara menerapkan DevOps?

Saat menggunakan DevOps, sangat penting untuk benar-benar menyadari bahwa Anda membuat produk digital dan waktu untuk memasarkan (TTM) penting bagi perusahaan.

Penting untuk mengubah semua tim menjadi tim pengembangan. Tidak ada lagi sysadmin terpisah, pengembang terpisah. Karena mereka yang kami sebut administrator sistem menulis apa yang disebut platform infrastruktur, dan pengembang menulis apa yang disebut produk, dan dengan demikian mereka saling memberikan layanan.

Hal lain yang tidak terlihat dan sangat penting yang kita semua lupakan adalah organisasi akumulasi dan pertukaran pengetahuan dalam tim dan antar tim. Kami memiliki masalah besar dengan ini. Kami tidak suka membagikan sesuatu yang, misalnya, belum siap, dan ini adalah kunci untuk keberadaan DevOps. Kita harus berbicara tentang apa yang tidak siap, uji hipotesis, kita harus terbuka kepada seseorang yang mengatakan kepada kita bahwa mereka tidak siap. Karena kita terbiasa, misalnya, jika administrator sistem menguji beberapa hal keren, datang, memberi tahu mereka, mereka menjawab: "Tidak, tetapi bagaimana cara kerjanya dalam produksi, apa yang Anda uji?"

Sysadmin, menyadari bahwa di suatu tempat mereka tidak mengerti, di suatu tempat mereka tidak menguji, meninggalkan, menutup, dan pengetahuan ini menghilang, dan kami tidak mengambil langkah maju. Dan itu benar untuk mengatakan: "Kawan, lihat! Anda melakukan pekerjaan yang sangat keren, pekerjaan yang hebat, tetapi ada satu pertanyaan yang saya benar-benar ingin tanyakan kepada Anda: bagaimana ini akan bekerja dalam produksi? Sudahkah Anda memikirkan hal ini? "Lain kali Anda menunjukkan kepada kami bagaimana menerapkan fungsi ini dalam produksi, itu akan sangat keren!"
Mereka sudah pergi dengan tugas. Dan dalam kasus pendekatan Rusia klasik kami "ya tidak tidak, semua sampah," mereka pergi dengan pemikiran "mengapa kita harus melakukan ini jika kita semua ditolak" . Dan ini adalah masalah besar di dalam komunitas DevOps. Kami tidak berbagi satu sama lain, karena kami tidak yakin bahwa ini tidak akan dikenali sejelas atau sekonyol kelihatannya, dan sebagainya.

Saya sudah mendengar dari penyelenggara konferensi bahwa setiap orang membutuhkan mega-hardcore. Yah, mungkin Anda tidak bisa membuat megahardcore, tetapi agar seseorang berbagi pengalaman nyata dan Anda bisa membicarakannya, itu juga keren.

Pengembang di DevOps

Pengembang di DevOps tidak menulis kode, tetapi produk. Dan ini bukan hal yang jelas, karena di institut, kursus, buku kita sebagai programmer diajarkan untuk menulis algoritma, bukan produk, mereka diajarkan untuk memecahkan bukan masalah bisnis, tetapi masalah algoritmik. Ini masalah besar. Sangat penting di kepala Anda untuk melacak pada titik mana Anda menyelesaikan masalah algoritmik, dan pada titik apa adalah masalah bisnis yang nyata.

Di sebuah perusahaan yang mempraktikkan DevOps, pengembang segera berpikir bagaimana kodenya akan berintegrasi dengan komponen lain. Segera mulai berkomunikasi tentang ini. Misalnya, untuk mengklarifikasi dalam obrolan, peta jalan perubahan API yang digunakan untuk memeriksa. Inilah awal kerjasama.

Pengembang memiliki ide tentang arsitektur aplikasi - ini sangat penting, karena tanpa memahami cara kerja arsitektur, apa lapisan teknologi dan bagaimana mereka berinteraksi satu sama lain, tidak mungkin untuk berpikir tentang integrasi.

Pengembang tahu bagaimana kode bekerja dalam pertempuran, dan memahami apa yang terjadi dengan aplikasi ini. Dalam contoh saya, ketika pengembang menulis kode dan wadah Docker sekaligus memonitor, ia harus memiliki gagasan tentang bagaimana arsitektur bekerja, bagaimana kode bekerja dalam produksi dan terintegrasi ke dalam aplikasi. Anda yang bekerja sebagai administrator sistem atau insinyur infrastruktur, pikirkan tentang cara menyampaikan pengetahuan ini kepada pengembang. Tugas Anda adalah memberi tahu mereka tentang hal itu. Anda dapat menyewa konsultan, tetapi lebih baik sendiri.

Insinyur Infrastruktur

Peran selanjutnya yang dimiliki DevOps adalah insinyur infrastruktur, yang sebelumnya disebut administrator sistem. Saya sangat tidak menyukai istilah "Insinyur DevOps" karena DevOps adalah praktik umum yang mencakup pengembangan, pengujian, dan operasi. Seperti yang saya katakan sebelumnya, Anda dapat memiliki insinyur DevOps, tim DevOps, teknologi terbaik, dan Anda tidak memiliki DevOps.

Seorang insinyur infrastruktur menciptakan platform terutama untuk pengembangan produk, tetapi harus nyaman bagi pengembang. Saldo ini harus dicoba untuk dipatuhi.
Seorang insinyur infrastruktur menggunakan beberapa lapis abstraksi untuk memberikan layanan. Misalnya, ada laporan bagus oleh Nikolai Ryzhikov tentang Kubernetes, ia menunjukkan di sana cara memilih dan menggunakan beberapa lapis abstraksi. Dia punya model ideal di sana, yang dipraktikkan. Model semacam itu dapat dipotong menjadi beberapa level abstraksi. Ini dilakukan untuk mengurangi kerumitan penyelesaian masalah dan integrasi. Ketika Anda memiliki tingkat abstraksi yang dapat dipahami, Anda dapat beralih di antara mereka dan melihat di mana perbedaannya. Anda tidak harus mempercayai lapisan abstraksi, tetapi mereka sangat berguna untuk membicarakannya. Artinya, mereka seharusnya tidak mutlak, tetapi alat yang berguna.

Insinyur infrastruktur merancang platform sebagai produk, tahu cara menjadi pemilik produk, apa yang dipikirkan desain, tahu cara mengumpulkan persyaratan dari pengembang. Tapi ini tingkat tinggi, dan saya tidak yakin bahwa insinyur seperti itu hadir di pasar dalam bentuk insinyur infrastruktur.

Teknisi Pengujian

Penguji juga berubah sedikit dan menjadi teknolog yang mencapai peningkatan kualitas perangkat lunak dan mengubah proses ini menjadi kode.

Manajer Rilis / Stasiun Servis

Manajer mengingat proses pengiriman perangkat lunak berkelanjutan, mengelola harapan bisnis dan kemampuan teknis, menghasilkan rilis dan rilis. Dia memproduksi, bukan merencanakan, karena proses transisi dari titik A ke titik B adalah non-linear, dan dalam keadaan seperti itu dia tidak dapat merencanakan.

Sebagai hasilnya, mereka bersama-sama membangun platform infrastruktur, yang merupakan alat untuk semua orang: insinyur infrastruktur, pengembang, dan penguji.


Penting di sini bahwa kode berjalan sepanjang proses pengiriman ke kanan, dan informasi tentang bagaimana ia pergi. Anda secara konstan mendapatkan informasi tentang bagaimana kode Anda melewati jalur pengiriman, dan menggunakan informasi ini, buat perubahan.

, , , — ( ), . , — , , , , continuous delivery pipeline.

, . (- CTO) — . , — , , , .


42 base-service-app. — () . . : , load balancers, , , CI- (TeamCity Jenkins ). , API, . , , CI Kubernetes.


Proses dan teknologi sangat penting. Teknologi yang Anda gunakan, selain dari mereka sendiri, memiliki cara untuk menggunakannya. Misalnya, Anda dapat memotong roti dengan pisau, atau Anda dapat membunuh seseorang. Jadi di sini, hanya dalam kasus kami itu masih lebih rumit, bahkan lebih banyak tingkat abstraksi. Proses yang Anda buat di sekitar ini sangat penting. Dan proses ini, pada prinsipnya, tidak ada yang dapat membuat kecuali Anda di dalam perusahaan, karena mereka sangat dirancang untuk aplikasi spesifik. Sekarang, pada prinsipnya, tidak mungkin bahwa, seperti sebelumnya, Anda menyewa seorang konsultan ITIL, dan dia menempatkan semua proses untuk Anda. Aplikasi Internet Banking dan Yandex.Music berbeda seperti surga dan bumi. Ada prinsip-prinsip umum, tetapi prosesnya sendiri sangat berbeda.

Setiap lapisan teknologi memiliki prosesnya sendiri yang harus dibangun. Dan di sini saya merujuk pada kata-kata Alan Kay, yang pernah berkata dalam sebuah wawancara dengan Habru sebuah ungkapan yang luar biasa: "Komputer dapat dibandingkan dengan alat musik, musik mereka adalah ide . "
Dengan demikian, teknologi yang kita miliki harus dimasukkan dalam proses yang menciptakan gagasan (gagasan meningkatkan produk, gagasan mengubah proses, gagasan menciptakan produk baru). Ini sangat penting.

Perusahaan yang mempraktikkan DevOps harus mengatur platform dalam diri mereka sendiri dan beberapa sistem nilai yang akan memungkinkan kami untuk mendiskusikan ide apa yang kami buat menggunakan teknologi yang kami gunakan dan seberapa banyak kami menggunakan teknologi ini (Kubernetes, Prometheus, Docker, dll.) , untuk memainkan musik, dan tidak mematahkan gitar di kepala tetangga.

, DevOps- . , , , . , continuous delivery, — , , . , , , . , , , « ». , .

Momen saat ini berbeda dari momen perusahaan lama dalam hal standar dipakukan di sana, dan sekarang mereka terus berubah. Selama 3-4 tahun terakhir, banyak teknologi dan standar penggunaan telah berubah, bahkan tidak berguna untuk memperbaikinya dalam dokumen, hanya di kepala orang.

Jika Anda menyukai laporan ini, datanglah ke konferensi DevOops 2018 : di sana Anda tidak hanya dapat mendengarkan laporan, tetapi juga mengobrol dengan pembicara mana pun di area diskusi. Konferensi akan diadakan di St. Petersburg pada 14 Oktober, mulai 1 September, biaya tiket akan meningkat.