Hello!
Nama saya Mikhail, saya adalah Timbalan Pengarah IT di syarikat Sportmaster. Saya ingin berkongsi kisah bagaimana kami menangani cabaran yang timbul semasa pandemik.
Pada hari-hari pertama realiti baharu, format dagangan luar talian biasa Sportmaster terhenti, dan beban pada saluran dalam talian kami, terutamanya dari segi penghantaran ke alamat pelanggan, meningkat 10 kali ganda. Hanya dalam beberapa minggu, kami mengubah perniagaan luar talian yang besar kepada perniagaan dalam talian dan menyesuaikan perkhidmatan dengan keperluan pelanggan kami.
Pada asasnya, apa yang pada asasnya operasi sampingan kami menjadi perniagaan teras kami. Kepentingan setiap pesanan dalam talian telah meningkat dengan ketara. Ia adalah perlu untuk menyelamatkan setiap ruble yang dibawa oleh pelanggan ke syarikat.
Untuk membalas permintaan pelanggan dengan pantas, kami membuka pusat hubungan tambahan di pejabat utama syarikat, dan kini boleh menerima kira-kira 285 ribu panggilan setiap minggu. Pada masa yang sama, kami memindahkan 270 kedai ke format operasi tanpa sentuh dan selamat baharu, yang membolehkan pelanggan menerima pesanan dan pekerja mengekalkan kerja mereka.
Semasa proses transformasi, kami menghadapi dua masalah utama. Pertama, beban sumber dalam talian kami telah meningkat dengan ketara (Sergey akan memberitahu anda bagaimana kami menangani perkara ini). Kedua, aliran operasi jarang (pra-COVID) telah meningkat berkali-kali ganda, yang seterusnya memerlukan sejumlah besar automasi pantas. Untuk menyelesaikan masalah ini, kami terpaksa memindahkan sumber dengan cepat dari kawasan yang sebelum ini menjadi yang utama. Elena akan memberitahu anda bagaimana kami menangani perkara ini.
Operasi perkhidmatan dalam talian
Kolesnikov Sergey, bertanggungjawab untuk pengendalian kedai dalam talian dan perkhidmatan mikro
Dari saat kedai runcit kami mula ditutup kepada pelawat, kami mula merekodkan peningkatan dalam metrik seperti bilangan pengguna, bilangan pesanan yang dibuat dalam aplikasi kami dan bilangan permintaan kepada aplikasi.
Jumlah tempahan dari 18 Mac hingga 31 MacBilangan permintaan kepada perkhidmatan mikro pembayaran dalam talianBilangan pesanan yang dibuat di laman web
Dalam graf pertama kita melihat bahawa peningkatan adalah kira-kira 14 kali, dalam yang kedua - 4 kali. Kami menganggap metrik masa respons bagi aplikasi kami sebagai yang paling menunjukkan.
Dalam graf ini kami melihat tindak balas bahagian hadapan dan aplikasi, dan untuk diri kami sendiri kami menentukan bahawa kami tidak melihat sebarang pertumbuhan seperti itu.
Ini disebabkan terutamanya oleh fakta bahawa kami memulakan kerja persediaan pada penghujung tahun 2019. Kini perkhidmatan kami dikhaskan, toleransi kesalahan dipastikan pada tahap pelayan fizikal, sistem virtualisasi, docker dan perkhidmatan di dalamnya. Pada masa yang sama, kapasiti sumber pelayan kami membolehkan kami menahan berbilang beban.
Alat utama yang membantu kami dalam keseluruhan cerita ini ialah sistem pemantauan kami. Benar, sehingga baru-baru ini kami tidak mempunyai satu sistem yang membolehkan kami mengumpul metrik pada semua lapisan, daripada tahap peralatan fizikal dan perkakasan kepada tahap metrik perniagaan.
Secara rasmi, terdapat pemantauan dalam syarikat, tetapi sebagai peraturan ia tersebar dan berada dalam bidang tanggungjawab jabatan tertentu. Malah, apabila insiden berlaku, kami hampir tidak pernah mempunyai pemahaman yang sama tentang apa yang sebenarnya berlaku, tiada komunikasi, dan selalunya ini membawa kepada berlari dalam bulatan untuk mencari dan mengasingkan masalah supaya ia dapat diperbaiki.
Pada satu ketika, kami berfikir dan memutuskan bahawa kami sudah cukup untuk menanggungnya - kami memerlukan sistem bersatu untuk melihat keseluruhan gambaran sepenuhnya. Teknologi utama yang disertakan dalam timbunan kami ialah Zabbix sebagai pusat storan amaran dan metrik, Prometheus untuk mengumpul dan menyimpan metrik aplikasi, Stack ELK untuk mengelog dan menyimpan data daripada keseluruhan sistem pemantauan, serta Grafana untuk visualisasi, Swagger, Docker dan perkara lain yang berguna dan biasa kepada anda.
Pada masa yang sama, kami bukan sahaja menggunakan teknologi yang terdapat di pasaran, tetapi juga membangunkan beberapa teknologi kami sendiri. Sebagai contoh, kami membuat perkhidmatan untuk menyepadukan sistem antara satu sama lain, iaitu sejenis API untuk mengumpul metrik. Selain itu, kami sedang mengusahakan sistem pemantauan kami sendiri - pada tahap metrik perniagaan kami menggunakan ujian UI. Dan juga bot dalam Telegram untuk memberitahu pasukan.
Kami juga cuba menjadikan sistem pemantauan boleh diakses oleh pasukan supaya mereka boleh menyimpan dan bekerja secara bebas dengan metrik mereka, termasuk menyediakan makluman untuk beberapa metrik sempit yang tidak digunakan secara meluas.
Sepanjang sistem, kami berusaha untuk proaktif dan penyetempatan insiden secepat mungkin. Di samping itu, bilangan perkhidmatan mikro dan sistem kami telah berkembang dengan ketara baru-baru ini, dan bilangan penyepaduan telah berkembang dengan sewajarnya. Dan sebagai sebahagian daripada mengoptimumkan proses mendiagnosis insiden di peringkat penyepaduan, kami sedang membangunkan sistem yang membolehkan anda menjalankan semakan silang sistem dan memaparkan hasilnya, yang membolehkan anda mencari masalah utama yang berkaitan dengan import dan interaksi sistem dengan satu sama lain.
Sudah tentu, kami masih mempunyai ruang untuk berkembang dan membangun dari segi sistem pengendalian, dan kami sedang giat mengusahakannya. Anda boleh membaca lebih lanjut mengenai sistem pemantauan kami .
Ujian teknikal
Orlov Sergey, mengetuai pusat kecekapan untuk pembangunan web dan mudah alih
Sejak penutupan kedai fizikal bermula, kami telah menghadapi pelbagai cabaran dari sudut pembangunan. Pertama sekali, lonjakan beban seperti itu. Adalah jelas bahawa jika langkah-langkah yang sesuai tidak diambil, maka apabila beban yang tinggi digunakan pada sistem, ia boleh berubah menjadi labu dengan dentuman yang menyedihkan, atau merosot sepenuhnya dalam prestasi, atau bahkan kehilangan fungsinya.
Aspek kedua, sedikit kurang jelas, ialah sistem di bawah beban tinggi terpaksa ditukar dengan cepat, menyesuaikan diri dengan perubahan dalam proses perniagaan. Kadang-kadang beberapa kali sehari. Banyak syarikat mempunyai peraturan bahawa jika terdapat banyak aktiviti pemasaran, tidak perlu membuat sebarang perubahan pada sistem. Tidak ada sama sekali, biarkan ia berfungsi selagi ia berfungsi.
Dan kami pada asasnya mempunyai Black Friday yang tidak berkesudahan, di mana ia perlu untuk menukar sistem. Dan sebarang ralat, masalah, atau kegagalan dalam sistem akan menjadi sangat mahal untuk perniagaan.
Memandang ke hadapan, saya akan mengatakan bahawa kami berjaya mengatasi ujian ini, semua sistem menahan beban, mudah diskalakan, dan kami tidak mengalami sebarang kegagalan teknikal global.
Terdapat empat tiang di mana keupayaan sistem untuk menahan beban lonjakan tinggi terletak. Yang pertama ialah pemantauan, yang anda baca di atas. Tanpa sistem pemantauan terbina dalam, hampir mustahil untuk mencari kesesakan sistem. Sistem pemantauan yang baik adalah seperti pakaian rumah; ia harus selesa dan disesuaikan dengan anda.
Aspek kedua ialah ujian. Kami mengambil perkara ini dengan sangat serius: kami menulis unit klasik, ujian penyepaduan, ujian beban dan banyak lagi untuk setiap sistem. Kami juga sedang menulis strategi ujian, dan pada masa yang sama cuba meningkatkan tahap ujian sehingga kami tidak lagi memerlukan pemeriksaan manual.
Tiang ketiga ialah CI/CD Pipeline. Proses membina, menguji dan menggunakan aplikasi hendaklah diautomatikkan seboleh mungkin; tidak perlu ada campur tangan manual. Topik CI/CD Pipeline agak mendalam, dan saya hanya akan menyentuhnya secara ringkas. Perlu dinyatakan bahawa kami mempunyai senarai semak CI/CD Pipeline, yang dilalui oleh setiap pasukan produk dengan bantuan pusat kecekapan.
Dan inilah senarai semaknya
Dengan cara ini, banyak matlamat dicapai. Ini ialah versi API dan togol ciri untuk mengelakkan kereta api keluaran, dan mencapai liputan pelbagai ujian pada tahap sedemikian sehingga ujian automatik sepenuhnya, penggunaan lancar dan sebagainya.
Tiang keempat ialah prinsip seni bina dan penyelesaian teknikal. Kita boleh bercakap banyak tentang seni bina untuk masa yang lama, tetapi saya ingin menekankan beberapa prinsip yang saya ingin fokuskan.
Pertama, anda perlu memilih alat khusus untuk tugas tertentu. Ya, kedengarannya jelas, dan jelas bahawa paku harus didorong masuk dengan tukul, dan jam tangan harus dibongkar dengan pemutar skru khas. Tetapi pada zaman kita, banyak alat berusaha untuk penyejagatan untuk meliputi segmen maksimum pengguna: pangkalan data, cache, rangka kerja dan selebihnya. Sebagai contoh, jika anda mengambil pangkalan data MongoDB, ia berfungsi dengan transaksi berbilang dokumen dan pangkalan data Oracle berfungsi dengan json. Dan nampaknya semuanya boleh digunakan untuk segala-galanya. Tetapi jika kita berdiri untuk produktiviti, maka kita perlu memahami dengan jelas kekuatan dan kelemahan setiap alat dan menggunakan yang kita perlukan untuk kelas tugas kita.
Kedua, apabila mereka bentuk sistem, setiap peningkatan kerumitan mesti wajar. Kita mesti sentiasa mengingati perkara ini; prinsip gandingan rendah diketahui oleh semua orang. Saya percaya bahawa ia harus digunakan pada tahap perkhidmatan tertentu, dan pada tahap keseluruhan sistem, dan pada tahap landskap seni bina. Keupayaan untuk menskala secara mendatar setiap komponen sistem di sepanjang laluan beban juga penting. Jika anda mempunyai keupayaan ini, penskalaan tidak akan sukar.
Bercakap tentang penyelesaian teknikal, kami meminta pasukan produk untuk menyediakan set cadangan, idea dan penyelesaian baharu, yang mereka laksanakan sebagai persediaan untuk gelombang beban kerja seterusnya.
Keshi
Adalah perlu untuk mendekati pilihan cache tempatan dan diedarkan secara sedar. Kadangkala masuk akal untuk menggunakan kedua-duanya dalam sistem yang sama. Contohnya, kami mempunyai sistem di mana sesetengah data pada dasarnya adalah cache pameran, iaitu, sumber kemas kini terletak di belakang sistem itu sendiri dan sistem tidak berubah. data ini. Untuk pendekatan ini kami menggunakan Cache Kafein tempatan.
Dan terdapat data yang sistem berubah secara aktif semasa operasi, dan di sini kami sudah menggunakan cache yang diedarkan dengan Hazelcast. Pendekatan ini membolehkan kami menggunakan faedah cache yang diedarkan di mana ia benar-benar diperlukan, dan meminimumkan kos perkhidmatan untuk mengedarkan data kelompok Hazelcast di mana kami boleh melakukannya tanpanya. Kami telah menulis banyak tentang cache. ΠΈ .
Di samping itu, menukar penyeri bersiri kepada Kryo dalam Hazelcast memberi kami rangsangan yang baik. Dan peralihan daripada ReplicatedMap kepada IMap + Near Cache dalam Hazelcast membolehkan kami meminimumkan pergerakan data merentas gugusan.
Nasihat kecil: sekiranya berlaku ketidaksahihan cache massa, taktik memanaskan cache kedua dan kemudian beralih kepadanya kadangkala terpakai. Nampaknya dengan pendekatan ini kita harus mendapat penggunaan memori berganda, tetapi dalam praktiknya, dalam sistem di mana ini diamalkan, penggunaan memori berkurangan.
Timbunan reaktif
Kami menggunakan timbunan reaktif dalam sejumlah besar sistem. Dalam kes kami, ini ialah Webflux atau Kotlin dengan coroutine. Timbunan reaktif amat baik di mana kami menjangkakan operasi input-output yang perlahan. Contohnya, panggilan untuk memperlahankan perkhidmatan, bekerja dengan sistem fail atau sistem storan.
Prinsip yang paling penting ialah mengelak daripada menyekat panggilan. Rangka kerja reaktif mempunyai sebilangan kecil rangkaian perkhidmatan langsung yang berjalan di bawah hud. Jika kita secara cuai membenarkan diri kita membuat panggilan menyekat terus, seperti panggilan pemandu JDBC, sistem akan terhenti begitu sahaja.
Cuba tukar ralat kepada pengecualian masa jalan anda sendiri. Aliran sebenar pelaksanaan program beralih kepada rangka kerja reaktif, dan pelaksanaan kod menjadi tidak linear. Akibatnya, sangat sukar untuk mendiagnosis masalah menggunakan jejak tindanan. Dan penyelesaian di sini adalah untuk mencipta pengecualian masa jalan yang jelas dan objektif untuk setiap ralat.
Elasticsearch
Apabila menggunakan Elasticsearch, jangan pilih data yang tidak digunakan. Ini, pada dasarnya, juga nasihat yang sangat mudah, tetapi selalunya inilah yang dilupakan. Jika anda perlu memilih lebih daripada 10 ribu rekod pada satu masa, anda perlu menggunakan Tatal. Untuk menggunakan analogi, ia agak seperti kursor dalam pangkalan data hubungan.
Jangan gunakan postfilter melainkan perlu. Dengan data yang besar dalam sampel utama, operasi ini banyak memuatkan pangkalan data.
Gunakan operasi pukal jika berkenaan.
API
Apabila mereka bentuk API, sertakan keperluan untuk meminimumkan data yang dihantar. Ini benar terutamanya berkaitan dengan bahagian hadapan: di persimpangan inilah kami melangkaui saluran pusat data kami dan sudah pun mengusahakan saluran yang menghubungkan kami dengan pelanggan. Jika ia mempunyai sedikit masalah, trafik yang terlalu banyak menyebabkan pengalaman pengguna yang negatif.
Dan akhirnya, jangan buang banyak data, jelaskan tentang kontrak antara pengguna dan pembekal.
Transformasi organisasi
Eroshkina Elena, Timbalan Pengarah untuk IT
Pada masa kuarantin berlaku, dan keperluan timbul untuk meningkatkan kadar pembangunan dalam talian secara mendadak dan memperkenalkan perkhidmatan omnichannel, kami sudah pun dalam proses transformasi organisasi.
Sebahagian daripada struktur kami telah dipindahkan untuk berfungsi mengikut prinsip dan amalan pendekatan produk. Pasukan telah dibentuk yang kini bertanggungjawab untuk operasi dan pembangunan setiap produk. Pekerja dalam pasukan sedemikian 100% terlibat dan menstrukturkan kerja mereka menggunakan Scrum atau Kanban, bergantung pada apa yang lebih disukai daripada mereka, menyediakan saluran paip penempatan, melaksanakan amalan teknikal, amalan jaminan kualiti dan banyak lagi.
Nasib baik, sebahagian besar pasukan produk kami berada dalam bidang perkhidmatan dalam talian dan omnichannel. Ini membolehkan kami beralih kepada mod kerja jauh dalam masa yang sesingkat mungkin (serius, secara literal dalam dua hari) tanpa kehilangan kecekapan. Proses tersuai membolehkan kami menyesuaikan diri dengan cepat kepada keadaan kerja baharu dan mengekalkan kadar penyampaian fungsi baharu yang agak tinggi.
Di samping itu, kami mempunyai keperluan untuk mengukuhkan pasukan yang berada di sempadan perniagaan dalam talian. Pada masa itu menjadi jelas bahawa kami hanya boleh melakukan ini menggunakan sumber dalaman. Dan kira-kira 50 orang dalam masa dua minggu menukar kawasan tempat mereka bekerja sebelum ini dan terlibat dalam mengusahakan produk yang baru bagi mereka.
Ini tidak memerlukan sebarang usaha pengurusan khas, kerana bersama dengan mengatur proses kami sendiri, penambahbaikan teknikal produk dan amalan jaminan kualiti, kami mengajar pasukan kami untuk mengatur sendiri - untuk menguruskan proses pengeluaran mereka sendiri tanpa melibatkan sumber pentadbiran.
Kami dapat memfokuskan sumber pengurusan kami dengan tepat pada tempat yang diperlukan pada masa itu - untuk menyelaraskan bersama-sama perniagaan: Apa yang penting untuk pelanggan kami sekarang, apakah fungsi yang perlu dilaksanakan terlebih dahulu, apa yang perlu dilakukan untuk meningkatkan keupayaan pemprosesan kami untuk menghantar dan memproses pesanan. Semua ini dan model peranan yang jelas memungkinkan dalam tempoh ini untuk memuatkan aliran nilai pengeluaran kami dengan perkara yang benar-benar penting dan perlu.
Adalah jelas bahawa dengan kerja jauh dan kadar perubahan yang tinggi, apabila penunjuk perniagaan bergantung pada penyertaan semua orang, anda tidak boleh bergantung hanya pada perasaan dalaman dari siri "Adakah semuanya berjalan lancar dengan kami? Ya, nampaknya bagus.β Metrik objektif proses pengeluaran diperlukan. Kami mempunyai ini, ia tersedia untuk sesiapa sahaja yang berminat dengan metrik pasukan produk. Pertama sekali, pasukan itu sendiri, perniagaan, subkontraktor dan pengurusan.
Setiap dua minggu sekali, status diadakan dengan setiap pasukan, di mana metrik dianalisis selama 10 minit, kesesakan dalam proses pengeluaran dikenal pasti dan penyelesaian bersama dibangunkan: apa yang boleh dilakukan untuk menghapuskan kesesakan ini. Di sini anda boleh segera meminta bantuan daripada pihak pengurusan jika sebarang masalah yang dikenal pasti berada di luar zon pengaruh pasukan, atau kepakaran rakan sekerja yang mungkin pernah menghadapi masalah yang sama.
Walau bagaimanapun, kami memahami bahawa untuk mempercepatkan beberapa kali (dan inilah matlamat yang kami tetapkan untuk diri kami sendiri), kami masih perlu belajar banyak dan melaksanakannya dalam kerja harian kami. Pada masa ini kami terus meningkatkan pendekatan produk kami kepada pasukan lain dan produk baharu. Untuk melakukan ini, kami perlu menguasai format baharu untuk kami - sekolah metodologi dalam talian.
Ahli metodologi, orang yang membantu pasukan membina proses, mewujudkan komunikasi dan meningkatkan kecekapan kerja, pada asasnya adalah agen perubahan. Pada masa ini, graduan kohort pertama kami bekerja dengan pasukan dan membantu mereka berjaya.
Saya berpendapat bahawa keadaan semasa membuka peluang dan prospek kepada kita yang mungkin kita sendiri masih belum sedar sepenuhnya. Tetapi pengalaman dan amalan yang kami perolehi sekarang mengesahkan bahawa kami telah memilih jalan pembangunan yang betul, kami tidak akan melepaskan peluang baharu ini pada masa hadapan dan akan dapat bertindak balas dengan berkesan kepada cabaran yang bakal dihadapi oleh Sportmaster.
Penemuan
Dalam masa yang sukar ini, kami telah merumuskan prinsip utama yang mana pembangunan perisian terletak, yang, saya fikir, akan relevan untuk setiap syarikat yang berurusan dengan ini.
Orang. Inilah yang menjadi tumpuan segala-galanya. Pekerja mesti menikmati kerja mereka dan memahami matlamat syarikat dan matlamat produk yang mereka usahakan. Dan, sudah tentu, mereka boleh berkembang secara profesional.
Π’Π΅Ρ Π½ΠΎΠ»ΠΎΠ³ΠΈΡ. Adalah perlu bagi syarikat untuk mengambil pendekatan matang untuk bekerja dengan timbunan teknologinya dan membina kecekapan di mana ia benar-benar diperlukan. Bunyinya sangat mudah dan jelas. Dan sangat sering diabaikan.
Proses. Adalah penting untuk mengatur kerja pasukan produk dan pusat kecekapan dengan betul, untuk mewujudkan interaksi dengan perniagaan untuk bekerjasama dengannya sebagai rakan kongsi.
Secara umum, begitulah cara kami bertahan. Tesis utama masa kami disahkan sekali lagi, dengan satu klik yang bergema di dahi
Walaupun anda adalah perniagaan luar talian yang besar dengan banyak kedai dan sekumpulan bandar tempat anda beroperasi, bangunkan perniagaan dalam talian anda. Ini bukan sekadar saluran jualan tambahan atau aplikasi cantik yang melaluinya anda juga boleh membeli sesuatu (dan juga kerana pesaing juga mempunyai yang cantik). Ini bukan tayar ganti just-in-case untuk membantu anda mengharungi badai.
Ini adalah keperluan mutlak. Bukan sahaja keupayaan teknikal dan infrastruktur anda mesti disediakan, tetapi juga kakitangan dan proses anda. Lagipun, anda boleh membeli memori tambahan, ruang, menggunakan kejadian baharu dengan cepat, dsb. dalam beberapa jam. Tetapi orang dan proses perlu bersedia untuk ini lebih awal.
Sumber: www.habr.com