Поддръжка на уеб сайт след пускането: какво включва

След пускането уеб сайтът или уеб приложението има нужда от редовни обновления за сигурност и на зависимостите, планирано надграждане на framework-а, архиви, които се проверяват чрез реално възстановяване, и наблюдение, което ви съобщава за грешки и прекъсвания, преди клиентите ви да ги забележат. Към това се добавят периодични проверки на скоростта, съдържанието и видимостта в търсачките. Липсата на поддръжка рядко създава проблем през първия месец. Създава по-голям по-късно, когато някой използва уязвимост в необновен плъгин или когато надграждането е отлагано толкова дълго, че се превръща в изграждане наново.

#Защо завършеният сайт продължава да изисква работа

Вашият код може да остане същият след пускането. Всичко около него продължава да се променя. Езикът за програмиране, framework-ът, сървърът на базата данни, библиотеките, браузърите и външните API пускат нови версии, поправят уязвимости и спират стари функции. Платежният доставчик може да прекрати поддръжката на дадена версия на своя API. Браузърът може да промени начина, по който обработва бисквитките. Авторът на плъгин може изобщо да спре да го поддържа.

Поддръжката е работата по това продуктът да остане съвместим и сигурен, докато всичко това се случва. Тя е по-лесна и по-евтина на малки, редовни стъпки, отколкото като едно голямо наваксване на няколко години.

#Обновления за сигурност и нови версии на framework-а

Повечето атаки срещу малки и средни сайтове използват известни уязвимости в остарял софтуер: старо ядро на CMS, необновен плъгин, библиотека с публикувано предупреждение за сигурност. Обновяването премахва лесните мишени.

• Проверявайте зависимостите редовно. Инструменти като composer audit, npm audit и вградените предупреждения в GitHub и GitLab показват пакетите с известни уязвимости.
• Прилагайте поправките за сигурност веднага, а рутинните обновления по график, например веднъж месечно.
• Обновявайте първо копие. Прилагайте обновленията в тестова среда, пуснете автоматичните тестове и минете през основните сценарии, преди да обновите продукционния сайт.
• Махнете това, което не използвате. Всеки неизползван плъгин, модул или пакет е код, който все още може да бъде атакуван.
• Поддържайте актуална и сървърната част: операционната система, PHP, Node.js или друга среда за изпълнение и сървъра на базата данни. При споделен или управляван хостинг доставчикът поема част от това; при VPS това е ваша задача или задача на разработчика ви.

Сертификатите за сигурност също са в този списък. Повечето днес се подновяват автоматично, но автоматичното подновяване може да спре тихо след промяна в DNS или на сървъра. В статията какво е SSL сертификат обясняваме подновяването и какво става, когато сертификатът изтече.

Надграждане на framework-а

Framework-ове като Laravel, Symfony, Django, Next.js и Rails пускат големи версии в редовен цикъл, а всяка голяма версия получава поправки за сигурност само за ограничен период. Същото важи за CMS платформите и за версиите на езиците, например PHP. Проверете политиката за поддръжка на всяка част от технологиите си и си запишете кога използваната от вас версия спира да получава поправки за сигурност.

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

#Архиви и проверка на възстановяването

Архив, който никога не е бил възстановяван, е само предположение. Много екипи откриват по време на реален инцидент, че архивите им са непълни, че не включват качените файлове или че никой не знае как да ги възстанови.

• Архивирайте всичко важно: базата данни, качените файлове и настройките. Самият код трябва вече да е в Git хранилище.
• Пазете копия на повече от едно място. Архив, който стои на същия сървър като сайта, изчезва заедно със сървъра.
• Пазете няколко поколения архиви. Ако данните се повредят и никой не забележи седмица, вчерашният архив вече съдържа повредата.
• Проверявайте възстановяването редовно. Възстановете архив в отделна среда, проверете дали сайтът работи и дали данните са пълни и запишете колко време е отнело.

#Наблюдение, грешки и производителност

За проблема трябва да научите от системата за наблюдение, преди клиент да ви пише.

• Наблюдението на достъпността проверява сайта отвън на кратки интервали и ви известява, когато спре да отговаря. Следете страниците, които имат значение, например поръчката или входа, а не само началната страница.
• Проследяването на грешки с инструменти като Sentry събира изключенията от сървъра и браузъра, групира ги и показва с коя версия са се появили.
• Наблюдението на планираните задачи и опашките потвърждава, че фоновата работа, например изпращането на имейли или синхронизирането на поръчки, продължава да върви. Тези откази са тихи, ако нищо не ги следи.
• Проверките на производителността с Google PageSpeed Insights и отчета Core Web Vitals в Google Search Console показват как реалните посетители възприемат страниците ви. Бавните заявки към базата данни обикновено се появяват с растежа на данните, затова ги преглеждайте периодично.
• Свободното дисково пространство и изтичането на сертификати се наблюдават лесно, а причиняват изненадващо много прекъсвания.

#Проверки на съдържанието и SEO

Сайтът може да е технически изправен и въпреки това да губи позиции в търсачките заради проблеми със съдържанието. Кратък периодичен преглед покрива повечето от тях:

• Счупени вътрешни и външни връзки и страници, които връщат грешка.
• Отчетите за индексиране и обхождане в Google Search Console, включително страниците, изключени от индекса.
• Пренасочвания за всяка преместена или премахната страница, за да продължат да работят старите връзки и резултатите в търсачките.
• Остаряло съдържание: цени, работно време, данни за екипа, правни страници и информация за продуктите.
• Заглавия и описания на важните страници и актуална карта на сайта (sitemap).
• Формите за контакт, които се чупят по-често, отколкото се очаква, обикновено заради промени в изпращането на имейли.

#Какво трябва да съдържа договорът за поддръжка

Независимо дали поддръжката се поема от екипа, който е изградил продукта, от друг разработчик или от ваши служители, запишете условията. Добрият договор отговаря на следните въпроси:

• Какво е включено: обновления за сигурност, обновления на зависимостите, надграждане на framework-а, архиви, наблюдение, промени в съдържанието, дребни поправки. Посочете изрично какво не е включено, например нови функции.
• Колко често: например поправките за сигурност веднага след излизането им, рутинните обновления веднъж месечно, проверка на възстановяването веднъж на тримесечие.
• Време за реакция: колко бързо се реагира на спешен проблем, например спрял сайт или неработещи плащания, и колко бързо на обикновените заявки.
• Как се съобщава за проблем: каналът, лицето за контакт и какво се смята за спешно.
• Как се заплаща работата: месечна такса за определен обхват, пакет часове или заплащане на заявка, и какво става с неизползваните часове.
• Достъп и собственост: кои акаунти може да използва разработчикът и потвърждение, че те остават на ваше име. Какво да проверите, сме описали в статията чий е кодът и акаунтите.
• Отчитане: кратък запис какво е обновено, какви инциденти е имало и какво предстои, например края на поддръжката на дадена версия.
• Прекратяване: срок на предизвестие и какво ви се предава.

#Как може да помогне PN Scripts

В PN Scripts поддръжката, обновленията и новите функции продължават след пускането толкова дълго, колкото клиентът желае, с автоматични тестове на критичните места като плащания, вход и данни, и с документация, която се поддържа актуална. Ако търсите екип, който да поддържа сайт или приложение, вижте нашата уеб разработка по поръчка.