Привіт!
Мене звуть Михайло, я заступник директора з ІТ у компанії «Спортмайстер». Я хочу поділитися історією про те, як ми впоралися з труднощами під час пандемії.
У перші дні нових реалій звичний формат офлайн-торгівлі «Спортмайстра» завмер, і навантаження на наш онлайн-канал, насамперед у частині доставки на адресу клієнту, зросло в 10 разів. За кілька тижнів ми трансформували гігантський за обсягом офлайн бізнес в онлайн, адаптували сервіс під потреби наших клієнтів.
Загалом те, що по суті було нашою другорядною операцією, стало основним бізнесом. Важливість кожного інтернет-замовлення зросла екстремально. Потрібно було зберегти кожен карбованець, який клієнт приносив у компанію.
Щоб оперативно реагувати на запити клієнтів, ми відкрили додатковий контактний центр у головному офісі компанії і тепер можемо приймати близько 285 тисяч дзвінків на тиждень. У той же час, ми перевели 270 магазинів у новий формат безконтактної та безпечної роботи, що дозволило клієнтам отримувати замовлення, а співробітникам зберегти робочі місця.
У процесі трансформації виникли дві основні проблеми. По-перше, відчутно зросло навантаження на наші онлайн-ресурси (як ми боролися з цим, розповість Сергій). По-друге, потік рідкісних (до COVID) операцій багаторазово зріс, що потребувало великого обсягу швидкої автоматизації. Щоб вирішити цю проблему, нам довелося оперативно перекинути ресурси з напрямків, які були основними раніше. Як ми впоралися з цим, — розповість Олена.
Експлуатація онлайн-сервісів
Колесников Сергій, відповідає за експлуатацію інтернет-магазину та мікросервісів
З того моменту, як наші роздрібні магазини почали закриватися для відвідувачів, ми почали фіксувати зростання таких метрик, як кількість користувачів, кількість замовлень, що оформлюються в нашому додатку, кількість реквестів до додатків.
Кількість замовлень з 18 по 31 березняКількість запитів до мікросервісів онлайн-оплатиКількість оформлених на сайті замовлень
На першому графіку ми бачимо, що приріст становив приблизно 14 разів, на другому – 4 рази. Найбільш показовою при цьому ми вважаємо метрику відповіді наших додатків.
На цьому графіку ми бачимо відповідь фронтів і додатків, і ми визначили, що як такого зростання ми помітили.
Насамперед це пов'язано з тим, що ми розпочали підготовчі роботи наприкінці 2019 року. Зараз наші сервіси зарезервовані, забезпечена стійкість до відмови на рівні фізичних серверів, систем віртуалізації, докерів, сервісів у них. При цьому потужності наших серверних ресурсів дозволяють переживати багаторазове навантаження.
Основним інструментом, який допоміг нам у всій цій історії, стала наша моніторингова система. Щоправда, ще зовсім недавно у нас не було єдиної системи, яка б дозволяла збирати метрики на всіх шарах, від рівня фізичного обладнання та апаратного забезпечення до рівня бізнес-метрик.
Формально моніторинг у компанії був, але як правило він був розосереджений і знаходився в зоні відповідальності конкретних підрозділів. Фактично, коли відбувався якийсь інцидент, у нас майже ніколи не було єдиного розуміння, що саме сталося, не було інформування, і часто це призводило до бігу по колу в пошуках та локалізації проблеми для подальшого усунення.
Якоїсь миті ми подумали і вирішили, що вистачить це терпіти — нам потрібна єдина система, щоб бачити всю картину повністю. Основні технології, які входять в наш стек, це Zabbix як центр алертингу та зберігання метрик, Prometheus для збору та зберігання метрик додатків, Stack ELK для логування та зберігання даних усієї системи моніторингу, а також Grafana для візуалізації, Swagger, Docker та інші корисні та знайомі вам штучки.
При цьому ми використовуємо не лише доступні на ринку технології, а й розробляємо дещо самостійно. Наприклад, ми робимо сервіси для інтеграції систем один з одним, тобто API для збору метрик. Плюс працюємо над власними системами моніторингу – на рівні бізнес-метрик ми використовуємо UI-тести. А також бот у Telegram для оповіщення команд.
А ще ми намагаємося робити систему моніторингу доступною для команд, щоб вони могли самостійно зберігати свої метрики та працювати з ними, у тому числі налаштовувати алертинг у якихось вузьких метриках, що мають значення не найширше застосування.
В рамках усієї системи ми прагнемо проактивності та максимально швидкої локалізації інцидентів. До того ж, кількість наших мікросервісів та систем значно зросла за останній час, відповідно, зростає і кількість інтеграцій. І в рамках оптимізації процесу діагностики інцидентів на рівні інтеграції ми розробляємо систему, яка дозволяє проводити крос-системні перевірки та виводити результат, що дозволяє знаходити основні проблеми, пов'язані з імпортами та взаємодією систем один з одним.
Звісно, нам ще є куди зростати та розвиватися в плані експлуатації систем, і ми активно над цим працюємо. Докладніше про нашу систему моніторингу можна почитати .
Технічні випробування
Орлов Сергій, керує центром компетенції веб- та мобільної розробки
З початку закриття фізичних магазинів нам довелося зіткнутися із різними випробуваннями з погляду розробки. Насамперед, стрибок навантаження як такий. Зрозуміло, що якщо не вжито відповідних заходів, то при подачі на систему високого навантаження вона може з сумною бавовною перетворитися на гарбуз, або повністю деградувати у продуктивності, або взагалі втратити свою працездатність.
Другий аспект, трохи менш очевидний, у тому, що систему під високим навантаженням потрібно було дуже швидко змінювати, адаптуючись під зміни бізнес-процесів. Іноді кілька разів на день. У багатьох компаніях є правило, що при великих маркетингових активностях не варто вносити до системи жодних змін. Взагалі ніяких, хай працює, раз працює.
А в нас, по суті, була нескінченна чорна п'ятниця, в яку при цьому потрібно було змінювати систему. І будь-яка помилка, проблема, збій у системі дуже дорого обходилися б бізнесу.
Забігаючи наперед, скажу, що нам вдалося впоратися з цими випробуваннями, всі системи витримали навантаження, легко відмасштабувалися і якихось глобальних технічних збоїв у нас не було.
Існує чотири кити, на яких тримається здатність системи витримувати високе стрибкоподібне навантаження. Перший із них — це моніторинг, про який ви читали трохи вище. Без побудованої системи моніторингу майже неможливо визначити тонкі місця системи. Хороша система моніторингу - це як домашній одяг, він повинен бути зручним і адаптованим під вас.
Другий аспект – це тестування. Ми дуже серйозно ставимося до цього моменту: пишемо і класичні юніти, інтеграційні, тести навантаження і багато інших для кожної системи. Ще ми пишемо стратегію тестування, і при цьому намагаємося довести рівень тестування до того, щоби ручні перевірки нам більше не були потрібні.
Третій кит – це CI/CD Pipeline. Процеси збирання, тестування, розгортання програми повинні бути максимально автоматизовані, тут не повинно бути ручних втручань. Тема CI/CD Pipeline досить глибока, і я торкнуся її тільки побіжно. Варто згадати лише, що у нас є чекліст CI/CD Pipeline, яким за допомогою центрів компетенції проходить кожна продуктова команда.
А ось і чекліст
Таким чином досягається дуже багато цілей. Це версіонування API, і feature toggle, щоб уникнути паровоза релізів, і досягнення покриття різних тестів такого рівня, щоб тестування було повністю автоматизоване, деплої були безшовні та інше.
Четвертий кит - це архітектурні принципи та технічні рішення. Про архітектуру можна говорити багато і довго, але я хочу наголосити на кількох принципах, на яких я хотів би загострити увагу.
По-перше, треба вибирати спеціалізовані інструменти під конкретні завдання. Так, звучить очевидно, і зрозуміло, що цвяхи забивати варто молотком, а наручний годинник розбирати спеціальними викрутками. Але в наш час багато інструментів прагнуть універсалізації, щоб охопити максимальний сегмент користувачів: бази даних, кеші, фреймворки та інше. Ось, наприклад, якщо взяти базу даних MongoDB, вона працює з мультидокументарними транзакціями, а база даних Oracle працює з json-ми. І здавалося б, що все можна використати для всього. Але якщо ми боремося за продуктивність, то нам потрібно чітко розуміти сильні та слабкі сторони кожного інструменту та використовувати потрібні нам для нашого класу завдань.
По-друге, під час проектування систем кожне підвищення складності має бути обґрунтованим. Ми повинні постійно пам'ятати це, принцип low coupling всім відомий. Я вважаю, що його потрібно застосовувати і на рівні конкретного сервісу, і на всій системі, і на рівні архітектурного ландшафту. Також важливою є здатність до горизонтального масштабування кожного компонента системи на шляху навантаження. Якщо мати цю здатність, масштабування не складе ніяких труднощів.
Якщо говорити про технічні рішення, ми попросили продуктові команди підготувати новий набір рекомендацій, ідей та рішень, які вони реалізували в процесі підготовки до чергової хвилі навантаження.
Кеші
Необхідно свідомо підходити до вибору локальних та розподілених кешів. Іноді має сенс використовувати і ті, й інші в рамках однієї системи. Наприклад, у нас є системи, в яких частина даних по суті є вітринним кешем, тобто джерело оновлень знаходиться за самою системою, і ці дані не змінюють. Для цього ми використовуємо локальний Caffeine Cache.
А є дані, які система активно змінює у процесі роботи, і тут ми вже застосовуємо розподілений кеш із Hazelcast. Такий підхід дозволяє нам використовувати переваги розподіленого кешу там, де вони дійсно потрібні, і мінімізувати сервісні витрати на циркуляцію даних кластера Hazelcast там, де ми можемо без цього обійтися. Про кеші ми багато писали и .
Крім того, зміна серіалізатора на Kryo у Hazelcast дала нам непоганий приріст. А перехід від ReplicatedMap до IMap+Near Cache у Hazelcast дозволив нам мінімізувати рух даних по кластеру.
Невелика порада: при масовій інвалідності кешу іноді застосовується тактика з прогріванням другого кешу з наступним перемиканням на нього. Здавалося б, за такого підходу ми маємо отримати подвійне споживання пам'яті, але практично, у тих системах, де таке практикувалося, споживання пам'яті зменшувалася.
Реактивний стек
Ми використовуємо реактивний стек у досить великій кількості систем. У нашому випадку це Webflux або Kotlin із корутинами. Особливо добре реактивний стек заходить там, де ми чекаємо на повільні input-output операції. Наприклад, виклики повільних сервісів, робота з файловою системою чи системами зберігання.
Найважливіший принцип — уникати блокуючих викликів. Під капотом реактивних фреймворків крутиться небагато живих сервісних потоків. Якщо ми необережно дозволимо собі зробити прямий блокуючий виклик, наприклад, виклик JDBC-драйвера, то система просто зупиниться.
Намагайтеся звертати помилки у власні runtime exception. Реальний потік виконання програми відходить до реактивних фреймворків, виконання коду стає нелінійним. Як наслідок, дуже складно діагностувати проблеми зі стек-трейсами. І рішенням тут буде створення зрозумілих об'єктивних runtime exception-ів на кожну помилку.
Elasticsearch
При використанні Elasticsearch не вибирати дані, що не використовуються. Це, в принципі, теж дуже проста порада, але найчастіше саме про це забувають. Якщо потрібно вибрати більше 10 тисяч записів, потрібно використовувати Scroll. Якщо проводити аналогію, це трохи схоже на курсор у реляційній базі даних.
Не використовуйте postfilter без необхідності. При великих даних в основній вибірці ця операція дуже вантажить базу даних.
Використовуйте bulk-операції там, де це можна застосувати.
API
При проектуванні API закладайте вимоги до мінімізації даних, що передаються. Особливо це актуально на зв'язці з фронтом: саме на цьому стику ми виходимо за канали наших ЦОДів і вже працюємо на каналі, який зв'язує нас із клієнтом. Якщо на ньому є найменші проблеми, надто високий трафік викликає негативний user experience.
І, нарешті, не вивалюйте весь стос даних, чітко підходьте до контракту між споживачами та постачальниками.
Організаційна трансформація
Єрошкіна Олена, заступник директора з ІТ
У момент, коли стався карантин, і виникла потреба різко нарощувати темпи розвитку онлайн та впроваджувати омніканальні послуги, ми вже перебували у процесі організаційної трансформації.
Частина нашої структури була переведена на роботу за принципами та практиками продуктового підходу. Сформувалися команди, які тепер відповідають за функціонування та розвиток кожного продукту. Співробітники в таких командах задіяні на 100% і будують свою роботу по скрам або канбан, залежно від того, що для них краще, налаштовують конвеєр розгортання, впроваджують технічні практики, практики забезпечення якості та багато іншого.
Завдяки щасливому випадку основна частина таких продуктових команд у нас саме знаходилася в області онлайн та омніканальних сервісів. Це дозволило нам у найкоротший термін (серйозно, буквально за два дні) перейти в режим віддаленої роботи без втрати ефективності. Налаштований процес дозволив швидко адаптуватися до нових умов роботи та витримати досить високий темп постачання нової функціональності.
Крім того, у нас виникла потреба посилити ті команди, які знаходяться на фронтирі онлайн-бізнесу. Тоді стало зрозуміло, що ми можемо це зробити тільки за рахунок внутрішніх ресурсів. І близько 50 осіб за два тижні змінили область, де вони працювали до цього, і влаштували роботу над новим для них продуктом.
Для цього не знадобилося якихось спеціальних управлінських зусиль, бо поряд з організацією власного процесу, з технічним удосконаленням продукту, з практикою забезпечення якості ми вчимо наші команди самоорганізації — керувати власним виробничим процесом без залучення адміністративного ресурсу.
Управлінський ресурс ми змогли сфокусувати саме там, де це було необхідно в той момент, — на координації разом із бізнесом: Що ж саме зараз важливо для нашого клієнта, яка функціональність має бути реалізована в першу чергу, що необхідно зробити, щоб збільшити нашу пропускну здатність по доставці та обробці замовлень. Все це і чітка рольова модель дозволили в цей період навантажувати наші виробничі потоки створення цінності тим, що дійсно важливе і потрібне.
Ясна річ, що за віддаленої роботи та високого темпу змін, коли від участі кожного залежать бізнес-показники, не можна покладатися лише на внутрішні відчуття із серії «А чи все у нас йде добре? Та начебто непогано». Потрібні об'єктивні метрики виробничого процесу. Такі ми маємо, вони доступні кожному, хто цікавиться метриками продуктових команд. Насамперед самій команді, бізнесу, суміжникам та керівництву.
Раз на два тижні з кожною командою проводиться статус, де протягом 10 хвилин аналізуються метрики, виявляються вузькі місця виробничого процесу та виробляється спільне рішення: що можна зробити для того, щоб усунути ці вузькі місця. Тут же можна одразу попросити допомоги у керівництва у випадку, якщо якась виявлена проблема знаходиться поза зоною впливу команд, або експертизи колег, які, можливо, вже стикалися зі схожою проблемою.
Тим не менш, ми розуміємо, що для кратного прискорення (а саме таку мету ми собі ставимо) нам ще багато чого необхідно навчитися та впровадити у щоденну роботу. Зараз ми продовжуємо масштабування продуктового підходу на інші команди і на нові продукти. Для цього нам довелося опанувати новий для нас формат онлайн-школи методологів.
Методологи, які допомагають командам вибудовувати процес, налагоджувати комунікації, підвищувати ефективність роботи, по суті є агентами зміни. Прямо зараз випускники нашого першого потоку працюють із командами та допомагають їм стати успішними.
Я думаю, що ситуація, що склалася, відкриває для нас такі можливості та перспективи, які, можливо, ми й самі поки що до кінця не усвідомлюємо. Але той досвід і та практика, яку ми отримуємо прямо зараз, підтверджує, що ми обрали правильний шлях розвитку, не проґавимо у майбутньому ці нові можливості і зможемо так само ефективно відповідати на ті виклики, які стоятимуть перед «Спортмайстром».
Висновки
За цей непростий час ми сформулювали головні принципи, на яких тримається розробка програмного забезпечення, які, гадаю, будуть актуальними для кожної компанії, яка цим займається.
Люди. Це те, на чому все й тримається. Співробітники повинні отримувати задоволення від роботи, розуміти цілі компанії та цілі продуктів, якими вони займаються. І, звичайно, могли професійно розвиватися.
Технологія. Необхідно, щоб компанія зріло підходила до роботи зі своїм технологічним стеком та нарощувала компетенції там, де це дійсно необхідно. Звучить дуже просто та очевидно. І часто ігнорується.
процеси. Важливо правильно вибудувати роботу продуктових команд і компетенційних центрів, налагодити взаємодію з бізнесом, щоб працювати з ним як з партнером.
Загалом приблизно так і вижили. Основна теза сучасності підтвердилася ще раз, дзвінко клацнувши по лобі
Навіть якщо ти – величезний офлайн-бізнес з безліччю магазинів та купою міст присутності, розвивай свій онлайн. Це не просто додатковий канал збуту або гарний додаток, через який теж можна щось купити (а ще тому, що у конкурентів теж гарне). Це не запаска про всяк випадок, що допоможе перечекати бурю.
Це потреба. До якої мають бути готові не лише ваші технічні потужності та інфраструктура, а й люди та процеси. Адже швидко докупити пам'ять, місце, розгорнути нові інстанси та інше можна за кілька годин. А ось людей та процеси треба готувати до такого заздалегідь.
Джерело: habr.com