Помня времената, когато сървърите ни стояха в съседната стая. Пипахме ги с ръцете си и всичко около тях беше наша грижа. После облакът навлезе лека-полека. Преместихме сървърите в него. После около облака започнаха да се появяват все повече услуги, резервни копия, мониторинг, сигурност, и днес почти всичко, което ни трябва, е на един клик разстояние. За мен въпросът сървър в съседната стая или облак изобщо не стои. Стои въпросът колко добре си подредил инфраструктурата си в него.
В работата ми има много различни дейности за вършене ежедневно. Едно от най-приятните е да градя софтуерни системи. Когато седна над облачната им инфраструктура, изпитвам голямо удовлетворение и то ме кара да я подобрявам постоянно. Днес едно малко подобрение, утре друго, следващата седмица трето. Ако основата е проектирана правилно, тези малки подобрения не остават отделни кръпки. Надграждат се едно върху друго като решетка и с времето стават здрава конструкция, върху която може да стъпи цял продукт.
Сега подготвяме платформата, на която стои BoroBit, за технически преглед от AWS. За нас това е естествена стъпка, защото скоро ще предлагаме част от BoroBit и през AWS. Преди да я пуснем за преглед, седнах и я прегледах сам, по същите шест стълба и със същите въпроси, по които AWS проверява системите. Не е първата система, която преглеждам така, но е нашата и за нея мога да пиша открито. А всичко тук важи за всяка облачна инфраструктура.
Ако трябва да го кажа с едно изречение, добрата облачна инфраструктура е замислена още от първия ден за години напред и в нея е помислено и за шестте стълба на добрата архитектура.
Къде боли
Малко собственици мислят за системата си в стълбове. Мислят за това, което ги притеснява.
Всяко пускане на нова версия е стрес. Ъпдейтите чупят нещо, което досега е работило. Всичко зависи от един човек. Идват GDPR и NIS2, страхът от пробив и въпросът кой до какво има достъп. Ако нещо падне, никой не е сигурен дали има резервно копие и дали от него изобщо може да се възстанови. В най-натоварения ден системата се бави. Сметката за облака расте всеки месец. А най-големите фирми вече са длъжни да отчитат и екологичен отпечатък - по-малките не са, но големите им клиенти може да ги питат.
Индустрията отдавна е подредила тези притеснения. AWS ги събира в шест стълба в рамката си Well-Architected. Google има същите шест, Microsoft пет от тях. Всяка от болките по-горе попада в някой от стълбовете, независимо за какво служи системата и при кой доставчик е. Стълбовете важат дори за сървъра в офиса. Нито един от въпросите не пита къде е машината.
А у нас облакът още е по-скоро изключение. По данни на Евростат за 2025 г. платени облачни услуги ползват 17,8% от фирмите с десет и повече служители, при 52,7% средно за ЕС. По това сме последни в Европейския съюз. Това значи, че за повечето фирми най-важните решения тепърва предстоят. И могат да се вземат правилно от самото начало.
Минавам стълбовете един по един. Какво значи всеки на човешки език, как го правим ние в нашата система и какво да попиташ за твоята.
Новата версия не е събитие
Оперативно съвършенство
Тук става дума за всекидневната работа със системата. Как пускаш промени, как разбираш, че нещо не е наред, и какво правиш тогава.
Помня времето, когато пускането на нова версия беше ръчно. В една от системите, за която се грижим от години, работят заедно над двайсет микросървиса. Представи си всеки от тях да го подготвиш, да го пуснеш и да го провериш на ръка, после следващия, и така двайсет пъти. Първото, което автоматизирахме там, беше точно пускането на новите версии. Продуктивността ни се вдигна с пъти и разтоварихме екипа от огромна ръчна работа.
Днес при нас нова версия се пуска с два клика. Последно добавихме подобрение в паричните потоци на BoroBit и го пуснахме до потребителите за няколко минути. И не на сляпо, защото системата сама проверява, че това е точно версията, която трябва, и че стига точно там, където трябва. Билдът е същият, който вече е работил в тестовата среда. Не се сглобява наново, затова при потребителите стига точно това, което сме тествали. Предишната версия остава активна и ако нещо не е наред, се връщаме към нея. Всичко това е записано в код, а не в главата на един човек. А освободеното време отива в продукта, не в сървърите. Опитваме се да постигаме все повече с малко хора, с автоматизация и AI, и облакът е част от този път.
Автоматизацията обаче стъпва върху правилното проектиране. Ако не е ясно какво пускаш и къде, просто ще повтаряш същата грешка по-бързо. Облакът не те прави бърз. Подреденият облак те прави бърз. А под бърз имам предвид колко скоро нещо ново стига до хората, които го чакат.
Колко нерви ти струва едно пускане? Ако нещо се обърка, за колко време се връщаш назад? И ако човекът, който обикновено пуска, утре го няма, може ли някой друг?
Знаеш кой до какво има достъп
Сигурност
Това, че системата е в облака, не значи, че е сигурна.
Облакът дава сигурност на два етажа. Доставчикът пази самия облак, сградите, машините, мрежата. Ти пазиш това, което слагаш в него, достъпите, настройките, данните. Ако твоят етаж е проектиран правилно, голяма част от тежестта поема доставчикът. Ползваш ли готови управлявани услуги, той се грижи и за машините под тях, и за ъпдейтите им. Но никой доставчик не може да те опази от врата, която сам си оставил отворена.
Една малка фирма не може да си позволи охрана на центрове за данни, криптиране и копия на различни места. При банките и финансовите институции към това идват и регулациите. За екип като нашия изборът е лесен. Влизаме в дълбочина в това, в което сме добри, в нашата система. За облака ползваме експертизата на инженери, които го градят от двайсет години. Не можеш да правиш и двете на едно и също ниво. Има фирми, които тръгват да правят всичко сами, и след време се вижда, че не работи. Топлата вода е открита, ползвай я.
При нас тестовата и работната среда са в отделни акаунти, а управлението на инфраструктурата е в трети. Автоматична проверка спира всяка промяна по инфраструктурата, ако е насочена към грешния акаунт. Платформата е проектирана така, че регулиран партньор да получи своя отделна среда, а кодът, който не му трябва, изобщо да не влиза в неговата версия. Каквото го няма, не може да бъде пробито. Данните са криптирани там, където се съхраняват. А ако фирмата ти е в обхвата на NIS2, отговорността за това вече е и лично на ръководството.
Кой има достъп до системата и до данните ти? Ще разбереш ли, ако някой си е тръгнал, а достъпът му е останал? Ако утре клиент или регулатор поиска да види какво правиш за сигурността, имаш ли какво да му покажеш?
Ако нещо падне, знаеш как да го вдигнеш
Надеждност
Това е въпросът, който никой не обича да си задава. Ако нещо падне, какво става и за колко време всичко пак работи?
У нас почти половината фирми нямат копие на данните си на отделно място. Имат го 54,6% при 79,2% средно за ЕС (Евростат, 2024). Но и „имаме бекъп“ е само началото на отговора. Важното е кога за последно някой е възстановил нещо от него и колко време е отнело.
Тук има две решения, които трябва да вземе бизнесът. Колко време можеш да си позволиш да не работиш. И колко от последните данни можеш да си позволиш да загубиш. ИТ хората ги наричат RTO и RPO. За една система отговорът е дни, за друга минути, и от него зависи какво трябва да се изгради и колко ще струва.
При нас базата има дневни и седмични резервни копия, които пазим седмици назад, и сме проверявали, че от тях наистина се възстановява. През юли вдигнахме цялата среда наново от код, когато я преместихме в новата ни структура с отделни акаунти. Частите на платформата са разделени и работят асинхронно. Ако системата на някоя банка временно не отговаря, останалата част от платформата продължава да работи нормално. Ако една и съща заявка дойде два пъти, например при прекъсната връзка, операцията се записва само веднъж. При пари няма място за двойни записи. А ако някоя част от системата спре да работи, тя се рестартира автоматично, без никой да се намесва.
Кога за последно си възстановявал от резервно копие наистина, а не на теория? Ще разбереш ли, че нещо не работи, преди да ти звънне клиент? Ако утре загубиш цялата среда, за колко време я вдигаш наново?
Издържа в най-натоварения ден
Ефективност на производителността
Тук въпросът е дали системата издържа, когато всички влязат наведнъж. В края на месеца или в деня на кампанията.
Бяхме в един от екипите зад система за голямо спортно събитие. Представи си над сто хиляди души на един стадион. В облака капацитетът се вдига многократно за няколко часа, а след събитието се връща обратно и плащаш само за това, което си ползвал. А сега си го представи без облак. Купуваш сървъри за един ден в годината и после мислиш какво да ги правиш.
Но облакът мащабира само това, което е проектирано да се мащабира. Ако всичко чака една претоварена база или една бавна външна услуга, още машини няма да помогнат. Тясното място е добре да го намериш преди големия ден, не по време на него.
Другото голямо предимство е, че почти всяко нещо, което вече го има в света като услуга, в облака можеш да го ползваш още днес. Затова навсякъде, където може, ползваме готови управлявани услуги, вместо да поддържаме свои. Базата ни е при специализиран доставчик, приложенията вървят без сървъри, за които да се грижим, а сайтовете се сервират от точката на мрежата, която е най-близо до човека.
Знаеш ли кое ще забави системата ти първо, ако натоварването се удвои? Проверявано ли е, или ще разбереш в деня, в който се случи?
Знаеш за какво плащаш
Оптимизация на разходите
Сметката за облака расте - това е една от най-големите болки и страхове, когато говорим за облачна инфраструктура. Не твърдя, че облакът е евтин. Твърдя, че алтернативите не са по-евтини. Проектиран правилно, облакът не е по-скъп от тях, а за стойността, която дава, е най-доброто решение. Пак казвам, проектиран правилно.
Сървърът в офиса също не е безплатен. Купен е, а после остарява, и той, и софтуерът му. Някой трябва да го обновява, да го следи и да сменя части, а това време също струва пари. В облака хардуерът не е твоя грижа и нова машина се пуска за минути.
В облака плащаш за това, което си пуснал. Ако е пуснато правилно, това е точно каквото ползваш. Ако не е, плащаш и за забравеното. В проучване на Flexera фирмите сами оценяват, че около 29% от парите им за облак отиват на вятъра. Затова сметката е въпрос основно на правилно проектиране и правилно изполване на ресурсите в облака.
Един малък пример. Преди сайтът ни беше на нает виртуален сървър, който по същество пак е облак. Днес inabit.eu е на S3, CloudFront и CodeBuild и ни струва жълти стотинки на месец. Същата логика важи и за платформата. Една обща среда обслужва много клиенти, а отделна правим само където наистина трябва. При нас този, който проектира системата, и този, който плаща за нея, е един и същ, и това много помага.
Имам една поговорка, която често използвам. Не съм богат да купувам два пъти. Ако търсиш евтино, няма да стигнеш далеч, защото евтиното излиза много скъпо.
Знаеш ли за какво точно плащаш всеки месец? Не общата сума, а за какво. Има ли човек, който може да ти обясни защо сметката се е променила? И плащаш ли за нещо, което никой не ползва?
Не плащаш за това, което не ползваш
Устойчивост
Шестият стълб е най-новият. Говори за хардуера и тока, които харчи системата ти. Големите фирми вече го пишат в отчетите си, но въпросът е валиден за всеки.
Сървърът в шкафа работи денонощно, дори когато никой не го ползва. В облака една машина обслужва много хора, а ресурсът се пуска и спира според нуждата. Каквото е добро за оптимизиране на разходите, обикновено е добро и за тока. Изключваш това, което не работи. Не пазиш данни без нужда. Не държиш среди, за които никой не помни защо съществуват.
Ние нямаме нито един собствен сървър. Ползваме управлявани услуги. Повечето клиенти работят в една обща среда, а отделна вдигаме само за големите, които наистина имат нужда от нея.
Колко от това, което плащаш и поддържаш, използваш наистина? Има ли среди, които още работят, и данни, които се пазят, а никой вече не ги ползва?
Какво научих
Всеки ден в работата взимаш решения и някои от тях няма да са правилни. Важно е основната посока да е вярна и ежедневните решения да я следват.
Моята първа грешка беше още в началото. Преди пет години сложихме работната среда на BoroBit в САЩ. Не че е проблем. Просто ни принуди да поддържаме допълнителни споразумения за защита на данните, които иначе нямаше да ни трябват, защото потребителите ни са тук, в Европа. Ако започвах сега, първо щях да реша къде да стоят данните, а после всичко останало. Да ги местиш после е много по-трудно.
Облакът е втори живот на софтуера. Поддържа се с код, развива се и се подобрява всеки ден, точно като продукта над него. Това не са просто едни сървъри, които си работят и толкова. Те са основата на продукта, но са си отделна, паралелна вселена. Затова времето, вложено в началото в архитектурата на системата и на облака под нея, се връща с годините с пъти. Когато започвахме BoroBit, бях наясно с това и отделих време да направим системата така, че да може да се развива с години. Още тогава избрахме готови управлявани услуги вместо собствени сървъри. Днес това ни позволява да делегираме. За машините, ъпдейтите им, мрежата и хардуера се грижи доставчикът на облака, а ние се грижим за продукта. Подреденият облак расте, поема пикове и се възстановява.
И още нещо. Често правиш нещата както трябва, но не ги записваш. Поддържаме софтуер и на финансови институции, не само нашия. Когато дойде DORA, се оказа, че повечето процеси ги имаме. Трябваше просто да ги опишем. Прегледът на нашата платформа ми показа същото. Много неща правим правилно, но живеят в главите ни. Показа ми и няколко неща, които ще направим по-добре.
В България само 13,7% от фирмите имат описани мерки за ИКТ сигурност, при 35,5% средно за ЕС (Евростат, 2024). Мисля си, че много от тези фирми все пак правят нещо, за да пазят системите и данните си. Просто никой не го е записал като правила. А това не е дребна подробност. Незаписаното не можеш да го предадеш на друг и не можеш да го покажеш, когато партньор или регулатор го поиска.
Как да провериш, без да си технически човек
Не е нужно да си технически човек, за да разбереш в какво състояние е системата ти. Въпросите, които съм маркирал под всеки стълб, са началото. Следващата стъпка е разговор с човека, който се грижи за системата ти.
Не го питай дали всичко е наред. Отговорът почти винаги ще е да. Помоли го да ти покаже три неща. Последното възстановяване от резервно копие и колко време е отнело. Списъка на хората и системите, които имат достъп. И как се пуска нова версия, стъпка по стъпка. Който си е свършил работата, ще ти ги покаже веднага.
Ако системата ти е в AWS, има и безплатен инструмент за това, Well-Architected Tool. Минава през същите шест стълба, а Microsoft има подобен преглед за Azure. Въпросите в инструмента на AWS са 57. Попитай го и дали е минавал системата ви през този инструмент. Ако не е, препоръчвам да го направи.
Доверието
Ако фирмата ти не е софтуерна, а системата ти е в облака или скоро ще бъде там, облакът за теб е нещо, което не познаваш отблизо. Знаеш, че е сравнително сложно, и знаеш, че ти трябва някой, на когото да се довериш. Накрая всичко опира до доверието.
Дали твоят ИТ човек или агенция го прави правилно, най-добре знаеш ти. За мен хората са най-важни. Колко време работиш с тях? Какво ти казва интуицията? Тя почти никога не лъже. Погледни и по колко проекта са работили, колко дълго остават при клиентите си и какво казват за тях другите. Договорите са важни, но не са единственото, заради което бих пуснал някого в системата си.
Когато някой претупа работата си или я направи през пръсти, това ме ядосва. Но в инфраструктурата е особено коварно, защото дълго време не си личи. Системата си работи и всички са доволни. Проличава в деня, в който нещо падне, в който дойде пик или в който някой поиска да види какво правиш за сигурността.
Ние се стараем да градим партньорствата си на доверие. Например с партньор в САЩ работим от дванайсет години. За това време заедно сме се грижили за три-четири системи. Последната е на шест години и още я развиваме. Гледаме я като малко бебе. Когато се грижиш за една система с години, живееш с последствията от собствените си решения. Така научаваш какво значи добра инфраструктура.
За мен добрата инфраструктура е тази, върху която можеш да градиш с години.
Петьо Стоянов
Inabit