Чекліст для свіжої інсталяції: 20 хвилин зараз — 20 годин пізніше

Мислення: зафіксуй базу, потім будуй

Свіжа інсталяція — це єдиний момент у житті системи, коли все чисто, детерміновано і ще підкоряється. Як тільки приходить продукційний трафік, починається ентропія: пакети дрейфують, конфіги правляться «тимчасово», а та одна людина, яка пам’ятає, навіщо змінено параметр ядра, у відпустці назавжди.

Ваша мета за перші 20 хвилин — не «завершити налаштування». Ваша мета — зафіксувати базу і встановити страховки:

• База: визначте апаратне та віртуальне середовище, яке ви фактично отримали (не те, що обіцяло закупівля).
• Підтвердьте інваріанти: час, DNS, маршрутизація, макет сховища та канали оновлень.
• Зробіть майбутнє дешевшим: снапшоти, резервні копії, місце для логів і спосіб налагоджувати без гадання.

Одна цитата для монітора. Це перефразована ідея від John Allspaw (операції та надійність): системи виходять з ладу несподіваними способами; ваше завдання — зробити безпечним процес навчання й швидкого відновлення.

Робіть нудні перевірки зараз. Або робіть їх опів на третю ночі, коли хтось питає, чи «це база даних».

Цікаві факти та контекст (чому це повторюється)

1. Шрами UNIX-таймкеепінгу старі. Предки NTP походять з декількох десятиліть тому; баги синхронізації часу досі викликають збій автентифікації, помилки TLS і «неможливі» хронології в логах.
2. Файлові системи мають історію — і вона видна. ext4 консервативний, бо взяв у спадок уроки від втрат живлення та поганих дисків.
3. Журналювання файлів було революцією. До масового впровадження журналюючих файлових систем аварійні перезавантаження могли перетворюватися на багатогодинні fsck. Багато «дивних» дефолтів сьогодні існують, щоб не повернути той період.
4. RAID ніколи не був резервною копією. Фраза старша за більшість он-кол ротацій і щотижня ігнорується; RAID захищає від певних відмов дисків, але не від видалення чи корупції.
5. DNS-помилки — постійний антагоніст. В інтернеті було кілька гучних інцидентів через помилки DNS; у компаніях та сама схема повторюється через split-horizon і застарілі резолвери.
6. OpenSSH дефолти еволюціонували не дарма. Відмова від слабших алгоритмів і перехід на автентифікацію ключами — не мода; це наслідок інцидентів.
7. cgroups і systemd змінили роботу з Linux. Вони зробили контроль ресурсів і супервізію сервісів кращими, але також ввели режими відмов, які ви помітите лише перевіривши відповідні статуси.
8. «Працює на моїй машині» стало гірше з віртуалізацією. Зсуви часу, шумні сусіди, перепідписаний I/O і невідповідні CPU-флаги можуть зробити дві «ідентичні» ВМ зовсім різними видами.

Це не дрібниці. Це причина, чому чекліст для свіжої інсталяції — не параноя. Це складений відсоток.

Чеклісти / покроковий план (рутину на 20 хвилин)

Хвилини 0–3: Ідентичність та доступ (перед тим як щось чіпати)

• Підтвердьте hostname, версію ОС, ядро та контекст віртуалізації.
• Підтвердьте, що ви можете зайти безпечно: SSH-ключі, sudo та запасний шлях (консоль, OOB або серійна консоль ВМ).
• Занотуйте початковий стан: джерела пакетів, kernel cmdline, розклад дисків.

Хвилини 3–8: Макет зберігання, який вам не набридне потім

• Перевірте, які диски у вас є, як вони названі і чи це NVMe, SATA або мережеве сховище.
• Підтвердьте розділення та точки монтування. Переконайтесь, що логи й дані випадково не ділять маленький root.
• Підтвердьте поведінку TRIM/discard для SSD, де це важливо.

Хвилини 8–12: Перевірка мережевої реальності

• Перевірте IP, маршрути та DNS-резолвери.
• Перевірте MTU та базову затримку. Шукайте PMTU-«чорні діри» рано.
• Перевірте вихідну доступність до mirror-ів пакетів та endpoint-ів моніторингу.

Хвилини 12–16: Час, оновлення та супервізор сервісів

• Підтвердьте синхронізацію часу та часовий пояс (і що синхронізація тримається).
• Підтвердьте політику автоматичних оновлень (або ваш процес патчування). «Зробимо пізніше» — брехня, яку люди собі говорять.
• Підтвердьте здоров’я systemd та збереження логів.

Хвилини 16–20: Обсерваторія + резервні копії (доведіть, що працює)

• Встановіть мінімальний агент для метрик/логів або хоча б увімкніть персистентні логи.
• Створіть перший снапшот (ВМ або файлової системи) після того, як система визнана «знаючою-до-роботи».
• Запустіть задачу резервного копіювання, а потім спробуйте невелике відновлення. Так, відразу.

Короткий жарт #1: Резервні копії як парашути: якщо ви дізнаєтесь, що вони не працюють тільки під час стрибка, ваш постмортем буде коротким.

Практичні завдання з командами, виводами та рішеннями

Мета команд — не збирати тривіальність. Кожна команда повинна відповісти: «Що є істинним?» і «Що робити далі?». Нижче практичні завдання для більшості сучасних дистрибутивів Linux. Налаштуйте шляхи та інструменти за потребою, але зберігайте намір.

Завдання 1: Підтвердьте ОС, ядро та архітектуру

cr0x@server:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04 LTS (Noble Numbat)"
ID=ubuntu

cr0x@server:~$ uname -r
6.8.0-31-generic

cr0x@server:~$ uname -m
x86_64

Що означає вивід: У вас точна версія дистрибутива, лінія ядра та архітектура CPU. Це впливає на доступність пакетів, дефолти ядра (планувальники I/O, cgroups) і поведінку драйверів.

Рішення: Підтвердьте, що це збігається з вашою політикою підтримки. Якщо вам потрібне конкретне ядро або LTS-майнор для драйверів (HBA/NIC), вирішіть це зараз — до появи продукційних даних.

Завдання 2: Підтвердьте віртуалізацію / хмарне середовище

cr0x@server:~$ systemd-detect-virt
kvm

cr0x@server:~$ cat /sys/class/dmi/id/product_name
KVM

Що це означає: Ви в KVM. Іменування дисків, поведінка годинника та межі I/O можуть відрізнятися від «голого» заліза.

Рішення: Якщо ви очікували bare metal — зупиніться і ескалуйте. Якщо очікували VM — перевірте припущення щодо продуктивності сховища (мережеві блочні пристрої можуть бути «нормальними», поки не стануть ні).

Завдання 3: Зафіксуйте базові характеристики CPU і пам’яті (виявлення недопостачання)

cr0x@server:~$ lscpu | sed -n '1,12p'
Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Byte Order:                           Little Endian
CPU(s):                               4
On-line CPU(s) list:                  0-3
Vendor ID:                            GenuineIntel
Model name:                           Intel(R) Xeon(R)
Thread(s) per core:                   2
Core(s) per socket:                   2
Socket(s):                            1
Virtualization:                       VT-x
L1d cache:                            64 KiB

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       420Mi       6.6Gi       4.0Mi       720Mi       7.1Gi
Swap:          0B          0B          0B

Що означає: У вас 4 vCPU, ~8 GiB RAM і не налаштовано swap.

Рішення: Вирішіть явно щодо swap. Для багатьох серверних навантажень невеликий swap може запобігти хаосу OOM-killer; для чутливих до затримок навантажень ви можете віддати перевагу відсутності swap і жорстким обмеженням пам’яті. Не переходьте ненароком на дефолт.

Завдання 4: Підтвердьте диски, моделі та транспорт

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MODEL,TRAN,ROTA,MOUNTPOINTS
NAME   TYPE  SIZE MODEL            TRAN ROTA MOUNTPOINTS
vda    disk  120G Virtio Block Dev  virtio    1
├─vda1 part    1G                          1 /boot
└─vda2 part  119G                          1 /

Що означає: Один virtio-диск, rotational=1 (часто не має значення у ВМ, але дає підказку). Root і boot ділять той же диск.

Рішення: Якщо тут будуть бази даних, черги або важкі логи — сплануйте окремі томи або точки монтування зараз (або перейдіть на LVM/ZFS). Один корінь на одному диску — шлях до «диск заповнений» через балакучі логи.

Завдання 5: Перевірте тип файлової системи та опції монтування

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /
/dev/vda2 ext4 rw,relatime,errors=remount-ro

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /boot
/boot /dev/vda1 ext4 rw,relatime

Що означає: ext4 зі «безпечною» конфігурацією. errors=remount-ro може врятувати від прихованої корупції ціною миттєвого болю — це хороший компроміс.

Рішення: Залишайте здраві дефолти, якщо у вас немає виміряної причини. Якщо ви використовуєте SSD і піклуєтесь про write amplification, перегляньте noatime vs relatime і ваші потреби в моніторингу.

Завдання 6: Перевірте вільне місце та запас по інодам

cr0x@server:~$ df -hT /
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/vda2      ext4  117G  6.1G  105G   6% /

cr0x@server:~$ df -ihT /
Filesystem     Type  Inodes IUsed IFree IUse% Mounted on
/dev/vda2      ext4   7.5M   132K  7.4M    2% /

Що означає: Місця й інодів достатньо. Виснаження інодів — класична пастка «диск наповнений, але здається ні» з дрібними файлами (кеші, черги, шари контейнерів).

Рішення: Якщо очікуєте багато дрібних файлів, розгляньте окремі файлові системи зі співвідношенням інодів, або перенесіть такі навантаження в об’єктне сховище чи БД, призначену для цього.

Завдання 7: Встановіть швидку базу I/O (латентність важливіша за MB/s)

cr0x@server:~$ sudo apt-get update -y
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://security.ubuntu.com/ubuntu noble-security InRelease [110 kB]
Fetched 110 kB in 1s (160 kB/s)
Reading package lists... Done

cr0x@server:~$ sudo apt-get install -y fio
Setting up fio (3.36-1) ...

cr0x@server:~$ fio --name=randread --filename=/tmp/fio.test --size=1G --rw=randread --bs=4k --iodepth=32 --numjobs=1 --direct=1 --runtime=20 --time_based --group_reporting
randread: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=32
fio-3.36
randread: (groupid=0, jobs=1): err= 0: pid=2176: Thu Feb  5 10:11:02 2026
  read: IOPS=18.4k, BW=71.9MiB/s (75.4MB/s)(1.40GiB/20001msec)
    slat (usec): min=3, max=140, avg=9.12, stdev=2.88
    clat (usec): min=179, max=4112, avg=1726.44, stdev=312.20
    lat (usec): min=188, max=4124, avg=1735.81, stdev=312.34

Що означає: Рандомний read IOPS і, що важливіше, розподіл латентності. Середнє ~1.7 ms може бути прийнятним для загальних навантажень; для бази даних, чутливої до хвостової латентності, це може бути критично.

Рішення: Якщо латентність вища, ніж очікувалось — досліджуйте бекенд сховища (virtio на мережевих блоках, кешування на хості, оверхед шифрування). Не «оптимізуйте» додаток, поки не перевірили, що диск не тихенько горить.

Завдання 8: Перевірте мережеві інтерфейси, адреси та стан лінку

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens3             UP             10.20.14.37/24 fe80::5054:ff:fe2a:1b2c/64

cr0x@server:~$ ip route
default via 10.20.14.1 dev ens3 proto dhcp src 10.20.14.37 metric 100
10.20.14.0/24 dev ens3 proto kernel scope link src 10.20.14.37

Що означає: Інтерфейс піднятий, має IP і є маршрут за замовчуванням.

Рішення: Якщо це продакшн, вирішіть, чи підходить DHCP. Для серверів зазвичай варто статичне адресування (або DHCP з резервацією та суворою інвентаризацією).

Завдання 9: Перевірте розв’язання DNS та конфігурацію резолверів

cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 10.20.0.54

cr0x@server:~$ getent hosts archive.ubuntu.com
2620:2d:4000:1::19 archive.ubuntu.com
91.189.91.83 archive.ubuntu.com

Що означає: Ви знаєте, які резолвери використовуються, і розв’язання імен працює.

Рішення: Якщо резолвери — «таємничі IP», виправте це зараз. Також вирішіть, чи потрібен split DNS, search-домени або валідація DNSSEC (рідко внутрішньо, але знайте вибір).

Завдання 10: Перевірте MTU та базове здоров’я шляху

cr0x@server:~$ ip link show ens3 | sed -n '1,2p'
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:2a:1b:2c brd ff:ff:ff:ff:ff:ff

cr0x@server:~$ ping -c 3 10.20.14.1
PING 10.20.14.1 (10.20.14.1) 56(84) bytes of data.
64 bytes from 10.20.14.1: icmp_seq=1 ttl=64 time=0.335 ms
64 bytes from 10.20.14.1: icmp_seq=2 ttl=64 time=0.284 ms
64 bytes from 10.20.14.1: icmp_seq=3 ttl=64 time=0.290 ms

cr0x@server:~$ ping -M do -s 1472 -c 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
1472 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=2.31 ms
1472 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=2.28 ms

Що означає: MTU — 1500, і ви можете пройти пакет повного розміру без проблем із фрагментацією.

Рішення: Якщо очікуються jumbo-фрейми (MTU 9000), підтвердіть end-to-end. Змішані MTU створюють тікети «все працює, крім важливого».

Завдання 11: Підтвердьте синхронізацію часу та здоров’я годинника

cr0x@server:~$ timedatectl
               Local time: Thu 2026-02-05 10:14:21 UTC
           Universal time: Thu 2026-02-05 10:14:21 UTC
                 RTC time: Thu 2026-02-05 10:14:22
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

cr0x@server:~$ chronyc tracking
Reference ID    : 0A140035 (10.20.0.53)
Stratum         : 3
Last offset     : -0.000021 seconds
RMS offset      : 0.000110 seconds
Frequency       : 11.432 ppm fast
Skew            : 0.221 ppm
Root delay      : 0.001234 seconds
Root dispersion : 0.000532 seconds
Update interval : 64.2 seconds
Leap status     : Normal

Що означає: Синхронізація часу активна й стабільна. Зсув дуже малий. Добре.

Рішення: Якщо час не синхронізується — виправте це до деплою будь-чого з TLS, Kerberos, JWT або кореляцією логів. Тобто: майже все.

Завдання 12: Перевірте systemd на наявність failed unit-ів (виявлення тихого збою)

cr0x@server:~$ systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.

Що означає: Немає failed unit-ів. Це той базовий стан, який треба зберегти.

Рішення: Якщо щось упало — читайте логи зараз, не під час інциденту. «Failed» unit може бути вашим агентом моніторингу, таймером резервних копій або мережею.

Завдання 13: Підтвердьте персистентність логування та контролі використання диска

cr0x@server:~$ sudo grep -E '^(Storage|SystemMaxUse|RuntimeMaxUse)=' /etc/systemd/journald.conf | grep -v '^#' || true

cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 64.0M in the file system.

Що означає: journald використовує дефолти; персистентність може бути лише в runtime залежно від дистрибутива та наявності директорії.

Рішення: Вирішіть, чи логам потрібно переживати перезавантаження. Для продакшн-дебагінгу зробіть їх персистентними й обмежте використання, щоб логи не з’їли root-файлову систему.

Завдання 14: Підтвердьте стан фаєрволу (і не вдавайте, що «security group» достатньо)

cr0x@server:~$ sudo nft list ruleset
table inet filter {
        chain input {
                type filter hook input priority filter; policy accept;
        }
        chain forward {
                type filter hook forward priority filter; policy accept;
        }
        chain output {
                type filter hook output priority filter; policy accept;
        }
}

Що означає: Політика фаєрволу відкрита широко.

Рішення: Якщо цей хост доступний поза жорстко контрольованою мережею — закрийте його. Навіть у «приватних» мережах бічний рух реальний. Встановіть default deny для inbound, дозволяйте тільки потрібне і логайте відхилення з розумною частотою.

Завдання 15: Підтвердьте конфігурацію SSH і доступ лише по ключах

cr0x@server:~$ sudo sshd -T | egrep '^(port|passwordauthentication|permitrootlogin|pubkeyauthentication|kexalgorithms|macs|ciphers)'
port 22
passwordauthentication no
permitrootlogin prohibit-password
pubkeyauthentication yes
kexalgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org
macs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com

Що означає: Аутентифікація по паролю вимкнена, вхід під root обмежений, увімкнено сучасну криптографію.

Рішення: Якщо паролі дозволені — вимкніть їх після підтвердження ключів і запасного доступу. Якщо root-login дозволений — виправте це, якщо немає суворого винятку.

Завдання 16: Підтвердьте політику оновлень (пачки безпеки не опція)

cr0x@server:~$ apt-cache policy | sed -n '1,20p'
Package files:
 100 /var/lib/dpkg/status
     release a=now
Pinned packages:

cr0x@server:~$ systemctl status unattended-upgrades --no-pager
● unattended-upgrades.service - Unattended Upgrades Shutdown
     Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled)
     Active: inactive (dead)

Що означає: Unattended upgrades встановлені/увімкнені (поширено на Ubuntu). Unit може виглядати inactive, бо запускається періодично таймером.

Рішення: Виберіть: автоматичні security-оновлення або заплановане вікно патчування з моніторингом і супроводом. Те, чого не варто — «надія».

Завдання 17: Підтвердьте kernel command line (впіймайте випадкові прапори)

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.0-31-generic root=/dev/vda2 ro quiet splash

Що означає: Нічого екзотичного. Добре.

Рішення: Якщо бачите тюнінгові прапори, яких ви не ставили (відключення мірацій, зміна IOMMU, примусове старе іменування), задокументуйте причину. Невідомі kernel-флаги — як успадкувати ризик.

Завдання 18: Швидко перевірте найактивніші споживачі (CPU, пам’ять, I/O) після деплою

cr0x@server:~$ top -b -n 1 | sed -n '1,20p'
top - 10:17:02 up  1:21,  1 user,  load average: 0.08, 0.04, 0.01
Tasks: 115 total,   1 running, 114 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.2 us,  0.8 sy,  0.0 ni, 97.8 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem :   7872.4 total,   6760.8 free,    430.7 used,    680.9 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   7441.7 avail Mem

Що означає: Низьке навантаження, CPU майже простий, iowait нуль. Це «тиха» база.

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

Зберігання: розділення, файлові системи та «майбутній ви»

Більшість інцидентів, що починаються словами «додаток повільний», закінчуються «диск заповнений», «диск бреше» або «ми побудували зберігання на припущенні». Сховище тихе, поки не стане іншим. І коли воно ламається, воно тягне все за собою.

Розділення: обирайте домени відмов навмисно

Один кореневий розділ підходить для короткоживучих ВМ і безстанційних сервісів. Вони — пастка для всього, що генерує логи, зберігає файли черги, кеші, шари контейнерів або дані бази даних.

Що робити:

• Відокремте /var (або принаймні /var/log), якщо очікуєте шумні логи або часті оновлення пакетів.
• Відокремте дані додатка (наприклад, /srv або /var/lib/<service>) від ОС.
• Якщо мусите залишити одну FS — застосуйте політику збереження логів і встановіть квоти/ліміти, де можливо.

Вибір файлової системи: нудність — це перевага

ext4 і XFS — «нудні» в найкращому смислі: зрозумілі режими відмов, передбачувані інструменти та зрілі шляхи відновлення.

ZFS чудовий, коли потрібні снапшоти, контрольно-сума, реплікація й цілісна історія адміністрування. Але ZFS вимагає поваги до RAM, recordsize, ashift і того, що це платформа зберігання, а не просто опція монтування.

Поведінка SSD: TRIM і міф про нескінченні IOPS

Для SSD-підтриманого сховища переконайтесь, що TRIM/discard підходить. Постійний discard може бути корисним або шкідливим залежно від бекенду; плановий TRIM (fstrim timer) — поширений компроміс.

Також: SSD швидкі у багатьох речах і несподівано повільні у кількох. Латентність рандомних записів під тривалим навантаженням може перетворитись із «приємного» на «чому ми пейджимо СЕО» якщо пристрій або бекенд наситяться.

Шифрування: вирішіть, виміряйте, потім стандартизуйте

Шифрування диска (LUKS) часто потрібно, іноді опціонально, і завжди варто робити бенчмарки. Апаратне прискорення зазвичай робить його дешевим. Невірні CPU-флаги або відсутність прискорення роблять його дорожчим.

Зробіть рішення явним: шифрувати диск ОС? шифрувати томи з даними? хто тримає ключі? як робити unattended boot у ВМ? Якщо ви не можете чітко відповісти — робота не завершена.

Мережа: перевіряйте реальність, а не діаграми

Мережі — політичні системи з пакетами. Ваш чекліст інсталяції має підтвердити, що істинно: маршрути, резолвери, MTU і яка межа безпеки насправді застосовує політику.

DNS: залежність вашої залежності

Підтвердіть резолвери і що вони правильні для вашого середовища. Найпоширеніші помилки DNS після інсталяцій:

• Використання дефолтного резолвера, який не може розрішити внутрішні зони.
• Search-домени, що викликають повільні запити і дивні колізії імен.
• Два резолвери в списку, один мертвий; половина запитів висить у таймаутах.

MTU: маленьке налаштування — велике поле ураження

Коли MTU не співпадає, деякий трафік працює. Потім ламається VPN, реплікація бази даних зависає, або оверлей контейнерів починає втрачати великі пакети. Перевіряйте рано за допомогою пінгів з «не фрагментувати» до представницьких кінцевих точок.

Егресс має значення

Сервер, який не може дістатися до репозиторіїв пакетів, NTP-серверів, endpoint-ів сертифікації або intake моніторингу — сервер, що буде повільно гнити. Підтвердіть егресс зараз. Якщо ви в замкненому середовищі, задокументуйте точні потрібні напрямки та порти, щоб зміни фаєрволу не стали фольклором.

Безпека: зміцнюйте без руйнування операцій

Хардениing безпеки провалюється двома шляхами: нічого не робите й вас «власнять», або робите «усе» і блокуєте людей, які мають лагодити продакшн.

SSH: ключі, мінімальна експозиція, передбачуваний доступ

• Використовуйте аутентифікацію по ключах. Вимкніть парольну автентифікацію після перевірки, що у вас є робочі ключі.
• Не дозволяйте прямий вхід root. Використовуйте sudo з аудитом.
• Обмежуйте SSH до мереж керування, де це можливо.

Фаєрвол: default deny inbound, дозволяти явно

Якщо в середовищі вже застосовуються мережеві засоби безпеки — чудово. Але все одно встановіть хост-фаєрвол, якщо немає суворої причини не робити це (деякі аплайенси, load balancer-и, спеціалізовані маршрутизатори). Захист у глибину — не слоган; це спосіб вижити при неправильному правилі вгору по ланцюгу.

Принцип найменших привілеїв: користувачі та сервіси

Створюйте сервісні акаунти. Уникайте запуску процесів додатків під root. Якщо потрібні привілейовані порти або доступ на рівні ядра — робіть це явно через можливості, hardening unit-ів systemd і документацію.

Короткий жарт #2: «Тимчасове» виключення для фаєрволу — найпостійніший співробітник у більшості компаній.

Обсерваторія: логи, метрики та час

Свіжі інсталяції — це момент, коли ви вирішуєте, чи буде налагодження інженерним, чи спиритичним.

Синхронізація часу — скелет обсерваторії

Якщо часові мітки дрейфують, хронологія інциденту стає фанфіком. Тримайте системи в UTC, якщо немає сильної причини інакше. Налаштуйте NTP/chrony, підтвердіть синхронізацію і моніторьте її.

Логи: зробіть їх персистентними, обмеженими й пошуковими

Щонайменше:

• Переконайтесь у персистентності journald (/var/log/journal) або налаштуйте rsyslog для запису на диск.
• Обмежте зберігання логів, щоб вони не з’їдали root-файлову систему.
• Відправляйте логи централізовано, якщо у вас більше одного сервера. «SSH і grep» не масштабується далі першого стресового інциденту.

Метрики: фіксуйте нудні речі

CPU, пам’ять, дискова латентність, використання файлової системи, мережеві помилки і кількість процесів — це не «просунута обсерваторія». Це мінімум. Захоплюйте їх з першого дня, щоб відповісти: «Це нове чи нормальне?»

Core dumps: вирішіть політику до того, як знадобиться

Core dumps можуть заощадити дні при налагодженні крашу. Вони також можуть витікати секрети і займати диск. Вирішіть:

• Увімкнути core dumps для конкретних сервісів у контрольованих місцях.
• Відключити або обмежити їх на чутливих системах, де політика забороняє.
• Завжди обмежувати розмір і місце зберігання, і вважати дампи як чутливі артефакти.

Резервні копії: доведіть відновлення, а не намір

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

Мінімально життєздатний дизайн резервного копіювання

• Визначте охоплення: ОС можна відновити? Тоді не витрачайте час на бекуп повної ОС; зберігайте конфіг і дані.
• Визначте RPO/RTO: скільки втрати даних прийнятно і як швидко потрібно відновитися.
• Зробіть відновлення першокласним тестом: кожен новий хост має мати drill відновлення.

Що робити одразу після інсталяції

• Створіть початковий снапшот (рівень ВМ або файлової системи) після проходження базових перевірок.
• Запустіть задачу резервного копіювання і відновіть невеликий файл чи директорію в інший шлях. Перевірте вміст.
• Підтвердіть, що облікові дані та ключі шифрування збережені в менеджері секретів і доступні за процедурою break-glass.

Якщо ваше рішення для бекапу — «ми маємо RAID», зупиніться. Прочитайте ще раз це речення, а потім виправте своє життя.

Швидка діагностика: план дій для швидкого пошуку вузького місця

Коли свіжий хост «здається повільним», не починайте з тюнінгу додатку. Почніть з критичних шляхів системи. Цей план впорядкований: перші перевірки ловлять найпоширеніші та найвпливовіші режими відмов.

Перш за все: машина голодує чи хвора?

• Перевірте навантаження та насичення: CPU, iowait, тиск пам’яті.
• Перевірте failed сервіси: мережа, синхронізація часу, монтажі сховищ, агенти.
• Перевірте диск повний / іноди: це класика, бо працює.

cr0x@server:~$ uptime
10:20:11 up  1:24,  1 user,  load average: 0.12, 0.06, 0.02

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 6758208  88240 650240    0    0     1     4   75   98  1  1 98  0  0
 0  0      0 6758120  88240 650240    0    0     0     0   70   90  0  0 100 0  0
 1  0      0 6758020  88240 650240    0    0     0    12   88  120 2  1 97  0  0
 0  0      0 6757908  88240 650240    0    0     0     0   66   85  0  0 100 0  0
 0  0      0 6757800  88240 650240    0    0     0     0   69   89  0  0 100 0  0

Інтерпретація: Високий wa означає i/o wait; зростаючий r — runnable процеси, що накопичуються; ненульові si/so — свапінг. Вирішіть, чи ви CPU-bound, I/O-bound чи memory-bound.

Друге: чи є сховище лімітом?

• Перевірте латентність і завантаження пристрою.
• Перевірте помилки файлової системи та стан монтажів.
• Перевірте джерела write amplification (логи, журналювання, балакучі сервіси).

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0-31-generic (server) 	02/05/2026 	_x86_64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.21    0.00    0.62    0.05    0.00   98.12

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await  r_await  w_await
vda              5.00    8.00    80.0   120.0    0.00    0.50   2.10   1.10     0.90     1.25

Інтерпретація: await зростає, а %util наближається до 100 — це вказує на насичення. Якщо латентність висока без реального навантаження, ваш бекенд обмежений.

Третє: чи мережа є вузьким місцем?

• Перевірте втрати пакетів і RTT до ключових залежностей.
• Перевірте затримку DNS і відмови.
• Перевірте ретрансляції та помилки інтерфейсу.

cr0x@server:~$ ip -s link show ens3 | sed -n '1,12p'
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:2a:1b:2c brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      1283942    9321      0       0       0       0
    TX:  bytes packets errors dropped carrier collsns
       902211    8010      0       0       0       0

cr0x@server:~$ dig +stats +time=2 +tries=1 archive.ubuntu.com A | tail -n 5
;; Query time: 21 msec
;; SERVER: 10.20.0.53#53(10.20.0.53)
;; WHEN: Thu Feb 05 10:22:01 UTC 2026
;; MSG SIZE  rcvd: 79

Інтерпретація: Інтерфейс без помилок/дропів; DNS швидкий. Якщо час запиту — сотні/тисячі мілісекунд, DNS — ваш генератор «випадкової» латентності.

Четверте: перевірте залежності додатка, а не тільки додаток

Бази даних, брокери повідомлень, об’єктне сховище, провайдери аутентифікації та ліцензійні сервери можуть бути вузьким місцем. Швидка діагностика означає ідентифікацію, яка залежність повільна, а потім — який шар (мережа vs сховище vs CPU) це викликає.

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: диск заповнюється за ніч

Корінна причина: Логи за замовчуванням надто докладні, journald без обмежень або додаток записує debug-логи в /var/log без ротації.

Виправлення: Обмежте journald, налаштуйте logrotate і відокремте /var або /var/log для хостів з інтенсивними логами. Перевірте за допомогою journalctl --disk-usage і df -h.

2) Симптом: SSH працює, але інсталяція пакетів випадково зависає

Корінна причина: Резолвер DNS частково зламаний; один резолвер таймаутиться, викликаючи періодичні затримки.

Виправлення: Використайте resolvectl status для ідентифікації серверів, видаліть мертві резолвери та перевірте час запитів за допомогою dig +stats. Якщо ви використовуєте systemd-resolved у режимі stub, впевніться, що upstream-и коректні.

3) Симптом: TLS-помилки, «certificate not yet valid», дивні помилки автентифікації

Корінна причина: Час не синхронізований; chrony/NTP вимкнено або заблоковано.

Виправлення: Увімкніть синхронізацію часу, переконайтесь, що UDP 123 до джерел NTP дозволений (або що використовує ваше середовище), перевірте timedatectl і chronyc tracking.

4) Симптом: «сервер повільний» тільки під час бекапів

Корінна причина: Задача резервного копіювання насичує диск I/O або мережу; немає обмеження пропускної здатності; снапшоти викликають copy-on-write ампліфікацію на певних файлових системах.

Виправлення: Заміряйте iostat -xz під час бекапу, встановіть обмеження швидкості, плануйте в непікові години і розгляньте розташування, дружнє до снапшотів. Тестуйте швидкість відновлення, а не лише бекапу.

5) Симптом: перезавантаження триває вічно, потім сервіси відсутні дані

Корінна причина: fsck або монтажі падають; том даних не змонтований; система продовжує з порожніми директоріями.

Виправлення: Використайте systemctl --failed, journalctl -b і findmnt. Додайте x-systemd.automount або залежності, якщо доречно, але не маскуйте помилку. Переконайтесь, що точки монтування не створюються мовчки в корені.

6) Симптом: регресія продуктивності після «тюнінгу»

Корінна причина: Зміна kernel/sysctl параметрів без базових вимірів; використання гайдів під тюнінг, написаних для інших ядер або сховищ.

Виправлення: Зафіксуйте базу (fio, iostat, vmstat) перед тюнінгом. Змінюйте одну змінну за раз, записуйте результати та будьте готові відкотити. Продакшн — не ваша лабораторія.

7) Симптом: періодичні обриви з’єднань під навантаженням

Корінна причина: Невідповідність MTU або PMTU discovery заблоковано; іноді лише великі пакети падають.

Виправлення: Перевірте за допомогою ping -M do та тестуйте між ключовими вузлами. Виправте MTU послідовно по шляху або дозволіть фрагментацію/ICMP за політикою.

8) Симптом: не можна зайти під час інциденту; доступ має лише один адміністратор

Корінна причина: Немає break-glass шляху, немає другого адміністративного ключа, немає документованого доступу до консолі.

Виправлення: Додайте щонайменше два адміністративні ключі, підтвердіть sudo, задокументуйте console/out-of-band доступ і протестуйте його. «Думаю, працює» — це не контроль.

Три корпоративні міні-історії з передової

Міні-історія №1: Інцидент через неправильне припущення

Компанія A розгорнула нову партію серверів додатка. Білд був «стандартний», команда пишалась: автоматизоване провіжнінг, однакові пакети, ідентичні типи інстансів. Вони навіть мали чекліст, але той більше нагадував список покупок: встановити агент, встановити додаток, готово.

Через два тижні з’явилися інтермітентні помилки: таймаути бази даних, потім хвилі відновлень. Графіки CPU виглядали нормально. Пам’ять — теж. Команда БД наполягала, що це не вони, що технічно було правдою і культурно підозріло.

Причина — одне неправильне припущення: що сховище за віртуальними дисками VM — local SSD. Насправді ні. Зміна в кластері віртуалізації перемістила ці ВМ на мережевий рівень блочного сховища з агресивним кешуванням і непередбачуваною хвостовою латентністю. Під нормальним навантаженням було нормально. Під сплесками випадкова латентність запису зростала, локальна черга додатку накопичувалась, і всі підряд вважалися підозрюваними.

Виправлення було прозаїчним: вони додали просту перевірку fio в pipeline provisioning, зафіксували перцентилі латентності і провалювали білди, що потрапляли на невірний клас сховища. Також вони відокремили директорію черги на виділений том з передбачуваною продуктивністю. Інцидент навчив їх не «оптимізувати», а підтверджувати, за що вони платять.

Міні-історія №2: Оптимізація, яка обернулась проти

Компанія B мала проблему, що виглядала як проблема зі зберіганням: великий об’єм логів від балакучого сервісу. Хтось запропонував «швидку перемогу»: змонтувати файлову систему для логів із більш агресивними опціями, щоб зменшити записи. Змінили опції монтування і підправили кілька sysctl з гайду. Першу годину виглядало добре. Усі пішли додому задоволені.

Але потім стало гірше. Після некоректного перезавантаження (обслуговування хоста, нічого екзотичного) файловій системі потрібне було відновлення. Час старту виріс. Гірше — сервіс відновився з тонкою втратою даних у локальному стані, бо припускав певну fsync-семантику, яку послабили «оптимізацією». Додаток не був для цього готовий. Більшість не готові.

Болючим було не лише регрес — а й відсутність вимірів. Немає бази I/O. Немає запису, що саме змінили. Немає швидкого плану відкату. Команда витратила більше часу на доведення причинності, ніж на фікс.

Вони врешті відкотили до безпечних дефолтів, перемістили логи на окремий том з жорсткою ротацією і зменшили шум на джерелі. Довгостроковий урок: якщо ви не можете пояснити тюнінг в одному абзаці і перевірити його до/після, це не тюнінг. Це cargo cult.

Міні-історія №3: Нудна, але правильна практика, що врятувала день

Компанія C керувала флотом внутрішніх сервісів без блиску: планувальники, glue API, малі БД. Нічого для конференцій. У команди була звичка, що здавалася надто обережною: після кожної свіжої інсталяції вони запускали тест відновлення.

Не щорічний дриж. Не «ми перевірили систему бекапу». Саме відновлення невеликої підмножини даних з таргету резервної копії в альтернативну директорію на новому хості. Кожного разу. Ритуал так укорінився, що став частиною definition of done для провіжнінгу.

Одного дня вони обернули облікові дані для таргету бекапу. Нові креденшали були розгорнуті на більшості хостів, але не на всіх. Моніторинг показував, що бекапи «йдуть», але частина падала з помилками аутентифікації. Помилки маскувалися retry-петлею, яка логувала ворнінги, що ніхто не читав, бо логи були галасними.

Тест відновлення впіймав проблему одразу на нових хостах. Команда виправила rollout креденшалів до того, як розрив став катастрофою. Ніяких героїчних вчинків, ніякої «war room», жодного вихідного. Просто нудна практика з високим сигнал/шум співвідношенням.

Питання та відповіді

1) Наскільки суворим має бути цей чекліст для девелоп середовищ?

Суворішим, ніж ви думаєте. Dev-системи — де народжуються погані дефолти, які потім просуваються у продакшн через «в staging працювало». Можна пропустити деякі жорсткі hardening-правила, але не пропускайте бази, синхронізації часу та перевірки розкладки дисків.

2) Використовувати ext4, XFS чи ZFS?

Використовуйте ext4 або XFS, коли потрібна передбачувана, зрозуміла операція і вам не потрібні просунуті функції снапшотів/реплікації. Використовуйте ZFS, коли ви дійсно використовуватимете його сильні сторони (контрольно-сума, снапшоти, реплікація) та зможете запускати його дисципліновано.

3) Чи swap ще актуальний на серверах?

Так. Правильна відповідь залежить від навантаження й терпимості до відмов. Невеликий swap може пом’якшити спайки і запобігти OOM-kill. Але неконтрольований свап може знищити латентність. Вирішіть явно, налаштуйте моніторинг і протестуйте під навантаженням.

4) Чи потрібен хост-фаєрвол, якщо в мережі є security groups?

Зазвичай так. Security groups можуть бути неправильно застосовані, дубльовані або тимчасово відкриті. Хост-фаєрвол — це друга застава. Він також документує намір прямо на машині.

5) Який мінімум обсерваторії для одного сервера?

Персистентні логи з ротацією/лімітами, метрики CPU/пам’яті/дискової латентності/мережі та моніторинг синхронізації часу. Якщо після інциденту ви не можете відповісти «що змінилося?» — у вас недостатньо інструментів.

6) Як уникнути інцидентів «диск повний» без надмірної інженерії?

Відокремлюйте /var або принаймні /var/log коли можливо, обмежуйте journald, налаштовуйте logrotate і моніторьте файлові системи з алертами ще до 95%.

7) Коли варто робити бенчмарк диска за допомогою fio?

Одного разу на чистій системі, щоб встановити базу, і знову після будь-якої зміни бекенду зберігання (новий хост ВМ, новий тип тома, зміни шифрування). Тестуйте акуратно — не рубайте продакшн-диски.

8) Що перш за все перевіряти, коли «додаток повільний» на свіжому хості?

Дискова латентність (iostat), тиск пам’яті (vmstat) і затримка DNS (dig +stats). Ці три найчастіше маскуються під проблеми додатку.

9) Як переконатися, що монтажі не падають мовчки?

Використовуйте findmnt у health-чекатах, переконайтесь, що systemd-юнити залежать від монтажів коли потрібно, і стежте за логами завантаження. Уникайте дизайнів, де відсутній том призводить до того, що додаток пише в корінь без уваги.

10) Що документувати після свіжої інсталяції?

Версії ОС/ядра, розкладка дисків і типи ФС, мережева конфігурація (IP/маршрути/DNS), джерела синхронізації часу, політика фаєрволу, політика оновлень і результати перевірки резервного копіювання/відновлення. Якщо це не записано — це ніби не сталося.

Висновок: наступні кроки, які справді приживаються

Чекліст для свіжої інсталяції — не бюрократія. Це зниження латентності у ваших майбутніх інцидентах. Хвилини, витрачені зараз, купують вам швидкість пізніше: швидшу діагностику, безпечніші зміни, менше «як ми до цього дійшли?» сюрпризів.

Зробіть наступне:

1. Перетворіть це на рунбук, який ваша команда зможе виконати без вас. Збережіть його поряд з інфраструктурним кодом.
2. Автоматизуйте перевірки, які можна автоматизувати: failed units, використання диска, синхронізацію часу, базовий fio-тест (де безпечно) і перевірки політик фаєрвол/SSH.
3. Вимагайте доказ для резервних копій: одне відновлення на новому хості, задокументоване як артефакт.
4. Фіксуйте бази (CPU/пам’ять/диск/мережа) і зберігайте їх. Без баз у вас лише думки.

Якщо нічого більше не зробите, пам’ятайте тезу: ви не встановлюєте сервер. Ви встановлюєте майбутній інцидент. Зробіть його добрим до вас.