Статус сторінки: готова текстова версія. Runbook можна перенести до внутрішньої операційної документації та доповнити контактами, адресами серверів і процедурами конкретного оператора.

Призначення runbook

Аварійний runbook валідатора — це структурований набір інструкцій для швидкого реагування на критичні події на ноді Solana. Його мета: мінімізувати час простою, зберегти делегований стейк і запобігти штрафам (slash) під час відмов обладнання, програмних збоїв чи компрометації ключів.

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

Перед використанням цього runbook переконайтеся, що сервер валідатора налаштовано відповідно до чек-листа підготовки сервера валідатора.

Типи аварійних сценаріїв

Втрата синхронізації з мережею

Валідатор перестає отримувати або обробляти слоти, відстає від найвищого відомого слота (highest known slot) більш ніж на допустимий поріг. Причина може бути в мережевих обмеженнях, нестачі ресурсів процесора чи пам'яті, а також у проблемах з RPC-вузлами, через які валідатор отримує дані.

Відмова диска або пошкодження даних

Фізична відмова накопичувача, пошкодження файлової системи або логічна помилка в базі даних леджера (ledger). Це призводить до неможливості прочитати історію слотів і продовжити валідацію без відновлення з резервної копії або повної синхронізації з нуля.

Компрометація ключів

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

Падіння продуктивності та пропущені слоти

Валідатор залишається в мережі, але систематично не встигає обробляти призначені слоти. Причини: деградація диска (зниження IOPS), перевантаження CPU через сторонні процеси, нестача оперативної пам'яті з подальшим використанням swap, або неоптимальні налаштування ОС.

Порядок дій для кожного сценарію

Втрата синхронізації з мережею

  1. Перевірте стан ноди. Виконайте команду перевірки синхронізації (solana slot) і порівняйте поточний слот із найвищим відомим слотом у мережі. Зафіксуйте різницю в слотах.
  2. Перевірте мережеве з'єднання. Переконайтеся, що порти для P2P-комунікації відкриті та доступні. Перевірте наявність блокувань від фаєрвола або провайдера.
  3. Перевірте ресурси сервера. Оцініть завантаження CPU, використання RAM та дискового I/O. Якщо якийсь ресурс близький до 100 % — виявіть процес, що його споживає.
  4. Перевірте доступність ентріпойнтів. Переконайтеся, що валідатор може підключитися до принаймні одного ентріпойнту кластера.
  5. Перезапустіть процес валідатора. Якщо попередні кроки не виявили очевидної причини, виконайте контрольований перезапуск. Спостерігайте за логами протягом перших хвилин після запуску.
  6. Якщо синхронізація не відновлюється. Розгляньте можливість тимчасового перемикання на інші ентріпойнти або перевірку цілісності леджера.

Відмова диска або пошкодження даних

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

Компрометація ключів

  1. Негайно зупиніть ноду. Відключіть валідатор від мережі, щоб зловмисник не міг використовувати скомпрометовані ключі.
  2. Оцініть, які саме ключі скомпрометовані. Identity keypair, vote account keypair або обидва. Від цього залежить подальша послідовність дій.
  3. Створіть нові ключі на безпечному, ізольованому пристрої (offline-машині). Не використовуйте той самий сервер, на якому сталася компрометація.
  4. Оновіть конфігурацію валідатора новими ключами. Переконайтеся, що старі ключові файли фізично видалено з усіх носіїв.
  5. Якщо скомпрометовано vote account. Залежно від налаштувань авторизованих змінників (authorized voters), може знадобитися створення нового vote account з подальшим перереєструванням. Перевірте поточні правила кластера щодо таких змін.
  6. Проведіть розслідування. Визначте вектор атаки: слабкий пароль, відкритий доступ до файлів, шкідливе ПЗ. Усуньте вразливість перед повторним підключенням.
  7. Повідомте делегаторів (якщо у вас є канали комунікації) про інцидент та вжиті заходи.

Ризик: під час зміни ключів валідатор тимчасово втрачає делегований стейк і позицію в активному сеті. Час відновлення залежить від швидкості перереєстрації та поведінки делегаторів.

Падіння продуктивності та пропущені слоти

  1. Зафіксуйте масштаб проблеми. Визначте відсоток пропущених слотів за останню годину та порівняйте з типовим показником вашої ноди.
  2. Моніторинг ресурсів у реальному часі. Використовуйте системні утиліти для відстеження CPU, RAM, disk IOPS і мережевого трафіку під час обробки слотів.
  3. Перевірте стан диска. Деградація SSD — поширена причина поступового падіння продуктивності. Перевірте SMART-показники та фактичну швидкість читання/запису.
  4. Перевірте налаштування ОС. Переконайтеся, що swap вимкнено або мінімізовано, налаштовані відповідні ліміти відкритих файлів (ulimit) і планувальник вводу-виводу відповідає рекомендаціям для валідаторів Solana.
  5. Виявіть сторонні процеси. Перевірте, чи не запущено на сервері моніторингові агенти, бекапні сервіси або інші завдання, що конкурують за ресурси під час обробки слотів.
  6. За необхідності — плановий перезапуск з подальшим спостереженням. Якщо проблема системна (апаратна деградація), заплануйте міграцію на новий сервер.

Обмеження runbook

  • Runbook охоплює типові сценарії відмов і не може передбачити всі можливі комбінації збоїв, особливо пов'язаних із нетиповим апаратним забезпеченням або кастомними налаштуваннями ОС.
  • Інструкції не містять конкретних команд для кожної версії клієнта Solana. Перед виконанням перевірте актуальну документацію до вашої версії валідатора.
  • Сценарій компрометації ключів вимагає індивідуального аналізу. Універсальної послідовності кроків, що гарантує повне відновлення, не існує — дії залежать від архітектури ключового управління, яку ви обрали.
  • Runbook не замінює автоматизовану систему моніторингу з алертами. Він призначений для використання людиною, а не для інтеграції в CI/CD або auto-remediation пайплайни.
  • Часові оцінки (наприклад, тривалість повної синхронізації) залежать від поточного стану кластера, швидкості вашого з'єднання та апаратних характеристик і не наводяться тут через їхню мінливість.

Версія ресурсу

Ресурс «Аварійний runbook валідатора»: статична версія 1.0. Сторінка містить готовий робочий runbook і готова до практичного використання без очікування окремого інтерактивного інструмента. Остання редакційна перевірка: 2 серпня 2026 року.

Джерела