Hi!
Nama saya Mikhail, saya Wakil Direktur IT di perusahaan Sportmaster. Saya ingin berbagi cerita tentang bagaimana kita menghadapi tantangan yang muncul selama pandemi.
Pada hari-hari pertama realitas baru, format perdagangan offline Sportmaster yang biasa terhenti, dan beban pada saluran online kami, terutama dalam hal pengiriman ke alamat klien, meningkat 10 kali lipat. Hanya dalam beberapa minggu, kami mengubah bisnis offline raksasa menjadi bisnis online dan menyesuaikan layanan dengan kebutuhan klien kami.
Pada dasarnya, apa yang pada dasarnya merupakan operasi sampingan kami menjadi bisnis inti kami. Pentingnya setiap pemesanan online telah meningkat pesat. Penting untuk menghemat setiap rubel yang dibawa klien ke perusahaan.
Untuk menanggapi permintaan pelanggan dengan cepat, kami membuka contact center tambahan di kantor utama perusahaan, dan kini dapat menerima sekitar 285 ribu panggilan per minggu. Pada saat yang sama, kami memindahkan 270 toko ke format operasi nirsentuh dan aman yang baru, yang memungkinkan pelanggan menerima pesanan dan karyawan dapat mempertahankan pekerjaan mereka.
Selama proses transformasi, kami menemui dua permasalahan utama. Pertama, beban pada sumber daya online kami telah meningkat secara signifikan (Sergey akan memberi tahu Anda bagaimana kami menangani hal ini). Kedua, arus operasi yang jarang terjadi (sebelum COVID) telah meningkat berkali-kali lipat, yang pada gilirannya memerlukan otomatisasi cepat dalam jumlah besar. Untuk mengatasi masalah ini, kami harus segera mentransfer sumber daya dari wilayah yang sebelumnya merupakan wilayah utama. Elena akan memberitahumu bagaimana kami menangani ini.
Pengoperasian layanan online
Kolesnikov Sergey, bertanggung jawab atas pengoperasian toko online dan layanan mikro
Sejak toko ritel kami mulai ditutup dari pengunjung, kami mulai mencatat peningkatan metrik seperti jumlah pengguna, jumlah pesanan yang dilakukan di aplikasi kami, dan jumlah permintaan ke aplikasi.
Jumlah pesanan dari 18 Maret hingga 31 MaretJumlah permintaan ke layanan mikro pembayaran onlineJumlah pesanan yang dilakukan di situs web
Pada grafik pertama kita melihat peningkatan sekitar 14 kali lipat, pada grafik kedua - 4 kali lipat. Kami menganggap metrik waktu respons aplikasi kami sebagai yang paling indikatif.
Dalam grafik ini kami melihat respons dari front dan aplikasi, dan kami sendiri memutuskan bahwa kami tidak melihat adanya pertumbuhan seperti itu.
Hal ini terutama disebabkan oleh fakta bahwa kami memulai pekerjaan persiapan pada akhir tahun 2019. Sekarang layanan kami sudah dicadangkan, toleransi kesalahan dipastikan di tingkat server fisik, sistem virtualisasi, buruh pelabuhan, dan layanan di dalamnya. Pada saat yang sama, kapasitas sumber daya server kami memungkinkan kami menahan banyak beban.
Alat utama yang membantu kami dalam keseluruhan cerita ini adalah sistem pemantauan kami. Benar, hingga saat ini kami tidak memiliki sistem tunggal yang memungkinkan kami mengumpulkan metrik di semua lapisan, mulai dari tingkat peralatan fisik dan perangkat keras hingga tingkat metrik bisnis.
Secara formal, ada pengawasan di perusahaan, tetapi biasanya tersebar dan menjadi tanggung jawab departemen tertentu. Faktanya, ketika suatu kejadian terjadi, kita hampir tidak pernah mempunyai pemahaman yang sama tentang apa yang sebenarnya terjadi, tidak ada komunikasi, dan seringkali hal ini menyebabkan kita harus berputar-putar untuk mencari dan mengisolasi masalah agar dapat diperbaiki.
Pada titik tertentu, kami berpikir dan memutuskan bahwa kami sudah cukup menanggungnya - kami memerlukan sistem terpadu untuk melihat gambaran keseluruhan secara utuh. Teknologi utama yang disertakan dalam tumpukan kami adalah Zabbix sebagai pusat peringatan dan penyimpanan metrik, Prometheus untuk mengumpulkan dan menyimpan metrik aplikasi, Stack ELK untuk mencatat dan menyimpan data dari seluruh sistem pemantauan, serta Grafana untuk visualisasi, Swagger, Docker dan hal-hal berguna dan lainnya yang Anda kenal.
Pada saat yang sama, kami tidak hanya menggunakan teknologi yang tersedia di pasar, tetapi juga mengembangkan teknologi kami sendiri. Misalnya, kami membuat layanan untuk mengintegrasikan sistem satu sama lain, yaitu semacam API untuk mengumpulkan metrik. Selain itu, kami sedang mengerjakan sistem pemantauan kami sendiri - pada tingkat metrik bisnis, kami menggunakan pengujian UI. Dan juga bot di Telegram untuk memberi tahu tim.
Kami juga mencoba membuat sistem pemantauan dapat diakses oleh tim sehingga mereka dapat menyimpan dan bekerja dengan metrik mereka secara mandiri, termasuk menyiapkan peringatan untuk beberapa metrik sempit yang tidak banyak digunakan.
Di seluruh sistem, kami berupaya untuk proaktif dan melokalisasi insiden secepat mungkin. Selain itu, jumlah layanan mikro dan sistem kami telah berkembang secara signifikan akhir-akhir ini, dan jumlah integrasi juga meningkat. Dan sebagai bagian dari optimalisasi proses diagnosis insiden di tingkat integrasi, kami mengembangkan sistem yang memungkinkan Anda melakukan pemeriksaan lintas sistem dan menampilkan hasilnya, yang memungkinkan Anda menemukan masalah utama yang terkait dengan impor dan interaksi sistem dengan satu sama lain.
Tentu saja, kami masih memiliki ruang untuk tumbuh dan berkembang dalam hal sistem operasi, dan kami secara aktif mengupayakannya. Anda dapat membaca lebih lanjut tentang sistem pemantauan kami .
Tes teknis
Orlov Sergey, mengepalai pusat kompetensi untuk pengembangan web dan seluler
Sejak penutupan toko fisik dimulai, kami menghadapi berbagai tantangan dari sudut pandang pembangunan. Pertama-tama, lonjakan beban seperti itu. Jelas bahwa jika tindakan yang tepat tidak diambil, maka ketika beban tinggi diterapkan pada sistem, sistem dapat berubah menjadi labu dengan ledakan yang menyedihkan, atau penurunan kinerja sepenuhnya, atau bahkan kehilangan fungsinya.
Aspek kedua, yang kurang jelas, adalah bahwa sistem dengan beban tinggi harus diubah dengan sangat cepat, beradaptasi dengan perubahan dalam proses bisnis. Terkadang beberapa kali sehari. Banyak perusahaan yang memiliki aturan bahwa jika aktivitas pemasaran sedang banyak, tidak perlu melakukan perubahan apa pun pada sistem. Tidak ada sama sekali, biarkan saja selama masih bisa.
Dan kami pada dasarnya mengalami Black Friday tanpa akhir, di mana sistem perlu diubah. Dan kesalahan, masalah, atau kegagalan apa pun dalam sistem akan sangat merugikan bisnis.
Ke depan, saya akan mengatakan bahwa kami berhasil mengatasi pengujian ini, semua sistem tahan terhadap beban, mudah diskalakan, dan kami tidak mengalami kegagalan teknis global.
Ada empat pilar yang menjadi sandaran kemampuan sistem untuk menahan beban lonjakan tinggi. Yang pertama adalah pemantauan, yang Anda baca di atas. Tanpa sistem pemantauan bawaan, hampir tidak mungkin menemukan hambatan sistem. Sistem pemantauan yang baik ibarat pakaian rumah; sistem tersebut harus nyaman dan disesuaikan dengan kebutuhan Anda.
Aspek kedua adalah pengujian. Kami menanggapi hal ini dengan sangat serius: kami menulis unit klasik, pengujian integrasi, pengujian beban, dan banyak lainnya untuk setiap sistem. Kami juga sedang menulis strategi pengujian, dan pada saat yang sama mencoba meningkatkan level pengujian hingga kami tidak lagi memerlukan pemeriksaan manual.
Pilar ketiga adalah CI/CD Pipeline. Proses pembuatan, pengujian, dan penerapan aplikasi harus diotomatisasi semaksimal mungkin; tidak boleh ada intervensi manual. Topik CI/CD Pipeline cukup mendalam, dan saya hanya akan membahasnya secara singkat. Perlu disebutkan bahwa kami memiliki daftar periksa CI/CD Pipeline, yang dilalui oleh setiap tim produk dengan bantuan pusat kompetensi.
Dan inilah daftar periksanya
Dengan cara ini, banyak tujuan tercapai. Ini adalah pembuatan versi API dan peralihan fitur untuk menghindari rangkaian rilis, dan mencapai cakupan berbagai pengujian pada tingkat sedemikian rupa sehingga pengujian sepenuhnya otomatis, penerapan berjalan lancar, dan seterusnya.
Pilar keempat adalah prinsip arsitektur dan solusi teknis. Kita dapat berbicara banyak tentang arsitektur untuk waktu yang lama, namun saya ingin menekankan beberapa prinsip yang ingin saya fokuskan.
Pertama, Anda perlu memilih alat khusus untuk tugas tertentu. Ya, kedengarannya jelas, dan jelas bahwa paku harus dipalu dengan palu, dan jam tangan harus dibongkar dengan obeng khusus. Namun di zaman kita, banyak alat yang berupaya untuk universalisasi untuk mencakup segmen pengguna maksimum: database, cache, kerangka kerja, dan lainnya. Misalnya, jika Anda menggunakan database MongoDB, database ini berfungsi dengan transaksi multi-dokumen, dan database Oracle berfungsi dengan json. Dan sepertinya semuanya bisa digunakan untuk apa saja. Namun jika kita mendukung produktivitas, maka kita perlu memahami dengan jelas kekuatan dan kelemahan masing-masing alat dan menggunakan alat yang kita perlukan untuk tugas-tugas kita.
Kedua, ketika merancang sistem, setiap peningkatan kompleksitas harus dapat dibenarkan. Kita harus selalu mengingat hal ini; prinsip kopling rendah diketahui semua orang. Saya percaya bahwa ini harus diterapkan pada tingkat layanan tertentu, dan pada tingkat keseluruhan sistem, dan pada tingkat lanskap arsitektur. Kemampuan untuk menskalakan setiap komponen sistem secara horizontal di sepanjang jalur beban juga penting. Jika Anda memiliki kemampuan ini, scaling tidak akan sulit.
Berbicara mengenai solusi teknis, kami meminta tim produk untuk menyiapkan serangkaian rekomendasi, ide, dan solusi baru, yang mereka terapkan sebagai persiapan menghadapi gelombang beban kerja berikutnya.
Keshi
Penting untuk secara sadar mendekati pilihan cache lokal dan terdistribusi. Kadang-kadang masuk akal untuk menggunakan keduanya dalam sistem yang sama. Misalnya, kita memiliki sistem yang beberapa datanya pada dasarnya adalah cache showcase, yaitu sumber pembaruan terletak di belakang sistem itu sendiri, dan sistem tidak berubah. data ini. Untuk pendekatan ini kami menggunakan Caffeine Cache lokal.
Dan ada data yang diubah secara aktif oleh sistem selama operasi, dan di sini kita sudah menggunakan cache terdistribusi dengan Hazelcast. Pendekatan ini memungkinkan kami memanfaatkan cache terdistribusi di tempat yang benar-benar dibutuhkan, dan meminimalkan biaya layanan dari sirkulasi data cluster Hazelcast yang dapat kami lakukan tanpa cache. Kami telah menulis banyak tentang cache. и .
Selain itu, mengubah serializer menjadi Kryo di Hazelcast memberi kami dorongan yang baik. Dan transisi dari RelicedMap ke IMap + Near Cache di Hazelcast memungkinkan kami meminimalkan pergerakan data di seluruh cluster.
Sedikit saran: jika terjadi pembatalan cache massal, terkadang taktik menghangatkan cache kedua dan kemudian beralih ke cache tersebut dapat diterapkan. Tampaknya dengan pendekatan ini kita akan mendapatkan konsumsi memori dua kali lipat, namun dalam praktiknya, pada sistem yang menerapkan hal ini, konsumsi memori menurun.
Tumpukan reaktif
Kami menggunakan tumpukan reaktif di sejumlah besar sistem. Dalam kasus kami, ini adalah Webflux atau Kotlin dengan coroutine. Tumpukan reaktif sangat baik terutama jika kita mengharapkan operasi input-output yang lambat. Misalnya, panggilan ke layanan lambat, bekerja dengan sistem file atau sistem penyimpanan.
Prinsip yang paling penting adalah menghindari pemblokiran panggilan. Kerangka kerja reaktif memiliki sejumlah kecil rangkaian layanan langsung yang berjalan di bawah tenda. Jika kita sembarangan membiarkan diri kita melakukan panggilan pemblokiran langsung, seperti panggilan driver JDBC, sistem akan terhenti begitu saja.
Cobalah untuk mengubah kesalahan menjadi pengecualian runtime Anda sendiri. Alur eksekusi program yang sebenarnya bergeser ke kerangka reaktif, dan eksekusi kode menjadi nonlinier. Akibatnya, sangat sulit untuk mendiagnosis masalah menggunakan pelacakan tumpukan. Dan solusinya di sini adalah dengan membuat pengecualian runtime yang jelas dan obyektif untuk setiap kesalahan.
Elasticsearch
Saat menggunakan Elasticsearch, jangan pilih data yang tidak digunakan. Ini, pada prinsipnya, juga merupakan nasihat yang sangat sederhana, tetapi paling sering hal inilah yang dilupakan. Jika Anda perlu memilih lebih dari 10 ribu catatan sekaligus, Anda perlu menggunakan Scroll. Untuk menggunakan analogi, ini seperti kursor dalam database relasional.
Jangan gunakan postfilter kecuali diperlukan. Dengan data besar dalam sampel utama, operasi ini memuat banyak database.
Gunakan operasi massal jika memungkinkan.
API
Saat merancang API, sertakan persyaratan untuk meminimalkan data yang dikirimkan. Hal ini terutama berlaku sehubungan dengan bagian depan: di persimpangan inilah kami melampaui saluran pusat data kami dan sudah mengerjakan saluran yang menghubungkan kami dengan klien. Jika ada masalah sekecil apa pun, lalu lintas yang terlalu banyak menyebabkan pengalaman pengguna yang negatif.
Dan terakhir, jangan membuang banyak data, jelaskan kontrak antara konsumen dan pemasok.
Transformasi organisasi
Eroshkina Elena, Wakil Direktur TI
Pada saat karantina terjadi, dan muncul kebutuhan untuk meningkatkan laju pengembangan online secara signifikan dan memperkenalkan layanan omnichannel, kami sudah berada dalam proses transformasi organisasi.
Sebagian dari struktur kami dialihkan untuk bekerja sesuai dengan prinsip dan praktik pendekatan produk. Tim telah dibentuk yang kini bertanggung jawab atas pengoperasian dan pengembangan setiap produk. Karyawan dalam tim tersebut 100% terlibat dan menyusun pekerjaan mereka menggunakan Scrum atau Kanban, tergantung pada apa yang mereka sukai, menyiapkan jalur penerapan, menerapkan praktik teknis, praktik penjaminan kualitas, dan banyak lagi.
Untungnya, sebagian besar tim produk kami berada di bidang layanan online dan omnichannel. Hal ini memungkinkan kami untuk beralih ke mode kerja jarak jauh dalam waktu sesingkat mungkin (serius, secara harfiah dalam dua hari) tanpa kehilangan efisiensi. Proses yang disesuaikan memungkinkan kami dengan cepat beradaptasi dengan kondisi kerja baru dan mempertahankan kecepatan penyampaian fungsionalitas baru yang cukup tinggi.
Selain itu, kami perlu memperkuat tim-tim yang berada di garda depan bisnis online. Pada saat itu menjadi jelas bahwa kami hanya dapat melakukan ini dengan menggunakan sumber daya internal. Dan sekitar 50 orang dalam dua minggu berpindah area tempat mereka bekerja sebelumnya dan terlibat dalam pengerjaan produk yang baru bagi mereka.
Hal ini tidak memerlukan upaya manajemen khusus, karena selain mengatur proses kami sendiri, peningkatan teknis produk, dan praktik jaminan kualitas, kami mengajarkan tim kami untuk mengatur diri sendiri - mengelola proses produksi mereka sendiri tanpa melibatkan sumber daya administratif.
Kami dapat memfokuskan sumber daya manajemen kami tepat di tempat yang diperlukan pada saat itu - untuk berkoordinasi dengan bisnis: Apa yang penting bagi klien kami saat ini, fungsi apa yang harus diterapkan terlebih dahulu, apa yang perlu dilakukan untuk meningkatkan kemampuan throughput kami untuk mengirimkan dan memproses pesanan. Semua ini dan teladan yang jelas memungkinkan selama periode ini memuat aliran nilai produksi kami dengan apa yang benar-benar penting dan diperlukan.
Jelas bahwa dengan kerja jarak jauh dan laju perubahan yang tinggi, ketika indikator bisnis bergantung pada partisipasi semua orang, Anda tidak bisa hanya mengandalkan perasaan internal dari serial “Apakah semuanya baik-baik saja dengan kita? Ya, sepertinya bagus.” Metrik obyektif dari proses produksi diperlukan. Kami memilikinya, tersedia bagi siapa saja yang tertarik dengan metrik tim produk. Pertama-tama, tim itu sendiri, bisnis, subkontraktor, dan manajemen.
Setiap dua minggu sekali, sebuah status diadakan dengan masing-masing tim, di mana metrik dianalisis selama 10 menit, hambatan dalam proses produksi diidentifikasi, dan solusi bersama dikembangkan: apa yang dapat dilakukan untuk menghilangkan hambatan ini. Di sini Anda dapat segera meminta bantuan dari manajemen jika ada masalah yang teridentifikasi berada di luar pengaruh tim, atau keahlian rekan kerja yang mungkin pernah mengalami masalah serupa.
Namun, kami memahami bahwa untuk mempercepat berkali-kali lipat (dan inilah tujuan yang kami tetapkan untuk diri kami sendiri), kami masih perlu belajar banyak dan menerapkannya dalam pekerjaan kami sehari-hari. Saat ini kami terus memperluas pendekatan produk kami ke tim lain dan produk baru. Untuk melakukan ini, kami harus menguasai format baru bagi kami - sekolah ahli metodologi online.
Para ahli metodologi, orang-orang yang membantu tim membangun proses, menjalin komunikasi, dan meningkatkan efisiensi kerja, pada dasarnya adalah agen perubahan. Saat ini, lulusan angkatan pertama kami bekerja dengan tim dan membantu mereka menjadi sukses.
Saya kira situasi saat ini membuka peluang dan prospek bagi kita yang mungkin belum sepenuhnya kita sadari. Namun pengalaman dan latihan yang kami peroleh saat ini menegaskan bahwa kami telah memilih jalur pengembangan yang tepat, kami tidak akan melewatkan peluang baru ini di masa depan dan akan mampu merespons tantangan yang akan dihadapi Sportmaster dengan sama efektifnya.
Temuan
Selama masa sulit ini, kami telah merumuskan prinsip-prinsip utama yang menjadi landasan pengembangan perangkat lunak, yang menurut saya akan relevan untuk setiap perusahaan yang menangani hal ini.
Orang-orang. Di sinilah semuanya bertumpu. Karyawan harus menikmati pekerjaannya dan memahami tujuan perusahaan serta tujuan dari produk yang mereka garap. Dan tentunya mereka bisa berkembang secara profesional.
Технология. Penting bagi perusahaan untuk mengambil pendekatan yang matang dalam bekerja dengan tumpukan teknologinya dan membangun kompetensi di tempat yang benar-benar dibutuhkan. Kedengarannya sangat sederhana dan jelas. Dan sangat sering diabaikan.
Процессы. Penting untuk mengatur kerja tim produk dan pusat kompetensi dengan benar, untuk menjalin interaksi dengan bisnis agar dapat bekerja dengannya sebagai mitra.
Secara umum, itulah cara kami bertahan. Tesis utama zaman kita sekali lagi dikonfirmasi, dengan bunyi klik yang nyaring di dahi
Bahkan jika Anda adalah bisnis offline besar dengan banyak toko dan banyak kota tempat Anda beroperasi, kembangkan bisnis online Anda. Ini bukan sekadar saluran penjualan tambahan atau aplikasi cantik yang melaluinya Anda juga bisa membeli sesuatu (dan juga karena pesaing juga punya yang cantik). Ini bukan ban cadangan untuk berjaga-jaga untuk membantu Anda menghadapi badai.
Hal ini merupakan suatu kebutuhan yang mutlak. Untuk itu tidak hanya kemampuan teknis dan infrastruktur Anda yang harus dipersiapkan, namun juga sumber daya manusia dan proses Anda. Lagi pula, Anda dapat dengan cepat membeli memori tambahan, ruang, menerapkan instance baru, dll. dalam beberapa jam. Namun masyarakat dan proses perlu dipersiapkan terlebih dahulu untuk menghadapi hal ini.
Sumber: www.habr.com