Когато поемаме съществуващ сайт, започваме с преглед на задачата и текущото състояние. Не приемаме предварително, че трябва да се сменят дизайнът, платформата или хостингът. Първо трябва да разберем какво работи, къде е проблемът и какво може да се запази.
Дълбочината на прегледа зависи от ситуацията. Спешен инцидент, текуща поддръжка и планирано развитие имат различни приоритети. Описаният подход е отправна точка, а не еднакъв чеклист за всеки сайт.
Започваме от работата, която сайтът върши
Уточняваме за какво се използва сайтът и кои действия са важни за бизнеса. Това може да са запитвания, поръчки, редактиране на продукти или предоставяне на информация на клиенти.
Интересува ни и причината за промяната на изпълнителя: конкретен технически проблем, липса на текуща грижа или нужда от функционалност. Разглеждаме наличната информация, без да правим оценка на предишната работа само по отделен симптом.
Полезни са документацията, списъкът с известни проблеми и информацията за промени, които вече са правени. Ако нещо липсва, отбелязваме го като неизвестно, вместо да го приемаме за проверено.
Изясняваме основата и отговорностите
Прегледът може да включва платформата, компонентите, специфичния код, интеграциите и хостинг средата. Важно е да се знае и кои акаунти са под контрола на бизнеса: домейн, хостинг, администрация и свързани услуги.
Достъпите трябва да се предоставят по защитен начин и с подходящи права. Прехвърлянето на работата не е повод пароли и ключове да се публикуват в общи документи.
Ако въпросът е около VPS управление, опитът ни с aaPanel показва един от инструментите, които използваме. Наличието на друг панел само по себе си не е причина за миграция.
Преди промени трябва да е ясно как се връщаме назад
Наличието на архив е начало. Трябва да се изясни какво съдържа, кога е създаден и как може да се използва за възстановяване. При промяна по активен магазин трябва да се отчита и информацията, която се добавя след създаването на копието.
Когато средата и задачата позволяват, тестово копие помага да се проверят промени преди прилагането им върху работещия сайт. Начинът на работа се избира според риска, а не само според удобството на изпълнителя.
За WordPress официалните насоки за сигурност разглеждат обновяванията, достъпите и резервните копия като части от защитата. Един успешен update не е доказателство, че всичко останало е проверено.
При инцидент приоритетът е различен
В публичния проект за MDDograma работата започна с проверка на сайта и хостинг средата след компрометиране. Намесата включваше почистване, възстановяване на базата от чист архив и обновяване на уязвими компоненти.
Този случай илюстрира защо при инцидент е нужна преценка на по-широкия контекст. Той не означава, че всеки поет сайт е компрометиран или изисква същата намеса.
Избираме между грижа за наличното и нова основа
Ако съществуващото решение позволява смислена работа, може да се започне с текуща техническа поддръжка и конкретни подобрения. При сериозни ограничения е разумно да се обсъди нова основа и какво означава преходът.
Тази преценка трябва да включва съдържанието, данните, адресите и работните действия, които не бива да се загубят. Новият сайт не е автоматично по-доброто решение само защото е нов.
Какво трябва да е ясно след първия преглед
Целта е да има разбираема картина: какво е проверено, кои въпроси остават отворени, какво е спешно и какъв обхват можем да поемем. Уточняваме и кой отговаря за съдържанието, свързаните системи и следващите промени.
Това позволява работата да започне с конкретна посока. Поемането на съществуващ сайт е поемане на контекст и отговорност, не просто получаване на парола за администрацията.
