Почніть з операційних вимог
Перед порівнянням конфігурацій зберіть стек застосунку кожного проєкту, базу даних, завантаження, заплановані завдання, інтеграції та очікувані зміни. Визначте, кому потрібен доступ до вмісту, доступ до розгортання та адміністрування хоста. Це різні завдання. Клієнту, який редагує сторінку, може знадобитися лише обліковий запис застосунку; підряднику, який обслуговує операційну систему, потрібні суттєво ширші повноваження.
Також запишіть прийнятне вікно обслуговування, хто схвалює простій, де зберігаються копії для відновлення та хто платить за операційну роботу. Занотуйте будь-яку вимогу клієнта щодо окремого сервера чи облікового запису як обмеження рішення. Таблиця ресурсів не може вирішити вимогу власності чи доступу.
- Назвіть основного оператора та заміну для кожного проєкту.
- Перелічіть спільні залежності: доступ до DNS, облікові дані розгортання, сервіси баз даних і призначення резервних копій.
- Позначте невідомі вимоги для рішення клієнта, перш ніж брати на себе зобов’язання щодо угоди.
Виберіть межу доступу перед розміром сервера
OWASP рекомендує надавати лише ті дозволи, які потрібні для виконання роботи особи, і перевіряти, що передбачені обмеження діють. Застосуйте цей принцип до плану хостингу: використовуйте окремі ідентичності, облікові дані застосунків для конкретних проєктів і задокументований шлях розгортання. Каталог, названий на честь клієнта, є організаційним засобом, а не політикою доступу.
Якщо використовуєте Docker, розглядайте доступ до його демона як відповідальність рівня хоста. Документація Docker щодо безпеки пояснює, що довірений оператор демона може монтувати й змінювати файли хоста. Тому надання зовнішньому підряднику необмеженого контролю над Docker погано узгоджується з хостом, що містить дані стороннього клієнта.
Окремі інстанції VPS дозволяють окреме адміністрування операційної системи та рішення про випуски. Вони все одно потребують ретельних дозволів у межах кожного проєкту. Спільні облікові дані агенції або спільний обліковий запис для розгортання можуть повторно об’єднати ризики, які ви мали намір розділити.
Опрацюйте два вигадані клієнтські брифи
Наведені нижче клієнти є вигаданими прикладами, а не історіями клієнтів. Агенція сьогодні веде обидва проєкти, але їхні вимоги до доступу й термінів різняться.
Розміщення цих двох проєктів разом зробило б доступ підрядника Morrow і графік запуску частиною операційного ризику Aster. Рішення про окремі сервери випливає з цих обмежень; воно не стверджує, що Morrow потребує певної кількості CPU, або що Aster не має ризиків.
Прокрутіть горизонтально, щоб побачити всі стовпці таблиці.
| Фактор рішення | Aster Furniture: сайт-брошура | Morrow Workshops: сайт реєстрації |
|---|---|---|
| Навантаження | Публічні сторінки та періодичні оновлення вмісту | Форми, база даних і заплановані експорти реєстрацій |
| Доступ | Клієнт редагує вміст; агенція розгортає | Зовнішньому розробнику потрібне адміністрування хоста |
| Обслуговування | Узгоджене вечірнє вікно | Жодних запланованих змін під час запуску бронювання |
| Вплив інциденту | Тимчасовий збій сторінки можна обговорити | Втрачені або дубльовані подання потребують розслідування |
| Вимога виходу | Експортувати вміст і перенести застосунок | Передати середовище, яке адмініструється незалежно |
| Попереднє рішення | Розгляньте спільне розміщення із сумісними сайтами, які веде агенція | Використовуйте окремий VPS і окремі облікові дані проєкту |
Порівняйте повну вартість обох варіантів
Створіть дві бюджетні версії за допомогою поточного конфігуратора: одну спільну конфігурацію та одну конфігурацію для кожного проєкту. Для кожної окремо вкажіть загальну суму хостингу за вибраний період, регулярні опції, зовнішні сервіси та час на обслуговування агенцією. Не переносьте стару ціну до брифу клієнта. Зафіксуйте, коли було підготовлено конфігурацію та хто затвердив розподіл.
Для спільного хоста узгодьте, як клієнти розподіляють фіксовані витрати та що відбувається, коли один із них виходить або потребує оновлення. Рівні частки прості, але можуть не підходити, якщо один проєкт спричиняє більшість зростання сховища чи операційної роботи. Окремі сервери роблять атрибуцію чіткішою, додаючи окремі завдання патчингу, моніторингу та відновлення.
Залишайте запас ресурсів для випусків, резервних копій і тимчасової роботи. Контейнери Docker за замовчуванням не мають обмежень CPU чи пам’яті; налаштуйте відповідні ліміти та оцініть сукупне навантаження. Лише список контейнерів не демонструє життєздатний бюджет ресурсів.
Зробіть обслуговування та відновлення специфічними для проєкту
На спільному хості перезапуск операційної системи впливає на кожен розміщений проєкт. Внесіть обслуговування хоста до спільного календаря та визначте, хто зв’язується з кожним клієнтом. За можливості розділяйте випуски застосунків і не плануйте експорт даних одного проєкту під час важливого запуску іншого.
Нотатки про відновлення мають визначати базу даних проєкту, файли, конфігурацію та потрібні облікові дані, не копіюючи секрети до нотаток. Плануйте відновлення до окремого тестового призначення. Відновлення всього спільного хоста як перша реакція могло б замінити здорові зміни, що належать іншому клієнту.
З окремими інстанціями VPS зафіксуйте спільні сервіси, що залишаються. Спільний обліковий запис DNS, призначення резервних копій або оператор усе ще можуть впливати на обидва проєкти. Розділення серверів не є доказом незалежної фізичної інфраструктури чи гарантованої доступності.
Перевірте домовленість і встановіть тригери перегляду
Перш ніж приймати угоду, нехай другий оператор перевірить, що ідентичність проєкту може виконувати призначену їй роботу й не може читати файли, резервні копії чи секрети іншого проєкту. Перегляньте дозволи бази даних і розгорнуті облікові дані, а також екрани застосунку. Використовуйте нешкідливі тестові дані в узгодженому середовищі; не перевіряйте робочі дані іншого клієнта.
Зафіксуйте результат як прийнято, відхилено або очікує на назване виправлення. Якщо ізоляцію неможливо продемонструвати, звужте доступ або перемістіть проєкт, перш ніж надавати ширші дозволи. Успішна відповідь головної сторінки не є перевіркою доступу чи відновлення.
- Зберігайте запис рішення з обраною схемою, затвердженим розподілом витрат, власниками та невирішеними питаннями.
- Перегляньте вибір, коли приєднується зовнішній адміністратор, змінюється вікно запуску, зростає сховище або клієнт готується піти.
- Використовуйте посібник із відповідальностей, щоб перетворити технічний вибір на операційну угоду.
Джерела та перевірка
Технічні посилання було перевірено 12 вересня 2026. Приклади є навчальними вправами; документація згаданого програмного забезпечення не встановлює можливості послуг PrivateHostLab.