DevOps для мене - це не окрема професія, а набір практик, які роблять розробку передбачуванішою та комфортнішою. У цій категорії я ділюся спостереженнями про автоматизацію, CI/CD, деплой, інфраструктуру та інструменти, з якими працюю під час створення власних і комерційних проєктів.
SSH може перестати приймати нові підключення, хоча сервер доступний, сайт працює, а sshd активний. Одна з неочевидних причин - автоматичні тунелі, які після розриву з’єднання перепідключаються занадто часто й потрапляють під UFW LIMIT.
Коли на одній машині живе кілька Docker-проєктів, оновлення PHP має залишатися локальною зміною конкретного середовища. Ізольований runtime, окремі workspace-контейнери, зрозумілі імена сервісів і перевірка Composer-сумісності допомагають не перетворити оновлення одного проєкту на приховану поломку іншого.
Успішно виконані команди розгортання ще не доводять, що застосунок працює. Після переключення потрібно перевірити HTTP-відповідь, критичні сервіси та фонові процеси, а при помилці - відкотити версію й перевірити вже результат відкату.
Якщо збірка, залежності, конфігурація або базові перевірки можуть впасти ще до зміни production стану, немає сенсу спочатку робити сайт недоступним. Режим обслуговування варто вмикати лише після попередніх перевірок, коли залишилися кроки, які справді потребують короткого вікна недоступності.
Скрипт, який запускається один раз, все одно може створити дублікати, записати дані не в ту категорію, опублікувати внутрішні службові позначення або зламати двомовну структуру. Якщо він змінює production дані, його варто захищати так само серйозно, як звичайний код застосунку.
Під час розслідування сплеску трафіку 155 upstream errors спочатку виглядали як проблема доступності основного застосунку. Але error log показав інше: запити потрапляли в окремий virtual host через поведінку HTTPS default server. Це змінило і діагноз, і захист.
Після нового сплеску трафіку я не стала одразу блокувати країну, User-Agent або IP. Спочатку звірила Laravel Analytics з Nginx logs, відокремила кілька незалежних джерел трафіку, перевірила роботу Fail2ban і лише потім додала Nginx rate limiting у dry-run режимі.
Файл backup на сервері ще нічого не доводить. Потрібно знати, коли він створений, чи процес запускається регулярно, чи розмір виглядає правдоподібно, чи є історія успішних запусків і головне - чи дані реально можна відновити.
Якщо критична вразливість знаходиться в самому PHP, оновлення Composer-залежностей її не виправить. Потрібно перевірити всі середовища, підготувати резервні копії, оновити встановлені пакети PHP і після цього перевірити сайт, PHP-FPM, черги та Docker-контейнери.
21 жовтня 2026 року команда безпеки PHP повідомила про CVE-2026-109618 і CVE-2026-109619 - дві критичні вразливості, які можуть дозволити віддалене виконання коду без авторизації. Проблема знаходиться в самому середовищі виконання PHP, а не в залежностях Composer.
Для великого релізу я не вливаю пов’язані задачі в development по одній. Спочатку вони збираються в окремій release branch, проходять спільну стабілізацію, а вже потім реліз рухається далі як одна перевірена одиниця.
Після налаштування блокування сканерів я залишила ICanUp працювати на ніч і вранці перевірила реальні журнали. Захист спрацював, Fail2ban заблокував реальні адреси, а аналіз одночасно показав прогалину на DEV для вкладених чутливих шляхів.