Menjelang DevOps Conf Russia 2018, kami berbicara dengan direktur teknis Uchi.ru Alexei Vakhov tentang tahapan pengembangan platform, alat apa yang mereka gunakan, dan seberapa banyak ovo DevOps ada di sana.
Alexey Vakhov - Direktur Teknis Uchi.ru. Dia bekerja sebagai pengembang C ++ pada sistem besar (puluhan juta baris kode). Teknologi server favorit - Ruby on Rails, termasuk di antara 100 kontributor teratas. Dia menyukai organisasi produksi TI, operasi, arsitektur aplikasi web.
Uchi.ru adalah platform pendidikan Rusia tempat siswa di kelas 1-11 belajar di sekolah dengan cara yang menyenangkan dan menghibur. Platform ini digunakan oleh lebih dari 2,5 juta siswa dan 220 ribu guru di Rusia, Amerika Serikat, Brasil, India, Afrika Selatan, dan Cina. Ini mengambil tempat ke-36 di peringkat global platform e-learning. Perusahaan ini memiliki lebih dari 400 karyawan.- Bagaimana semuanya dimulai? Berapa banyak orang di perusahaan ketika Anda tiba?- Saya diundang ke perusahaan pada 2012, yaitu, enam tahun yang lalu. Saat itu saya adalah karyawan kelima atau keenam, dan satu-satunya pengembang. Saya mengeset dan melakukan pengembangan server. Kami membuat aplikasi web pertama dan mempostingnya di Heroku.
"Bagaimana keadaanmu sekarang?" Berapa banyak tim dan ukuran apa? Bagaimana mandiri? Bagaimana mereka berinteraksi satu sama lain?- Hari ini kami memiliki lebih dari 400 orang, di mana sekitar 100 adalah insinyur yang bersatu dalam sekitar 20 tim terpisah. Kami memiliki dua arah besar: pengembangan produksi dan pengembangan tugas interaktif.
Tim terpisah memiliki lingkungan sendiri yang terisolasi, sistem pembangunan khusus, dipertajam untuk tugas-tugas yang dilakukan tim, server mereka sendiri, kode sumber. Mereka berkomunikasi satu sama lain hanya jika diperlukan.
- Dengan tingkat pertumbuhan perusahaan ini, apakah Anda berhasil membuat wiki sendiri? Bagaimana Anda mendukungnya?- Kami memiliki beberapa basis pengetahuan. Ada wiki dalam bentuk pertemuan, di mana ada bagian umum dan tematik, dan masing-masing tim memiliki bagian sendiri. Di setiap repositori kami mendukung readme dan white paper tambahan. Bagaimanapun, setiap tim dialokasikan ruangnya sendiri, bagiannya sendiri di jira, dalam pertemuan, semua ini diatur sesuai dengan keinginan tim. Kami tidak memiliki dikte dan standarisasi desain.
- Peningkatan tajam dipenuhi dengan kehilangan kontrol. Bagaimana Anda menangani ini? Bagaimana Anda mengoordinasikan pekerjaan banyak tim?- Koordinasi umum dicapai dengan membangun hierarki manajemen. Kami memiliki koordinator rujukan, dan masing-masing tim memiliki pemimpinnya sendiri. Semuanya sederhana di sini.
Jika Anda menjawab pertanyaan ini dari sudut pandang teknologi, maka tim mematuhi aturan umum, misalnya, tes terhubung ke setiap repositori, seluruh pengembangan pergi ke cabang baru, yang diperiksa, diluncurkan ke lingkungan pengujian, dan kemudian ke produksi.
- Tahapan pembentukan perusahaan apa yang Anda pilih sendiri?- Saya suka pendekatan yang saya baca dalam buku yang menarik, yang menurutnya krisis terjadi ketika sistem nilai yang biasa runtuh. Dalam kasus kami, karena pertumbuhan krisis yang begitu cepat, ada banyak krisis dan masing-masing menentukan pergerakan selanjutnya.
Krisis pertama datang ketika kami menjadi sempit di satu ruangan dan harus berkembang menjadi dua. Pada tahap ini, informasi muncul yang tidak lagi diketahui semua orang. Krisis kedua dan selanjutnya terjadi ketika pengembang harus membagi ke dalam tim produk. Sekali lagi, tim kami yang besar dan ramah dipaksa untuk berpisah dan berpisah dalam berbagai sudut.
Setiap perubahan yang terjadi bersama kami didukung oleh inovasi teknologi yang tepat waktu dan relevan. Hal yang sama berlaku untuk metodologi DevOps. Kita dapat mengatakan bahwa saya sendiri baru-baru ini mulai memahami apa nilai-nilai budaya dan mengapa mereka penting dalam tim besar. Misalnya, ada saat ketika tidak ada yang memiliki pertanyaan tentang siapa yang bertanggung jawab atas stabilitas situs. Semua orang mengerti bahwa orang yang menggelar layanan bertanggung jawab untuknya. Kami merekrut orang yang seharusnya hanya bertanggung jawab untuk server - dan konfrontasi "pengembang vs administrator" dimulai pada hari yang sama. Itu luar biasa, seperti buku.
- Ceritakan lebih banyak tentang masing-masing tahap. Alat apa yang Anda ambil untuk diri sendiri, mana yang harus Anda tinggalkan? Seperti yang saya pahami dari pengumuman kinerja Anda di DevOpsConf 2018, semua infrastruktur Anda dikerahkan di awan dalam wadah buruh pelabuhan. Mengapa Anda mengambil keputusan seperti itu? Sejak kapan Anda tidak bisa hidup tanpa wadah?- Awalnya tidak ada, bahkan pelacak. Hanya meluncurkan ke Heroku: git push, dan semua orang senang. Tetapi Heroku dengan cepat berhenti memuaskan kami, karena memiliki cukup banyak ping, dan mereka tidak mentolerir muatan. Kami pindah ke server besi biasa dan menyewa konsultan. Seiring waktu, server sangat dikotori. Pada saat ini, kami telah sangat meningkatkan lalu lintas, jumlah produksi, layanan internal dan eksternal. Kami mengkonfigurasi server melalui Chef. Suatu hari, kami jatuh di bawah beban dan pada malam hari kami pindah ke cloud menggunakan Ansible. Perasaan beralih ke Ansible hanya kosmik. Ternyata menjadi sederhana dan dapat dimengerti, terutama dalam hal infrastruktur kecil seperti itu.
Dimulai dengan sekitar 60 aplikasi, infrastruktur kami telah berkembang menjadi terpisah, sebagaimana kami menyebutnya, "situs". Ini adalah cloud yang terisolasi dengan subnet mereka sendiri, dengan terraform mereka sendiri dan konfigurasi yang memungkinkan.
Dengan semakin banyaknya aplikasi dan server, konfigurasi kami mulai mengambang, karena ada banyak hal yang perlu dipertimbangkan sebelum memulai aplikasi sederhana pada RoR. Plus, bagian dari konfigurasi roll-out berada di repositori dengan aplikasi, bagian dalam resep ansambel, para pengembang mulai menggunakan sihir rahasia, membuat tautan ke folder, semacam sinkronisasi. Akibatnya, menjadi sangat mustahil untuk dipertahankan.
Ketika kami memiliki sekitar seratus aplikasi di awan yang berbeda, kami mulai melihat lebih dekat pada buruh pelabuhan. Itu musim panas lalu. Dalam sekitar 10 bulan, kami mentransfer semua aplikasi kami, dan pada saat itu ada sekitar 150 dari mereka, pada kelompok buruh pelabuhan. Ini telah menjadi keselamatan nyata bagi kita. Kami terhindar dari versi pemantauan dan memo lingkungan di server. Segalanya menjadi jauh lebih nyaman dan sederhana: aplikasi dapat dengan mudah ditempatkan di cluster buruh pelabuhan, mudah dihapus dari sana, ia memiliki meta-informasi sendiri, dari mana jelas layanan yang terdiri dari aplikasi, yang mahkota, pekerjaan latar belakang, dll diluncurkan.
- Seberapa teguh Anda berdiri pada pendekatan DevOps yang asli? Apakah semuanya cocok untuk Anda atau apakah Anda mengubah sesuatu untuk diri sendiri? Apakah sulit untuk membangun kembali tim?- Saya sendiri tidak memiliki jawaban yang tepat untuk pertanyaan tentang apa itu DevOps. Dalam bekerja, saya selalu melanjutkan dari akal sehat sederhana. Dan orang-orang mengatakan bahwa di sini DevOps telah tumbuh. Bahkan, saya hampir tidak memerlukan bagian teoritis dari DevOps, karena bisnis meminta saya untuk hasil. Dengan kata lain, jika saya memberi tahu mereka dengan indah dan tidak melakukan apa-apa, itu akan sangat buruk, dan jika saya lakukan, tetapi jangan memberi tahu tentang kecantikan, itu akan tetap baik.
Pemahaman saya tentang DevOps adalah sebagai berikut. Misalnya, ada beberapa perusahaan besar yang ingin membuat atau sudah membuat produk digital. Produk digital selalu umpan balik cepat dari pasar. Pengiriman terus-menerus secara otomatis terjadi, batas-batas antara pengembangan dan dukungan menjadi kabur, budaya DevOps sedang diperketat, yang menafsirkan aturan bentuk yang baik antara orang-orang yang bertanggung jawab untuk meluncurkan, menguji dan mendukung. Akibatnya, hubungan semacam itu memungkinkan mereka untuk sepakat di antara mereka sendiri untuk mencapai tujuan bersama, serta mengalihkan fokus dari tanggung jawab pribadi mereka ke hasil bersama. Dalam sebuah perusahaan besar dan mapan, perubahan dalam proses terjadi, mereka melanggar.
Karena kami tidak memiliki perusahaan yang mapan, maka kami mengembangkan prinsip kerja dengan sangat cepat. Selain itu, bisnis terus-menerus memberi kami tugas baru, jadi kami membangun infrastruktur kami terutama berdasarkan akal sehat dan persyaratan internal.
Kata DevOps tidak berarti bagi saya. Tetapi sekarang, ketika kita melewati semua ini, ketika saya melihat munculnya titik-titik konflik, kaburnya tanggung jawab, saya menyadari bahwa DevOps seperti aspek budaya interaksi antara orang-orang untuk tujuan bersama. Dan tujuan umum dalam produk digital adalah membuat fitur baru dan meluncurkannya secepat mungkin.
- Akan menarik untuk belajar tentang betapa sulitnya bagi pemula untuk bergabung dengan pekerjaan Anda dengan begitu banyak alat modern. Bagaimana pekerjaan Anda dengan orang-orang diorganisir?- Kami memiliki program adaptasi. Kami memberi tahu karyawan baru tentang bagaimana kami berkembang dan bagaimana semuanya diatur sekarang, kami melampirkan mentor kepadanya. Pada hari pertama, kami membantunya mengatur lingkungan dan mengeluarkan pertempuran, tetapi bukan tugas yang sangat sulit. Mentor menemaninya selama beberapa bulan, membantu dengan adaptasi.
- Ceritakan tentang rencana perusahaan. Di mana Anda berencana untuk tumbuh dan bidang apa yang harus dikembangkan? Apakah tumpukan teknologi saat ini memberikan dasar untuk pertumbuhan lebih lanjut, atau Anda harus mengubahnya lagi?- Rencana bisnis ambisius. Hari ini, lebih dari dua juta anak sekolah secara teratur menghadiri Uchi.ru, yaitu sekitar 30% dari semua siswa sekolah dasar di seluruh negeri. Kami akan terus menarik pengguna baru ke platform di Rusia dan terlibat dalam pengembangan internasional.
Secara teknis, kami memiliki 15 cluster buruh pelabuhan yang terisolasi, dan cukup banyak waktu dihabiskan untuk beralih dari satu ke yang lain, menjadi sulit untuk mempertahankan dan meningkatkannya. Persyaratan untuk kecepatan perubahan dan keandalan hanya tumbuh. Karena itu, ada cadangan, tetapi kami juga akan memperbarui.
Teman-teman, jika Anda tertarik dengan pengalaman Alexey, kami segera mengundang ke
DevOps Conf Russia 2018 kami , yang akan diadakan pada 1-2 Oktober. Dalam laporannya, ia akan berbicara tentang pengalaman menggunakan cloud, penerapan metodologi DevOps, nilai-nilai dan prinsip-prinsip timnya.
Berlangganan Newsletter Bertema Ontiko DevOps untuk menerima pembaruan program segera setelah tersedia. Kami mencoba menjadikan surat-surat itu berguna dan tidak mengganggu, kami mengirim berita konferensi, transkrip laporan, dan video segar.
Ngomong-ngomong, video dapat dipantau secara terpisah di saluran YouTube - ada semua video yang dikumpulkan dalam beberapa tahun terakhir dan daftar ini terus diperbarui.