Балі стартапаў: як правільна развіваць ІТ-інфраструктуру
Калі верыць статыстыцы, выжывае толькі 1% стартапаў. Разважаць аб прычынах такога ўзроўню смяротнасці не будзем, гэта не наша справа. Лепш раскажам, як павысіць верагоднасць выжывання з дапамогай пісьменнага кіравання ІТ-інфраструктурай.
Варта ўдакладніць, што пад стартапамі мы маем на ўвазе не кавярню ці інсектарый у гандлёвым цэнтры. Мы пра тэхналагічныя стартапы – пра тых, каму не дае спакою поспех GitHub, Uber, Slack, Miro і інш.
У стартапаў заўсёды маса праблем, якія мяшаюць стрэліць: ад недастатковых інвестыцый да непрапрацаванай бізнэс-мадэлі. У гэтым жа шэрагу, як не дзіўна, і праблема з першымі поспехамі.
Першыя поспехі - зло для стартапераў, якія пераацэньваюць свае магчымасці, асабліва фінансавыя і кадравыя. Пасля закрыцця першых паспяховых кейсаў у такіх аптымістаў з'яўляецца жаданне неадкладна пашырыцца: зняць яшчэ адзін офіс, набраць у каманду новых прадаўцоў, распрацоўшчыкаў, а заадно - маштабаваць бэкенд (ды так, каб з запасам). Тут адразу праяўляецца праблема №1.
Людзі ў стартапе робяць тое, што не ўмеюць
І не робяць тое, што патрабуецца для развіцця стартапа. Растлумачым.
У кожным стартапе павінны быць зачыненыя як мінімум тры ролі:
айцішнік (або тэхнолаг);
прадавец (або маркетолаг);
візіянер (ці прадпрымальнік, які яшчэ і нярэдка інвестар).
Часта гэтыя ролі змешваюцца. Напрыклад, стартапер - гэта айцішнік, які ў дадатак вымушаны прадаваць. Ён ніколі не прадаваў і робіць гэта як умее. Такі стартап - род злаякаснай крос-функцыянальнай каманды.
Але дапусцім, стартапу пашанцавала: ёсць каму прадаваць, і ІТ-спецыяліст займаецца сваім справамі. Аднак рэдкі айцішнік сумяшчае ў сабе розныя кваліфікацыі: распрацоўшчыка, тэсціроўшчыка, адміністратара, інжынера-архітэктара. А калі і сумяшчае, то ці наўрад аднолькава добра. Ён можа разбірацца ў прамежкавым ПЗ, а ў працы хмарных сэрвісаў і ПЗ для віртуалізацыі – не вельмі.
Калі бэкэнд пашыраецца, нагрузка на айцішніка ўзрастае. Нешта пачынае "прасядаць". Горш за ўсё, калі гэта крытычнае для стартапа кірунак, напрыклад распрацоўка прадукта. І вось ужо чалавеку даводзіцца працаваць звышурочна, а часам і кругласутачна.
Перагруз з-за недахопу людзей і кваліфікацый - характэрная асаблівасць большасці стартапаў, следства таго, што людзі займаюцца не тым, чым трэба.
Усе сэрвісы разгортваюцца на адной віртуальнай машыне
Стартапы часта, зыходзячы з уласных уяўленняў аб эканоміі, размяшчаюць на адной ВМ асяроддзя распрацоўкі, базы дадзеных, вэб-сервер, маніторынг і гэтак далей. Спачатку ўся гэтая гаспадарка працуе больш-менш ніштавата. Праблемы пачынаюцца, калі трэба маштабавацца.
Маштабуюцца стартапы звычайна вертыкальна. Гэта значыць проста павялічваюць колькасць CPU, аб'ём RAM, дыскаў і т. д. - гэта класічны маналітны падыход, негатыўны эфект якога ў нейкі момант становіцца незваротным. Калі маладая кампанія расце, на пэўным этапе цэннік за нарошчаныя рэсурсы падскоквае да непад'ёмнага ўзроўню. Аптымізаваць інфраструктуру пры гэтым можна ўжо толькі адным спосабам: сабраць яе нанова.
Як дапамагае managed IT
Для такога тыпу праектаў у нас ёсць паслуга класа managed services. managed DevOps.
Заказчык атрымлівае «са скрынкі»:
падрыхтоўку неабходных асяроддзяў для працы: dev, test, prod;
настроеныя працэсы CI/CD;
падрыхтаваны інструментарый для каманднай работы: таск-трэкеры, сістэмы кантролю версій, дэплою, тэсціравання і інш.
На ўзроўні інфраструктуры і інструментаў усім стартапам трэба прыкладна адно і тое ж. Калі параўнаць венчурны рынак з золатаздабычай, Managed Services Provider (MSP) падае новыя, якасныя прылады: кірхі і каляскі, якія не ламаюцца, карты, якія не хлусяць. Старальніку застаецца толькі выбраць месца, дзе капаць.
Плюсы managed IT
Managed IT – гэта комплексная паслуга, якая закрывае шэраг абавязковых патрэб.
На старце мы даем неабходныя і настроеныя рэсурсы для працы, росту і праверкі гіпотэз.
Дакладна можам сказаць, як будзе павялічвацца кошт пры маштабаванні, таму што ведаем, што ключавая метрыка - збежнасць эканомікі стартапа.
Кансультуем, каб зэканоміць стартапу значная колькасць чалавека-гадзін. Таксама можам дапамагчы з разлікамі юніт-эканомікі праекту.
Дзелімся best practices рынку. Людзі ў ITGLOBAL.COM, працавалі з немалой колькасцю стартапаў. Многія з гэтых стартапаў на штомесячным абслугоўванні. Гэта дазваляе нам сабраць разам лепшыя (і горшыя) прыклады і дзяліцца досведам з кліентамі.
Два выпадкі з практыкі
Па NDA мы не можам называць канкрэтныя кампаніі, але сферу і прадукт – так.
Сфера: фінтэх/рытэйл
Прадукт: маркетплейс
Праблемы:
У ланцужку CI/CD адсутнічала тэставанне. Даданне выдаленых тэсціроўшчыкаў толькі ўскладніла працэс зборкі.
Распрацоўнікі працавалі адначасова на адным dev-серверы без вылучаных асяроддзяў у кантэйнерах.
70% часу распрацоўшчыкаў сыходзіла на адны і тыя ж дзеянні з рэлізу ў рэліз. Хуткасць распрацоўкі была вельмі маруднай.
Інфраструктура была разгорнута на лоўкостэр-хостынгу ў Нямеччыне (т. е. ні хуткасці, ні надзейнасці).
Такое, дарэчы, назіраецца ў кожным першым праекце.
Рашэнне – managed DevOps: укаранілі працэсы CI/CD, наладзілі карэктнае тэсціраванне і маніторынг, умяшаліся ў распрацоўку на ўзроўні бізнес-працэсаў, перанеслі інфраструктуру на прадукцыйныя серверы ў дата-цэнтр ўзроўню Tier III.
Вынік:
вырасла эфектыўнасць распрацоўкі: новыя фічы і абнаўленні сталі выходзіць хутчэй пры меншых працавыдатках;
як следства, знізілася кошт працэсу распрацоўкі ў цэлым;
інфраструктура стала гнуткай: кліент можа хутка маштабавацца як уверх, так і ўніз;
выдаткі на managed DevOps, па дадзеных кліента, акупіліся ўжо праз паўгода.
Сфера: вэб-рэклама
Прадукт: ІІ-платформа для аўтаматызацыі рэкламных кампаній
Праблемы:
бэкенд на старым «жалезе», у дата-цэнтры з нізкім узроўнем адмоваўстойлівасці;
адсутнасць рэгулярных бэкапаў;
маналітная інфраструктура.
Рашэнне – managed IT: перанеслі інфраструктуру на топавы «жалеза», наладзілі кластар Galera для гарызантальнага маштабавання, паказалі, як будзе размяркоўвацца нагрузка на ВМ, наладзілі бэкапы і маніторынг. Цяпер, акрамя абслугоўвання, актыўна кансультуем, у тым ліку па DevOps.
Вынік:
інфраструктура стала мікрасэрвіснай: кошт пашырэння значна знізілася, а магчымасці па маштабаванні, пры тых жа выдатках, - выраслі;
павялічылася надзейнасць і бяспека інфраструктуры;
распрацоўшчыкі перайшлі з каскаднай мадэлі зборкі на CI/CD, што дапамагло знізіць выдаткі;
фінансавая выгада ад managed IT, па дадзеных кліента, стала відавочнай адразу.
Заключэнне
Выжывальнасць стартапаў шмат у чым залежыць ад поспеху. Адзін стартапер можа патраціць грошы на дарагое абсталяванне і не атрымаць з гэтага нічога. Іншы стане паспяховым нават з нікуды не вартыя ІТ-інфраструктурай - гэтак жа, як золаташукальнікаў знаходзіць залатую жылу, варочаючы старой кіркай.
Тым не менш, сучасныя інструменты, практыкі і прафесійныя кадры, якія дае Managed IT-правайдэр, значна зніжаюць верагоднасць няўдачы.