Galaxy Note 7: смартфон, який перетворив аеропорти на комедію

Коли аеропорти стали частиною життєвого циклу пристрою

Історія Galaxy Note 7 — це не «у телефону була несправність». Таке формулювання занадто заспокійливе. Воно дозволяє всім вдавати, що реальний світ — це чиста лабораторна стійка і акуратна дошка в Jira.
Насправді сталося ближче до інциденту, який розлився в фізичну інфраструктуру: авіалінії додали це до оголошень, працівники біля хвіртки отримали нові сценарії, а пасажири почали робити аналіз ризиків у черзі на посадку.

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

Ось центральний урок: коли режим відмови має швидку криву займання (термічний розгін, каскадна ескалація привілеїв, некерований процес ущільнення), ви не маєте права налагоджувати в продакшні.
Ваш «час на розуміння» коротший за «час до шкоди». Це й є визначення нічного кошмару інциденту.

Короткий жарт №1: Note 7 був єдиним телефоном, який міг забезпечити вам додатковий огляд без купівлі квитка.

Короткі конкретні факти, що мають значення

Це фрагменти історичного контексту, які реально змінюють рішення. Не тривіа. Не «пам’ятаєте колись». Саме ті факти, що визначають, як ви будуєте, відвантажуєте й реагуєте.

1. Випущений у серпні 2016 року і швидко похвалений за дизайн та функції — отже, комерційні стимули рухатись швидко були дуже реальними.
2. Перше відкликання почалося на початку вересня 2016 року після повідомлень про перегріви та пожежі; реакція була велика й публічна, а не тихим «сервісним бюлетенем».
3. Заміщені пристрої також відмовляли — друга хвиля інцидентів зруйнувала наратив «ми виправили це» і змусила повністю припинити модель.
4. Авіалінії та регулятори втрутилися: пристрій заборонили в польоті великі авіаційні органи, перетворивши споживчий продукт на об’єкт відповідності.
5. Корінний механізм відмови — внутрішні замикання в батареї, що призводили до термічного розгону; літій-іонні елементи можуть вибухати, коли пошкоджено сепаратор.
6. Проектування батареї та упаковка мали вузькі допуски: тонкі зазори, механічні навантаження та технологічні варіації виробництва могли стати фабрикою коротких замикань.
7. Samsung зрештою припинила виробництво конкретної моделі, взявши на себе як прямі витрати (повернення, логістика), так і непрямі (довіра, репутаційні втрати).
8. Це змінило поведінку галузі: тестування безпеки батарей, посилена перевірка постачальників та консервативні рішення щодо релізів отримали нову терміновість на ринку.

Зверніть увагу, чого тут немає: «одна погана партія», «зловмисний постачальник», «випадковий дефект». Це заспокійливі міфи.
Note 7 не став відомим через те, що один пристрій відмовив. Він став відомим через те, що відмова відтворювалася в масштабі.

Ланцюг відмов: від міліметрів до маяка тривоги

Фізика: літій-іонні батареї не торгуються

Літій-іонна батарея — це контрольована хімічна система, упакована в тонку оболонку. Вона поводиться передбачувано, коли все залишається в допусках: механічне вирівнювання, цілісність сепаратора, відстані між електродами, обмеження заряджання, температурний режим.
Коли всередині відбувається коротке замикання, воно може генерувати тепло швидше, ніж елемент може його відвести. Тепло прискорює реакції. Це породжує ще більше тепла. Цикл — це термічний розгін.

У продуктивних системах ви бачили цей патерн: петля зворотного зв’язку, що стабільна у нормальних умовах і катастрофічна поза допусками.
Конверт Note 7 був надто вузьким, а реальність груба.

Інженерний режим відмови: щільне пакування зустрічає варіації виробництва

Надійний апарат — це не просто «гарний дизайн». Це дизайн плюс технологічність виготовлення плюс покриття тестами плюс час. Батарея в тонкому телефоні — гра міліметрів і точок тиску.
Навіть якщо середній пристрій в порядку, хвости розподілу — це місце, де репутації йдуть у небуття.

Інцидент Note 7 широко трактують як пов’язаний з внутрішніми дефектами батарей, що могли призвести до замикань — думайте про механічні напруги та проблеми сепаратора, а не «помилка програмного забезпечення зробила батарею вибухонебезпечною».
Чим агресивніше пакування, тим більше ви залежите від ідеального вирівнювання та ідеального контролю процесу. Ідеал — не виробнича стратегія.

Чому друга хвиля важила більше, ніж перша

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

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

Аеропорти як вимушені руни для реагування

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

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

Читання історії Note 7 крізь призму SRE

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

Надійність — це властивість «від краю до краю»

Пристрій включав хімію елементів, механічну упаковку, процеси виробництва, варіації ланцюга постачання, відбір QA, логістику дистрибуції, логістику відкликання і поведінку клієнтів.
Це система. І системи ламаються на швах.

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

Швидкість — це вразливість, коли ваша відмова швидка

Для повільних відмов можна спостерігати, трендувати й реагувати. Для швидких відмов ваші реальні інструменти — запобігання і контейнмент.
Термічний розгін — це швидко. Так само й помилки, що призводять до втрати даних. Так само і крадіжки облікових даних після експлуатації.

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

Цитата, яку варто повісити на стіні

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

Як має виглядати «якість постмортему», коли за всім спостерігає світ

Є різниця між постмортемом, який інформує, і постмортемом, який працює на практику.
Note 7 примусив проблему «публічної версії»: потрібна суворість без витоку чутливих даних про постачальників і ясність без надмірного спрощення.

Всередині вам досі потрібні важкі частини:

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

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

Ви не можете виконати adb під час аеропортного оголошення 2016 року, але ви можете провести дисципліновану діагностику систем, які відвантажують ваші продукти.
Нижче — практичні завдання, які я очікую від інженера SRE/зберігання під час інциденту класу «щось перегрівається»: швидкий триаж, ідентифікація вузького місця, захоплення доказів і контейнмент.
Кожне завдання містить (1) команду, (2) що означає типовий вивід, (3) рішення, яке ви приймаєте.

1) Перевірте сигнали термічного або апаратного рівня в ядрі

cr0x@server:~$ sudo dmesg -T | egrep -i 'thermal|overheat|throttle|mce|edac|hardware error' | tail -n 20
[Sun Jan 21 10:02:11 2026] CPU0: Package temperature above threshold, cpu clock throttled
[Sun Jan 21 10:02:12 2026] mce: [Hardware Error]: Machine check events logged

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

2) Швидко визначте троттлінг ЦП та температуру

cr0x@server:~$ sudo turbostat --Summary --quiet --show PkgTmp,Bzy_MHz,Busy%,IRQ,POLL --interval 2 --num_iterations 3
PkgTmp  Bzy_MHz  Busy%  IRQ    POLL
92      1800     78.21  12034  0.00
94      1700     80.05  11890  0.00
95      1600     79.88  12112  0.00

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

3) Отримайте швидкий огляд навантаження системи проти runnable-потоків

cr0x@server:~$ uptime
 10:05:19 up 31 days,  4:10,  3 users,  load average: 28.14, 26.77, 22.03

Значення: Середнє навантаження набагато вище за кількість CPU свідчить про насичення CPU або заблокований ввід/вивід, що збільшує кількість runnable-процесів.
Рішення: Негайно перевірте чергу виконання та i/o wait (наступні команди). Визначте, чи це CPU-bound, I/O-bound чи lock-bound.

4) Відокремте насичення CPU від очікування I/O

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.1.0 (server) 	01/21/2026 	_x86_64_	(16 CPU)

12:05:23 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
12:05:24 AM  all   22.11 0.00  6.02  41.33 0.00  0.54   0.00 29.99

Значення: Високий %iowait вказує, що CPU в основному чекають на зберігання/мережевий ввід-вивід.
Рішення: Перейдіть до діагностики зберігання/мережі; поки не «оптимізуйте код».

5) Підтвердіть затримки диска та черги

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20.01    0.00    5.22   42.18    0.00   32.59

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz  avgqu-sz   await  svctm  %util
nvme0n1         120.0  1800.0   12.0   210.0     248.0      9.30    6.20   0.45  85.00

Значення: await в мілісекундах плюс висока avgqu-sz вказують на чергування. Високий %util свідчить, що пристрій зайнятий.
Рішення: Визначте топ-писачів/читачів; розгляньте обмеження швидкості, перенесення гарячих наборів даних або масштабування.

6) Знайдіть процеси, що створюють I/O-тиск

cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ: 0.00 B/s | Total DISK WRITE: 220.00 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
21842 be/4  postgres   0.00 B/s  180.00 M/s  0.00 % 99.00% postgres: checkpointer
30111 be/4  root       0.00 B/s   35.00 M/s  0.00 % 90.00% rsync -a /var/lib/app/ /mnt/backup/

Значення: Є два очевидні писачі; один — контрольний пункт бази даних, інший — конкуренція резервного копіювання.
Рішення: Призупиніть/переплануйте резервне копіювання; налаштуйте параметри чекпоінта; подумайте про відокремлення цілі резервного копіювання від основного I/O шляху.

7) Перевірте заповненість файлової системи та виснаження інодів

cr0x@server:~$ df -h /var /mnt/backup
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  400G  388G   12G  98% /var
/dev/sdb1       3.6T  3.5T   70G  99% /mnt/backup

Значення: Майже повні файлові системи збільшують фрагментацію, уповільнюють операції з метаданими і створюють ризик жорстких збоїв при досягненні 100%.
Рішення: Розпочніть відновлення простору негайно; застосуйте квоти/правила зберігання; припиніть неважливі записування, поки не з’явиться запас.

8) Виявлення відкритих видалених файлів (диск «таємно повний»)

cr0x@server:~$ sudo lsof +L1 | head -n 8
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NLINK   NODE NAME
java     9121 app   12w   REG  259,2  7340032     0 123456 /var/log/app/debug.log (deleted)

Значення: Місце на диску не повернеться, поки процес не закриє файловий дескриптор.
Рішення: Перезапустіть або безпечно прокрутіть процес; виправте конфігурацію logrotate/service, щоб уникнути повторення.

9) Перевірте тиск пам’яті, що може маскуватися під «все повільно»

cr0x@server:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           64000       61000         900         600        2100        1200
Swap:           8192        7800         392

Значення: Низька доступна пам’ять і інтенсивне використання swap вказують на пейджинг; затримки підскочать по всій системі.
Рішення: Зменшіть пам’ятний слід, перезапустіть сервіси з витоком пам’яті або масштабуйтесь вгору/назовні; не ігноруйте swap-шторми.

10) Перевірте, що мережа не прихований вузький хребет (зберігання по мережі)

cr0x@server:~$ ss -s
Total: 2142 (kernel 0)
TCP:   1890 (estab 120, closed 1720, orphaned 0, timewait 1650)

Transport Total     IP        IPv6
RAW	  0         0         0
UDP	  12        10        2
TCP	  170       165       5
INET	  182       175       7
FRAG	  0         0         0

Значення: Велике число timewait і багато закриттів можуть вказувати на churn з’єднань; не обов’язково погано, але підозріло, якщо зростає затримка.
Рішення: Корелюйте з повторними передачами та падіннями інтерфейсу; вирішіть, чи налаштовувати keepalive, пулінг або виправити політику upstream LB.

11) Перевірте помилки/скидання інтерфейсу (вбивця «виглядає нормально»)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped overrun mcast
    9876543210  8123456  0       421     0       0
    TX:  bytes  packets  errors  dropped carrier collsns
    8765432109  7234567  0       97      0       0

Значення: Скидання на RX/TX можуть викликати хвостову латентність, повтори і «випадкові» таймаути.
Рішення: Дослідіть чергування, розміри кільцевих буферів NIC, драйвер/прошивку, перевантаження порту комутатора; розгляньте обмеження швидкості або QoS.

12) Перевірте стан накопичувача (S.M.A.R.T. / NVMe лог)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i 'critical_warning|temperature|percentage_used|media_errors|num_err_log_entries'
Critical Warning:                   0x00
Temperature:                       77 Celsius
Percentage Used:                   89%
Media and Data Integrity Errors:    2
Error Information Log Entries:      14

Значення: Висока температура, великий знос і зростаючі журнали помилок: пристрій старіє і фліртує з проблемою.
Рішення: Плануйте негайну заміну; зменшіть write amplification; перемістіть критичні навантаження; не чекайте, поки «critical_warning» зміниться.

13) Перевірте стан пулу ZFS і затримки (якщо застосовно)

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.
action: Replace the device and run 'zpool scrub' after the replacement is complete.
  scan: scrub repaired 0B in 00:21:13 with 0 errors on Sun Jan 21 09:40:01 2026
config:

	NAME        STATE     READ WRITE CKSUM
	tank        DEGRADED     0     0     0
	  mirror-0  DEGRADED     0     0     0
	    sda     ONLINE       0     0     0
	    sdb     FAULTED      0     0     0  too many errors

errors: No known data errors

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

14) Перевірте контролер RAID / шляхи дисків (загальний вигляд у Linux)

cr0x@server:~$ sudo multipath -ll
mpatha (3600508b400105e210000900000490000) dm-2 HP,MSA
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:1 sdc 8:32 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:1 sdd 8:48 active ready running

Значення: Шляхи мають різні пріоритети; якщо високопріоритетний шлях хиткий, ви побачите періодичні скачки латентності.
Рішення: Корелюйте з журналами SAN-комутатора та повідомленнями ядра; чисто переключіть шляхи або виправте проблемну гілку.

15) Захопіть докази для постмортему до того, як «поправите»

cr0x@server:~$ sudo tar -czf /tmp/incident-evidence-$(date +%F-%H%M).tgz /var/log/syslog /var/log/kern.log /etc/fstab /etc/sysctl.conf
tar: Removing leading `/' from member names

Значення: Ви зберегли ключові логи/конфіги для подальшого аналізу; видалення ведучого ‘/’ — нормальна поведінка tar.
Рішення: Збережіть архів поза хостом; потім застосуйте пом’якшення. Без доказів у вас будуть лише відчуття, а не виправлення.

Короткий жарт №2: Note 7 зробив «вимкнути й увімкнути знову» рекомендацією громадської безпеки.

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

Коли в продакшні «щось нагрівається» — буквално тепло, неконтрольована латентність, вибухове зростання помилок — у вас немає часу на повну теорію всього.
Потрібна коротка, повторювана послідовність, що швидко звужує простір пошуку і уникати двох класичних пасток: (1) гадання, (2) налаштування неправильного шару.

По-перше: стабілізуйте і обмежте радіус ураження

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

По-друге: вирішіть, чи ви CPU-bound, memory-bound чи I/O-bound

• CPU: високий %usr і низький idle, мінімальний iowait, стабільні частоти.
• Пам’ять: мала доступна пам’ять, swap in/out, зростання major faults, OOM kills.
• I/O: високий iowait, високе await пристроїв, зростання черг, мережеві повтори при віддаленому зберіганні.

По-третє: визначте топ-контриб’ютора і застосуйте найменш ризиковане пом’якшення

• Процес-найбільший споживач: ідентифікуйте за CPU або I/O і обмежте/зупиніть порушника.
• Перемістіть навантаження: евакуюйте на інші вузли або пули; переключіть на резерв, якщо архітектура це підтримує.
• Відкотіть зміну: якщо це почалося після розгортання/налаштування, відкотіть перед тим, як «оптимізувати».

По-четверте: збирайте докази, потім виправляйте клас відмов

• Захопіть логи/метрики/знімки конфігів.
• Напишіть коротку хронологію, поки пам’ять свіжа.
• Перетворіть пом’якшення на запобіжний гейт (тести, каниари, QA постачальника, ліміти навантаження).

Еквівалент Note 7: коли підозрюєте термічний розгін, ваш план — контейнмент, а не «можливо, це просто цей зарядний пристрій».
Коли відмова швидка й фізична, ваш відкат — «припинити використання».

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

Міні-історія 1: Інцидент, спричинений хибним припущенням

Компанія середнього розміру експлуатувала флот краєвих (edge) приладів, що збирали телеметрію й кешували медіа. Прилади були «загартовані», безвентиляторні і відправлялися у великій кількості.
Інженери припустили, що флеш-пам’ять витримає їхній патерн записів, бо у даташиті виробника були вказані показники витривалості, які здавалися щедрими.

Хибне припущення було тонким: вони сприйняли витривалість як середнє, а їхнє навантаження як репрезентативне. Так не було. Сервіс інжесту записував малі файли, активно синхронізував метадані і періодично проводив компресію.
Підвищилася write amplification. Прилади не помирали відразу. Вони загинули хвилею, одразу після закінчення гарантії, бо хвости розподілу зносу співпали.

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

Вирішення не вимагало героїчного патчу. Це була корекція дизайну: пакетні записи, зменшення частоти fsync, використання лог-структурованого підходу, який відповідав середовищу, і введення телеметричного гейта здоров’я для проактивної заміни.
Культурна корекція була жорсткішою: більше ніяких масових запусків апаратури без моделювання write amplification і валідації реальними робочими навантаженнями.

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

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

Команда SaaS хотіла швидші деплоя і дешевший обчислювальний ресурс. Вони ввімкнули агресивну компресію на томі бази даних і налаштували параметри ядра для «рідше скидувати брудні сторінки».
На папері це зменшило I/O і покращило пропускну здатність у бенчмарках. Панелі показників виглядали чудово тиждень.

Потім прийшов сплеск трафіку. Система накопичила величезне відставання брудних сторінок, і коли скидання нарешті відбулося, воно сталося як прорив дамби.
Латентність підскочила. Сервери додатку накопичили черги. Повтори підсилювали навантаження. Автоскейлер побачив CPU і масштабувався, роблячи базу даних ще зайнятішою. Охайна петля зворотного зв’язку перетворилася на спіраль.

Інженер на чергуванні спочатку ганявся за неправильним: за CPU застосунку. Проблема була не в CPU. Вона була в I/O-латентності, спричиненій їхнім «ефективним» налаштуванням.
Компресія не допомогла, коли вузьким місцем був writeback і глибина черги; вона додала накладні витрати CPU в найгірший момент і збільшила хвостову латентність.

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

Паралель з Note 7: проштовхування конверту заради тоншого, щільнішого пристрою — це оптимізація. Якщо ваші маржі надто малі, оптимізація стає відмовою.
За швидкість вам не ставлять плюс, якщо відмова ефектна.

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

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

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

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

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

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

Якщо ви хочете уникнути створення власного Note 7 — чи то апаратного, чи зберігання, чи програмного — припиніть робити ті самі категорійні помилки.
Ось патерни, які я бачу в реальних організаціях, написані так, як їх насправді говорять респондери інцидентів.

1) Симптом: «Відбувається лише у кількох користувачів»

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

2) Симптом: «Замінник повинен це виправити»

Корінна причина: Ви поміняли компоненти, не довівши, що контролюєте механізм відмови; вина — системна (допуски дизайну, технологічне вікно або інтеграція).
Виправлення: Підтвердіть пом’якшення планом відтворення і контейнментом режиму відмови. Якщо не можете безпечно відтворити — потрібні ширші запасні межі і консервативний контейнмент.

3) Симптом: «QA пройшло, отже продакшн неправий»

Корінна причина: Ваш QA не репрезентативний: неправильне навантаження, неправильна температура навколишнього середовища, неправильний режим заряджання/використання, недостатній час під навантаженням або недостатній розмір вибірки.
Виправлення: Тестуйте, як поводяться клієнти, а не як інженери бажають, щоб вони поводилися. Використовуйте soak-тести, варіації середовища і статистично значущі вибірки.

4) Симптом: «Ми можемо запатчити пізніше»

Корінна причина: Ви застосовуєте програмний рефлекс до швидкої фізичної відмови або до зміни, яку важко відкотити (прошивка, апаратне забезпечення, незворотний формат даних).
Виправлення: Відокремте «патчувані» класи від «потребують контейнменту». Для класів, що потребують контейнменту, відвантажувати слід лише з великими запасами і перевіреною логістикою відкату/відкликання.

5) Симптом: «Нам потрібно продовжувати відвантаження; зупинка виглядатиме погано»

Корінна причина: Некоректна ціна ризику. Ви оптимізуєте квартальні показники в обмін на довгострокову довіру та відповідальність. Також: пастка sunk cost з PR-бюджетом.
Виправлення: Попередньо визначте гейти серйозності з підтримкою керівництва. Зробіть «зупинити відвантаження» політикою, підкріпленою вимірюваними тригерами, а не дебатами під час паніки.

6) Симптом: «Реагування на інцидент хаотичне і суперечливе»

Корінна причина: Немає єдиного командира інциденту, незрозуміла відповідальність за повідомлення і відсутня спільна фактологічна хронологія.
Виправлення: Проводьте інцидент-командування серйозно: один IC, одне джерело істини, один зовнішній канал комунікації з технічним оглядом.

7) Симптом: «Наше виправлення погіршило ситуацію»

Корінна причина: Ви пом’якшили видимий симптом (тепло, латентність) збільшуючи навантаження в іншому місці (швидкість заряджання, writeback, повтори, одночасність).
Виправлення: Моделюйте петлі зворотного зв’язку. Додайте ліміти швидкості. Віддавайте перевагу граціозному деградуванню над «повною швидкістю до відмови».

Чеклісти / покроковий план

Чекліст A: Передзапусковий гейт «не відвантажувати відмову класу Note 7»

1. Визначте класи відмов і позначте, які з них вимагають контейнменту (ризик пожежі, втрата даних, невідновна корупція, питання безпеки).
2. Встановіть явні запаси: запас по теплу, запас по витривалості, запас по ємності, запас по відкату.
3. Тестуйте хвости: найгірша температура навколишнього середовища, найгірше навантаження, найгірша варіація постачання, тривале витримування.
4. Аудитуйте постачальників, ніби вони частина вашого виробничого середовища — бо вони нею є.
5. Вимагайте план відкату/відкликання, який є операційно здійсненним: логістика, комунікація з клієнтами, перевірка повернутих одиниць.
6. Інструментуйте з поля: телеметрія температури, циклів заряджання, рівня помилок, зносу і аномальної поведінки.
7. Стадіруйте релізи: кандіари, обмежені регіони, обмежені партії, контрольований ріст.
8. Попередньо напишіть повідомлення для клієнтів для класів високої серйозності, щоб не імпровізувати під час кризи.

Чекліст B: Перші 60 хвилин, коли з’являється відмова класу безпеки

1. Призначте командира інциденту і заблокуйте канали зв’язку.
2. Зупиніть нову експозицію: припиніть відвантаження, відключіть ризикові функції, призупиніть релізи, заморозьте партію виробництва, якщо підозрюється.
3. Зберіть докази: ідентифікатори уражених одиниць, умови навколишнього середовища, логи/телеметрія, дії клієнта перед відмовою.
4. Обмежте радіус ураження: визначте, які партії/версії/регіони уражені; дійте консервативно, якщо сумніви.
5. Оголосіть чітку дію для клієнтів: припинити використання, вимкнути живлення, повернути або застосувати пом’якшення — оберіть одне й зробіть незаперечним.
6. Відкрийте регуляторні/партнерські канали рано, якщо залучені зовнішні оператори (авіалінії, перевізники, дистриб’ютори).
7. Призначте два треки: контейнмент (зараз) і коренева причина (потім). Не змішуйте їх.

Чекліст C: Постмортем, що змінює результати (не лише відчуття)

1. Напишіть хронологію з точками рішення, а не лише подіями.
2. Документуйте режими відмов і докази для кожної виключеної гіпотези.
3. Перелічіть сприяючі фактори у категоріях: дизайн, процес, тестування, людський фактор, стимули.
4. Випишіть конкретні дії з власниками і кроками верифікації.
5. Додайте гейт-тести, що б зловили проблему або обмежили її раніше.
6. Оновіть руни і навчіть підтримку/операції на нові патерни розпізнавання.
7. Вимірюйте ефективність: менше інцидентів, знижений хвостовий ризик, покращений час виявлення.

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

1) Що насправді спричинило відмови Galaxy Note 7?

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

2) Чому сталося друге відкликання?

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

3) Це була проблема зарядного пристрою чи помилка ПЗ?

Зарядні пристрої й контроль заряджання можуть впливати на температуру, але клас інцидентів відповідав внутрішнім дефектам батареї, що призводили до замикань. ПЗ рідко робить здорову комірку самостійно займистою; однак воно може підштовхнути маргінальний дизайн за край.

4) Чому авіалінії заборонили конкретну модель телефону?

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

5) Який SRE-еквівалент термічного розгону батареї?

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

6) Як запобігти відмовам через «вузькі допуски» у продуктах?

Додавайте запас, валідуйте хвости і тестуйте в реалістичних умовах зловживання. Припускайте, що виробництво і поведінка користувачів дослідять кожен кут вашого конверту. Якщо ви не можете терпіти варіації — переробіть дизайн.

7) Що має робити компанія в момент підозри дефекту класу безпеки?

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

8) Яка найбільша помилка команд під час високопрофільних інцидентів?

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

9) Як уникнути ситуації «заміщені пристрої теж відмовляють» у вашому світі?

Не відвантажуйте пом’якшення, яке не можете валідувати. Використовуйте каниари, стадійні релізи і явні acceptance-тести, спрямовані на підозрюваний механізм відмови — не лише загальні регресійні набори.

10) Чому це важливо саме для інженерів зберігання?

Відмови в зберіганні часто мають ті ж огидні властивості: вузькі запаси (ємність, витривалість), неочевидні петлі зворотного зв’язку (уплотнення, write amplification) і повільне виявлення, поки все раптом не стане швидким і незворотним.

Практичні кроки далі

Galaxy Note 7 не був моралізаторським інженерним фолк-хітом. Це був системний урок, доставлений з димом.
Якщо ви керуєте продакшн-системами або відвантажуєте апарат, що лежить у кишенях людей — візьміть підказку: надійність — не функція, яку додають після презентації.

1. Напишіть ваші критерії «зупинити відвантаження» до того, як вони стануть потрібними. Якщо ви не можете описати тригер, ви будете сперечатися, поки клієнти постраждають.
2. Побудуйте тест-плани, орієнтовані на хвости, що відтворюють некрасиві кути: температура, сплески навантаження, варіація виробництва й неправильне використання.
3. Інструментуйте поле, щоб ви могли виявляти класи відмов рано і обмежувати їх за версією/партією/регіоном.
4. Практикуйте контейнмент, як ви практикуєте failover: тренування, руни, власники і шаблони комунікації.
5. Захистіть постмортем: збирайте докази, називайте сприяючі фактори і вводьте превентивні гейти, що б спіймали це раніше.

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