Hai Nama saya Pasha Chernyak, saya adalah pengembang terkemuka di QIWI, dan hari ini saya ingin berbicara tentang hal yang tak terhindarkan. Tentang Legacy
Mari kita mulai dengan pertanyaan: apa itu layanan Legacy? Apakah layanan Legacy adalah layanan yang belum disentuh pengembang selama seminggu / bulan / tahun? Atau itu layanan yang ditulis oleh programmer yang kurang berpengalaman, misalnya, khusus oleh Anda, tetapi setahun yang lalu? Dan sekarang Anda lebih keren dan lebih berpengalaman. Atau, setelah semua, apakah layanan Legacy adalah layanan yang Anda putuskan untuk tidak pernah berkomitmen lagi dan secara perlahan mempersiapkan penggantinya? Bagaimanapun, meninggalkan layanan ini tanpa pengawasan dan tidak memperbarui adalah bom waktu yang dapat meledak kemudian.
Sebelum beralih ke cara kami bekerja dengan layanan Legacy kami di QIWI, saya akan memberi tahu Anda cara kami menertibkan layanan di Wallet. Selama dua tahun sekarang saya bertanggung jawab atas kinerjanya. Jika ada masalah, mereka selalu memanggil saya terlebih dahulu. Saya biasanya tidak memiliki keberanian untuk menelepon orang lain pada pukul 11 malam, jadi saya harus duduk dan memahami semua layanan dari domain kami.
Tapi saya, seperti orang lain, suka tidur di malam hari, jadi saya mencoba menangani operasi: "Guys, mengapa Anda memanggil saya?" Untuk itu ia menerima jawaban yang agak ringkas dari formulir "Siapa lagi?" Karena saya sedang memperbaiki layanan, dan orang-orang tidak tahu siapa yang harus dihubungi.
Oleh karena itu, dalam salah satu retrospektif dari tim backend Wallet, kami memutuskan bahwa kami perlu menyusun sebuah piring yang di dalamnya tertulis daftar layanan, layanan mikro dan monolit dompet kami, dan mereka yang bertanggung jawab untuk itu. Tablet umumnya bermanfaat, sampai batas tertentu.
Selain informasi tentang siapa yang bertanggung jawab atas apa, ada jawaban atas pertanyaan: siapa pemilik layanan, siapa yang bertanggung jawab atas pengembangannya, untuk arsitektur, dan siklus hidup. Orang yang bertanggung jawab untuk layanan ini adalah orang yang dapat memperbaikinya jika terjadi sesuatu. Pemilik layanan memiliki hak untuk meninggalkan +2 dalam komit, mereka yang bertanggung jawab juga harus hadir di ulasan sebelum layanan ini mengambil alih komit baru.
Seiring berjalannya waktu, praktik-praktik baru mulai diterapkan, misalnya, migrasi ke Kubernetes, semua jenis checkstyle, spotbugs, ktlint, keberadaan log di kiban, layanan autodiscovery alih-alih menentukan alamat secara langsung dan hal-hal berguna lainnya. Dan di mana pun meja kami memungkinkan kami untuk mempertahankan relevansi layanan kami. Bagi kami, ini adalah daftar periksa yang mengatakan bahwa layanan ini tahu bagaimana melakukan ini, tetapi ini belum.Tapi kami melangkah lebih jauh, menyadari bahwa kami kekurangan informasi tentang layanan kami, di mana kami melacak di mana kode sumber layanan terletak , di mana tugas-tugas perakitan diluncurkan di TeamCity, bagaimana mereka digunakan, di mana kode sumber tes end2end disimpan, foto dari perawatan tentang arsitektur, tentang keputusan yang dibuat. Idealnya, saya ingin semua informasi ini berada di suatu tempat dan siap ketika dibutuhkan. Karena itu, piring kami telah menjadi titik keberangkatan untuk mencari informasi.
Tapi QIWI, sambil mempertahankan semangat startup, adalah perusahaan besar. Kami sudah berusia 12 tahun, dan tim berubah: orang-orang pergi, orang-orang datang, tim baru sedang dibentuk. Dan kami menemukan beberapa layanan di domain kami yang kami warisi. Sesuatu datang bersama pengembang dari tim lain, sesuatu yang entah bagaimana terkait secara tidak langsung dengan Dompet, sehingga layanannya sekarang ada di neraca kami. Menangani apa dan bagaimana cara kerjanya - mengapa? Layanan berfungsi, dan kami memiliki fitur produk yang harus dicuci.
Seperti yang terjadi
Tetapi pada suatu titik waktu, kami menemukan bahwa layanan berhenti untuk memenuhi fungsinya, sesuatu telah rusak - apa yang harus dilakukan dalam situasi ini? Layanan baru saja berhenti bekerja. Tentu saja Dan kami belajar tentang ini, pertama, secara kebetulan, dan kedua, enam bulan kemudian. Itu terjadi. Satu-satunya hal yang kami ketahui adalah di mana mesin virtual yang digunakan layanan ini, tempat sumbernya berada, dan hanya itu. Kami membuat git klon dan terjun ke pikiran orang yang menulis ini beberapa tahun yang lalu, tetapi apa yang kita lihat? Tidak ada Spring Boot yang akrab bagi kita, meskipun kita terbiasa dengan segalanya, kita memiliki setumpuk penuh dan semua itu. Mungkin ada Kerangka Pegas? Tapi tidak.
Orang yang menulis semua ini keras dan menulis semuanya di Jawa murni. Tidak ada alat yang dikenal untuk pengembang, dan muncul ide - perlu untuk menulis ulang semuanya. Kami juga memiliki layanan microser, dan dari masing-masing pemanggang kami mendengar "Teman, layanan microser yang Anda butuhkan!". Jika tiba-tiba ada sesuatu yang salah, Anda akan dengan tenang mengambil bahasa apa pun dan semuanya akan baik-baik saja.
Masalahnya adalah bahwa sekarang kita tidak memiliki pelanggan yang bertanggung jawab atas layanan ini. Apa persyaratan bisnisnya, apa yang harus dilakukan layanan ini secara umum? Dan layanan terintegrasi erat ke dalam proses bisnis Anda.
Sekarang katakan, betapa mudahnya untuk menulis ulang layanan tanpa mengetahui persyaratan bisnisnya? Layanan tidak jelas bagaimana cara login, apakah ada metrik tidak diketahui. Apa itu, jika ada, semakin tidak diketahui. Dan sementara dalam layanan sejumlah besar kelas logika bisnis tidak jelas. Sesuatu termasuk dalam beberapa jenis basis data, yang tentangnya kami juga belum tahu apa-apa.
Di mana untuk memulai?
Dari yang paling logis - dengan ketersediaan tes. Setidaknya beberapa jenis logika biasanya ditulis di sana dan kesimpulan dapat ditarik tentang apa yang terjadi. Sekarang TDD modis, tetapi kita melihat bahwa 5 tahun yang lalu semuanya hampir sama seperti sekarang: hampir tidak ada tes unit, dan mereka tidak akan memberi tahu kita apa-apa. Yah, kecuali mungkin semacam cek bagaimana beberapa xml ditandatangani dengan semacam sertifikat khusus.
Kami tidak dapat memahami apa pun dengan kode tersebut, dan kami mengirim tampilan untuk melihat apa mesin virtual itu ada. Kami membuka log layanan, menemukan kesalahan http-client di dalamnya, sertifikat yang ditandatangani sendiri yang dijahit ke sumber daya aplikasi, tanpa ampun busuk. Kami menghubungi analis kami, mereka meminta sertifikat baru, mereka menerbitkannya kepada kami dan layanan berfungsi lagi. Tampaknya hanya itu saja. Atau tidak? Namun, layanan tetap berfungsi, menjalankan beberapa fungsi yang dibutuhkan bisnis kami. Kami memiliki beberapa standar pengembangan aplikasi yang kemungkinan besar Anda miliki. Sebagai contoh, jangan menyimpan log pada node di folder, tetapi simpan di beberapa jenis penyimpanan, seperti elastis, lihat mereka di kiban. Anda dapat mengingat metrik emas. Artinya, beban pada layanan, jumlah permintaan untuk layanan, apakah dia masih hidup atau tidak, bagaimana HealthCheck-nya berjalan. Paling tidak, metrik ini akan membantu Anda mencari tahu kapan itu dapat dinonaktifkan dan dilupakan seperti mimpi buruk dengan hati nurani yang jelas.
Apa yang harus dilakukan
Oleh karena itu, kami menambahkan layanan lama ke tablet, dan kemudian kami mencari sukarelawan dari antara pengembang yang akan mengurus layanan dan menertibkan: mereka akan menulis setidaknya beberapa informasi tentang layanan, menambahkan tautan ke dasbor di graphan, untuk tugas perakitan, dan memahami bagaimana Sebarkan aplikasi, jangan unggah file menggunakan ftp dengan tangan Anda.
Yang utama adalah berapa banyak semua sukarelawan yang berguna ini akan mengambil? Satu sprint untuk pengembang yang kurang lebih berpengalaman, misalnya, selama utang teknis 20%. Dan berapa banyak waktu yang diperlukan untuk memahami semua logika yang mengakar dalam berkomunikasi dengan sistem negara tertentu dan membawanya ke teknologi yang lebih baru? Saya tidak bisa menjamin ini, mungkin sebulan, atau mungkin dua tim bekerja. Ini saya katakan dari pengalaman integrasi saat ini dengan beberapa layanan baru.
Pada saat yang sama, tidak ada nilai bisnis yang habis. Tentu saja Untuk mengambil layanan dukungan dan menghabiskan sedikit waktu untuk itu adalah normal. Tetapi setelah tarian standar kami dengan layanan, kami menambahkannya ke meja, menambahkan informasi tentang itu dan, mungkin, suatu hari kami akan menulis ulang. Tapi sekarang memenuhi standar layanan kami.
Sebagai hasilnya, saya ingin membawa rencana apa yang harus dilakukan dengan layanan Legacy.
Menulis ulang warisan dari awal adalah ide yang burukSerius, Anda bahkan tidak perlu memikirkannya. Jelas bahwa kita ingin, dan beberapa keuntungan terlihat, tetapi biasanya ini tidak perlu bagi siapa pun, termasuk Anda sendiri.
Buku referensiGali kode sumber aplikasi Anda, buat direktori yang akan menunjukkan apa dan di mana letaknya dan cara kerjanya, masukkan deskripsi proyek di sana (readme.md bersyarat) untuk dengan cepat memahami di mana log dan metrik berada. Pengembang yang akan menangani ini setelah Anda hanya akan mengucapkan terima kasih.
Pahami domainnyaJika Anda memiliki domain, cobalah untuk menjaga jari Anda pada denyut nadi. Kedengarannya klise, ya, tetapi tidak semua orang memastikan bahwa layanan berada dalam satu kunci. Tetapi bekerja dalam satu standar sebenarnya jauh lebih mudah.