Habrapost ini adalah wawancara dengan Anton Weiss, co-owner konsultan teknologi Otomato Software, pemilik pengalaman lebih dari 15 tahun di bidang teknologi tinggi. Dia adalah seorang ahli dalam pengajaran teknis, penggagas dan penulis bersama kursus sertifikasi DevOps Israel pertama. Anton berpartisipasi dalam konferensi internasional dan dikenal sebagai pembicara yang keren.
Kami akan berbicara tentang topik-topik berikut:
Perbedaan antara Rusia dan Israel
Oleg: Tolong beritahu saya siapa Anda dan apa yang Anda lakukan.Anton: Saya Anton, saya lahir di St. Petersburg, tetapi saya pindah ke Israel pada usia 15 dan telah tinggal di sana sejak itu. Selama dua puluh tahun terakhir di Israel saya telah terlibat dalam IT dalam berbagai bentuknya. Dari dua puluh tahun ini, sepuluh terakhir telah mengkhususkan diri dalam segala hal yang berkaitan dengan pengiriman perangkat lunak: integrasi, apa yang sebelumnya disebut manajemen konfigurasi, dan apa yang sekarang disebut DevOps. Saya bekerja di perusahaan besar - di perusahaan internasional seperti AT&T, BMC. Dia bekerja di perusahaan rintisan. Selama empat tahun terakhir saya memiliki perusahaan konsultan sendiri, bernama Otomato Software, di mana kami berkomitmen untuk membantu organisasi mengoptimalkan proses pengiriman dan menguasai alat-alat baru: yaitu, kami melakukan bagian teknis dan segala sesuatu di sekitar.
Oleg: Apakah ada perbedaan antara Rusia dan Israel dalam hal pekerjaan?Anton: Saya jarang bekerja dengan klien Rusia. Fakta bahwa 3 tahun terakhir menghubungkan saya dengan Rusia adalah konferensi. Dan di beberapa perusahaan Rusia, kami melakukan sesuatu seperti audit: kami tiba, melihat, menyelesaikannya, mengeluarkan beberapa rekomendasi dan pergi. Artinya, secara khusus tidak ada pekerjaan harian seperti itu, jadi sulit bagi saya untuk mengatakan dengan tepat bagaimana perbedaannya. Saya pikir ada banyak hal yang berbeda. Yaitu, di Israel yang sama, kami memiliki organisasi perusahaan yang sangat besar di mana orang telah bekerja selama 15 tahun, dan semuanya bergerak sangat keras. Dan tidak peduli bagaimana mereka mencoba melakukan semacam transformasi, meningkatkan proses: mereka akan berbicara, mereka akan berbicara, tapi ... Kami memiliki klien yang dengannya kami melakukan semuanya dua tahun lalu dan membuat semua keputusan, mengembangkan semua program, dan di mana maka saat semuanya terhenti, kami keluar dari sana. Hanya beberapa hari yang lalu, saya bertemu dari sana para bos yang bekerja dengan kami, saya katakan:
- Bagaimana caranya?
- Baiklah kalau begitu. Sulit, kata mereka, kami sedang melakukannya, sekarang sesuatu mulai terjadi.
Dua tahun kemudian. Ada politik, ada zona pengaruh. Ada orang yang tidak ingin melepaskan zona pengaruh ini, masing-masing, ketika situasi seperti itu, sangat sulit untuk mengubah sesuatu. Nah, toolkit itu sendiri entah bagaimana bergerak maju. Di sisi lain, di Israel ada permulaan di mana semuanya berubah dengan sangat cepat, mudah untuk menaikkan tuling baru, dan mereka semua adalah cloud asli dan sepenuhnya duduk di awan. Omong-omong, ini mungkin salah satu dari perbedaan nyata antara Rusia dan Israel. Di Israel, dengan cloud publik jauh lebih mudah. Dari apa yang saya lihat. Di Rusia, misalnya, tampaknya sangat sulit bagi semua orang kecuali startup untuk masuk ke cloud publik, tetapi di Israel masih lebih mudah. Saat ini, bahkan bank dan perusahaan asuransi sudah memiliki pemahaman bahwa setidaknya sebagian dari barang-barang mereka dapat diluncurkan ke cloud publik. Dan di sini, kontrak dengan Google dan Amazon tidak menakuti siapa pun. Dari apa yang saya dengar di konferensi di Rusia, masih ada yang lebih rumit, yah, bahkan dari sudut pandang sanksi, bukan sanksi dan beberapa masalah hukum.
Perbedaan antara startup dan raksasa
Oleg: Saya mengerti. Omong-omong, di mana lebih menarik dan menyenangkan bagi Anda untuk bekerja: di startup atau di organisasi besar?Anton: Ini lebih menyenangkan, tentu saja, di startup, karena organisasi besar ... yah, materialnya bergerak sangat keras. Tentu ada keuntungannya. Jika Anda melihat organisasi besar, maka mereka, misalnya, memiliki lebih dari apa yang disebut keberagaman. Perusahaan besar hanya karena mereka membutuhkan banyak orang atau karena itu adalah semacam budaya organisasi yang telah berkembang selama bertahun-tahun, siap untuk merekrut orang yang berbeda. Khususnya, di Israel, misalnya, di perusahaan pemula Anda hampir tidak akan menemukan, misalnya, orang Arab, mereka hampir tidak ada. Dalam organisasi besar, ini jauh lebih mudah. Tapi startup sudah tumbuh dari semacam latar belakang budaya di mana sebagian besar peserta sebagian besar adalah pria kulit putih yang sama. Ada budaya yang perlu dirobek dengan benar, dan disarankan untuk bekerja 10-12 jam sehari, dan ini juga tidak cukup. Sepertinya Moskow (yaitu, Tel Aviv) ada di belakang kita, tidak ada tempat untuk mundur, dan karena itu harus berdarah di sini dan sekarang.
Oleg: Dan bagaimana dengan perbedaan dalam pendekatan untuk DevOps di perusahaan kecil dan besar? Artinya, jika Anda, misalnya, bekerja untuk dua orang, Anda tidak dapat mengonfigurasi CI / CD Anda sendiri, tetapi menyalin artefak dari SCP.Anton: Untuk satu hal. Di sisi lain, pengaturan CI / CD hari ini tidak berarti Anda benar-benar melakukan pengiriman terus menerus. Tetapi menyiapkan semacam pipa, jika Anda adalah perusahaan yang terdiri dari dua orang, sangat, sangat sederhana. Jika sebelumnya Anda entah bagaimana harus bingung, hari ini Anda memiliki banyak layanan cloud. Tulis YAML - dan maju, ayo pergi. Ini lebih mudah. Faktanya, tantangannya adalah startup startup. Mereka yang melampaui 20 orang, dan di sini mereka mulai sakit dengan penskalaan, karena tidak ada proses. Segala sesuatu dulu berfungsi entah bagaimana, tetapi kemudian seluruh kekacauan ini dimulai, dan tidak jelas bagaimana kita dapat mempertahankan dinamisme sebelumnya dan pada saat yang sama melakukan proses, dan memutuskan siapa lagi yang akan melakukan semua ini.
Dan kemudian semua hal dimulai, seperti "kita akan memiliki tim DevOps yang akan bertanggung jawab untuk DevOps", kita tahu apa yang mengarah pada kebanyakan kasus. Kemacetan muncul, dan secara bertahap mereka tumbuh ke tempat perusahaan besar sekarang. Perusahaan-perusahaan besar memiliki bencana yang sama sekali berbeda, mereka bahkan tidak memiliki hambatan, tetapi hanya sebuah gerbang yang kuat yang dibuka sekali sehari, dan sisa waktu sejumlah besar sampah terkumpul di sana. Dan mereka berpikir: “Bagaimana kita sekarang membuat banyak gateway kecil dari gateway ini yang dapat dibuka lebih mudah?” Itu adalah masalah yang sangat berbeda. Startups memiliki masalah dengan fakta bahwa "kita sedang tersedot ke dalam corong, bagaimana kita bisa berenang keluar?", Dan untuk perusahaan besar - mereka sudah berada di corong, mereka sudah berada di dunia bawah, sekarang mereka berpikir bagaimana berenang kembali ke atas.
Tren ini meningkatkan kompleksitas, dan apa yang harus dilakukan
Oleg: Yah, ditambah bagian teknis: ketika Anda memiliki sedikit orang, teknologi sederhana, Anda perlu tahu beberapa Linux dasar, dan hanya itu. Dan dengan penskalaan sekecil apa pun, Anda perlu mempelajari beberapa Kubernet, dan ini tampaknya menjadi masalah.Anton: Dan ini tidak diragukan lagi masalah. Kami mengadakan konferensi hanya dua hari yang lalu, dan sangat nyata bahwa hampir semua orang yang mengatakan sesuatu di sana menyebut satu kata: "kompleksitas" (kompleksitas). Ini telah menjadi semacam kata yang menentukan untuk seluruh ceramah DevOps hari ini.
Oleg: Apakah itu setahun yang lalu?Anton: Dalam upaya melakukan segalanya dengan cepat, dinamis, untuk mencapai fleksibilitas yang terkenal, kami membungkus diri dengan kerumitan seperti itu. Memang, ada banyak pipa kecil yang bekerja secara luar biasa secara terpisah, dan kemudian kami mencoba untuk mengumpulkan beberapa gambaran dunia dari semua ini, dan di sini kompleksitas tiba-tiba muncul. Karena kita sekarang sedang membangun satu proses dari semua jaringan pipa kecil ini sehingga seluruh perusahaan bekerja sebagai manusia.
Oleg: Dan apa jawabannya? Bagaimana cara mengatur kompleksitas ini?Anton: Ya, tidak ada jawaban, mereka terlahir dalam proses itu. Laporan saya tentang salah satu solusi ini. Pada umumnya, apakah semua ini akan terjadi? Saya pernah terinfeksi dengan pemikiran sistemik, banyak yang menyebutkannya di DevOps. Saya menjadi tertarik, saya membaca buku-buku Peter Senge, Russell Ackoff, Donella Meadows - orang-orang yang pada suatu waktu mulai berpikir sistemik entah bagaimana dan, pada umumnya, mengemukakan dalil-dalil utamanya. Salah satu prisma utama di mana pemikiran sistemik memandang dunia adalah umpan balik. Dengan kompleksitas ini, loop umpan balik ini sekarang muncul, yaitu kompleksitas menjadi sangat, sangat tinggi, kami mulai mencari alat untuk entah bagaimana mempertimbangkan kompleksitas ini. Saya tidak mengatakan mengurangi - mengambil kendali agar tidak meluncurkan.
Solusi terpusat muncul, pada umumnya Kubernetes adalah sesuatu seperti itu. Anda memiliki bidang kontrol terpusat, yang saat ini Anda kendalikan, akan mengontrol kerumitan layanan yang berjalan di sekitarnya. Saringan layanan, mesh layanan yang sama, adalah jenis solusi yang sama. Kami mengatakan: "Kami memiliki banyak layanan, mereka harus dapat berbicara satu sama lain entah bagaimana, karena tidak jelas di mana mereka duduk dan tidak jelas apakah mereka akan menjawab atau tidak, dan mereka tidak akan mengatasinya. Jadi, mari kita lakukan sekarang, di tengah-tengah kita akan menyisipkan pikiran universal yang akan memberi tahu mereka, dengan siapa Anda dapat berbicara, dengan siapa Anda tidak dapat berbicara, dan melindungi mereka jika mereka tiba-tiba mengatakan sesuatu yang kasar sebagai balasannya. " Dan ada banyak pertanyaan. Di satu sisi, ini semacam kebutuhan, karena organisasi tidak dapat mengatasinya. Selama beberapa tahun terakhir, kami telah membantu beberapa organisasi pindah ke dunia baru Cloud Native, terutama ketika menyangkut pertumbuhan perusahaan, penskalaan, dan orang-orang tersesat. Di tengah-tengah semua ini adalah beberapa tim kecil dari apa yang disebut DevOps, yang harus menulis ribuan baris YAML untuk entah bagaimana mengatasi semua ini, dan semuanya meledak begitu saja.
Cloud asli
Oleg: Bisakah Anda menjelaskan sedikit apa itu Cloud Native? Karena sudah menjadi semacam kata kunci, sekarang semua orang menulisnya di setiap dinding. Bagaimana Anda melihatnya?Anton: Secara umum semuanya dimulai dengan munculnya pendekatan “platform as a service”, yaitu ketika kita perlu menjalankan lebih banyak perangkat lunak dan lebih banyak layanan web daripada yang kita butuhkan sebelumnya. Kami menyadari bahwa meluncurkan setiap layanan secara terpisah sebagai hewan peliharaan favorit, yang kami tahu namanya dan merawatnya sepanjang hidup kami, tidak lagi mungkin, kami harus berurusan dengan mereka seperti sejenis kawanan. Untuk melakukan ini, kita memerlukan semacam platform yang homogen tempat kita bisa meletakkan kode ini, dan platform itu akan cukup pintar untuk menyajikannya. Peminum mobil, singkatnya, peminum-peminum mobil untuk layanan.
Pelopor dari pendekatan ini adalah Heroku. Mereka mengatakan bahwa agar layanan ini menggunakan infrastruktur kami, mereka juga harus sapi. Artinya, mereka harus memiliki kualitas tertentu. Jadi ada aplikasi 12 faktor, yang seharusnya memiliki kondisi stabil sesedikit mungkin. Aplikasi semacam itu harus dirakit oleh pipa tertentu di mana kompatibilitasnya dengan platform diperiksa. Itu harus bisa ulet (stabil) - untuk mengetahui bahwa jika terjadi kesalahan, maka jangan langsung jatuh. Di sisi lain, dalam arti tertentu, bergantung pada platform. Secara umum, hibrida seperti itu. Pahamilah bahwa Anda tidak sendirian, bahwa ada platform dan Anda harus menghargai keterbatasannya. Pada umumnya semuanya dimulai dari sana.
Tetapi untuk beberapa alasan pendekatan "platform sebagai layanan" ini tidak membenarkan dirinya sendiri, dan booming yang dijanjikan tidak terjadi. Ya, itu adalah Heroku, lalu segera setelah mereka semua orang-orang besar juga mengangkat analog mereka: Google App Engine, Amazon - Elastic Beanstalk. Saya harus banyak bekerja dengan perusahaan yang memulai dengan ini. Tetapi pada saat Anda melakukan sesuatu yang sedikit melampaui batas yang diizinkan oleh platform, itu berubah menjadi sakit kepala yang mengerikan. Karena Anda mulai menemukan tembok yang ada di mana-mana. Dan seperti orang cenderung, ketika mereka tersandung dinding, mereka mulai mencari cara untuk menembus dinding.
Cloud Native modern telah berkembang dari sana: cara membuatnya masih berjalan di cloud, menggunakan beberapa layanan platform, tetapi juga memberikan fleksibilitas luar biasa untuk semua yang terjadi. Kami terus menyeimbangkan antara fleksibilitas dan kesederhanaan. Fleksibilitas menyebabkan kerumitan, sementara menyederhanakan dan menciptakan platform yang jelas selalu menyebabkan keterbatasan. Cloud Native, tampaknya, menemukan semacam keseimbangan antara keterbatasan platform cloud dan fleksibilitas yang memungkinkan cloud Anda dengan penskalaan otomatisnya, dan semua ini ada harganya.
Oleg: Mungkin, organisasi itu sendiri entah bagaimana harus belajar untuk hidup secara proses dengan semua hal ini.Anton: Secara alami, alami! Semua ini meninggalkan bekasnya. Layanan microser juga termasuk dalam ini. Pada umumnya, ini adalah gagasan bahwa kami memiliki layanan kecil, aplikasi kecil yang tersebar di cloud dan dapat di mana saja kapan saja, dan mungkin ada 10 replika sekarang, dan besok - 1.500, ini juga merupakan bagian dari Cloud Asli Gagasan bahwa kita tidak dibatasi oleh batas fisik pusat data. Pada umumnya, seluruh dunia adalah awan saya, itu adalah visi yang benar-benar luar biasa, pengejaran yang luar biasa, tetapi memiliki harga, dan harga ini adalah kompleksitas, harganya adalah bahwa pada umumnya tidak ada seorang pun di kepala yang dapat memenuhi apa yang akan terjadi, ketika aplikasi kita tiba-tiba tumbuh dari 10 instance menjadi 1500. Tidak ada yang bisa membayangkan ini, dan semua artefak skala mulai muncul. Sebagai manusia, sebagai operator, kita tidak dapat melakukan apa pun dengan ini kecuali untuk menanggapi kekacauan yang terjadi. Maka kita mulai berpikir: “Tetapi bagaimana kita dapat membangun aplikasi dan infrastruktur kita sehingga ketika artefak ini muncul, pertama, mereka dapat diramalkan, dan kedua, entah bagaimana kita dapat mengatasi artefak ini dan melanjutkan berfungsi? "
Menggabungkan keterampilan teknis dan non-teknis
Oleg: Apakah Anda memiliki laporan tentang hal-hal teknis, misalnya, tentang saringan layanan dan ada laporan tentang kepemimpinan, tentang manajemen, semua itu. Apakah Anda lebih sebagai orang teknis, atau Anda seorang manajer, atau apakah pekerjaan Anda berbeda?Anton: Saya bahkan mulai menulis di beberapa titik tentang posting ini, saya belum selesai. Dalam arti tertentu, saya secara murni terpecah antara dua hal ini, karena, di satu sisi, saya suka memahami cara kerja berbagai hal, saya suka mengatasinya. Ketika mungkin untuk memecahkan masalah teknis, itu hanya memberikan rasa luar biasa dari kemampuan seseorang, apa yang disebut kepuasan instan, hadiah langsung, isian dopamin: "Oh, keren, saya bisa, saya memutuskan." Dan sulit untuk menolak, sulit untuk turun. Dan karena itu, saya terus melakukan hal-hal teknis. Teknologi baru membuat saya bersemangat: keren untuk memilih sesuatu, untuk memahami sesuatu. Karena ini, ternyata karena ada pengetahuan ini, orang ingin membelinya, dan saya terus menjualnya.
Di sisi lain, saya mengerti bahwa ini hanya sebagian kecil dari gambaran besar, saya telah bekerja di industri untuk waktu yang lama, dan saya tidak dapat membantu tetapi melihat bahwa teknologi hanyalah sudut dari sistem besar, hanya salah satu komponen. Saya mengelola tim, dan saya mengerti betapa pentingnya untuk memperhitungkan interaksi teknologi dan alat dengan orang-orang yang menggunakannya. Pada akhirnya, teknologi informasi, pada kenyataannya, teknologi apa pun, ada bagi orang untuk menggunakannya. Dan untuk menciptakan teknologi tanpa memikirkan siapa yang menggunakannya tidak ada gunanya. Teknologi itu sendiri tidak menarik sama sekali, kecuali jika Anda memikirkan aplikasinya, dan aplikasinya selalu dikaitkan dengan orang yang entah bagaimana mendapat manfaat darinya. Dan segala sesuatu di sekitar teknologi juga sangat menarik bagi saya. Saya merasa perlu untuk membicarakannya, saya mengerti bahwa tanpa ini, semuanya benar-benar tidak masuk akal. Sampai-sampai saya kadang-kadang duduk tinggi, sesuatu untuk mengendus di sana selama dua sampai tiga hari, kadang-kadang berminggu-minggu. Saya bisa terbawa dengan beberapa jenis masalah yang tidak bisa saya selesaikan, saya bisa menyelesaikannya, mendapatkan paroki yang luar biasa darinya. Tapi kemudian saya mengangkat kepala dari keyboard, melihat sekeliling, dan saya mengerti bahwa ada sesuatu yang terjadi di sekitar yang tidak bisa saya abaikan dengan cara apa pun. Dan kemudian kode dan memilih di Linux menjadi sama sekali tidak menarik bagi saya, tidak penting, dan saya ingin mulai memecahkan masalah di tingkat yang berbeda, di tingkat manusia.
Cara cepat mengetahui DevOps
Oleg: Dengar, bisakah kamu memberi saran kepada orang-orang yang sekarang terlibat dalam rekayasa dan mempelajari praktik-praktik DevOps pada saat yang sama? Bagaimana cara mendorong semuanya dan dalam urutan apa? Secara relatif, bagaimana merencanakan, mungkin, karier Anda menjadi lebih sukses dalam waktu singkat?Anton: Eh ... Nah, tidak ada tips universal, lagi, dari pengalaman saya sendiri. Untuk waktu yang lama, mungkin 10 tahun pertama karier saya, saya tidak senang dengan tempat saya. Saya mencari apa yang tidak saya sukai, saya fokus padanya, saya mencari apa yang akan lebih menarik untuk saya lakukan. Tetapi pada umumnya, dia tidak melakukan apa-apa tentang itu. Saran utama adalah ... Pada titik apa saya pikir karier saya sudah menanjak? Saat saya mulai berbicara tentang hal-hal yang menarik bagi saya. Bidang pengetahuan teknis, bahkan tidak hanya teknis, secara umum, bidang teknologi informasi sangat luas, yaitu, Anda bisa menjadi teknisi: pengembang, penguji, integrator, dan administrator sistem - ini semua adalah hal yang berbeda, semua orang dapat menemukan ceruk mereka sendiri di sana. Anda tidak ingin menjadi teknisi sepenuhnya, apakah Anda tertarik pada hal-hal teknis dan pada saat yang sama? Terlibat dalam produk, proyek. Ceruk penuh, temukan ceruk yang menarik minat Anda.
Sekarang banyak yang dikatakan tentang para profesional dalam bentuk "T". Anda perlu memahami di mana kaki T Anda berada, pilih satu hal, mulailah menggali di tempat ini. Kedalaman yang luar biasa akan ditemukan pada saat penggalian. Tapi Anda bisa menggali di mana saja. Dan saya sangat sadar bahwa ada banyak area yang tidak saya gali lebih dalam, karena saya mencoba melihat dan menyadari bahwa ini bukan milik saya. Dan di sini, di mana Anda tertarik untuk menggali - teruslah menggali, dan di sini sangat penting untuk membicarakannya. Sekali lagi, saya mengerti bahwa ini bukan untuk semua orang. : -, , , — , Gist' GitHub. - — .
. DevOps — . , , . , , , , - , - , , - . , . , , , , , , , . , . . ? — , , . , , . , . Sesuatu seperti itu. .
: , , DevOps', , . , , . , -, , … , . - , ? . , , : « ». , ?: -, , , : « ». - , , , , . , , : « ».
: ?: , , , , , . , — . , , «, , », - . , - , . - , - . , Agile: , , , , , .
, . . , — , - — , , — , , , , , . : « — , . , , . , . , , , -, , , ». , , , .
, - , , continuous integration … , , , . , , . , 10 : , , - , , , , , , , , . — . : , , , , . E - , , .
: . , - , , - , , , , DevOps -. ?: , , , , . , , , , ? , , . . - , , .
, , . , , .
DevOps
: , : Google, Netflix, . , ?: , , ( ) , — , , , . , , lean management — value stream mapping. . , , , - : , , , , , , , , . , , , .
: ? - — - , , — . , , , , . , , , Java, , , . , :
— , .
— , ? ?
— , , .
, , , , — , . — , .
, :
— .
:
— , , . .
, , :
— .
:
— . ?
:
— , .
, — , , . . . , CI/CD — . , . , , . , , .
: , ? , CI/CD . ?: -, , . - , , , , . Kubernetes: , — Kubernetes. VMware , Kubernetes . , Google . , , .
: Google ?: , , Swarm Kubernetes, Docker. Docker , . , Microsoft, Amazon — « Docker». Docker! Docker . , , , , Google, Microsoft, Amazon? , . , , , . , . .
Jadi disini. . — . — « Kubernetes , ». . Kubernetes . Kubernetes — - API, , . API . — , , , , : « API, , Kubernetes, Kubernetes , ».
— , Continuous Delivery Foundation, - , , Google, CloudBees, GitLab. Tekton, — API continuous delivery-. , continuous integration / continuous delivery- Kubernetes, , , . ,
. Microsoft , , SMI Spec. , , - .
Kubernetes . , , - , , Kubernetes — .
Oleg: Laporan apa yang Anda ikuti, apa yang menurut Anda menarik?Anton: Pertama-tama, jika ada beberapa fitur teknologi baru, nyasar yang belum sempat saya lihat sendiri, dan ada pembicara yang dapat menceritakannya dengan cerdas, maka saya pikir ini adalah keuntungan liar, karena sebagai gantinya untuk membaca dan menggali sekarang, dan mungkin dengan kesulitan memahami, Anda dapat datang dan mendengarkan dalam setengah jam bagaimana seseorang akan menunjukkan kepada Anda, memberi tahu Anda. Sekali lagi, untuk ini Anda memerlukan keterampilan dan keinginan tertentu untuk dapat berbicara tentang teknologi. Dan saya mengerti bahwa ini juga tidak datang dari mana saja, kita perlu mengusahakannya. Aku juga butuh banyak waktu. Omong-omong, fakta bahwa saya terlibat dalam pengajaran teknis sangat membantu saya dalam hal ini. Ketika Anda memiliki kelas di depan Anda, Anda perlu menjelaskan sesuatu kepada orang-orang, dan Anda memahami bahwa, tidak peduli bagaimana Anda menjelaskan, mereka bodoh - Anda menyadari bahwa, tampaknya, masalahnya adalah bagaimana Anda menjelaskan, dan bukan bahwa orang itu bodoh .
Oleg: Dan pengajaran teknis seperti apa? Apa yang kamu lakukanAnton: Saya mengajar disiplin ilmu murni selama 7-8 tahun. Itu dimulai dengan fakta bahwa saya mengajar hal-hal seperti Maven dan skrip shell selama setahun. Karena saya sangat sibuk dengan Jenkins dan mengenalnya secara mendalam, saya mengajar orang bagaimana bekerja dengan Jenkins, administrasi. Dalam beberapa tahun terakhir, segala sesuatu yang terkait dengan cloud asli: Kubernetes, wadah, dan segala sesuatu di sekitarnya. Saya akan ke London segera, saya akan melakukan kelas master di Istio. Ini bukan bagian utama dari kegiatan saya, tetapi di suatu tempat dalam satu atau dua bulan saya melakukan kelas master.
Oleg: Apakah Anda pergi terutama ke laporan, ke topik atau ke seseorang?Anton: Jika saya tahu bahwa pembicara itu baik, maka saya pergi ke seseorang hanya karena masih sangat penting bagi saya untuk belajar dari orang lain bagaimana cara memberi tahu dengan baik. Belajar selalu penting. Jika ada topik, tetapi saya tidak tahu pembicara, maka saya akan pergi melihat, tetapi seperti biasa, bagaimana cara pergi ke stand-up: Saya melihat 10-15 menit pertama, tidak masuk - saya pergi. Atau ada pembicara yang benar-benar akan saya ikuti, karena mereka selalu mengatakan dengan menarik, bahkan hal-hal yang Anda ketahui dapat ditunjukkan dari sudut pandang mereka, itu hanya untuk Anda dan mengubah seluruh pertanyaan dari perspektif baru. Dari yang saya sukai belakangan ini ... Pertama, ada Simon Wardley - seorang konsultan, ia memiliki chip sendiri dengan kartu gambar, ia menjelaskan dengan bantuan kartu bagaimana perusahaan dapat membangun strategi mereka dengan benar, ia pernah kemudian CTO, CEO perusahaan rintisan, ia banyak berbicara tentang ini, tentang teknologi. Ngomong-ngomong, dia terus-menerus tenggelam untuk serverless dan mengatakan bahwa mereka yang tidak melakukan serverless saat ini memiliki masalah besar.
Oleg: Apakah ini kawan yang memiliki buku Menengah ? Dia membuatnya dalam bentuk posting. Format yang tidak biasa.Anton: Dia berbicara sangat keren. Kuliahnya selama 2-3 tahun terakhir yang paling saya ingat. Yah, John Willis, yang datang ke DevOops tahun lalu - hanya karena dia
benar-benar tahu cara mengatakannya . Ada beberapa masalah dengan dia, karena dia berbicara banyak tentang realitas Amerika, hal-hal yang kadang-kadang tidak berlaku untuk realitas Rusia atau Israel. Sekarang mereka memiliki semacam perang sekarang dengan beberapa papan persetujuan perubahan, yang mereka terus bicarakan. Ini, tampaknya, adalah hal tertentu yang ada di perusahaan-perusahaan Amerika, ada semacam proses untuk melakukan dan menyetujui perubahan dalam IT, semacam komitmen yang harus dijalani.
Oleg: Tapi kami tidak memilikinya - saya bahkan tidak mengerti apa yang Anda bicarakan sekarang.Anton: Jadi saya juga tidak benar-benar mengerti, tidak ada hal seperti itu di Israel juga. Dan di sana mereka membicarakannya. Jika Anda mendengarkan semua kawan ini, seperti DORA, yang
membuat Laporan State of DevOps , mereka juga menulis banyak tentang hal itu. Secara umum, maksud saya adalah orang berbicara tentang beberapa masalah yang hanya mereka miliki, dan Anda tidak tertarik sama sekali.
Oleg: Anda berada di DevOops terakhir, laporan apa yang layak untuk ditinjau dan meninjau rekaman?Anton: Lihat
semuanya . Sedikit tertarik dengan topik - go.
Oleg: Menurut saya, ada beberapa Anton Weiss. Mungkin patut dilihat.Anton: Tidak, jangan lakukan itu, beberapa hal yang membosankan :-)
Oleg: Yah, terima kasih banyak. Itu luar biasa! Saya melihat bahwa Anda telah mengirimkan laporan ke konferensi berikutnya, jadi - sampai jumpa di DevOops berikutnya!Konferensi Moskow DevOops 2020 akan diadakan 29-30 April, kali ini di Moskow. Kami menggambarkan esensi dari konferensi tentang Habré dalam pengumuman "DevOps-engineer tidak ada . " Program ini sedang aktif dibentuk (masih ada berbulan-bulan sebelum konferensi), tetapi pembicara pertama sudah dapat dilihat di situs . Anda dapat membeli tiket di sana .