‘Format C:’ та інші команди, що зруйнували вихідні

Чому гинуть вихідні: руйнівні команди досі з нами

«Format C:» став жартом, бо він відображав істину: комп’ютери виконують саме те, що ви їм наказали, а не те, що ви мали на увазі. Сучасні системи лише дають більше способів помилитися із точністю. Замість одного диска — шари LVM, RAID-контролери, які віртуалізують реальність, multipath імена пристроїв, контейнерні overlay-файлові системи, ефемерні хмарні томи та оркестраційні системи, що можуть масштабувати вашу помилку.

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

Ось операційний паттерн, який варто запам’ятати: рутинне завдання обслуговування перетинається з невизначеністю (який пристрій який?) під тиском часу (тривоги лунають). Інженер намагається бути ефективним. Ефективність перетворюється на швидкість. Швидкість перетворюється на здогадки. Здогадки перетворюються на тікет «дані відсутні» і менеджера, що питає, чому резервні копії не вирішили все автоматично.

Цитата, яку варто приклеїти до монітора — бо вона вірна, навіть коли вам цього не хочеться, — це перефразована думка Джона Оллспоу: інциденти рідко є результатом однієї поганої людини; вони виникають, коли нормальні люди орієнтуються в нечітких системах.

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

Жарт 1/2: руйнівна команда — як бензопила: чудовий інструмент, жахливий іграшка для нервів.

Факти та історія для постмортемів інцидентів

• Початковий DOS-команді FORMAT було не лише «стерти»; вона записувала структури файлової системи. Це розрізнення важливе й сьогодні: «форматування» може означати скидання метаданих, а не повне занулення.
• Раннє упорядкування дисків у BIOS робило ідентичність диска нестабільною. Те, що виглядало як «Disk 0», могло змінитися після апаратних змін — сьогоднішній еквівалент це перенумерація /dev/sdX після перезавантажень або заміни HBA.
• Принцип Unix «все — файл» зробив пристрої придатними для запису як файли. Це і сила, і небезпека: dd байдуже до того, чи ціль — тестовий образ, чи ваш завантажувальний диск.
• Багато файлових систем «видаляють» шляхом видалення посилань, а не затирання вмісту. Ось чому судова експертиза іноді вдається, і чому безпечне стирання — це окрема проблема.
• Device-mapper, LVM і multipath додали нові абстракції. Вони вирішили проблеми (гнучкість, HA-шляхи), але ускладнили питання «який це диск?» під тиском.
• Файлові системи copy-on-write змінили режими відмов. Снапшоти можуть врятувати від видалення, але фрагментація і облік простору можуть неприємно здивувати під час відновлення.
• Хмарне зберігання зробило диски одноразовими — і люди так почали ставитися до даних. «Просто перебудувати інстанс» нормально, поки ви не зрозумієте, що стан зберігався на локальному instance store.
• Enterprise RAID-контролери можуть «мовчати» про подробиці. Вони показують логічні томи, що приховують фізичну топологію, тому заміна «не того диска» може все одно зламати потрібний RAID.
• Автоматизація збільшила радіус ураження. Та сама IaC, що може відбудувати фліт, може й стерти фліт, якщо неправильно задано області видимості або ціль.

Режими відмов: як люди потрапляють на невірну ціль

1) Неоднозначна ідентичність: проблема «який це /dev/sdb?»

Імена пристроїв у Linux — не ідентифікатор. Це порядок. Порядок — це підказка. На системах з кількома HBA, NVMe-namespace, iSCSI LUN або подіями hotplug, відображення між /dev/sdX і «диском, до якого ви думаєте, що торкаєтеся» — як підкидання монети, замасковане під детермінізм.

Серйозні оператори використовують стабільні ідентифікатори: WWN, серійник, шляхи by-id і UUID файлових систем. Помилка — думати, що можна «швидко глянути lsblk». Під тиском інциденту «швидко» стає «достатньо», а «достатньо» стає «ой».

2) Неправильний контекст: продакшн проти стейджингу, хост проти контейнера, вузол проти кластера

Чимало «руйнівних команд» виконувалися на правильній машині — але не в правильному середовищі. Або всередині контейнера, уявляючи, що це хост. Або на вузлі Kubernetes, коли том був прикріплений десь інде. Помилки контексту виникають через оманливі підказки в промптах, множинні SSH-сесії і довіру до м’язової пам’яті замість перевірок.

3) Команди, що здаються безпечними, бо ви їх уже використовували безпечно

rm -rf — класика, але сучасні хіти включають mkfs на не тому пристрої, parted на неправильному диску, zpool labelclear до впевненості у бекапах та «скрипти очищення», що припускають постійність шляхів пристроїв. Самі по собі команди не злі; проблема — відсутність перевірки.

4) Оптимізація під видом правильності

Коли системи повільні, люди креативлять. Вимикають бар’єри, збільшують глибину черги, тонують dirty ratios, монтують з ризикованими опціями або змінюють поведінку writeback. Деякі оптимізації легітимні, але все, що змінює порядок записів або семантику надійності, може перетворити мерехтіння електрики на корупцію. Дозволяються виправлення продуктивності; неперевірені компроміси щодо надійності — ні.

5) Спроби відновлення, що ускладнюють відновлення

Найпоширеніший вбивця відновлення — це продовження записів на диск після випадкового видалення. Друге місце посідає «повторне створення» файлової системи, думаючи, що відновить точки монтування. Коли ви запускаєте mkfs, ви перезаписали ключові метадані. Частково відновити ще можливо, але ви перейшли від «відновлюємо зі снапшоту» до «дзвоніть в сервіс відновлення даних і моліться».

Жарт 2/2: продавці відновлення даних не рахують по годинах; вони рахують, скільки разів ви казали «це швидко».

Три корпоративні міні-історії (досить реальні, щоб боліти)

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

У компанії була невелика група реплік бази даних для аналітики. Старшого інженера попросили «витерти та перебудувати найстарішу репліку», бо її латентність зберігання була гірша за інші. На хості було два NVMe-пристрої: один для ОС, інший для даних. У тикеті пристрій даних описали як «другий NVMe». Така формулювання — як заклик до хаосу.

На тому конкретному хості після нещодавнього оновлення прошивки порядок нумерації змінився. Імена пристроїв залишилися /dev/nvme0n1 та /dev/nvme1n1, але який з них був «даними» — виявився інвертований порівняно з пам’яттю інженера. Він виконав mkfs.xfs /dev/nvme1n1, вважаючи, що це диск даних. Насправді це був диск ОС. Вузол припинив участь у кластері прямо під час виконання команди, як це й буває.

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

Постмортем був не про команду. Він був про припущення: «другий диск = диск даних». Виправлення не було «будь уважнішим». Виправлення — стандартизувати на стабільних ідентифікаторах, маркувати пристрої в автоматизації і вважати «репліку» за «продакшн, поки не доведено протилежне».

Міні-історія №2: Оптимізація, що зіграла злий жарт

Сервіс із великим обсягом записів відчував проблеми з латентністю записів. Інженери бачили спайки під час піків, і команда застосунку вимагала «швидкої перемоги». Хтось запропонував підлаштувати опції монтування файлової системи та параметри VM, щоб знизити латентність, дозволивши більш агресивний writeback. Зміна пройшла під час вікна техобслуговування, була валідована синтетичним бенчмарком і розгорнута.

Тиждень латентність виглядала краще. Команда оголосила перемогу. Потім стався непланований подія живлення в стійці — короткий, брудний, такий, що «не повинен був траплятися», поки не трапився. Після перезавантаження кілька вузлів повідомили про непослідовність файлових систем. Декілька повернулися з корупцією, що вимагала відновлення з бекупів. Швидке рішення перетворилося на повільне відновлення.

Корінь проблеми не в тому, що «тюнінг — погано». Він у тюнінгу без моделі загрози для надійності. Бенчмарки не включають браун-аути. А опція монтування, що підходить для кеш-тиру, може бути катастрофічною для первинного джерела правди. Якщо ви міняєте семантику порядку записів, треба документувати радіус ураження і тестувати сценарії відмов, а не тільки щасливі шляхи.

Тривале покращення було нудним: кращі вимірювання write amplification, розділення «гарячих» та «холодних» даних, вибір апаратури, що відповідає навантаженню. Ризикований тюнінг відкатали, і команда додала політику: зміни продуктивності, що торкаються надійності, потребують підпису storage/SRE і плану інжекції відмов.

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

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

Одного вечора інженер на чергуванні демонтував орендодавця. У тікеті було «видалити датасет pool/customers/acme». Він випадково ввів zfs destroy -r pool/customers/acme-prod, бо, звісно, назви були схожі. Команда пройшла миттєво, і датасет зник. Ось той момент, коли шлунок намагається покинути тіло через туфлі.

Але політика зі снапшотами була виконана. Снапшот існував від двох хвилин до того, і реплікація на вторинний сайт була актуальною. Відновлення пройшло як контрольована процедура: зупинити залежні сервіси, відкотити датасет до снапшоту та відновити роботу. Без дзвінків постачальникам. Без археології. Інцидент став невеликою миттю замість катастрофи для клієнта.

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

Практичні завдання: команди, виводи та рішення (12+)

Це завдання, які ви можете виконувати під час рутинної роботи та під час інцидентів. Кожне включає: команду, що означає її вивід, і яке рішення з нього випливає. Команди орієнтовані на Linux, бо саме там відбувається більшість сучасних «format C:» моментів, але принципи універсальні.

Завдання 1: Підтвердьте, де ви зараз (ідентичність хоста та середовище)

cr0x@server:~$ hostnamectl
 Static hostname: prod-db-07
       Icon name: computer-vm
         Chassis: vm
      Machine ID: 9a2c3b...
         Boot ID: 4b113c...
  Virtualization: kvm
Operating System: Ubuntu 22.04.4 LTS
          Kernel: Linux 5.15.0-97-generic
    Architecture: x86-64

Значення: Це показує hostname, віртуалізацію та ОС. Якщо ви очікували стейджинг і бачите prod-, зупиніться.

Рішення: Якщо ідентичність не точно відповідає тикету зміни — відступіть. Підключіться через правильний бастіон/профіль.

Завдання 2: Зробіть промпт, що кричить «PROD» (швидка перевірка)

cr0x@server:~$ echo "$PS1"
\u@\h:\w\$

Значення: Бляклий промпт заохочує помилки контексту.

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

Завдання 3: Перелічіть блокові пристрої зі стабільними ідентифікаторами

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MODEL,SERIAL,WWN,MOUNTPOINTS
NAME        TYPE  SIZE MODEL          SERIAL        WWN                MOUNTPOINTS
nvme0n1     disk  476G Samsung SSD    S4EVNX0R...   0x5002538d...       
├─nvme0n1p1 part  512M                             /boot
└─nvme0n1p2 part 475G                             /
nvme1n1     disk 1.75T Intel SSD     BTTV1234...   0x55cd2e41...       
└─nvme1n1p1 part 1.75T                             /var/lib/postgresql

Значення: Ви бачите, який диск підкладений під які точки монтування, плюс серійник/WWN для ідентифікації.

Рішення: Якщо планується руйнівна дія — зафіксуйте WWN/серійник у журналі змін. Працюйте з тією ідентичністю, а не з «nvme1n1».

Завдання 4: Перевірте шляхи пристроїв через /dev/disk/by-id

cr0x@server:~$ ls -l /dev/disk/by-id/ | sed -n '1,12p'
total 0
lrwxrwxrwx 1 root root 13 Jan 21 10:11 nvme-INTEL_SSDPE2KX020T8_BTT... -> ../../nvme1n1
lrwxrwxrwx 1 root root 13 Jan 21 10:11 nvme-SAMSUNG_MZVLW512HMJP_S4E... -> ../../nvme0n1
lrwxrwxrwx 1 root root 15 Jan 21 10:11 nvme-eui.55cd2e4141414141 -> ../../nvme1n1
lrwxrwxrwx 1 root root 15 Jan 21 10:11 nvme-eui.5002538d22222222 -> ../../nvme0n1

Значення: Ці симлінки дають відносно стабільні імена. EUI/WWN-стиль IDs — те, що потрібно в автоматизації.

Рішення: Використовуйте шлях by-id в скриптах і runbook. Приклад: /dev/disk/by-id/nvme-eui.55cd....

Завдання 5: Підтвердьте, що змонтовано і хто це використовує

cr0x@server:~$ findmnt -rno TARGET,SOURCE,FSTYPE,OPTIONS / /var/lib/postgresql
/ /dev/nvme0n1p2 ext4 rw,relatime,errors=remount-ro
/var/lib/postgresql /dev/nvme1n1p1 xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k

Значення: Показує тип файлової системи та опції монтування. Якщо ви збираєтеся витерти диск, який змонтовано — це погано.

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

Завдання 6: Визначте процеси, що записують у точку монтування

cr0x@server:~$ sudo lsof +f -- /var/lib/postgresql | sed -n '1,8p'
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
postgres 2312  pg   cwd    DIR  259,1     4096    2 /var/lib/postgresql
postgres 2312  pg    10u   REG  259,1 10485760  123 /var/lib/postgresql/base/16384/2600
postgres 2312  pg    11u   REG  259,1  8388608  124 /var/lib/postgresql/base/16384/2601

Значення: Якщо ви бачите активні записи, файлову систему не можна вважати «холостою».

Рішення: Зупиніть сервіс або злити вузол перед обслуговуванням диска. Якщо не можете зупинити — перенесіть або відкладіть роботу.

Завдання 7: Подивіться тиск диску в реальному часі («чи сховище — вузьке місце?»)

cr0x@server:~$ iostat -xz 1 3
Linux 5.15.0-97-generic (prod-db-07)  01/21/2026  _x86_64_  (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    3.22    8.45    0.00   76.23

Device            r/s     w/s   rkB/s   wkB/s  await  %util
nvme0n1          12.0   110.0   512.0  4096.0   2.10  18.0
nvme1n1         180.0   240.0  8192.0 16384.0  21.50  98.0

Значення: Високі await і %util близько до 100% вказують на насичення пристрою або підвищену латентність.

Рішення: Якщо nvme1n1 має 98% завантаження з 21ms await і ваш SLO очікує низьких ms, діагностуйте навантаження (черги, write amplification) перш ніж «оптимізувати» опції монтування.

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

cr0x@server:~$ df -hT /var/lib/postgresql
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/nvme1n1p1  xfs  1.8T  1.7T   90G  95% /var/lib/postgresql

Значення: 95% заповнення може викликати фрагментацію, проблеми з виділенням та спайки латентності записів.

Рішення: Якщо ФС вище ~85–90% для інтенсивного запису — плануйте нарощення або чистку. Не «виправляйте продуктивність», відключаючи засоби безпеки.

Завдання 9: Перевірте, що про це думає шар RAID/LVM

cr0x@server:~$ sudo pvs; sudo vgs; sudo lvs -a -o +devices
  PV         VG   Fmt  Attr PSize   PFree
  /dev/sda2  vg0  lvm2 a--  931.00g 12.00g
  VG   #PV #LV #SN Attr   VSize   VFree
  vg0    1   2   0 wz--n- 931.00g 12.00g
  LV   VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  root vg0  -wi-ao---- 100.00g                                            /dev/sda2(0)
  data vg0  -wi-ao---- 819.00g                                            /dev/sda2(25600)

Значення: Якщо ваш «диск» насправді PV у VG, його витерши — ви витираєте все в цій VG.

Рішення: Якщо бачите LVM, трактуйте стек як систему. Плануйте зміни на правильному шарі і оновлюйте діаграми/runbook.

Завдання 10: Підтвердьте ZFS пули та датасети перед видаленням

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:12:03 with 0 errors on Tue Jan 20 03:10:22 2026
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            /dev/disk/by-id/ata-WDC_WD80...      ONLINE       0     0     0
            /dev/disk/by-id/ata-WDC_WD80...      ONLINE       0     0     0

errors: No known data errors

Значення: Топологія пула і ідентичність пристроїв явні. Якщо ви бачите /dev/sdX тут — виправте це, перш ніж це стане міграційним кошмаром.

Рішення: Якщо збираєтесь видаляти/замінювати диск, переконайтеся, що оперуєте точно тим by-id пристроєм, що в zpool status.

Завдання 11: Зробіть снапшот перед ризиковими операціями (приклад ZFS)

cr0x@server:~$ sudo zfs snapshot -r tank/customers/acme@pre-decom-2026-01-21
cr0x@server:~$ sudo zfs list -t snapshot -o name,used,refer -r tank/customers/acme | tail -n 3
tank/customers/acme@pre-decom-2026-01-21     0B  1.2T

Значення: Снапшот існує і спочатку дешевий (0B), бо посилається на існуючі блоки.

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

Завдання 12: Запустіть dry-run видалення (де можливо) і звузьте охоплення

cr0x@server:~$ rsync -aHAXn --delete /srv/app/ /srv/app.new/ | sed -n '1,8p'
deleting old-cache/tmp123
deleting old-cache/tmp124
./
config/
config/app.yaml

Значення: -n показує, що б змінилося. Слово «deleting» має викликати пильний огляд.

Рішення: Якщо dry run показує несподівані видалення, виправте include/exclude правила перед запуском без -n.

Завдання 13: Спіймайте «ой, не та директорія» перед rm -rf

cr0x@server:~$ pwd; ls -la
/var/lib/postgresql
total 24
drwx------  19 pg   pg  4096 Jan 21 10:02 .
drwxr-xr-x   3 root root 4096 Jan 10 09:11 ..
drwx------   5 pg   pg  4096 Jan 21 10:02 base
drwx------   2 pg   pg  4096 Jan 21 10:02 global

Значення: Якщо ви в каталозі даних і ваша наступна команда — «cleanup», ви граєтеся з вдачею.

Рішення: Використовуйте абсолютні шляхи у руйнівних командах. Якщо мусите використовувати відносні шляхи — явним чином виведіть pwd спочатку і читайте його, ніби підписуєте контракт.

Завдання 14: Доведіть, що блочний пристрій — це саме той, що ви маєте на увазі (перевірка тільки для читання)

cr0x@server:~$ sudo blkid /dev/nvme1n1p1
/dev/nvme1n1p1: UUID="2a1d7c8f-3f2d-4b9d-9a7d-2ddfdd5d8b9a" TYPE="xfs" PARTUUID="b3d1..."

Значення: Це показує, яка ФС існує і її UUID.

Рішення: Якщо ви очікували «без файлової системи», а бачите валідний XFS/ext4 підпис — зупиніться. Ви майже стираєте щось реальне.

Завдання 15: Перевірте останні kernel-логи на скиди диска та помилки

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvme|reset|I/O error|blk_update_request' | tail -n 8
[Tue Jan 21 10:05:11 2026] nvme nvme1: I/O 123 QID 4 timeout, aborting
[Tue Jan 21 10:05:11 2026] nvme nvme1: Abort status: 0x371
[Tue Jan 21 10:05:12 2026] nvme nvme1: resetting controller
[Tue Jan 21 10:05:14 2026] blk_update_request: I/O error, dev nvme1n1, sector 983040 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0

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

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

Завдання 16: Підтвердьте поведінку TRIM/discard (бо «очищення» може нашкодити)

cr0x@server:~$ lsblk -D -o NAME,DISC-ALN,DISC-GRAN,DISC-MAX,DISC-ZERO
NAME     DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1         0      512B       2G         0
nvme1n1         0      512B       2G         0

Значення: Пристрій підтримує discard. Залежно від файлової системи та опцій монтування, видалення може викликати discard/TRIM і ускладнити судову відновлюваність.

Рішення: Якщо ви розраховуєте на відновлення «undelete», вважайте, що discard значно знижує шанси. Віддавайте перевагу снапшотам/бекупам над надією.

Швидкий план діагностики: що перевіряти першим/другим/третім

Це послідовність «перестаньте гадати». Вам не потрібна кімната для криз — потрібні дисципліна й готовність швидко визнати помилку.

Перше: доведіть, що саме відмовляє (симптом чи джерело)

1. Чи це латентність, помилки чи відсутні дані для користувача? Відсутні дані вказують на руйнівну дію або корупцію. Латентність вказує на конкуренцію, насичення або деградацію.
2. Перевірте шаблон помилок застосунку. Таймаути часто відповідають I/O wait; «no such file» — видалення/проблеми з монтуванням; помилки контрольних сум — корупція.
3. Підтвердьте, що ви на правильному хості й шарі. Контейнер проти хоста має значення. Шлях в контейнері може відображатися в том, якого ви не очікували.

Друге: класифікуйте вузьке місце (CPU, пам’ять, диск, мережа, блокування)

1. CPU і черга виконання: якщо load високий, але iowait низький — це не передусім сховище.
2. Тиск пам’яті: якщо відбувається свопінг, усе може виглядати як затримка диску, але насправді це нестача пам’яті.
3. Насичення диску: високе %util і зростаючий await вказують на черги; корелюйте з піковими навантаженнями.
4. Мережа: якщо сховище віддалене (iSCSI, NFS, хмарний блок) — виміряйте мережеву латентність/втрати.
5. Блокування і fsync-штурми: бази даних можуть самі створювати I/O-проблеми через чекпоінти або інтенсивні операції синхронізації.

Третє: оберіть найменш ризикову наступну дію

1. Якщо можуть бути видалені або пошкоджені дані: зупиніть записи. Заморозьте пацієнта. Зробіть снапшоти (або LVM-снапшоти), якщо ще можливо.
2. Якщо це продуктивність: спочатку збирайте докази (iostat, vmstat, dmesg). Потім застосовуйте оборотні пом’якшувальні заходи (обмеження швидкості, переміщення навантаження, додавання ємності).
3. Якщо підозрюєте апаратне: не «ремонтуйте», форматуючи. Ізолюйте, переключайте, замінюйте.

Поширені помилки: симптоми → корінь проблеми → виправлення

1) «Я відформатував не той диск»

Симптоми: система не завантажується; монтування не вдається; підпис файлової системи змінився; сервіс аварійно зупинився.

Корінь: ідентичність диска ґрунтувалася на /dev/sdX або «другий диск», а не на стабільних ID; відсутні пре-флайт перевірки; немає снапшотів.

Виправлення: використовуйте /dev/disk/by-id у runbook; вимагаючи lsblk з серійником/WWN; впровадьте пре-оп снапшот там, де можливо; виконувати руйнівні дії у режимі техобслуговування.

2) «rm -rf видалив більше, ніж очікувалося»

Симптоми: раптово відсутні файли; сервіси не стартують; конфігураційні каталоги зникли; логи показують видалення.

Корінь: використано відносний шлях з неправильного робочого каталогу; розгортання оболонки; змінна була порожня (rm -rf "$DIR" при незаданому DIR) або містила «/».

Виправлення: використовуйте абсолютні шляхи; ставте set -u у скриптах, щоб падати на незаданих змінних; додавайте перевірки-щити, як-от «каталог має відповідати regex»; використовуйте dry run (rsync -n) для масових видалень.

3) «dd записав нулі не в той пристрій»

Симптоми: таблиця розділів зникла; файлову систему не змонтувати; blkid нічого не повертає; дані виглядають порожніми.

Корінь: плутанина шляхів пристроїв; копіпейст помилка; змішування if= і of=.

Виправлення: ніколи не запускайте dd без кроку перевірки на читання; віддавайте перевагу безпечнішим інструментам для стирання; коли мусите використовувати dd, виведіть команду, підтвердіть ціль by-id і вимагайте перевірки колеги для продакшну.

4) «Ми оптимізували продуктивність диска і отримали корупцію пізніше»

Симптоми: після перезавантаження або збою журнал не відновлюється; помилки контрольних сум у базі; потрібна ремонт файлової системи.

Корінь: змінені опції монтування або параметри ядра, що впливають на надійність; відключені бар’єри; неправильно налаштований RAID write cache без батареї/флеш-захисту.

Виправлення: ставте семантику надійності в рамки дизайну; проводьте тести інжекції відмов; документуйте, які шари можуть міняти надійність заради швидкості (кеш) і які не можуть (джерело істини).

5) «Усе повільно, але тільки інколи»

Симптоми: періодичні спайки латентності; iowait спайки; таймаути застосунків групуються у прогнозовані часи.

Корінь: фонові роботи (scrub, бекап, компакція); завершення снапшотів; відновлення RAID; витрати кредитів burst для хмарних томів.

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

6) «Ми не можемо відновити, бо продовжували писати»

Симптоми: відновлення не вдається; видалені файли перезаписані; інструменти undelete нічого корисного не знаходять.

Корінь: продовження записів після усвідомлення видалення; повторне створення файлової системи; автоматичні сервіси очищення, що працюють.

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

Перевірочні списки / покроковий план

A. Перед будь-якою руйнівною командою зі сховища (wipe, mkfs, destroy, labelclear)

1. Підтвердіть середовище: ідентичність хоста, обліковий запис/профіль, контекст кластера.
2. Ідентифікуйте ціль по стабільному ID: WWN/серійник, не sdX/nvmeX.
3. Доведіть, що змонтовано: findmnt на цілі.
4. Доведіть, хто пише: lsof або статус сервісу.
5. Створіть ручку відкату: снапшот/датасет- снапшот/LVM-снапшот або снапшот на шарі зберігання. Якщо не можете — отримаєте явне схвалення для невідворотної зміни.
6. Сформулюйте радіус ураження в одному реченні: «Це витре диск, що обслуговує /var/lib/postgresql на prod-db-07.» Якщо не можете написати це речення — ви не розумієте зміну.
7. Перегляд колегою: інша людина читає точний шлях пристрою та команду. Не «виглядає добре». Вони мають повторно вивести ціль.
8. Виконання з запобіжниками: використовуйте by-id шляхи, інтерактивні підтвердження, де можливо, і логування виводу команд.

B. Якщо підозрюєте, що виконали не ту команду (контроль шкоди в перші 5 хвилин)

1. Зупиніть записи негайно. Зупиніть сервіси, від’єднайте томи, cordon вузли — усе, що зупиняє подальше поширення збитків.
2. Не запускайте імпульсивно «команди ремонту». Особливо mkfs, інструменти «repair» або перерозбивку диска.
3. Зберіть стан: dmesg, lsblk, blkid, mount, статус шару зберігання.
4. Зробіть снапшот, якщо можливо. Навіть пошкоджений снапшот може зберегти докази і запобігти подальшій втраті.
5. Ескалюйте рано. Storage і SRE повинні бути в курсі до того, як хтось почне «швидке відновлення».

C. Якщо проблема — «сховище повільне» (безпечна реакція продуктивності)

1. Спочатку виміряйте: iostat, vmstat, per-process I/O та kernel-логи.
2. Визначте головних «говорунів»: який процес або робота створює I/O.
3. Пом’якшіть оборотно: обмежте пакетні задачі, перемістіть навантаження, додайте репліки, збільшіть кеш, зменшіть паралелізм.
4. Лише потім тюньте: і тільки з планом відкату та оцінкою надійності.

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

1) Чи «форматування» те саме, що «стирання»?

Ні. Форматування зазвичай записує метадані файлової системи (суперблоки, структури алокації). Стирання означає більш широке перезаписування. Обидва можуть зруйнувати можливість відновлення.

2) Чому /dev/sdX ненадійний?

Бо його присвоюють за порядком виявлення. Порядок виявлення може змінитися при перезавантаженнях, оновленнях прошивки, зміні шляхів або додаванні пристроїв. Використовуйте шляхи by-id, серійники, WWN або UUID.

3) Якщо я видалив неправильний каталог, чи потрібно перемонтнути в readonly?

Якщо ви підозрюєте, що буде потрібне відновлення даних і ви можете дозволити простій — так, припиніть записи. Записи перезаписують звільнені блоки і зменшують шанси на відновлення.

4) Чи робить TRIM/discard відновлення неможливим?

Не завжди, але це значно ускладнює процес. Якщо блоки видалені, пристрій може трактувати їх як незадіянні і повертати нулі. Припускайте, що discard знижує ваші шанси.

5) Чи замінюють снапшоти резервні копії?

Ні. Снапшоти відмінні для швидкого відкату і «ой»-відновлення, але зазвичай ділять ту ж доменну зону відмов. Вам усе одно потрібні окремі резервні копії (і перевірені відновлення).

6) Який найбезпечніший спосіб виконувати ризиковані команди в продакшні?

Зробіть ідентичність однозначною (by-id), звузьте охоплення (точний шлях/пристрій), додайте ручку відкату (снапшот) і вимагайте іншої людини, щоб вона підтвердила ціль.

7) Чому оптимізації іноді призводять до корупції пізніше?

Бо деякі тюнінги змінюють семантику надійності: порядок записів, поведінку flush, безпечність кешу або припущення про захист від втрати живлення. На перший погляд усе може бути добре, поки збій це не перевірить.

8) Я запустив mkfs на неправильному розділі. Чи є надія?

Іноді. Припиніть записи негайно. Не запускайте mkfs повторно. Зафіксуйте метадані і залучіть досвідчену допомогу з відновлення. Успіх залежить від того, що було перезаписано і скільки записів відбулося з того часу.

9) Як запобігти скриптам робити «rm -rf /»-подібні пошкодження?

Використовуйте set -euo pipefail, валідуйте змінні, вимагайте allowlist’ів і реалізуйте підтвердження «ви впевнені?» для інтерактивного використання. Для автоматизації використовуйте поетапні релізи та dry-run режими.

10) Яка найкраща звичка, щоб уникнути руйнівників вихідних?

Примусіть себе ідентифікувати цілі за стабільною ідентичністю і проговорити радіус ураження вголос (або в тикеті) перед натисканням Enter.

Висновок: наступні кроки, що реально зменшують ризик

Якщо ви візьмете з епохи «format C:» одну річ у сучасні операції — це має бути ось що: комп’ютери буквальні, а продакшн — безжальний. Руйнівні команди не зникнуть. Мета — зробити їх навмисними, перевіреними та відкатними.

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

1. Оновіть runbook, щоб використовувати стабільні ідентифікатори (/dev/disk/by-id, WWN/серійник, UUID). Перестаньте документувати «/dev/sdb», як ніби це закон природи.
2. Впровадьте обов’язкову політику снапшотів перед руйнівними діями, де технічно можливо, і відстежуйте виключення явно.
3. Наробіть м’язову пам’ять «зупинити записи» для підозрюваних інцидентів втрати даних. Перші п’ять хвилин вирішують, чи буде відновлення простим або археологією.
4. Відокремте тюнінг продуктивності від змін надійності з гейтом на рецензію і планом відкату.
5. Практикуйте відновлення не в продакшні: відновлення з бекапу, відкат снапшотів, імпорт пулів, монтування томів. Найкращий час вчитися — не під час відмови клієнта.

Вихідні — для сну, а не для спостереження за прогресбаром відновлення, коли ви переосмислюєте кожний життєвий вибір, що призвів до «лише швидкої команди».