Топ 10 грешки при системно мащабиране

Архитектурни грешки

1. Проектирайте изпълнението, но не и търсенето на архитектурно решение

Кой от следните подходи бихте използвали, за да опишете продуктовата си архитектура?

Вариант A:„Ние сме Java магазин, поддържан от GlassFish, Apache Felix с MySQL и MongoDB.“

Случай B:„Имаме 3-слойна архитектура с изолирани зони, които нямат синхронна комуникация помежду си за устойчивост на грешки. Постоянното съхранение на данни е комбинация от релационни и NoSQL бази данни, използващи вградена репликация с хоризонтално шардинг.

Правилен отговор "". Отговорът "А" описва по-добре изпълнението на архитектурата към даден ден, но не говори за мащабируемост. Компонентите (език за програмиране, операционни системи, бази данни, хардуер и т.н.) ще се мащабират или не в зависимост от това как си взаимодействат тези системи. Мащабируемостта и наличността не се появяват от нищото. Само правилният дизайн позволява лесна подмяна на компонентите на софтуерното решение, ако е необходимо.

2. Дизайн без грешка

Потъването на Титаник е един от най-известните примери за грешка в дизайна, която струва цял проект: отделенията на кораба не са били напълно изолирани и когато корабът се е претърколил напред, водата просто е преляла през преградите, докато не е наводнила всичко

3. Вертикално мащабиране вместо балансиране на натоварването

Много продукти все още разчитат на релационна база данни (MySQL, Oracle, SQL Server и др.) като основно хранилище. Вместо да сегментирате клиентите на множествомалки бази данни (всеки хостинг с множество клиенти за ефективност на разходите) много компании все още разчитат на скъп и високопроизводителен хардуер за мащабиране на монолитна система.

Такова „решение“ в крайна сметка ще доведе до по-високи транзакционни разходи и повече щети в случай на провал, докато компанията расте. В допълнение, възвръщаемостта на инвестицията ще бъде ниска, тъй като обемистата система ще бъде неактивна, докато натоварването постепенно се увеличи. В крайна сметка най-голямата система няма да е достатъчно голяма и вашият продукт пак ще има проблеми. Помислете за eBay през 1999 г. или PayPal през 2004 г.

4. Използване на грешни инструменти

Помолете дърводелец да поправи банята ви и той ще дойде с чук. Вероятно няма да сте доволни от резултатите. Това е все едно да помолите специалист по база данни да ви помогне с продуктовата архитектура. Релационната база данни все още е основната и често е най-подходяща за съхраняване на решения, които изискват стриктно съответствие с ACID или свързани данни (напр. продукти, показващи организационни йерархии, йерархични продуктови каталози и т.н.). Сега обаче имаме много алтернативи за създаване на разпределено хранилище в зависимост от типа на данните. Така че, ако имате JSON данни, тогава съхранението на документи е най-доброто решение. Съхраняването на данни в собствен формат винаги трябва да бъде балансирано спрямо режийните разходи за внедряване и поддържане на допълнителни технологии.

Организационни пропуски

5. Разделяне по функция

В миналото, когато създавахме и продавахме софтуер, ролята на функционалните мениджъри беше напълно да изолират функционалнитеотдели по такъв начин, че да неутрализира всички разсейвания и да позволи максимално съсредоточаване върху задачата. Беше добре, когато всеки екип имаше тясно специализирана насоченост и резултатът от работата беше прехвърлен на поточната линия. Днешните SaaS компании произвеждат услуга и промените в решението се правят на всеки две седмици, а понякога и няколко пъти на ден. Това задължава продуктовите мениджъри да говорят по-често с инженерите, а инфраструктурните инженери да отговарят, преди дори да започне кодирането. Функционалната организация понякога води до намалено качество, бавно време за пускане на пазара, ниска иновация и конфликт между функционални екипи. Най-добрите екипи днес са мултидисциплинарни, автономни и контролират услугата от идеята до поддръжката (следвайки принципа на дизайна на Уилям Макдона „от люлка до люлка“ за развитие на услугата). Ако се съмнявате в този принцип, запитайте се: „Какво правим по време на криза?“. Почти винаги отговорът ще бъде: „Събираме хора от различни екипи, заключваме ги в една стая и ги молим да решат проблема“. Ако това е важно по време на криза, тогава защо не го правим всеки ден?

6. Твърде големи отбори

Друга голяма грешка при мащабирането на организация е твърде много хора, работещи върху един и същ код. Когато един екип се състои от повече от 15-20 инженери, комуникацията между тях и координацията започват да страдат. Възникват разногласия при планирането на ресурсите, подчинението и вземането на решения. Тези конфликти отнемат времето, определено за производството на нова функционалност, което намалява стойността на продукта за клиентите.

Изолирането на грешки в услугите (вижте точка 2 относно архитектурата) може да създаде естествени разделения в продукта, които неутрализират тези конфликти.Добре е, когато един екип отговаря за няколко услуги (вход, регистрация, търсене), но два екипа не трябва да отговарят за една и съща услуга.

7. Неполагане на грижи за градината си

Добрите лидери винаги засяват, поливат и плевят градината на своите служители: привличат нови таланти (засяване), развиват членовете на екипа (поливане) и ги пускат, когато е необходимо (плевене). За най-добър резултат трябва постоянно да оценявате екипа си. Обичаме да анализираме представянето на служителите в три области: умения, растеж и поведение. Категорията на уменията е колко добре познават и изпълняват ролята, за която са наети.

Неизправност на процеса

8. Неспособност за учене

Пророческата фраза на Сантаяна „Тези, които не са в състояние да се учат от грешките на историята, са обречени да я повтарят“ е вярна за организациите и продуктите. Услугата беше недостъпна в резултат на повреда и ако искате само да я възстановите до работоспособност, тогава пропускате невероятна възможност да учите и да научавате нови неща. Всеки провал трябва да се разглежда като извинение да не се повтарят грешките от миналото. Необходима е самодисциплина, за да отделите време за провеждане на задълбочено разследване. Ако смятате, че хардуерен срив е причината за спирането на вашата услуга, определено сте пропуснали целта. Продължавайте да питате „Защо?“, докато не откриете първопричините в архитектурата, хората и процесите.

9. Вяра в Agile като панацея

Методологията за гъвкаво развитие е страхотна, но използването й не решава проблеми със структурата на екипа (вижте точки 5 и 6 в раздела за организационни неуспехи) или бизнес проблеми като комуникацията между продуктовите и търговските отдели. Разбиране на Agile като част от бизнес процес, а не само теория за разработка на софтуерсигурността е много важна за успеха. И накрая, Agile може да коригира някои от проблемите, които е предназначен да решава. Очакването от нея да гарантира конкретни резултати на определени дати е подобно на очакването дърводелец да поправи банята ви (вижте точка 4 в архитектурни грешки).

10. Тестовете за натоварване и производителност ще покажат всички проблеми с мащабирането

Препоръчваме книгата за четене. Авторите на книгата не са описали догмата, но са посочили тънкостите, които дори най-добрите от нас понякога могат да забравят, а именно:

правилно подбрани и приложени инструменти и методологии;
компетентно управление на екипа;
надграждайки предишен опит.

Такава триада достатъчна ли е за успеха на софтуерен продукт?