Ціла компанія на одному невеликому сервері

Ситуація. Продакшн‑хост компанії — одноядерний хмарний інстанс із 512 МБ пам’яті, з яких реально доступні близько 464 МБ, і 10 ГБ диска. На ньому працює все, що компанія тримає в публічному доступі: вебсервер, який термінує TLS для семи доменів, git‑сервер, onion‑сервіс Tor, сервер Gemini, сервер Gopher, зашифровані резервні копії та автоматичне блокування зловмисників. Звична реакція на такий перелік — купити потужнішу машину.

Завдання. Обмеження треба було сприймати як вихідну умову для архітектури, а не як проблему, яку розв’язують грошима, бо чесне питання звучало не «чи впоралася б більша машина», а «чи потрібна вона цій архітектурі».

Дія. Вирішальним аргументом у кожному рішенні стала пам’ять. Тут немає ні агента моніторингу, ні пайплайна метрик, ні дашборда: звіти отримують на запит — це сім команд, які читають хост і формують Markdown, нічого не змінюють і запускаються лише тоді, коли їх викликають. Супервізор — systemd, а не другий менеджер процесів поверх нього, а контейнерний рівень — це юніти Quadlet під тим самим супервізором, а не окремий демон зі своїм. З тієї самої причини ще на етапі проєктування відкинули платформи з вебпанеллю керування. Коли постало питання, чи потягне хост onion‑сервіс, відповідь дали вимірювання протягом доби, а не чиясь думка: доступна пам’ять жодного разу не опустилася нижче приблизно 310 МБ із 464, своп тримався на рівні 2,6 відсотка, а процесор 99,7 відсотка часу простоював.

Результат. Уся компанія працює на машині, яка коштує на місяць менше, ніж обід, і саме завдяки цій дисципліні архітектура не просто дешевша, а краща. Платою стала відсутність запасу на будь‑яку недбалість — пошти на цій машині навмисно немає взагалі: її оформлено як заготовку для встановлення, що чекає на окремий хост, бо поштовому серверу потрібен запас, який ця машина вже вичерпала, і це записано заздалегідь, а не з’ясується згодом.