چه چیزی به ما کمک کرد تا به سرعت با تجارت آنلاین در شرایط جدید سازگار شویم

سلام!

نام من میخائیل است، من معاون فناوری اطلاعات در شرکت Sportmaster هستم. من می‌خواهم داستان نحوه برخورد ما با چالش‌هایی را که در طول همه‌گیری به وجود آمد به اشتراک بگذارم.

در روزهای اول واقعیت های جدید، قالب معمول معاملات آفلاین Sportmaster مسدود شد و بار کانال آنلاین ما، عمدتاً از نظر تحویل به آدرس مشتری، 10 برابر افزایش یافت. تنها در چند هفته، ما یک تجارت آفلاین غول پیکر را به یک تجارت آنلاین تبدیل کردیم و خدمات را با نیازهای مشتریان خود تطبیق دادیم.

اساساً، آنچه اساساً عملیات جانبی ما بود، به تجارت اصلی ما تبدیل شد. اهمیت هر سفارش آنلاین به شدت افزایش یافته است. لازم بود هر روبلی که مشتری به شرکت آورده بود ذخیره شود. 

برای پاسخگویی سریع به درخواست‌های مشتریان، یک مرکز تماس اضافی در دفتر اصلی شرکت افتتاح کردیم و اکنون می‌توانیم حدود 285 هزار تماس در هفته دریافت کنیم. در همان زمان، ما 270 فروشگاه را به یک فرمت جدید بدون تماس و ایمن منتقل کردیم که به مشتریان امکان می‌داد سفارشات را دریافت کنند و کارمندان شغل خود را حفظ کنند.

در طول فرآیند تحول با دو مشکل اساسی مواجه شدیم. اولا، بار منابع آنلاین ما به میزان قابل توجهی افزایش یافته است (سرگئی به شما خواهد گفت که چگونه با این موضوع برخورد کردیم). ثانیاً، جریان عملیات نادر (قبل از COVID) چندین برابر افزایش یافته است که به نوبه خود به مقدار زیادی اتوماسیون سریع نیاز دارد. برای حل این مشکل مجبور شدیم منابع را به سرعت از مناطقی که قبلاً اصلی بودند، منتقل کنیم. النا به شما خواهد گفت که چگونه با این موضوع برخورد کردیم.

بهره برداری از خدمات آنلاین

Kolesnikov Sergey، مسئول عملکرد فروشگاه آنلاین و میکروسرویس ها

از لحظه‌ای که فروشگاه‌های خرده‌فروشی ما شروع به بسته شدن به روی بازدیدکنندگان کردند، شروع به ثبت افزایش در معیارهایی مانند تعداد کاربران، تعداد سفارش‌های ثبت‌شده در برنامه ما و تعداد درخواست‌ها به برنامه‌ها کردیم. 

تعداد سفارشات از 18 مارس تا 31 مارستعداد درخواست‌ها به میکروسرویس‌های پرداخت آنلاینتعداد سفارش های ثبت شده در وب سایت

در نمودار اول می بینیم که افزایش تقریباً 14 برابر و در نمودار دوم - 4 برابر بود. ما معیار زمان پاسخگویی برنامه‌هایمان را نشان‌دهنده‌ترین می‌دانیم. 

در این نمودار ما پاسخ جبهه‌ها و اپلیکیشن‌ها را می‌بینیم و برای خودمان مشخص کردیم که هیچ رشدی را به این شکل مشاهده نکرده‌ایم.

این در درجه اول به این دلیل است که ما کار مقدماتی را در پایان سال 2019 آغاز کردیم. اکنون خدمات ما رزرو شده است، تحمل خطا در سطح سرورهای فیزیکی، سیستم های مجازی سازی، داکرها و خدمات موجود در آنها تضمین می شود. در عین حال، ظرفیت منابع سرور ما به ما اجازه می دهد تا بارهای متعدد را تحمل کنیم.

ابزار اصلی که در کل این ماجرا به ما کمک کرد، سیستم نظارتی ما بود. درست است، تا همین اواخر، ما سیستم واحدی نداشتیم که به ما اجازه دهد معیارها را در همه لایه‌ها، از سطح تجهیزات فیزیکی و سخت‌افزار گرفته تا سطح معیارهای تجاری، جمع‌آوری کنیم. 

به طور رسمی نظارت در شرکت وجود داشت، اما قاعدتاً پراکنده بود و در حوزه مسئولیت بخش‌های خاص بود. در واقع، هنگامی که یک حادثه رخ می داد، ما تقریباً هرگز درک مشترکی از آنچه دقیقاً اتفاق افتاده بود نداشتیم، هیچ ارتباطی وجود نداشت، و اغلب این منجر به دویدن در حلقه ها برای پیدا کردن و جداسازی مشکل می شد تا بتوان آن را برطرف کرد.

در مقطعی، ما فکر کردیم و تصمیم گرفتیم که تحمل این را به اندازه کافی داشته باشیم - ما به یک سیستم یکپارچه نیاز داشتیم تا کل تصویر را به طور کامل ببینیم. فناوری‌های اصلی که در پشته ما گنجانده شده‌اند عبارتند از Zabbix به عنوان مرکز ذخیره‌سازی هشدار و متریک، Prometheus برای جمع‌آوری و ذخیره معیارهای برنامه، Stack ELK برای ثبت و ذخیره داده‌ها از کل سیستم نظارت، و همچنین Grafana برای تجسم، Swagger، Docker. و سایر موارد مفید و آشنا که برای شما آشنا هستند.

در عین حال، ما نه تنها از فناوری های موجود در بازار استفاده می کنیم، بلکه برخی از فناوری های خود را نیز توسعه می دهیم. به عنوان مثال، ما خدماتی را برای یکپارچه سازی سیستم ها با یکدیگر ایجاد می کنیم، یعنی نوعی API برای جمع آوری معیارها. به علاوه ما در حال کار بر روی سیستم های نظارتی خودمان هستیم - در سطح معیارهای تجاری از تست های UI استفاده می کنیم. و همچنین یک ربات در تلگرام برای اطلاع رسانی به تیم ها.

ما همچنین در تلاش هستیم تا سیستم نظارت را برای تیم‌ها در دسترس قرار دهیم تا بتوانند به طور مستقل معیارهای خود را ذخیره کرده و با آنها کار کنند، از جمله تنظیم هشدار برای برخی از معیارهای محدود که به طور گسترده استفاده نمی‌شوند. 

در سرتاسر سیستم، تلاش می‌کنیم تا در سریع‌ترین زمان ممکن، رویدادها را بومی‌سازی کنیم. علاوه بر این، تعداد ریزسرویس‌ها و سیستم‌های ما اخیراً رشد قابل توجهی داشته است و تعداد ادغام‌ها نیز بر این اساس رشد کرده است. و به عنوان بخشی از بهینه سازی فرآیند تشخیص حوادث در سطح یکپارچه سازی، ما در حال توسعه سیستمی هستیم که به شما امکان می دهد بررسی های متقابل سیستمی را انجام دهید و نتیجه را نمایش دهید، که به شما امکان می دهد مشکلات اصلی مربوط به واردات و تعامل سیستم ها را پیدا کنید. یکدیگر. 

البته از نظر سیستم عامل هنوز جای رشد و توسعه داریم و فعالانه روی این موضوع کار می کنیم. شما می توانید در مورد سیستم نظارت ما بیشتر بخوانید اینجا. 

تست های فنی 

Orlov Sergey، سرپرست مرکز صلاحیت برای توسعه وب و موبایل است

از زمانی که تعطیلی فروشگاه های فیزیکی آغاز شد، از منظر توسعه با چالش های مختلفی روبرو بوده ایم. اول از همه، افزایش بار به این صورت است. واضح است که در صورت عدم انجام اقدامات مناسب، هنگامی که بار زیادی به سیستم وارد می شود، می تواند با صدای غم انگیز به کدو تنبل تبدیل شود یا عملکرد آن کاملاً کاهش یابد یا حتی عملکرد خود را از دست بدهد.

جنبه دوم، کمی کمتر آشکار، این است که سیستم تحت بار زیاد باید خیلی سریع تغییر می کرد و با تغییرات در فرآیندهای تجاری سازگار می شد. گاهی چندین بار در روز. بسیاری از شرکت ها این قانون را دارند که اگر فعالیت بازاریابی زیاد باشد، نیازی به ایجاد تغییر در سیستم نیست. اصلاً هیچ، بگذارید تا زمانی که کار می کند کار کند.

و ما اساساً یک جمعه سیاه بی پایان داشتیم که طی آن لازم بود سیستم را تغییر دهیم. و هر گونه خطا، مشکل یا خرابی در سیستم برای کسب و کار بسیار پرهزینه خواهد بود.

با نگاهی به آینده، من می گویم که ما موفق شدیم با این آزمایش ها کنار بیاییم، همه سیستم ها بار را تحمل کردند، به راحتی مقیاس بندی شدند و هیچ نقص فنی جهانی را تجربه نکردیم.

چهار ستون وجود دارد که توانایی سیستم برای تحمل بارهای بالا بر روی آنها استوار است. اولین مورد نظارت است که در بالا در مورد آن خواندید. بدون سیستم نظارت داخلی، یافتن گلوگاه های سیستم تقریبا غیرممکن است. یک سیستم مانیتورینگ خوب مانند لباس خانه است؛ باید راحت و متناسب با شما باشد.

جنبه دوم آزمایش است. ما این نکته را بسیار جدی می‌گیریم: واحدهای کلاسیک، تست‌های یکپارچه‌سازی، تست‌های بارگذاری و بسیاری موارد دیگر را برای هر سیستم می‌نویسیم. ما همچنین در حال نوشتن یک استراتژی تست هستیم و در عین حال سعی می کنیم سطح تست را به حدی افزایش دهیم که دیگر نیازی به بررسی دستی نداشته باشیم.

ستون سوم خط لوله CI/CD است. فرآیندهای ساخت، آزمایش و استقرار یک برنامه کاربردی باید تا حد امکان خودکار باشد و هیچ مداخله دستی وجود نداشته باشد. موضوع خط لوله CI/CD کاملاً عمیق است و من فقط به طور خلاصه به آن می پردازم. فقط لازم به ذکر است که ما یک چک لیست CI/CD Pipeline داریم که هر تیم محصول با کمک مراکز شایستگی آن را بررسی می کند.

و در اینجا چک لیست است

در این راه اهداف زیادی محقق می شود. این نسخه API و تغییر ویژگی برای جلوگیری از رهاسازی قطار و دستیابی به پوشش تست های مختلف در سطحی است که آزمایش کاملاً خودکار باشد، استقرار یکپارچه باشد و غیره.

رکن چهارم اصول معماری و راهکارهای فنی است. ما می‌توانیم برای مدت طولانی درباره معماری صحبت کنیم، اما من می‌خواهم بر چند اصل تأکید کنم که می‌خواهم روی آنها تمرکز کنم.

ابتدا باید ابزارهای تخصصی را برای کارهای خاص انتخاب کنید. بله، واضح به نظر می رسد، و واضح است که میخ ها را باید با چکش وارد کرد و ساعت های مچی را باید با پیچ گوشتی های مخصوص جدا کرد. اما در عصر ما، بسیاری از ابزارها برای پوشش دادن حداکثر بخش کاربران: پایگاه‌های اطلاعاتی، حافظه‌های پنهان، چارچوب‌ها و بقیه، برای جهانی‌سازی تلاش می‌کنند. به عنوان مثال، اگر پایگاه داده MongoDB را بگیرید، با تراکنش های چند سندی کار می کند و پایگاه داده اوراکل با json کار می کند. و به نظر می رسد که همه چیز را می توان برای همه چیز استفاده کرد. اما اگر طرفدار بهره‌وری هستیم، باید نقاط قوت و ضعف هر ابزار را به وضوح درک کنیم و از مواردی که برای کلاس وظایف خود نیاز داریم استفاده کنیم. 

ثانیاً، هنگام طراحی سیستم ها، هر افزایش پیچیدگی باید توجیه شود. ما باید دائماً این را در نظر داشته باشیم؛ اصل کم کوپلینگ برای همه شناخته شده است. من معتقدم که باید در سطح یک خدمات خاص و در سطح کل سیستم و در سطح چشم انداز معماری اعمال شود. توانایی مقیاس افقی هر جزء سیستم در طول مسیر بار نیز مهم است. اگر این توانایی را داشته باشید، مقیاس بندی کار سختی نخواهد بود.

صحبت از راه‌حل‌های فنی، از تیم‌های محصول خواستیم مجموعه جدیدی از توصیه‌ها، ایده‌ها و راه‌حل‌ها را آماده کنند، که آنها برای آماده‌سازی برای موج بعدی حجم کاری اجرا کردند.

کشی

لازم است آگاهانه به انتخاب کش های محلی و توزیع شده نزدیک شود. گاهی اوقات استفاده از هر دو در یک سیستم منطقی است، به عنوان مثال، ما سیستم هایی داریم که در آنها برخی از داده ها اساسا یک کش ویترینی هستند، یعنی منبع به روز رسانی ها در پشت خود سیستم قرار دارد و سیستم ها تغییر نمی کنند. این داده ها برای این رویکرد ما از کافئین کش محلی استفاده می کنیم. 

و داده هایی وجود دارد که سیستم به طور فعال در حین کار تغییر می کند، و در اینجا ما از یک کش توزیع شده با Hazelcast استفاده می کنیم. این رویکرد به ما امکان می‌دهد از مزایای یک کش توزیع شده در جایی که واقعاً مورد نیاز است استفاده کنیم و هزینه‌های سرویس گردش داده‌های خوشه Hazelcast را در جایی که می‌توانیم بدون آن انجام دهیم به حداقل برسانیم. ما در مورد کش ها زیاد نوشته ایم. اینجا и اینجا.

علاوه بر این، تغییر سریال به Kryo در Hazelcast به ما رونق خوبی داد. و انتقال از ReplicatedMap به IMap + Near Cache در Hazelcast به ما این امکان را داد که حرکت داده ها را در سراسر خوشه به حداقل برسانیم. 

یک توصیه کوچک: در صورت عدم اعتبار کش انبوه، گاهی اوقات تاکتیک گرم کردن کش دوم و سپس تغییر به آن قابل اجرا است. به نظر می رسد که با این رویکرد باید دو برابر مصرف حافظه داشته باشیم، اما در عمل، در سیستم هایی که این کار انجام می شد، مصرف حافظه کاهش می یابد.

پشته واکنشی

ما از پشته واکنشی در تعداد بسیار زیادی از سیستم ها استفاده می کنیم. در مورد ما، این Webflux یا Kotlin با کوروتین است. پشته واکنشی به ویژه در جایی که انتظار عملیات ورودی-خروجی کند را داریم خوب است. به عنوان مثال، تماس با خدمات کند، کار با سیستم فایل یا سیستم های ذخیره سازی.

مهمترین اصل جلوگیری از مسدود کردن تماس ها است. فریم ورک‌های واکنش‌گرا دارای تعداد کمی از رشته‌های سرویس زنده هستند که در زیر هود اجرا می‌شوند. اگر بی دقت به خود اجازه دهیم که یک تماس مسدودکننده مستقیم، مانند تماس راننده JDBC برقرار کنیم، سیستم به سادگی متوقف می شود. 

سعی کنید خطاها را به استثنای زمان اجرا خود تبدیل کنید. جریان واقعی اجرای برنامه به چارچوب های واکنشی تغییر می کند و اجرای کد غیرخطی می شود. در نتیجه، تشخیص مشکلات با استفاده از stack traces بسیار دشوار است. و راه حل در اینجا ایجاد استثناهای زمان اجرا واضح و عینی برای هر خطا خواهد بود.

ارزیابی جستجو

هنگام استفاده از Elasticsearch، داده های استفاده نشده را انتخاب نکنید. این، در اصل، همچنین توصیه بسیار ساده ای است، اما اغلب این چیزی است که فراموش می شود. اگر نیاز به انتخاب بیش از 10 هزار رکورد در یک زمان دارید، باید از Scroll استفاده کنید. برای استفاده از قیاس، کمی شبیه مکان نما در یک پایگاه داده رابطه ای است. 

از پس فیلتر مگر در موارد ضروری استفاده نکنید. با داده های بزرگ در نمونه اصلی، این عملیات پایگاه داده را تا حد زیادی بارگذاری می کند. 

در صورت لزوم از عملیات انبوه استفاده کنید.

API

هنگام طراحی یک API، الزاماتی را برای به حداقل رساندن داده های ارسالی لحاظ کنید. این به ویژه در ارتباط با قسمت جلویی صادق است: در این نقطه اتصال است که ما از کانال های مراکز داده خود فراتر می رویم و در حال حاضر روی کانالی کار می کنیم که ما را با مشتری متصل می کند. اگر کوچکترین مشکلی داشته باشد، ترافیک زیاد باعث تجربه کاربری منفی می شود.

و در نهایت، یک دسته کامل از داده ها را دور نریزید، در مورد قرارداد بین مصرف کنندگان و تامین کنندگان شفاف باشید.

تحول سازمانی

اروشکینا النا، معاون مدیر فناوری اطلاعات

در لحظه ای که قرنطینه اتفاق افتاد و نیاز به افزایش شدید سرعت توسعه آنلاین و معرفی سرویس های همه کانالی به وجود آمد، ما قبلاً در مرحله تحول سازمانی بودیم. 

بخشی از ساختار ما با توجه به اصول و شیوه های رویکرد محصول به کار منتقل شد. تیم هایی تشکیل شده اند که اکنون مسئولیت عملیات و توسعه هر محصول را بر عهده دارند. کارمندان در چنین تیم هایی 100٪ درگیر هستند و کار خود را با استفاده از Scrum یا Kanban ساختار می دهند، بسته به اینکه چه چیزی برای آنها ترجیح داده می شود، راه اندازی خط لوله استقرار، اجرای شیوه های فنی، شیوه های تضمین کیفیت و بسیاری موارد دیگر.

خوشبختانه، بخش عمده ای از تیم های محصول ما در حوزه خدمات آنلاین و همه کاناله بودند. این به ما امکان داد در کوتاه ترین زمان ممکن (به طور جدی، به معنای واقعی کلمه در دو روز) بدون از دست دادن کارایی به حالت کار از راه دور سوئیچ کنیم. فرآیند سفارشی سازی شده به ما این امکان را می دهد که به سرعت با شرایط کاری جدید سازگار شویم و سرعت نسبتاً بالایی را در ارائه عملکردهای جدید حفظ کنیم.

علاوه بر این، ما نیاز به تقویت تیم هایی داریم که در مرز تجارت آنلاین هستند. در آن لحظه مشخص شد که ما فقط با استفاده از منابع داخلی می توانیم این کار را انجام دهیم. و حدود 50 نفر در دو هفته منطقه ای را که قبلاً در آن کار می کردند تغییر دادند و درگیر کار روی محصولی شدند که برای آنها جدید بود. 

این نیاز به هیچ تلاش مدیریتی خاصی ندارد، زیرا در کنار سازماندهی فرآیند خودمان، بهبود فنی محصول و اقدامات تضمین کیفیت، به تیم‌هایمان آموزش می‌دهیم که خود سازماندهی شوند - فرآیند تولید خود را بدون دخالت منابع اداری مدیریت کنند.

ما توانستیم منابع مدیریتی خود را دقیقاً در جایی که در آن لحظه مورد نیاز بود متمرکز کنیم - روی هماهنگی با کسب و کار: آنچه در حال حاضر برای مشتری ما مهم است، ابتدا چه عملکردی باید پیاده سازی شود، چه کاری باید انجام دهیم تا توانایی توان عملیاتی خود را افزایش دهیم. برای تحویل و پردازش سفارشات همه اینها و یک الگوی نقش روشن باعث شد در این دوره بتوانیم جریانهای ارزش تولید خود را با آنچه واقعا مهم و ضروری است بارگذاری کنیم. 

واضح است که با دورکاری و سرعت بالای تغییر، وقتی شاخص‌های کسب‌وکار به مشارکت همه بستگی دارد، نمی‌توان تنها به احساسات درونی سریال «آیا همه چیز با ما خوب پیش می‌رود؟» تکیه کرد؟ بله، به نظر خوب است.» معیارهای عینی فرآیند تولید مورد نیاز است. ما اینها را داریم، آنها برای هر کسی که به معیارهای تیم های محصول علاقه دارد در دسترس است. اول از همه، خود تیم، تجارت، پیمانکاران فرعی و مدیریت.

هر دو هفته یک بار، وضعیتی با هر تیم برگزار می شود، که در آن معیارها به مدت 10 دقیقه تجزیه و تحلیل می شوند، گلوگاه ها در فرآیند تولید شناسایی می شوند و یک راه حل مشترک ایجاد می شود: برای از بین بردن این تنگناها چه کاری می توان انجام داد. در اینجا می‌توانید در صورتی که هر مشکل شناسایی شده خارج از حوزه نفوذ تیم‌ها باشد یا تخصص همکارانی که قبلاً با مشکل مشابهی مواجه شده‌اند، فوراً از مدیریت کمک بخواهید.

با این حال، ما درک می کنیم که برای شتاب گرفتن چندین بار (و این دقیقاً هدفی است که برای خود تعیین کرده ایم)، هنوز باید چیزهای زیادی یاد بگیریم و آن را در کار روزانه خود پیاده کنیم. در حال حاضر، ما به توسعه رویکرد محصول خود برای سایر تیم ها و محصولات جدید ادامه می دهیم. برای انجام این کار، ما باید یک قالب جدید را برای خود مسلط می کردیم - یک مدرسه آنلاین متدولوژیست.

متدولوژیست ها، افرادی که به تیم ها در ایجاد یک فرآیند، برقراری ارتباطات و بهبود کارایی کار کمک می کنند، اساساً عوامل تغییر هستند. در حال حاضر، فارغ التحصیلان اولین گروه ما با تیم ها کار می کنند و به آنها کمک می کنند تا موفق شوند. 

من فکر می کنم که شرایط فعلی فرصت ها و چشم اندازهایی را برای ما باز می کند که شاید خود ما هنوز به طور کامل از آن آگاه نیستیم. اما تجربه و تمرینی که در حال حاضر به دست می آوریم تأیید می کند که ما مسیر توسعه را درست انتخاب کرده ایم، در آینده این فرصت های جدید را از دست نخواهیم داد و می توانیم به همان اندازه موثر به چالش هایی که Sportmaster با آن مواجه خواهد شد پاسخ دهیم.

یافته ها

در این زمان دشوار، ما اصول اصلی را که توسعه نرم افزار بر آن استوار است، فرموله کرده ایم، که فکر می کنم برای هر شرکتی که با این موضوع سروکار دارد، مرتبط خواهد بود.

مردم. این چیزی است که همه چیز بر آن استوار است. کارمندان باید از کار خود لذت ببرند و اهداف شرکت و اهداف محصولاتی که روی آنها کار می کنند را درک کنند. و البته، آنها می توانند به صورت حرفه ای پیشرفت کنند. 

Технология. لازم است که شرکت رویکردی بالغانه برای کار با پشته فناوری خود اتخاذ کند و شایستگی هایی را در جایی که واقعاً مورد نیاز است ایجاد کند. خیلی ساده و واضح به نظر می رسد. و اغلب نادیده گرفته می شود.

فرایندها. سازماندهی مناسب کار تیم های محصول و مراکز شایستگی، ایجاد تعامل با کسب و کار به منظور همکاری با آن به عنوان یک شریک مهم است.

به طور کلی، ما تقریباً اینگونه زنده ماندیم. تز اصلی زمانه ما یک بار دیگر با یک کلیک طنین انداز بر پیشانی تایید شد

حتی اگر یک کسب و کار آفلاین بزرگ با فروشگاه های زیاد و تعداد زیادی از شهرهایی هستید که در آن فعالیت می کنید، کسب و کار آنلاین خود را توسعه دهید. این فقط یک کانال فروش اضافی یا یک برنامه کاربردی زیبا نیست که از طریق آن بتوانید چیزی بخرید (و همچنین به این دلیل که رقبا نیز موارد زیبایی دارند). این یک لاستیک یدکی مناسب برای کمک به شما در مقابله با طوفان نیست.

این یک ضرورت مطلق است. که نه تنها توانایی ها و زیرساخت های فنی شما، بلکه افراد و فرآیندهای شما نیز باید برای آن آماده باشد. پس از همه، شما می توانید به سرعت حافظه، فضای اضافی، نصب نمونه های جدید و غیره را در چند ساعت بخرید. اما افراد و فرآیندها باید از قبل برای این امر آماده باشند.

منبع: www.habr.com