Един уебсайт може да изглежда перфектно — и въпреки това да се счупи за минути след пускане на production среда.
В практиката си сме виждали:
- счупени онлайн магазини след необмислен ъпдейт;
- изгубени поръчки;
- паднали сайтове без бекъп;
- домейни, които не принадлежат на реалния собственик на бизнеса.
В тази статия ще покажем едни от най-често срещаните грешки при production уебсайтове — и как да ги избегнете.
В практиката ни сме се срещали с най-различни казуси – от безобразно изработени до абсолютно хаотично поддържани.
В този материал ще предложим и някои мерки за превенция, както и често допускани грешки на продукшън среда.
Но първо да дефинираме терминологията.
Какво е продукшън среда?
Продукшън среда е, когато вашият уебсайт е готов и го пуснете „на живо“ да работи за реални клиенти. Това се отнася за всякакъв вид уебсайтове – представителни, каталози, онлайн магазини, тип „услуга“ /SaaS платформа/ или други.
Това е ключов етап при стартиране на един проект, защото той маркира финализиране на неговата основна разработка.
Редно е преди пускането за реални клиенти да се проведат редица тестове, които да удостоверят:
- Коректна работа на уебсайта на настолна и мобилна версия.
- Бързо зареждане от гледна точка на потребителя – като кликне на меню, влезе в продукт или в статична страница – бързо ли се отваря сайтът?
- Снимките в уебсайта компресирани ли са – например към .avif или .webp формат /тези снимкови формати са предназначени за уеб като .avif е най-новият и най-добрият към момента/ – по-бързи снимки = по-малко трафик = по-бързо отваряне на сайта = по-харесван от търсачки и трасиращи алгоритми /включително на AI услуги/
- Успешно ли минават поръчките/запитванията? //препоръка, активация на SMTP на мястото на PHP MAIL, повече детайли тук/
- Осигурени ли са достатъчно системни ресурси за адекватна работа на уебсайта? Например чрез задаване в конфигурация на PHP & wp-config.php
- Коректно и адекватно ли е настроен PHP и ползва ли се актуална/нова версия, стабилна и с правилна конфигурация?
- Защитен ли е уебсайтът от СПАМ атаки?
- Защитен ли е админ панелът на уебсайта от неоторизиран достъп?
- Въведени ли са защити на вътрешните ресурси и съотвени рестрикции в .htaccess?
- Има ли твърде много администратори с лесни пароли за достъп? Излишните да се орежат и да се понижат правата им.
- Работят ли интеграциите с външни софтуерни платформи/услуги?
- Конкретно за е-магазини: работят ли куриерите и разплащанията? Лесна и удобна ли е количката и касата за клиентите?
- Всичко адаптирано ли е на български език?
- Ако има мултиезичност, тя успешно ли се превключва и всичко преведено ли е – в това число и системни съобщения?
- И други.
Бележка: не е възможно да изброим изчерпателно всички възможни проверки, които да се извършат преди пускане на уебсайт на продукшън среда, защото те зависят от спецификата на проекта.
Но след като се удостовери, че проектът работи коректно и съгласно очакванията, и заданието – същият може да се „пусне“.
Тогава започва период на дошлифоване
Винаги по проектите излизат дребни неща, които да се дошлифоват в движение и това е нормално.
Например, на конкретен браузър даден бутон може да излиза малко по-встрани, отколкото трябва.
Или пък дадена анимация да не се показва идентично на всички браузъри. Това са нормални неща, дребни – но те се оправят в най-добрия случай за минути, в по-лошия – за малко повече, от разработчика, който следва да се увери, че системата работи коректно под всички популярни браузъри.
И ето, вече сме в продукшън. Имаме разработена, публикувана, стабилна система.
Какво да правим, и да не правим – на нашия продукшън проект?
1. Никога не ъпдейтвайте уебсайт на жива среда
Това е изключително лоша практика. При актуализация на система на продукшън среда има опасност нещо да се счупи и то по начин, по който ще бъдат необходими часове или дори дни за неговата корекция – особено ако няма резервно копие.
Дори ъпдейтите да изглеждат незначителни – препоръчваме винаги същите да се правят на тестова среда /на копие на уебсайта, при професионалните агенции това става на dev сървър/. По този начин дори нещо да се счупи – няма проблем. Имате цялото време на света да го оправите, защото титулярния продукшън сайт си работи, няма прекъсваемост, влизат поръчки и запитвания, а Вие ъпдейтвате на тестова среда. Идентифицирайте счупеното нещо. Намерете решение. Прилагате го и тествате. И когато всичко е наред – обявявате проекта за ъпдейтнат.
2. Никога не изтривайте веднага файловете и базата данни на стария сайт
Виждали сме това доста пъти – обновява се сайтът, старият веднага се изтрива, новият се качва, но хоп – появява се проблем, който не е забелязан, а е съществен.
Или пък липсват данни – например поръчки, потребители, продукти, съдържание или друго. Ако сте изтрили стария сайт и нямате резервно копие – няма как да възстановите тези данни, което вече е проблем.
Ето защо препоръчваме следния подход:
– сайтовете обикновено са в папка с името ‘public_html’ – не я трийте, преименувайте я на ‘public_html_old’
– базата данни, която се е използвала за стария сайт – не я пипайте, не я трийте и не я модифицирайте. Просто я оставете.
– за новия сайт направете нова папка – качете файловете в нея. За новия сайт направете нова база – работете с нея.
– след което инсталирайте системата, тествайте и вижте дали всичко е както трябва – ако сте работили правилно на тестовата среда, би следвало да е окей.
Но! Ако случайно се окаже, че има нещо критично, което не е било забелязано – буквално в рамките на минути можете да включите /временно/ стария сайт, който работи пълноценно, да отстраните проблема по актуализираната система – след което да я публикувате.
По този начин се гарантира нулева или минимална прекъсваемост /2-3-5 минути/
Ние се стремим прекъсваемостта да е нулева и в повечето случаи успяваме да го постигнем.
3. Никога не правете големи нови разработки на продукшън уебсайт
Особено когато става дума за куриери, разплащания, големи интеграции с външни услуги.
Ако искате да изпробвате алтернативен куриерски модул, да речем, вместо официалния на дадения куриер – направете копие на уебсайта, инсталирайте новия модул, тествайте, вижте как работи, вижте има ли някакви проблеми. По същия начин е редно да се процедира и с разплащанията в системата.
Също, при големи нови разработки в процеса на тяхната направа може сайта временно, нещо да не работи, нещо да се счупи – i това е нормално. Както когато ремонтирате двигател на автомобил – в момента на ремонтирането няма как да го използвате. Но именно поради това е важно да се работи на тестова среда – тя е вашата мека възглавница. Дори нещо да стане, дори цялата система да падне – няма проблем. Титулярния сайт работи, приема поръчки и обслужва клиенти. А вие имате цялото време и спокойствие – да отстраните казуса.
4. Никога не правете компромис с хостинг доставчика
Една система, колкото и добре да е направена, може да се счупи или да не работи оптимално, ако не ѝ бъдат осигурени съответните ресурси.
В практиката ни сме имали много сериозни и скъпи проекти, с големи и сложни функционалности, които се качват на хостинг от 5 евро на месец. Това е несериозно.
Не може да искате сложна система, с много процеси под капака, интеграции, тракинг системи, фийдове и какво ли не – и да очаквате тя да работи на най-бюджетната хостинг услуга.
Тук е много важна ролята на разработчика. Именно той следва да препоръча на търговеца подходяща хостинг услуга, която отговаря на системните изисквания за системата, която е създадена.
Защото, няма как да искате да шофирате автомобил с 800 коня и той да харчи 1 на 100. Това е невъзможно.
Също така, некачествения хостинг води и до други последствия:
- бавно зареждане на уебсайта.
- лесно пада при натоварване.
- липса на бекъпи.
- стари технологии.
- липса на адекватна техническа поддръжка.
- липса на адекватен панел за управление.
- и други.
5. Защо да плащам за хостинг? Имам един „бритчед“, който чатка компютри и ще ми даде хост без пари
Това е изключително опасно изречение. В практиката сме имали случаи на сериозни проекти, които се хостват не безобразно оборудване.
Последния случай беше от тази седмица, при който:
- Сървърът нямаше панел за управление.
- Сървърът нямаше поддръжка на имейли – и се използваше външна услуга.
- Сървърът нямаше FTP.
- Сървърът нямаше възможност за контрол на версията на програмния език, както и фините настройки.
- Сървърът нямаше бекъп система.
- Сървърът нямаше адекватна поддръжка.
- Сървърът беше бавен – сайтът зареждаше бавно.
- И други.
Няма сериозен онлайн търговец, който да е постигнал нещо смислено с подобни предпоставки.
Един качествен онлайн бизнес, за своето утвърждаване и развитие – изисква и качествена техническа инфраструктура.
Не само разработката.
Но и сървърното оборудване.
И сървърния софтуер.
6. Домейнът не е на ваше име, а на името на предния разработчик
Голяма грешка.
Този, който е купил домейна се води неговия собственик.
Да, вие може да сте изпратили на разработчика си парите, но след като вие пряко не сте купили домейна – той не е ваш.
Сега се разбирате с разработчика.
Ами ако се скарате и той не иска да ви даде домейна?
Или ви го спре?
Или го продаде на конкурента?
Или ви изнудва за висока цена, за да си го вземете?
Препоръчваме: домейнът да си закупите пряко вие. Той да е във ваш акаунт, до който лично вие да имате достъп.
А техническия екип да отговаря само за технически настройки.
Но не и за собствеността.
7. „Направих уебсайт, но той не се класира на първа позиция в Google – разработчикът е виновен!“
Доста хора не са запознати каква точно е ролята на един разработчик.
Разработчикът е като.. строителна фирма.
Отивате при строителната фирма и ѝ казвате – „искам да ми построите ресторант“.
Влиза се в детайли, изчистват се, избира се дизайн, визуализация, прави се проект, дава се цена.
От един момент нататък – получавате готова сграда и построен ресторант, с дограма, плочки, тоалетни, всичко.
Но строителят няма отношение към привличането на клиенти за ресторанта. Той си е свършил работата – построил го е.
Привличането на клиенти е съвсем друга дейност.
То се осъществява чрез реклама.
Защото, може да имате най-добрия представителен уебсайт, каталог или онлайн магазин – но ако никой не знае за него, респективно няма да имате поръчки и запитвания.
Ето защо следващата стъпка е да се рекламира в интернет пространството.
За целта, може да опитате с Meta Ads, Google Ads, SEO, Tik Tok, LinkedIn, медии, телевизия, радио, флаери, визитки или нещо друго.
Тук, ако нямате опит, бихме препоръчали да се обърнете към хора, които разбират от реклама – и те да Ви предложат решения.
Но да завършим с това – ролята на разработчика е да създаде сайта съгласно уговорка и техническо задание.
Оттам насетне – разработчикът не е рекламист.
Той не носи отговорност за вашите продажби.
Той за грижи за техническата обезпеченост на проекта ви.
8. Пипате настройки, които не разбирате – и оттам нещо се чупи
Имаше един клиент, който се свърза с нас, че от седмица не му влизали поръчки в магазина. Човекът няма технически познания. Но влязал в магазина, правил, струвал – и изключил куриерския модул.
Понякога клиентите пипат неща, които не разбират – и с които си чупят система, куриери, плащания, външен вид, мобилна версия или друго.
Препоръчваме да се пипат само неща, които се разбират. А за другото – да се обръщате към разработчика и съответния технически екип, с който работите.
Доста търговци влизат в ролята на хора, които настройват постоянно неща по системата. Това е грешка.
Ако ще бъдете търговци – съсредоточете се върху продукти, продажби и съдържание. Добавяйте продукти, обслужвайте поръчки, пишете статии, сменяйте текстове, изображения – и общо взето това ви е работата.
Ако ще бъдете програмисти/ит специалисти – тогава оставете търговията на търговците.
Разделението на труда е нещо много важно. Човек не може да разбира от всичко. Търговията е изкуство, тя е голяма сфера, която се учи цял живот. Но същото се отнася и до ИТ професията.
Един успешен търговец е важно да разбира ангажиментите си в проекта си.
Обобщение
Това са основни и често срещани грешки при управлението на уебсайтове.
Има, разбира се, още много тънкости, но те са твърде технически и биха били предназначени по-скоро за програмисти и ит специалисти.
Важно е търговецът да разбере, че той не бива да е поставян в ситуация – да бъде програмист/ит специалист – и да разбира от всичко.
Търговецът трябва да има система, която му позволява нормална и стабилна работа, възможност да управлява самостоятелно продуктите и поръчките си, а клиентите да пазаруват лесно и удобно.
Техническите казуси са ангажимент на съответния технически екип.
Ако търсите професионален екип, който може да ви предложи разработка на уебсайт, който просто работи и не го мислите – може би ние сме подходящите и ще очакваме вашето запитване.
С това статията приключва.
Аз съм Кирил Йовев, технически специалист в Агенцията и неин основател.
Надявам се да съм ви бил полезен и благодаря за вниманието!
Още полезно съдържание:
- Как да осигурим по-стабилна работа на сървър за WordPress / WooCommerce – мерки за превенция
- Какво трябва да знаем за кеширането?
- Какво е техническо задание за уебсайт и защо е толкова важно?