Empat tahun lalu, basis pelanggan dipertahankan secara terpisah di setiap toko, ditambah yang lain di situs.
Dalam seri sebelumnya: tiga tahun lalu, kami memutuskan bahwa kami perlu melakukan pengembangan di Rusia. Dua tahun lalu, mereka mulai menulis kode mereka sendiri alih-alih memodifikasi kode garpu dari perusahaan induk. Kisah hari ini adalah tentang bagaimana kita beralih dari satu monolit Legacy besar ke sekelompok layanan mikro kecil yang dihubungkan oleh sejenis bus (orkestra).
Kasing pengguna termudah: lakukan pemesanan melalui situs dan ambil di toko nyata Leroy Merlin di Rusia. Sebelumnya, pesanan toko online diproses di aplikasi lain secara umum dan sesuai dengan skema yang berbeda. Sekarang kami membutuhkan showcase omnichannel sehingga pesanan apa pun dipecah menjadi antarmuka: kasir di toko, aplikasi seluler, terminal di toko, situs web - apa pun. Jika Anda meletakkan Linux di microwave, biarkan microwave. Hal utama adalah bahwa beberapa antarmuka dapat mengetuk API ke belakang dan mengatakan bahwa di sini Anda perlu memesan ini dan itu. Dan mereka menerima jawaban yang jelas untuk ini. Kisah kedua adalah dengan permintaan untuk ketersediaan dan properti barang dari kartunya.
Di depan (kami akan segera menulis tentang ini), kami memiliki monster - AEM, dan di belakangnya ada dua aplikasi besar: OPUS dan MoVe. Yang pertama adalah database properti masing-masing produk (dari dimensi ke deskripsi), yang kedua bertanggung jawab untuk checkout, yaitu monolit meja kas. Jika sangat disederhanakan.
Apa yang salah dengan Opus?
OPUS adalah basis distribusi besar. Lebih tepatnya, itu adalah perangkat lunak yang menyediakan antarmuka untuk mengakses database, yaitu, mengakses database dan, misalnya, mencari atau hanya mengekspos API sehingga klien tidak langsung pergi ke database. Perangkat lunak ini berfungsi dan didukung di Prancis. Fitur kedua,
seperti yang telah kami katakan , adalah bahwa garis perbaikannya sangat panjang, dan kami tidak berada dalam prioritas tertinggi dibandingkan dengan unit bisnis Perancis.
Dengan susah payah, kami dapat memahami bagaimana pengembang dapat melakukan perubahan tanpa tim dari Perancis, persetujuan yang sangat lama terjadi. Fitur dirilis selama enam bulan. Sebenarnya, pada awalnya kami ingin melakukan pengembangan sendiri dan ulasan mereka, dan kemudian kami sampai pada pengembangan kami sendiri, infrastruktur kami, tes kami, dan secara umum kami sendiri. Dan pada saat yang sama membuang hampir sepertiga dari kode Legacy.
Tetapi kembali ke OPUS. Karena sistem menyimpan informasi yang relevan tentang ketersediaan, karakteristik, transaksi, dan hal-hal lain, kami mengetuknya dengan alasan apa pun. Khusus untuk situs, ini berarti bahwa jika pengguna memiliki tiga produk dalam keranjang, maka Anda perlu mengetuk basis data dari setiap halaman, karena relevansi diperiksa. Bahkan jika Anda mengetuk sekali untuk cache, dan kemudian memperbaruinya dengan cerdas, maka masih ada fitur. Ketika Anda membuka halaman katalog secara umum, semua spesifikasi produk diambil dari OPUS.
Langkah logis berikutnya adalah bahwa kami mulai lebih jarang menarik OPUS dan membuat basis kami (lebih tepatnya, layanan microser dengan basis). Sistem secara keseluruhan disebut PUB Rusia.
Kemudian mereka membuat orkestra, yang sudah dapat menyimpan agregat, yaitu, sebenarnya - data yang dikumpulkan untuk membangun halaman. Dalam arti bahwa ketika pengguna mengalihkan tampilan halaman dari kartu ke daftar, itu masih agregat yang sama, hanya bagian depan yang berbeda.
Yaitu, kami meninggalkan OPUS yang asli (masih di Perancis), tetapi cermin kami yang hampir lengkap "menghisap" itu, yang memotong pangkalan menjadi potongan-potongan, siap untuk berkumpul di orkestra. Dan orkestra mengumpulkan dan menyimpan agregat (atau dengan cepat menerimanya dan mulai menyimpannya), yang dibutuhkan oleh sistem lain. Akibatnya, bagian ini berfungsi sebagaimana mestinya. Dari fungsi asli OPUS Prancis, sekitar lima persen tersisa. Kami akan segera menggantinya.
Apa yang salah dengan MoVe?
Tidak ada yang istimewa, kecuali kenyataan bahwa kami memutuskan untuk membuang semua kode, karena:
- Sudah kuno di tumpukan tua.
- Dia memperhitungkan karakteristik masing-masing wilayah "Leroy Merlin" dalam rantai IF.
- Sangat sulit untuk membaca dan mempertahankan bahwa metode refactoring terbaik adalah "menulis lagi dan segera mendokumentasikan secara normal."
Yang kami lakukan. Hanya kami menulis ulang bukan sebagai monolit, tetapi mulai membuat layanan microser untuk setiap fungsi individu. Dan kemudian bagian dari fungsi MoVe dengan beralih ke microservice dengan lancar diambil. Jadi - satu per satu, sampai fungsi MoVe berakhir sepenuhnya. Artinya, masih berfungsi, tetapi di suatu tempat dalam ruang hampa dan tanpa aliran data.
Karena kami membangun platform dari potongan-potongan, proyek itu bernama Lego.
Lego benar-benar mengubah tengah ini. Ya, mari kita perjelas: backend nyata adalah legacy bus, sistem file, basis data, dan tingkat infrastruktur lainnya. Aplikasi besar di sekitar ini dan microservices dari logika sedang. Presentasi sudah menjadi bagian depan.
Mengapa Anda perlu menulis ulang semua ini?
Karena kami hidup dengan basis klien terpisah untuk setiap contoh 15 tahun sejak pembukaan di Rusia, dan ini tidak cocok untuk siapa pun. Tidak ada sinkronisasi juga. Di negara lain mereka masih hidup seperti itu.
Perusahaan induk dari Perancis membuat logistik umum, kami menggunakan kembali sistem Pixis - ini adalah satu toko kwitansi, yaitu, pesanan pelanggan: satu toko melihat pesanan dari toko lain. Tapi ini tidak sepenuhnya menyelesaikan masalah pesanan omnichannel. Oleh karena itu, perlu untuk mengkonsolidasikan basis dan melakukan pemrosesan umum. Ini yang utama.
Alasan kedua adalah hukum box office federal: dengan jadwal pengembangan kami untuk sistem umum (dan pengujian) untuk semua negara, kami akan didenda karena denda.
Sebuah opsi yang kira-kira serupa digulirkan di Brasil: mereka memulai Leroy Merlin di sana tanpa perangkat lunak dari perusahaan induk, dan mereka berhasil. Itu sebelum keputusan split. Ngomong-ngomong, mereka banyak berkomitmen untuk
innersor , mereka memiliki perkembangan yang sangat cepat.
Pixis diperbolehkan memesan hanya dari kasir, sebenarnya. Kami mengubah situasi dalam tiga tahap:
- Pertama kami membuat aplikasi mobile untuk karyawan, yang sangat menyederhanakan hidupnya. Atas dasar ini, mereka mulai membangun ekosistem di mana antarmuka dipisahkan dengan logika.
- Sementara semuanya sudah diatur, pesanan Internet dibawa ke meja kas dengan tangan.
- Mereka menempatkan layanan microser pada gilirannya, yang menggantikan semuanya di tengah.
Mengapa Anda harus memulai dengan aplikasi toko? Karena kami kembali memiliki proses unik dibandingkan dengan Prancis. Misalnya, seseorang memutuskan untuk membeli rantai enam meter sepuluh sentimeter di toko. Penjual memotongnya, memberikan dokumen berapa lama dan berapa biayanya. Anda pergi ke kasir dengan selembar kertas ini, Anda membayar di sana. Dari sudut pandang logika, penjualan tidak harus di box office, tetapi penjual harus memilikinya, tetapi sebenarnya di box office itulah hal yang paling menarik dimulai: Anda harus memiliki barang dan kertas.
Pada akhirnya, kami akan menjadi platform untuk menempatkan pesanan: sekarang, misalnya, di atas sistem utama kami, layanan untuk membeli layanan master ditambahkan (saya membeli dapur - saya memesan instalasi dari master eksternal, tetapi kami menemukannya dan memberikan jaminan dari diri kami sendiri),
marketplace ( pembelian langsung dari pemasok dalam rentang yang lebih luas), dan segera harus ada afiliasi sehingga blok kami dapat ditempatkan di mana saja. Sesuatu seperti menanamkan toko Amazon di blog, hanya lebih fleksibel.
Bagaimana keputusan penggantian dibuat?
Saya melangkah. Sempurnakan model bisnis.Kami memeriksa, dan memang: model, seperti di Rusia - harga rendah setiap hari - berhasil. Leroy Merlin di Eropa jauh lebih mahal, tetapi di Rusia inilah ceruk kami: toko konstruksi tempat Anda dapat menemukan barang dengan harga terbaik.
Langkah II. Buat skrip klien.Artinya, untuk membangun proses seperti yang kita inginkan mereka berinteraksi dengan kita dari sudut pandang klien. Yaitu, satu visi tentang siapa yang kita inginkan dalam beberapa tahun dan bagaimana tampilannya dari sudut pandang arsitektur.
Langkah III. Bangun arsitektur.Hancurkan visi ini menjadi TK dan arsitektur spesifik dengan detail lebih tinggi. Ternyata 110 proyek, yang kami bagi menjadi lima kategori selama lima tahun.
Kemudian mereka membentuk tim khusus. Paling sering ini adalah orang-orang mereka ditambah kontraktor. Pada awalnya, mereka sangat menderita dari ini: ketika mereka pergi ke prod, mereka tidak benar-benar mengerti bagaimana mencerna volume perubahan yang begitu besar. Kemudian mereka mulai membuat pendekatan umum untuk tugas-tugas dan secara bertahap meningkatkan andil perkembangan mereka.
Di tempat-tempat di mana kesalahan itu kritis, mereka bekerja sesuai dengan skema NASA, di mana kesalahan tidak dapat diterima, bukan pilihan sama sekali. Ini semua tentang transaksi uang.
Dan di mana dimungkinkan untuk jatuh, hal utama adalah bangun dengan cepat, kami menggunakan pendekatan yang dekat dengan SRE Google. Iteratif, dengan tiang tembok, tetapi proyek dapat diimplementasikan sesegera mungkin. Dan sekarang kami melakukan banyak hal, dan sangat keren untuk dikembangkan.
Pendekatan ketiga adalah inovasi. Kami mengembangkan kotak pasir ide untuk dengan cepat melakukan MVP pertama dengan sumber daya internal kami, yang memungkinkan kami untuk menguji dengan cepat dan murah. Ini adalah nyata "coba cepat, gagal cepat". Ini memungkinkan Anda untuk mendapatkan anggaran dan otoritas untuk mereka yang datang dengan proyek keren.
Fokus penting kedua adalah dalam geo-development. Kemudian membuka 20 toko setahun (sekarang sedikit lebih lambat). Enam ribu karyawan. Banyak daerah. Itu perlu untuk menulis ulang seluruh rantai pasokan, untuk dengan cepat mengembangkan proses untuk meningkatkan infrastruktur toko.
Pada 2017, kami memutuskan untuk menjadi platform untuk pesanan konstruksi: ini adalah strategi yang menjanjikan untuk beberapa tahun mendatang.
Untuk geografi, kami membutuhkan back office TI yang besar untuk pertumbuhan perusahaan dan pertumbuhan rantai pasokan. Untuk omnichannel (urutan umum) - tingkat SLA yang berbeda untuk sistem internal, waktu nyata, layanan mikro, dan sinkronisasi antara ratusan subsistem. Ini umumnya tingkat kematangan TI yang berbeda. Untuk platform, kecepatan perubahan juga penting.
Ketika baru mulai, semua orang berpikir bahwa gesit akan menyelamatkan dunia. Dengan kontraktor, gesit mungkin tidak efektif. Karenanya keinginan untuk
merekrut 200 orang di departemen IT.
Kami menyaksikan seberapa cepat kami dapat mengimplementasikan semuanya tanpa kehilangan merek. Sesuatu dapat ditulis dengan cepat, tetapi tidak punya waktu untuk menyiapkan layanan. Misalnya, jika tidak ada informasi stok, maka tidak ada cara untuk membayar online tanpa jaminan bahwa barang akan dipesan. Kami menguraikan rantai saling ketergantungan menjadi beberapa. Sekarang kita sudah tahu bahwa kita perlu membuat siklus lebih pendek, karena kompetensi tim masih penting. Sekarang kami menggergaji fitur dalam potongan-potongan kecil, kami mengumpulkan koneksi, sekarang hanya tahun ini dalam rencana. Strategi jangka panjang, tetapi berdasarkan fitur, adalah maksimum satu tahun, dan banyak tim produk terpisah.