10 основних помилок масштабування систем
10 основних помилок масштабування систем
Архітектурні помилки
1. Проектування реалізації, але не пошук архітектурного рішення
Які з наступних підходів ви використовували для опису архітектури свого продукту?
Варіант А:«Ми Java-магазин, що працює на GlassFish, Apache Felix з MySQL та СУБД MongoDB».
Варіант В:«У нас 3-х рівнева архітектура із ізольованими зонами, які для стійкості до збоїв не мають синхронної комунікації один з одним. Постійне сховище даних — поєднання реляційної та NoSQL баз даних з використанням вбудованої реплікації з горизонтальним шардингом».
Правильну відповідь "". Відповідь «А» краще описує реалізацію архітектури станом на будь-який день, але не говорить про масштабованість. Компоненти (мова програмування, операційні системи, бази даних, апаратне забезпечення тощо) масштабуватимуться чи ні залежно від того, яким чином взаємодіють ці системи. Масштабованість та доступність не з'являються з повітря. Тільки правильне проектування дає можливість легко замінити компонентів програмного рішення у разі потреби.
2. Проектування без розрахунку на помилку
3. Вертикальне масштабування замість розподілу навантаження
Багато продуктів все ще покладаються на реляційну базу даних (MySQL, Oracle, SQL Server і т.д.) як основне сховище. Замість сегментування клієнтів за безліччюневеликих баз даних (кожен хостинг з кількома клієнтами для підвищення ефективності витрат) багато компаній, як і раніше, покладаються на дороге та високопродуктивне обладнання для масштабування монолітної системи.
Подібне «рішення» зрештою призведе до збільшення витрат на транзакції та більшої шкоди у разі збою в міру зростання компанії. Крім того, ефективність капіталовкладень виявиться низькою, оскільки громіздка система простоюватиме поки що поступово не зросте навантаження. Зрештою, найбільша система виявиться недостатньо великою, і у вашого продукту все одно виникнуть проблеми. Згадайте eBay 1999 або PayPal в 2004 році.
4. Використання неправильних інструментів
Запросіть тесляра полагодити ваш санвузол, і він прийде з молотком. Ви, мабуть, не будете задоволені результатами. Це те саме, що попросити спеціаліста з баз даних допомогти з архітектурою продукту. Реляційна база даних, як і раніше, основна і часто оптимально підходить для зберігання рішень, що вимагають суворого дотримання вимог ACID або пов'язаних даних (наприклад, продукти, що показують організаційні ієрархії, ієрархічні каталоги продукції і т.д.). Тим не менш, тепер ми маємо безліч альтернативних варіантів для створення розподіленого зберігання в залежності від типу даних. Так, якщо у вас є дані формату JSON, сховище документів буде найкращим рішенням. Зберігання даних у природному форматі завжди має бути збалансовано з накладними витратами на впровадження та підтримку додаткових технологій.
Організаційні невдачі
5. Поділ за функціями
У минулому, коли ми створювали та продавали програмне забезпечення, роль функціональних менеджерів полягала у повній ізоляції функціональнихвідділів таким чином, щоб нейтралізувати всі фактори, що відволікають, і дозволити максимально зосередитися на виконанні завдання. Було добре, коли кожна команда мала вузькоспеціалізовану спрямованість, а результат роботи передавався на лінію збирання. Сьогоднішні SaaS-компанії роблять послугу, і зміни до рішення вносяться раз на два тижні, а іноді й кілька разів на день. Це зобов'язує product-менеджерів говорити з інженерами частіше, а інфраструктурних інженерів реагувати ще до початку кодування. Функціональна організація іноді призводить до зниження якості, повільного виходу на ринок, низького рівня інновацій та конфліктів між функціональними командами. Найкращі команди сьогодні - це багатопрофільні, автономні та контролюючі сервіс від зародження ідеї до підтримки (за дизайнерським принципом Вільяма Макдоноу "від колиски до колиски" для розвитку послуг). Якщо ви сумніваєтеся у цьому принципі, запитайте себе: «Що ми робимо під час кризи?». Майже завжди відповідь буде такою: «Збираємо людей із різних команд, закриваємо їх у кімнаті і просимо, щоб вони вирішили проблему». Якщо це важливо у кризу, то чому ми не робимо цього щодня?
6. Занадто великі команди
Ще одна важлива помилка у масштабуванні організації — наявність зайвої кількості людей, які працюють із одним кодом. Коли команда складає більш ніж 15-20 інженерів, зв'язки між ними та координація починають страждати. Розбіжності виникають у плануванні ресурсів, субординації та прийнятті рішень. Ці конфлікти займають відведений виробництва нового функціоналу час, що знижує цінність продукту клієнтам.
Ізоляція несправностей на службах (див. п. 2 про архітектуру) може створити природні поділу на продукті, які нейтралізують ці конфлікти.Добре, коли команда відповідає за кілька служб (логін, реєстрація, пошук), але дві команди не повинні відповідати за ту саму службу.
7. Невміння доглядати свій сад
Хороші керівники завжди засіюють, поливають і прополюють свій «сад» співробітників: залучають нові таланти (посів), розвивають членів команди (полив), а за потреби дозволяють їм піти (прополка). Для найкращого результату необхідно постійно оцінювати свою команду. Нам подобається аналізувати продуктивність працівника за трьома напрямками: майстерність, зростання та поведінка. Категорія вміння - це те, наскільки добре вони знають і виконують роль, для якої були найняті.
Збій процесу
8. Нездатність вчитися
Пророча фраза Сантаяна «Хто нездатний вчитися на помилках історії, приречений повторювати її» — вірна для організацій та продукції. Сервіс виявився недоступним в результаті збою, і якщо ви хочете тільки відновити його працездатність, то втрачаєте приголомшливу можливість зробити висновки і навчитися новому. Кожну невдачу слід розглядати як привід не повторювати помилок минулого. Потрібна самодисципліна, щоб згаяти час і провести ретельне розслідування. Якщо вважаєте, що причиною відключення вашого сервісу був апаратний збій, ви точно схибили. Продовжуйте ставити запитання «Чому?», доки не виявите основні причини в архітектурі, людях та процесах.
9. Віра в Agile як у панацею
Гнучка методологія розробки - велика річ, але її використання не вирішує проблем зі структурою команди (див. пункти 5 і 6 у розділі невдач з організацією) або бізнес-завданнями, такими як комунікації між продуктовим та торговим відділом. Розуміння Agile як частини бізнес-процесу, а не просто теорія розробки програмногозабезпечення дуже важливе для досягнення успіху. Нарешті Agile може виправити частину проблем, для вирішення яких вона призначена. Очікувати від неї гарантії отримання конкретних результатів у конкретні дати аналогічно очікуванням, що тесляр полагодить ваш санвузол (див. п. 4 в архітектурних помилках).
10. Навантажувальне та тестування продуктивності покажуть усі проблеми масштабування
Рекомендуємо книгу до прочитання. Автори книги не описали догму, але вказали на тонкощі, про які часом можуть забути навіть найкращі з нас, а саме:
- правильно підібрані та застосовані інструменти та методології;
- грамотний менеджмент у команді;
- опора на отриманий досвід.