Halo, Habr! Nama saya Roman, dan saya ingin berbicara hari ini tentang bagaimana kami di Innopolis University mengembangkan bangku tes dan layanan untuk sistem Acronis Active Restore, yang akan segera menjadi bagian dari lini produk perusahaan. Setiap orang yang tertarik pada bagaimana universitas membangun hubungan dengan mitra industri, saya mengundang Anda untuk melanjutkan di bawah cat.
Pengembangan Active Restore dimulai di dalam Acronis, tetapi kami, sebagai mahasiswa Universitas Innopolis, mengambil bagian dalam proses ini sebagai bagian dari proyek pelatihan industri. Kurator saya (dan sekarang kolega) Daulet Tumbaev sudah menulis tentang gagasan itu, dan juga arsitektur,
di posnya . Hari ini saya akan berbicara tentang bagaimana kami menyiapkan layanan dari Innopolis.
Semuanya dimulai pada musim panas, ketika kami diberi tahu bahwa pada semester pertama, perusahaan IT akan datang kepada kami dan menawarkan ide-ide mereka untuk kerja praktek. Maka, pada bulan Desember 2018 kami diberi 15 proyek berbeda, dan pada akhir bulan kami menetapkan prioritas, mencari tahu siapa yang paling suka.
Semua mahasiswa mengisi formulir di mana perlu untuk memilih empat proyek di mana kami ingin berpartisipasi. Itu perlu untuk memotivasi mengapa saya, dan mengapa tepatnya proyek ini. Sebagai contoh, saya menunjukkan bahwa saya sudah memiliki pengalaman dalam pemrograman dan pengembangan sistem dalam C / C ++. Tetapi yang paling penting, proyek ini memungkinkan saya untuk mengembangkan keterampilan saya dan terus tumbuh.
Dua minggu kemudian, kami ditugaskan, dan dari awal semester kedua, pekerjaan pada proyek dimulai. Tim dibentuk, pada pertemuan pertama kami mengevaluasi kekuatan dan kelemahan masing-masing dan peran yang ditugaskan.
- Roman Rybkin adalah pengembang Python / C ++.
- Eugene Ishutin - Pengembang Python / C ++, bertanggung jawab untuk berinteraksi dengan perusahaan.
- Anastasia Rodionova adalah pengembang Python / C ++ yang bertanggung jawab untuk menulis dokumentasi.
- Brandon Acosta - menyiapkan lingkungan, menyiapkan dudukan untuk eksperimen dan pengujian.
Dua minggu pertama kami harus memulai proses. Kami menjalin kontak dengan pelanggan, meresmikan persyaratan untuk proyek, meluncurkan proses berulang, dan mengatur lingkungan untuk bekerja.
Omong-omong, pekerjaan kami dengan pelanggan benar-benar mulai mendidih ketika kami memulai pilihan. Faktanya adalah bahwa Acronis memimpin di Universitas Innopolis (dan bukan hanya) subjek pilihan. Dan Alexey Kostyushko, pengembang terkemuka tim Kernel, mengajarkan dua kursus secara berkelanjutan: Rekayasa Balik dan Arsitektur dan Driver Kernel Windows. Sejauh yang saya tahu, kursus pemrograman sistem dan komputasi multi-threaded juga direncanakan di masa depan. Tetapi yang utama adalah bahwa semua kursus ini dirancang sedemikian rupa untuk membantu siswa mengatasi proyek industri. Mereka serius memompa dalam memahami bidang subjek dan dengan demikian mempermudah pekerjaan pada proyek.
Karena ini, kami mulai lebih giat dari tim lain, dan interaksi dengan Acronis sendiri menjadi lebih padat. Alexey Kostyushko bertindak untuk kami dalam peran sebagai Pemilik Produk, darinya kami menerima pengetahuan yang diperlukan dalam bidang subjek. Berkat pilihannya, kemampuan keras dan kompetensi kami dipompa dengan sangat kuat, kami menjadi sangat siap untuk memenuhi tugas yang kami hadapi.
Dari pemikiran ke proyek
Bulan pertama untuk semua tim adalah sesulit mungkin. Semua orang tersesat, tidak tahu harus mulai dari mana - mungkin dengan dokumen atau, sebaliknya, menyelami kode. Pada awalnya, komentar yang saling bertentangan datang dari kurator dan mentor di universitas dan perwakilan perusahaan.
Ketika semuanya jatuh ke tempatnya (setidaknya di kepala saya), menjadi jelas bahwa mentor dari universitas membantu kami membangun hubungan internal dalam tim dan menyiapkan dokumen. Tapi titik terobosan nyata adalah kedatangan Daulet pada bulan Maret. Kami hanya duduk dan mengerjakan proyek sepanjang akhir pekan. Kemudian kami memikirkan kembali esensi proyek, memulai kembali, mendistribusikan kembali prioritas tugas dan dengan cepat terbang ke depan. Kami memahami apa yang perlu dilakukan untuk memulai percobaan (tentang hal itu nanti) dan untuk mengembangkan layanan. Sejak saat itu, gagasan umum berubah menjadi rencana yang jelas. Pengembangan kode yang sebenarnya dimulai, dan dalam 2 minggu kami mengembangkan versi pertama dari bangku tes, termasuk mesin virtual, layanan dan kode yang diperlukan untuk mengotomatisasi eksperimen dan mengumpulkan data.
Perlu dicatat bahwa seiring dengan proyek industri ada kursus pelatihan yang membantu kami membangun arsitektur yang kompeten untuk proyek kami dan mengatur Manajemen Kualitas. Pada awalnya, tugas-tugas ini memakan waktu 70-90% dari waktu per minggu, tetapi, ternyata, waktu diperlukan untuk menghindari masalah dalam proses pengembangan. Tujuan universitas adalah agar kami belajar membangun proses pengembangan secara kompeten, dan perusahaan, sebagai pelanggan, lebih tertarik dengan hasilnya. Ini, tentu saja, membawa banyak kebingungan, tetapi membantu menggabungkan keterampilan teoretis dan praktis. Kompleksitas dan beban yang memadai memastikan adanya motivasi, yang menghasilkan proyek yang sukses.
Awalnya, dua orang di tim kami terlibat dalam pengembangan murni, satu orang mengambil alih dokumen, dan yang lain terjun ke pengaturan lingkungan. Namun, kemudian tiga bujangan bergabung dengan kami, yang dengannya kami menjadi satu tim. Universitas memutuskan untuk meluncurkan proyek industri uji untuk siswa dari tahun ketiga studi. Memperluas tim dari 4 hingga 7 orang sangat mempercepat prosesnya, karena bujangan kami dapat dengan mudah melakukan tugas yang berkaitan dengan pengembangan. Ekaterina Levchenko membantu penulisan kode python dan skrip batch untuk bangku tes. Ansat Abirov dan Ruslan Kim bertindak sebagai pengembang, mereka terlibat dalam pemilihan dan optimalisasi algoritma.
Kami bekerja dalam format ini hingga akhir Mei, ketika percobaan diluncurkan. Pada saat ini, proyek industri untuk bujangan berakhir. Dua dari mereka memulai magang Acronis dan terus bekerja bersama kami. Karena itu, setelah Mei, kami sudah bekerja sebagai satu tim yang terdiri dari 6 orang.
Sebelum kami adalah semester ketiga, yang di Innopolis bebas dari kegiatan akademik. Kami hanya memiliki 2 pilihan, dan sisa waktu dihabiskan untuk proyek industri. Itu di semester ketiga yang bekerja pada layanan berjalan intensif. Proses pengembangan sepenuhnya jatuh pada rel, demo dan laporan menjadi teratur. Dalam format ini, kami bekerja selama 1,5 bulan, dan pada akhir Juli kami hampir menyelesaikan bagian pengembangan pekerjaan.
Rincian teknis
Pertama, persyaratan untuk suatu layanan dirumuskan, yang harus cukup berinteraksi dengan driver sistem file minifilter (yang dapat Anda baca di
sini ) dan arsitekturnya dipikirkan. Dengan memperhatikan kesederhanaan dukungan kode lebih lanjut, kami segera memberikan pendekatan modular. Layanan kami mencakup beberapa manajer, agen, dan penangan, dan bahkan sebelum dimulainya pengkodean, kemampuan untuk bekerja dalam mode paralel diletakkan.
Namun, setelah membahas arsitektur pada pertemuan dengan Acronis, diputuskan untuk melakukan percobaan terlebih dahulu, dan kemudian mengambil layanan itu sendiri. Akibatnya, pengembangan hanya memakan waktu 2,5 bulan. Sisa waktu, kami melakukan percobaan untuk menemukan daftar file minimum yang memadai yang dapat dijalankan Windows. Dalam sistem nyata, set file ini dihasilkan menggunakan driver, namun, kami memutuskan untuk menemukan set ini secara heuristik, menggunakan metode setengah pembagian, untuk memeriksa operasi driver.
Stand percobaan.
Untuk melakukan ini, kami mengumpulkan stand di Python dari dua mesin virtual. Salah satunya bekerja di Linux, dan yang kedua memuat Windows. Dua disk dikonfigurasikan untuk mereka: Virtual HD1 dan Virtual HD2. Kedua drive terhubung ke VM1 di mana Linux diinstal. Pada mesin virtual ini pada HD1, aplikasi Killer diinstal, yang "merusak" HD2. Kerusakan mengacu pada penghapusan beberapa file dari disk. HD2 adalah disk boot untuk VM2 yang bekerja di bawah Windows. Setelah "kerusakan" pada disk, kami mencoba memulai VM2. Jika mungkin untuk melakukan ini, maka file yang dihapus dari disk dianggap tidak perlu dijalankan.
Untuk mengotomatiskan proses ini, kami mencoba menghapus file tidak secara acak, tetapi sebagai bagian dari pendekatan yang dipikirkan sebelumnya. Algoritma terdiri dari 3 langkah:
- Bagilah daftar file menjadi dua.
- Hapus salah satu dari setengah file.
- Cobalah untuk memulai sistem. Jika sistem dimulai, kemudian tambahkan file yang dihapus ke daftar yang tidak perlu. Jika tidak, kami kembali ke langkah 1.
Pertama, kami memutuskan untuk mensimulasikan algoritma. Misalkan ada 1.000.000 file dalam sistem file. Dalam hal ini, pencarian yang paling efektif untuk file-file penting terjadi dalam kasus di mana file-file penting sekitar 15% dari total.
Metode setengah pembagian.Awalnya, ada banyak masalah dengan eksperimen. Selama 2-3 minggu, tempat tes sudah siap. Dan 1-1,5 bulan lagi saya harus menangkap bug, menambahkan kode dan menerapkan berbagai trik untuk membuat stand bekerja.
Hal yang paling sulit adalah menangkap bug yang dikaitkan dengan operasi caching disk. Percobaan bekerja selama 2 hari dan menghasilkan hasil yang sangat optimis yang beberapa kali lebih cepat daripada simulasi. Namun, pengujian file kritis gagal, sistem tidak memulai. Ternyata selama pematian paksa mesin virtual, operasi penghapusan yang di-cache oleh sistem file tidak dilakukan, dan, oleh karena itu, disk tidak sepenuhnya dihapus. Alhasil, algoritma menerima hasil yang salah, dan selama beberapa hari kami berusaha keras untuk memastikan semuanya.
Pada titik tertentu, kami perhatikan bahwa selama operasi terus-menerus, algoritma tersebut dimakamkan di salah satu segmen sistem file dan mulai berupaya menghapus file yang sama (dengan harapan hasil baru). Ini terjadi pada saat-saat ketika algoritma beristirahat di daerah di mana sebagian besar diperlukan, sambil memilih interval yang salah untuk dihapus. Pada titik ini, kami memutuskan untuk menambahkan daftar file perombakan. Yaitu, sekali beberapa iterasi, daftar file dikocok. Ini membantu untuk menghilangkan algoritma dari tongkat tersebut.
Ketika semuanya sudah siap, kami meluncurkan dua VM ini selama 3 hari. Secara total, sekitar 600 iterasi berlalu, di antaranya ada lebih dari 20 peluncuran yang berhasil. Menjadi jelas bahwa percobaan ini dapat berjalan untuk waktu yang lama, serta pada mesin yang lebih kuat, untuk menemukan ukuran file yang optimal untuk menjalankan Windows. Selain itu, algoritma dapat didistribusikan di beberapa mesin untuk mempercepat proses ini
Dalam kasus kami, selain Windows, hanya ada Python dan layanan kami di disk. Dalam tiga hari kami berhasil mengurangi jumlah file dari 70 ribu menjadi 50 ribu. Daftar file berkurang hanya 28%, tetapi menjadi jelas bahwa pendekatan ini berfungsi, dan memungkinkan Anda untuk menentukan set minimum file yang diperlukan untuk memuat OS.
Struktur layanan
Mari kita sentuh sedikit struktur layanan. Modul layanan utama adalah manajer antrian. Karena kita mendapatkan daftar file dari driver, kita perlu mengembalikan file dari daftar ini. Untuk melakukan ini, kami membuat pergantian dengan prioritas.
Kami memiliki daftar file yang dipulihkan pada gilirannya. Dan jika permintaan akses baru muncul, file yang sangat dibutuhkan dipulihkan dalam prioritas. Berkat ini, di awal antrian akan ada file-file yang benar-benar dibutuhkan pengguna sekarang, dan pada akhir antrian akan ada file-file yang mungkin diperlukan di masa depan. Tetapi dengan karya aktif pengguna, "antrian objek luar biasa" dapat dibentuk, serta daftar file yang sedang dipulihkan sekarang. Selain itu, operasi pencarian seharusnya diterapkan ke semua antrian ini sekaligus. Sayangnya, kami tidak menemukan implementasi antrian yang dapat menetapkan beberapa prioritas file, sementara mendukung pencarian, serta mengubah prioritas dengan cepat. Kami tidak ingin beradaptasi dengan struktur data yang ada, dan karena itu kami harus menulis sendiri dan mengatur kemampuan untuk bekerja dengannya.
Layanan kami perlu berkomunikasi terlebih dahulu dengan driver yang Daulet kerjakan, dan setelah itu dengan komponen yang bertanggung jawab untuk mengembalikan file ... Oleh karena itu, untuk permulaan, kami memutuskan untuk membuat emulator kecil kami sendiri dari sistem pemulihan, yang dapat mengeluarkan file dari drive eksternal sehingga mereka dapat pulihkan dan uji layanan.
Secara total, dua mode operasi disediakan - mode normal dan pemulihan. Dalam mode normal, driver mengirimkan kepada kami daftar file yang dipengaruhi oleh startup OS. Kemudian, ketika sistem sedang berjalan, driver memonitor semua operasi file dan mengirimkan pemberitahuan ke layanan kami, dan itu, pada gilirannya, mengubah daftar file. Dalam mode pemulihan, driver memberi tahu layanan bahwa pemulihan sistem diperlukan. Layanan mengantri file, menjalankan agen perangkat lunak yang meminta file dari cadangan, dan memulai proses pemulihan.
Diploma, undangan kerja, dan proyek baru
Ketika layanan sudah siap dan diuji, kami memiliki aktivitas terakhir di proyek. Penting untuk memperbarui dan menyusun semua artefak yang telah kami kumpulkan, serta menyajikan hasil kami kepada pelanggan dan universitas. Bagi perusahaan, ini adalah langkah lain menuju implementasi proyek, untuk universitas dengan tesis kelulusan kami.
Setelah presentasi, sebuah proposal diajukan kepada siswa. Dan setelah beberapa minggu saya mulai bekerja di Acronis. Hasil proyek membuat para pengembang berpikir bahwa adalah mungkin untuk membuat layanan lebih efisien dengan menurunkannya ke tingkat Aplikasi Windows Asli. Tetapi lebih lanjut tentang itu di artikel berikutnya.