Apakah Anda menggunakan pendekatan DevOps di rumah? Inilah kode suami yang digunakan untuk bekerja. Istri infrastruktur menyiapkan telur goreng, kopi brews, kemeja setrika. Kucing pemantau tergelincir dari bawah kakinya tepat waktu, membersihkan baki dan dengan keras menunjukkan kapan sang istri menyimpang dari protokol yang ditetapkan.
Pada hari pertama Slurm DevOps, saya bertemu Artyom Galonsky, STO Bureau of Bureau. Dia memberi kuliah tentang CI / CD dan pengantar otomatisasi. Dia berbicara tentang jalur konveyor perakitan pabrik dan penerapannya di TI. Dan pada saat yang sama ia membagikan contoh-contoh praktis, seperti membangun pipa “umum”.
Setelah pidatonya, saya menangkapnya saat rehat kopi dan meminta saya untuk menceritakan tentang tempat DevOps dalam aktivitas profesionalnya, dan pada saat yang sama persyaratan apa yang dia lihat untuk jabatan insinyur DevOps. Artyom mengejutkan saya dengan mengatakan bahwa para insinyur DevOps ada di alam semesta yang sama dengan unicorn merah muda. Dan baginya, " tidak ada insinyur DevOps, ada admin yang baik yang memahami Kubernet ."
Tentang karier
Anda telah dalam pengembangan selama 11 tahun. Memulai di Biro Biro?
Tidak. Dia mulai sebagai freelancer pada tahun 2008, kemudian mengangkat beberapa startup. "Otfermery" adalah startup seperti itu. Itu ada selama 2 tahun dan terbentuk. Pada 2011, ia mulai terlibat dalam sistem CRM untuk agen asuransi. Ada tim kecil - 4 orang. Pada 11-12 ia menjadi pemimpin tim. Dia adalah pengembang terkemuka, kepala departemen pengembangan perusahaan. Pada 2017, itu menjadi STO RedStart di Kaliningrad. Dan pada awal 2018, saya pindah ke Biro Biro.
Apa yang membuatmu tertarik?
Langkah selanjutnya. Mereka menawarkan kondisi yang menarik. Kesempatan untuk mengumpulkan tim Anda. Ditambah proyek yang menarik. Saya pindah dari Kaliningrad ke Moskow. Dia bekerja di Moskow selama enam bulan. Kemudian direktur Biro Biro memutuskan bahwa kita harus membuka kantor belakang di Kaliningrad.
Mengapa
Pertama, saya sendiri dari Kaliningrad. Saya tahu lebih banyak profesional berkualitas tinggi dan kuat di Kaliningrad daripada di Moskow. Pemeliharaan segala kebutuhan lebih murah di Kaliningrad. Dan komunitas TI kuat di sana. Dan zona ekonomi bebas perlahan maju.
Kami di Southbridge percaya bahwa potensi provinsi belum sepenuhnya dilepaskan. Bahwa ada sejumlah besar orang yang berbakat dan cerdas yang, karena sejumlah alasan - psikologis, sosial, keuangan - tidak dapat pindah ke ibukota.
Ya, itu bahkan bukan psikologis atau alasan apa ... Orang-orang tidak ingin pindah.
Ya, saya berbicara tentang ini. Tidak semua orang ingin pindah.
Dan ini bukan masalah - psikologis atau finansial. Seseorang tidak mau.
Ya Saya setuju. "Masalah" adalah kata yang buruk. Sebaliknya, "instalasi."
Seseorang tidak mau. Dia nyaman di sana. Saya bekerja selama enam bulan di Moskow, mengumpulkan tim. Sulit bagi saya di pagi hari untuk menghabiskan 40 menit dalam perjalanan ke kereta bawah tanah. Atau kemacetan di mobil bahkan lebih lama. Saya sekarang berada di Kaliningrad selama empat puluh menit berjalan melalui tempat-tempat yang indah, melewati danau, melewati rumah-rumah yang indah. Dan empat puluh menit ini saya menikmati hidup. Dan menghirup udara bersih. 20 menit - dan saya di laut. 40 menit - dan saya di Eropa. Ditambah lagi, banyak pria yang tinggal di Kaliningrad ketika mereka mengetahui bahwa saya kembali, berkata, " Oke, ayolah, kami akan dengan senang hati kembali ke tim Anda dan terus bekerja dengan Anda ." Dan selama setahun sekarang kantor pusat kami - pengembangan, pengujian, analitik, manajer pendukung - telah berlokasi di Kaliningrad. Dan kami bahagia dan bahagia.
Dan di Moskow?
Di Moskow, kami memiliki kantor depan. Manajemen, manajer proyek, akun direktur, perancang antarmuka, perancang, dan administrator sistem.
Dan bagaimana interaksinya?
Tidak ada yang mengganggu. Semuanya bekerja dengan sangat sempurna. Itu semua tergantung pada bagaimana Anda mengaturnya.
Anda sendiri, sebagai stasiun layanan, siapa yang Anda sukai - karyawan jarak jauh atau di kantor?
Hal utama adalah membangun pertukaran pengetahuan yang benar. Saya menghilangkan Alur Kerja - karena jika alur kerja tidak ditetapkan, tidak masalah bagaimana pengetahuan dipertukarkan. Tidak ada yang akan berhasil. Tetapi pertukaran pengetahuan sehingga orang berbagi praktik mereka - apa yang mereka ciptakan, dipahami, dilakukan - lebih baik dilakukan di rumah ketika mereka duduk di kantor yang sama. Dengan satu atau lain cara, mereka akan mulai berkomunikasi tentang topik ini. Dan ketika orang jauh, mereka mungkin tidak berbagi. Karena itu, penting untuk membuat basis pengetahuan. Penting untuk memotivasi orang untuk membagikan informasi ini. Setiap hari Jumat, teknologi, yaitu, setiap orang yang tidak memiliki proyek "membakar", terlibat dalam pendidikan mandiri pada paruh kedua hari Jumat. Dan kemudian dibagikan dengan orang lain.
Tentang pengembangan
Bagaimana Anda memotivasi?
Saya memotivasi pengembangan. Terus terang, semuanya berubah sangat cepat di "web", dan jika Anda tidak berkembang, maka Anda akan tetap pada level ini selamanya. Dan dalam hal uang Anda tidak akan tumbuh, dan dalam hal pengembangan.
Salah satu kutipan favorit saya dari Lewis Carroll dari "Alice in Wonderland": "Di sini Anda harus berlari secepat hanya untuk tetap di tempat yang sama, tetapi untuk sampai ke tempat lain Anda harus berlari dua kali lebih cepat."
Kami memiliki hampir sama. Dalam 11 tahun saya terlibat dalam web, teknologi telah berubah secara dramatis. Dua tahun lalu, secara relatif, kami tidak tahu apa itu Kubernetes dan bagaimana cara mengimplementasikannya. Sekarang di mana-mana. Dan dalam satu tahun itu akan diperlukan untuk semua orang. Karena bebannya akan bertambah. Jika Anda tidak memompa pengetahuan dan menggunakannya dalam proyek Anda, maka Anda akan tertinggal. Memulai setiap proyek, kami mencoba memperkenalkan sesuatu yang baru. Bekerja terus-menerus pada satu produk, cukup sulit untuk memperkenalkan yang baru. Dan itu sedikit lebih mudah bagi kami - memulai proyek baru, kami memperkenalkan teknologi baru yang telah kami pelajari dan uji. Dan kami berkembang dari proyek ke proyek.
Teknologi apa yang Anda gunakan sekarang, yang menurut Anda relevan, perlu?
Kami memiliki apa yang kami lakukan sekarang, tumpukannya cukup sederhana - frontend react.js, untuk backend yang kami gunakan sebagian PHP sebelum dan sekarang, sekarang kami mencoba untuk beralih ke Go. Ini adalah garis lurus, tempat kami bergerak, untuk membiarkan PHP sepenuhnya berjalan dan berkembang di dalamnya. Ini adalah teknologi baru, bagus, stabil, yang memberikan peningkatan kecepatan yang luar biasa - baik dalam pengembangan maupun dalam kecepatan produk itu sendiri. Yaitu, tumpukan kami adalah React.js, PHP dan Go. Ini untuk bahasa pemrograman. Nah, juga teknologi standar Redis, PostgreSQL, RabbitMQ.
Anda dapat mengingat teknologi yang sudah usang. Kami baru-baru ini berbicara dengan teman-teman - jadi mereka saling menggoda karena mereka dulu pro di Perl.
Ya Yah, mungkin orang lain menggunakan Perl. JS yang sama, yang terus berkembang ... Apa yang sebelumnya ES6 sudah usang, atau jpl yang sama. Js yang sama datang ke "node" dan menjadi node.js. Php yang sama, yah, seseorang tidak menyukainya - versi 5 buruk, sekarang 7.2 sedang berkembang di bawah tren saat ini. Bagi saya tidak ada satu yang sepenuhnya ketinggalan zaman. Secara moral, mungkin ya. Atau saya tumbuh dari teknologi. Sebelumnya, 10 tahun yang lalu saya menggunakan MySQL, sekarang untuk proyek yang saya buat, tidak ada gunanya di mana-mana. Teknologi yang saya miliki ... Kemungkinan besar, saya hanya tumbuh keluar dari mereka yang sudah ketinggalan zaman.
Apa yang kamu sukai dari Go sekarang?
Kecepatan eksekusi, penghematan. Untuk semuanya. Apa yang saya lihat, berkomunikasi dengan arsitek, prospek, dan pengembang saya, katakan saja apa yang biasa kita lihat di skrip php, tetap ada di Go ditambah fitur bahasa yang dikompilasi ditambahkan. Goroutine, multichannel. Itu yang tidak ada di php, dan kami melakukannya melalui php-fpm, secara relatif. Ditambah pengetikan data yang kuat. Dan juga kompilasi cepat dari biner itu sendiri.
Apa pengembang yang baik untuk Anda?
Bagi saya, pengembang yang baik adalah seseorang yang dapat beralih ke bahasa pemrograman baru dalam waktu sekitar 2-3 bulan untuk memahaminya. Secara alami, dia tidak akan melakukan apa pun selama 2-3 bulan. Dia akan berada pada tahap "Juni", melakukan tugas-tugas sederhana. Dipompa dengan cepat - dan mulai menutup tugas yang rumit dan bagus.
Perusahaan mana yang Anda hubungkan - oranye, pirus?
Kami bukan pirus pasti. Agak oranye. Dengan kontrol vertikal. Saya sendiri agak otoriter dalam manajemen. Kami melakukan ini dan itu - dan jika mereka tidak datang kepada saya dan membuktikan dengan contoh nyata bahwa itu lebih baik dengan cara lain, akan sangat sulit untuk meyakinkan saya. Jika tidak terbukti, maka ini tidak perlu. Misalkan seorang karyawan datang dan berkata: “Artyom, kita perlu melakukan ini. Untuk alasan ini dan ini. Anda menyarankan ide yang buruk. Ya, Anda adalah direktur dan arsitek. Tetapi Anda tidak menawarkan ide yang sangat bagus. Dan kita harus melakukannya. " Dan jika saya belum jelas dan 100% terbukti, maka saya akan mendorong keputusan saya. Jadi bukan pirus pasti.
Katakanlah, secara relatif, teknologi baru telah muncul. Dan bagaimana seorang karyawan dapat membuktikan kepada Anda bahwa itu layak digunakan jika hanya sedikit orang yang menggunakannya dan tidak ada contoh dan kasus praktis yang representatif? Namun teknologinya konon menjanjikan.
Tampilkan proyek kesayangan. Yah, bukan hanya: " Lihat, itulah yang saya lakukan ." Ini harus sudah disatukan. Agar seseorang secara sadar melakukan ini, ia mencoba untuk memproduksinya, untuk memberinya beban. Dia datang kepada saya dan berkata: “ Saya menemukan fitur, bahasa, teknologi seperti itu. Saya membuat produk atau layanan mikro kecil jadi . " Lalu aku mendengarkan. Masih ada masalah - ketika bekerja dengan bisnis yang serius, teknologi yang mapan diperlukan. Kita bisa maju dan bergerak. Dan pelanggan kami - mereka kadang-kadang mengerikan, karena fakta bahwa mereka sangat besar, terutama yang milik negara - mereka hanya siap untuk teknologi yang stabil dan tidak suka eksperimen. Saya ingat dua tahun lalu saya menyarankan untuk bereaksi terhadap seseorang - dan jawaban yang tajam adalah “ Tidak. Kami tidak akan bekerja. Mengapa Ini adalah semacam perpustakaan untuk UI. Tidak. Html, Css, Js - itu cocok untuk kita. " Di perusahaan besar, struktur negara ternyata perkembangan teknologi baru agak terlambat. Sampai teknologi stabil, sampai mereka menemukan seseorang yang mengetahui teknologi ini dan mendukungnya dari dalam, mereka tidak akan mengambil risiko.
Tentang proyek
Kapan mudah bagi Anda untuk bekerja dengan pelanggan?
Saya pikir ketika ada arsitek yang baik di sisi pelanggan. Maka menjadi menarik untuk bekerja. Kemudian kami mendapatkan pesanan yang baik, tugas yang baik, dan solusi yang baik. Dan mereka mengerti bagaimana ini akan diterapkan. Dan ketika di tempat pelanggan hanya ada manajemen dan analis produk yang menginginkan sesuatu seperti ini, maka itu lebih sulit. Sistemnya sangat besar. Dan kami memberikan produk yang akan menjadi bagian dari sistem. Dan mereka memberi tahu kami: “ Oh, dan hubungkan kedua produk ini bersama-sama. Sehingga pengguna mengklik tombol ini dan dia punya ini ... "Dan ada banyak di bawah tenda - otorisasi, transfer data. Dan Anda bertanya: “Teman-teman , oke, bagaimana seharusnya itu terjadi di dalam? Apa yang sebenarnya Anda inginkan? "Dan mereka menjawab:" Oh, kami tidak tahu. Yang terpenting adalah semuanya harus indah. Dan apa yang ada di balik tudung - Anda memberi tahu keamanan informasi kami. Biarkan mereka memeriksa apakah itu bekerja dengan baik atau tidak . "
Bisakah Anda mengingat contoh ketika Anda dengan cepat dan awalnya memecahkan masalah?
Kami memiliki proyek di mana otorisasi hanya oleh ESIA. Dan ESIA sering berbaring. Ketika seseorang masuk, kami memverifikasi bahwa dialah yang masuk. Dan ada rekonsiliasi data dari ESIA bahwa paspornya atau dokumen lainnya belum diperbarui. Dan kemudian ESIA mengacaukan sesuatu. Dan kami memiliki sekelompok pelanggan yang mencoba masuk, menerima pesan “ Data Anda telah berubah. Mohon konfirmasi . " ESIA mulai mengeluarkan nama depan baru atau nama tengah atau data paspor baru. Dan kami tidak dapat melakukan apa pun, karena sistem kami sangat terkonfigurasi sehingga ESIA adalah pusat kebenaran bagi kami. Dan kami menghentikan otorisasi untuk sementara waktu. ESIA dengan cepat memutuskan segalanya. Admin kami di tingkat penyeimbang pengguna telah melemparkan ke halaman " Maaf, untuk sementara tidak berfungsi ." Dan kami cepat menyelesaikannya sehingga hanya pelanggan lama yang bisa masuk tanpa pembaruan sementara. Dan pengguna baru tidak diizinkan. Yah, ini sebenarnya bukan situasi kami, tetapi kami terhubung ke sana untuk solusi.
Katakan padaku, proyek tantangan apa yang paling menarik untukmu akhir-akhir ini? Dari mana Anda mendapatkan kesenangan profesional?
A: Saya menikmatinya ... Kami melakukan akun pribadi untuk Siemens Finance. Anak perusahaan dari Siemens, yang bergerak dalam bidang penyewaan di Rusia. Bersama mereka, kami mengembangkan akun pribadi. Di sini kesenangannya adalah bahwa Siemens memberi kami kesempatan untuk membangun arsitektur yang baik, pelanggan tidak melakukan intervensi, dan menyiarkan " Guys, kami percaya Anda ." Kami membuat UI dan UX yang bagus untuk mereka. Kerja yang sangat bagus dengan pelanggan. Dan itu bukan tantangan atau penanggulangan. Kemudian saya sangat menikmati pekerjaan itu. Dari produk itulah akhirnya diterima. Dan sekarang produk itu berfungsi, hidup. Semua orang menyukainya - dan saya menyukainya. Dan tantangan yang kita miliki adalah terus-menerus. Ketika bekerja dengan perusahaan besar tanpa ini dengan cara apa pun. Setiap perusahaan memiliki 12 departemen - ada departemen TI, ada departemen infrastruktur, departemen logika bisnis, dan yang lainnya. Plus ada banyak vendor, orang-orang seperti Anda yang mengintegrasikan CRM mereka. Dan untuk mengoordinasikan setiap perubahan dengan semua departemen ini adalah sebuah tantangan. Anda menawarkan arsitektur Anda, berkomunikasi dengan arsitek perusahaan utama, berinteraksi dengan arsitek vendor ...
Tetapi bukankah arsitek perusahaan pelanggan harus berurusan dengan ini?
Tidak selalu. Ada topik yang fashionable - transformasi digital. Misalnya, perusahaan memiliki arsitek, dan ia terlibat langsung dalam arsitektur solusinya. Misalnya, penagihan atau sektor perbankan. Tapi dia, sebagai arsitek seluruh sistem, tidak memiliki pengalaman dan kompetensi yang diperlukan. Tetapi spesialis yang baik mulai belajar. Dan yang belum terlalu tua usianya sedikit lebih rumit di sini - karena mereka kurang memperhatikan tren baru. Dan Anda harus berkomunikasi untuk waktu yang lama dan menjelaskan, kata mereka, mari kita coba solusi progresif ini. Dan di suatu tempat ada arsitek muda yang tumbuh di "web" modern. Cukup sederhana di sana - dengan syarat, kami melakukan sinkronisasi seperti ini, sambungkan modul-modul ini seperti itu. Dan mereka dengan cepat dan kompeten menyetir.
Jadi Anda sudah melihat dua generasi pengembang yang berbeda?
Di web, ya. Karena sekarang semuanya bergerak ke web. Sekarang bahkan sistem internal secara bertahap pindah ke layanan mikro yang berkomunikasi dengan API. Dan API paling sering adalah http dan https. Arsitek harus mengerti cara kerjanya. Dan cara termudah untuk mendengarkan mereka yang bekerja di web. Menurut saya. Sangat sering situasi ini terjadi. Pelanggan menginginkan situs keren baru. Dia melihat situs yang dimiliki pesaing, bagaimana situs ini bekerja. Dan dia datang, menuntut agar kami membangun seluruh sejarah digital situs, hingga CRM. Dan kami hanya berurusan dengan situs. Kami siap berintegrasi dengan CRM seseorang. Dan ternyata kami menjadi pendorong perubahan untuk perusahaan tertentu.
Tentang teknologi
Transformasi digital - berapa banyak yang menurut Anda dibutuhkan?
Seperti tema hype, itu modis dan perlu. Kami memiliki sejumlah besar pesanan untuk melakukan unduhan excel. Sejumlah besar perusahaan bekerja di Excel. Dan mereka perlu memastikan bahwa "excel" ini dimuat, diuraikan, diubah menjadi database dan kemudian mereka dapat bekerja dengannya, dan kemudian membongkarnya. Transformasi digital harus mengarah pada transisi ke sistem kerja normal - CRM, sistem konten, CMS. Dan tinggalkan excel dan hiduplah di dunia web yang normal. Ada contoh yang bagus. Di perusahaan sebelumnya, tempat saya bekerja sebelum Biro-Biro, kami memiliki dua perusahaan klien. Dan kami dapat melacak secara detail bagaimana semuanya terjadi. Di satu perusahaan, layanan pelanggan melalui Excel. Ada database besar. Itu tahun 2012-2013. CRM normal tidak cocok di sana - banyak alur kerja dan butuh waktu yang sangat lama untuk mengonfigurasinya pada CRM biasa. Dan satu perusahaan mulai bekerja di Excel. Dan yang kedua menghabiskan setengah tahun - dan menulis CRM-nya. Akibatnya, perusahaan pertama enam bulan setelah mereka mencapai puncak penjualan, dan mereka mulai bekerja dengan pelanggan - mereka runtuh. Hanya saja layanan panggilan mereka tidak dapat memberikan layanan yang baik dan cepat. Dan perusahaan kedua, dengan CRM-nya, sebaliknya, dengan cepat dilacak dengan satu tombol, klien macam apa, bagaimana ia sampai kepada mereka, apa yang dijawab manajer. Mereka selamat dari puncak pertumbuhan ini - dan masih bekerja. Alur kerja elektronik juga menjadi tren. Hemat waktu. Siapa yang beroperasi lebih cepat dengan informasi, ia mendapatkan lebih cepat. Jadi dalam segalanya. Jika tidak ada pemantauan yang baik dan tidak ada penebangan yang baik pada proyek, maka para insinyur tidak akan dapat dengan cepat memahami apa masalahnya. Dan kelangsungan hidup dan kesuksesan bisnis sangat bergantung padanya sekarang. Jadi tidak hanya diperlukan untuk membuat situs web yang indah, tetapi untuk membangun situs web yang tepat dan sistem pencatatan yang benar. Transformasi digital diperlukan. Perlu untuk tetap up to date. Jika ada teknologi seperti itu, kita harus mencoba memperkenalkannya.
Teknologi apa yang Anda lihat sekarang yang akan menjanjikan dalam waktu dekat? Misalnya, dua tahun lalu Kubernetes dianggap menjanjikan. Sekarang itu hanya perlu.
Masa depan adalah pembelajaran mesin dan AI. Dalam lima tahun, ini akan menjadi relevan. Setahun yang lalu, ada crypto dan ada pembelajaran mesin di hype. Sekarang semuanya tenang. Tapi tetap saja, dalam lima tahun ke depan, pembelajaran mesin akan menembak, seperti yang saya pikirkan. Pekerjaan sedang berlangsung - pengalaman dan solusi menumpuk.
Dipercayai bahwa dengan pembelajaran mesin dan kecerdasan buatan, banyak profesi akan lenyap begitu saja. Ini berlaku untuk guru dan ekonom. Dan pengacara mengatakan bahwa teknologi blockchain akan menggerakkan bidang-bidang tertentu dalam yurisprudensi. Profesi apa dalam TI, seperti yang Anda lihat, akan hilang?
Penutup, seperti yang saya pikir, akan hilang. Sepertinya saya dalam tiga tahun ke depan. Seperti kata pepatah, ingat tweet ini. (tertawa) Kemungkinan besar, pembelajaran mesin akan segera ditulis, yang akan menjadi tata letak yang baik. Mereka akan datang dengan sesuatu. Dan kemudian, mungkin, pemrogram sistem yang sederhana akan menghilang. Namun tetap saja, akan selalu ada programmer yang akan merancang dan memprogram inti microchip. Akan selalu ada programmer.
Wahai para devops
Sekarang di pasar ada defisit insinyur DevOps ...
Dengar, aku sangat menentang hal seperti insinyur DevOps.
Mengapa
DevOps adalah praktik, itu adalah filosofi. Insinyur DevOps - siapa itu? Apakah itu admin yang dipompa atau apakah itu "backend" yang dipompa dengan baik yang bisa ada di admin? Bagi saya tidak ada insinyur DevOps, bagi saya ada admin yang baik yang mengerti Kubernetes. Tapi Kubernetes bukan DevOps. Satu-satunya hal yang saya terima untuk diri saya sendiri adalah penginjil DevOps. Siapa yang bisa datang ke perusahaan dan berkata: “Teman-teman , kita perlu bergerak ke arah ini. Belajar berkomunikasi dan berinteraksi . ” Karena DevOps bukan tentang teknologi. Secara umum, seluruh filosofi DevOps adalah tentang interaksi. Untuk mempelajari cara berkomunikasi, pengembangan dan QA, dan dukungan lebih lanjut. Dan semua insinyur DevOps ini mengingatkan saya pada hype oleh scrum-master sekitar tiga tahun lalu. Semua orang membutuhkan master scrum, tidak ada yang bisa bekerja tanpanya. Atau lima tahun yang lalu, semua orang sangat membutuhkan manajer pengaturan Jira. , «», . , DevOps — .
, - ?
, - . . , — , , «», , . , «». , DevOps. , DevOps-. . — . Kubernetes.
, IT-?
. . . . 90- .
, , ?
. . , . - . — , . , . , , , . . . , . , . , , . — .
Post scriptum
. , , , , - — , , . . , , , , , -. , . ? «Time will tell. Sooner or later time will tell».©