Не зупиняйтеся на першій несправності.
Перша несправність, яку ви знаходите, майже ніколи не є єдиною. Наш метод розплутування багатопричинного збою: ранжуйте причини за внеском, а не за гучністю, читайте першоджерела на рівні ядра замість панелей, знімайте по одній несправності за раз і вважайте будь-який симптом, що повернувся, цілком новою діагностикою.
У цій статті 6 розділів
- У багатопричинному збої кілька несправностей одночасно носять один і той самий симптом. Виправлення найгучнішої відчувається як прогрес і майже нічого не змінює.
- Метод: ранжуйте причини за внеском, а не за гучністю. Виправляйте в цьому порядку. Вимірюйте знову на межі, що відмовила, після кожної окремої зміни.
- Коли виправлення тримається, а симптом повертається, не застосовуйте виправлення повторно. Діагностуйте заново з нуля. Той самий симптом не означає ту саму причину.
- Відновлення теж має порядок: спочатку зупиніть безпосередній тригер, доведіть стан перед будь-яким деструктивним кроком, тримайте кожен крок оборотним.
Ваш сайт падає. Хтось знаходить правдоподібну несправність, виправляє її й оголошує перемогу. Сайт лежить далі або повертається і знову падає на наступному тригері. Виправлення зупинилося на першій несправності, а в найгірші дні за нею стоять ще чотири. Це дисципліна, яка не зупиняється.
Правило перше: ранжуйте за внеском, а не за гучністю
Найгучніший симптом є жахливим ключем сортування. Приклад: ядро кричить про суперечку за дисковий ввід-вивід, але двигуном каскаду є завислий resolver, що тримає кожен worker, а найбільшим постійним рушієм є шторм файлів сесій, якого не включала жодна перша теорія. Ранжуйте причини за тим, яку частку збою вони спричиняють, і виправляйте в цьому порядку.
- Суперечка за дисковий ввід-вивід (гучний симптом)
- Завдання, яке всі підозрюють
- Resolver, якого ніхто не підозрює
- Resolver: двигун
- Шторм сесій: найбільший рушій
- Завдання: реальне, але не рушій
Правило друге: читайте першоджерела, а не панелі
Панелі узагальнюють. Ядра свідчать. Коли шари не погоджуються, перемагає ядро. Канонічний перший прохід по будь-якому заклиненому Linux-хосту є тим самим коротким списком щоразу, а далі одна евристика, яку варто взяти в рамку: є запас, а сайт лежить, означає несправність застосунку або залежності, а не брак потужності. Диск із завантаженням у частки відсотка, тоді як workers висять, означає суперечку за блокування, а не ввід-вивід, хоч би що казав графік.
# the canonical first pass on a wedged Linux box
dmesg -T | tail -50 # OOM kills, hung tasks, hardware complaints
journalctl --list-boots # did this box reboot when you think it did?
last -x reboot | head # corroborate the reboot story
cat /etc/resolv.conf # who does this box think answers DNS?
iostat -x 5 3 # is the disk actually busy, or just blamed?
cat /proc/<pid>/stack # where exactly is that worker stuck?
strace -p <pid> -c -f # a few seconds: is it even making syscalls?Десять хвилин першоджерел варті більше за пообіддя археології по панелях.
Правило третє: знімайте по одній несправності за раз
Одна зміна, потім повторне вимірювання на межі, що відмовила, перш ніж торкатися наступного шару. Ця дисципліна відчувається повільною і є найшвидшим із доступного, бо дві одночасні зміни, які взаємодіють, не кажуть вам нічого про жодну з них. Перевірка робиться пошарово: виправте resolver, доведіть розв'язання імен на хості; розчистіть шторм, доведіть стани workers; потім рухайтеся вище.
Правило четверте: не довіряйте моменту «ми це виправили»
Коли виправлення тримається, а симптом повертається через кілька годин, рефлекс підказує застосувати виправлення сильніше. Натомість виміряйте знову. Запитання, яке треба поставити, просте: звідки ви знаєте, що воно робить ввід-вивід? Кілька секунд strace, які не ловлять жодного системного виклику, означають, що workers заблоковані в ядрі на блокуванні, а не роблять ввід-вивід узагалі, і саме так знаходять справжній рушій замість того, щоб його замазати. Коли симптом повертається після справжнього виправлення, це інша несправність в тому самому одязі.
Правила з п'ятого по сьоме: відновлення теж має порядок
Зупиніть безпосередній тригер, перш ніж торкатися причини.
Якщо кластер валить опитування моніторингу, спочатку зупиніть опитування, відновіть позицію, усуньте причину і лише потім застосовуйте заплановану зміну до здорового кластера.
Доведіть стан перед будь-яким деструктивним кроком.
Том, позначений як пошкоджений, спершу проходить перевірку цілісності лише для читання, перш ніж хтось зніме прапорець чи потягнеться до відновлення. Саме відновлення має свої пастки. Знайте їх до того, як ступити.
Тримайте кожен крок оборотним.
Резервна копія перед дотиком. Відкладіть убік, не видаляйте. Перезавантажте конфігурацію, а не перезапускайте, під навантаженням. Панічний крок, який неможливо скасувати, ніколи не є правильним кроком.
Правило восьме: закрийте діру для всіх
Кожен новий шаблон відмови стає іменованою передстартовою перевіркою в еталонній конфігурації. Метод є не лише способом розплутати поганий ранок. Він є способом не дати тому самому ранку повторитися будь-де ще.
Прямі відповіді
Чому проблема мого сервера повертається після кожного виправлення?+
Бо інцидент має більше ніж одну причину, а кожне виправлення усунуло одну. Коли виправлення тримається, а симптом повертається, діагностуйте заново від перших принципів. Той самий симптом не означає ту саму причину.
Як знайти справжню кореневу причину високого навантаження на сервер?+
Спочатку першоджерела: dmesg для OOM і завислих завдань, iostat, щоб перевірити, чи диск справді зайнятий, стек процесу або кілька секунд трасування, щоб побачити, де застрягли workers. Ранжуйте знайдене за внеском у збій, а не за тим, наскільки гучно воно виглядає.
Що означає високе навантаження при простоюючому диску?+
Зазвичай суперечку за блокування або завислу залежність, а не брак потужності. Наявний запас при лежачому сайті вказує на несправність застосунку чи залежності, і додавання ресурсів нічого не змінює.
Чи варто перезапускати сервіс, який падає, щоб його виправити?+
Не поки тригер усе ще активний. Якщо щось його раз у раз убиває, перезапуск повторює падіння. Спочатку зупиніть безпосередній тригер, потім усуньте причину, потім перезапускайте в здоровий стан.
Який метод постмортему інциденту є хорошим?+
Перелічіть кожну несправність, що зробила внесок, а не лише першу. Ранжуйте за внеском. Зафіксуйте ознаку, яка викрила кожну. І перетворіть кожну діру на постійну передстартову перевірку, щоб вони не могли зійтися знову. Якщо постмортем має рівно одну причину для повного збою, прочитайте його двічі.
Друга думка щодо впертого інциденту?
Якщо він повертається, у нього більше причин, ніж знайшов останній звіт. Принесіть нам історію симптомів, ми принесемо метод.
Поговоріть з інженеромВи дійшли до кінця.
Застосуйте прочитане на практиці
Що ви запускаєте?
Розкажіть нам про навантаження, трафік і вимоги до відновлення. Почніть з конструктора сервера або обговоріть деталі з інженером.
Написано інженерами, які будують і експлуатують інфраструктуру, про яку йдеться.Поговоріть з інженером