Моніторинг та аварійне відновлення

Цей розділ — операційний центр для команд, які утримують валідатори Solana на production-рівні. Тут зібрані діагностичні процедури, метрики, що вимагають негайного реагування, та перевірені сценарії відновлення після аварій. Усі команди супроводжуються вказівками щодо середовища, очікуваного результату та ризиків.

Операційні вимоги для «Моніторинг та аварійне відновлення» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.

Як працює система credits та root slot у Solana

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

Що таке credits у контексті валідатора

Credits — це внутрішня одиниця обліку активності валідатора. Валідатор отримує credits за кожен успішний голос (vote transaction), який підтверджує поточний слот. Credits не є токеном і не виводяться з мережі — це суто бухгалтерський показник лояльності та участі.

Як credits впливають на rewards

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

Root slot: визначення та значення

Root slot — це найвищий слот, який валідатор вважає остаточно фіналізованим (rooted). Коли supermajority мережі досягає консенсусу щодо певного слота, валідатор позначає його як root. Усі слоти нижче root вважаються незмінними. Якщо валідатор відстає і не може підтвердити новий root, він втрачає здатність брати участь у консенсусі.

Як відстежити credits та root slot

Передумови: валідатор запущений, RPC-порт доступний. Клієнт: Agave. Кластер: mainnet-beta.

Перевірка поточного root slot:

solana slot --url http://127.0.0.1:8899

Очікуваний результат: число, близьке до поточного слота мережі (перевірте на explorers). Різниця понад 150–200 слотів сигналізує про відставання.

Перевірка credits vote-акаунта:

solana vote-account <vote_account_pubkey> </vote_account_pubkey>

У виводі шукайте поле credits та порівняйте з попередньою епохою.

Зв'язок між epoch, credits та delinquent

У кожній епосі мережа обчислює, чи накопичив валідатор достатньо credits. Якщо значення нижче порогу, валідатор позначається як delinquent на початку наступної епохи. Це механізм автоматичного очищення від неактивних вузлів.

Типові питання про credits

• Credits скидаються щоразу? Ні, credits накопичуються протягом усього життя vote-акаунта. Але для розрахунку винагород використовується приріст за конкретну епоху.
• Чи можна відновити втрачені credits? Ні. Пропущені голоси означають втрачені credits назавжди.
• Чи впливає delinquent на credits? Перебування у delinquent не анулює наявні credits, але блокує накопичення нових, поки статус не буде знято.

Чому валідатор став delinquent: причини та рішення

Що таке delinquent статус

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

Як delinquent впливає на rewards

У delinquent-стані валідатор не отримує винагород. Крім того, стейкхолдери, які делегували на vote-акаунт delinquent-валідатора, не отримують прибуток, що створює ризик відделегації.

Основні причини delinquent

• Відставання за слотами (root slot занадто далеко від поточного). Найчастіша причина — недостатня продуктивність сервера або перевантаження диска.
• Збій процесу валідатора. Agave-процес впав і не перезапустився.
• Мережеві проблеми. Втрата зв'язку з достатньою кількістю peer-вузлів.
• Диск повний. Логи або snapshot-файли заповнили розділ, і валідатор не може писати дані.
• Некоректна конфігурація після оновлення. Зміна параметрів, що призвела до несумісності.

Як перевірити delinquent статус

Передумови: доступ до CLI Agave, підключення до кластера.

solana validators --url https://api.mainnet-beta.solana.com | grep <identity_pubkey> </identity_pubkey>

Очікуваний результат: якщо біля вашого identity є позначка (delinquent) — статус підтверджено. Альтернативно:

solana vote-account <vote_account_pubkey> --url https://api.mainnet-beta.solana.com </vote_account_pubkey>

Шукайте поле delinquent у виводі.

Кроки для виходу з delinquent

Delinquent знімається автоматично на початку наступної епохи, якщо валідатор відновив нормальну активність. Порядок дій:

1. Визначте причину (логи, моніторинг, стан диска).
2. Усуньте проблему (звільніть місце на диску, перезапустіть процес, відновіть мережу).
3. Переконайтеся, що валідатор наздоганяє поточний слот: solana slot має показувати зростання.
4. Дочекайтеся закінчення поточної епохи. Перевірте статус повторно.

Ризик: якщо проблема не усунута повністю, валідатор може знову стати delinquent у наступній епосі.

Запобігання повторному delinquent

• Налаштуйте моніторинг відстані до root slot (див. розділ про alerts).
• Зарезервуйте мінімум 15–20% вільного місця на розділі зі snapshot-даними.
• Налаштуйте автоматичний перезапуск сервісу через systemd.
• Після будь-яких змін інфраструктури перевіряйте стан валідатора протягом кількох епох.

Як аналізувати skip rate валідатора

Що таке skip rate та як він розраховується

Skip rate — це відсоток лідерських слотів, які валідатор пропустив (не створив блок). Розраховується як відношення кількості пропущених слотів до загальної кількості призначених лідерських слотів за певний період.

Допустимі та критичні значення skip rate

Уточнення: ці межі є типовими для mainnet-beta. Перевірте актуальні рекомендації спільноти операторів, оскільки пороги можуть змінюватися з оновленнями протоколу.

Інструменти для перевірки skip rate

Через CLI Agave:

solana show-validators --url https://api.mainnet-beta.solana.com | grep -A 5 <identity_pubkey> </identity_pubkey>

Також skip rate відображається на сторонніх дашбордах операторів. Для власного моніторингу використовуйте Prometheus-експортер метрик валідатора.

Причини високого skip rate

• CPU не встигає обробити лідерський слот (найчастіша причина).
• Дисковий I/O bottleneck під час запису блоку або snapshot.
• Мережева затримка (latency) до peer-вузлів перевищує допустиму.
• Конфлікт процесів на сервері (інші навантаження на CPU або диск).
• Некоректні налаштування sysctl (наприклад, обмеження мережевого буфера).

Покрокова діагностика високого skip rate

1. Перевірте завантаження CPU під час лідерських слотів: htop або mpstat 1. Якщо використання перевищує 90% на ядрах, що обслуговують валідатор — це причина.
2. Перевірте дисковий I/O: iostat -x 1. Зверніть увагу на %util та await на розділі з ledger-даними.
3. Перевірте мережеву затримку: ping до кількох відомих peer-вузлів. Latency понад 50–100 мс може бути проблемою.
4. Перевірте логи на наявність повідомлень про пропущені слоти (деталі у розділі аналізу логів).
5. Перевірте конфлікти процесів: systemd-cgtop або аналіз cgroup-споживання.

Оптимізація для зниження skip rate

• Ізолюйте валідатор на виділеному сервері без сторонніх навантажень.
• Використовуйте NVMe-диски для ledger та accounts.
• Налаштуйте sysctl: збільште мережеві буфери (net.core.rmem_max, net.core.wmem_max).
• Закріпіть процеси валідатора на конкретних ядрах через taskset або cgroups.
• Перевірте, що frequency scaling процесора встановлено на performance.

Моніторинг валідатора Solana: метрики, інструменти, дашборди

Ключові метрики валідатора

• Root slot distance — різниця між поточним слотом мережі та root slot валідатора. Критично: більше 200.
• Skip rate — частка пропущених лідерських слотів.
• Vote success rate — частка успішних голосів.
• Snapshot creation time — час створення snapshot. Різке зростання сигналізує про проблеми з I/O.
• Disk usage — заповненість розділів з ledger, accounts та snapshot.
• CPU usage — завантаження процесора, особливо під час лідерських слотів.
• Network peer count — кількість підключених peer-вузлів. Різке падіння — сигнал проблеми.
• Memory usage — споживання RAM процесом валідатора.
• Epoch progress — поточний слот у епосі відносно загальної кількості слотів в епосі.

Інструменти моніторингу

• Prometheus + node_exporter — базова інфраструктурна метрика (CPU, диск, пам'ять, мережа).
• Prometheus-експортер Agave — метрики валідатора (skip rate, root slot, vote success). Увімкнути через прапорець --metrics при запуску.
• Grafana — візуалізація метрик, дашборди.
• Alertmanager — маршрутизація сповіщень.
• journalctl / log-analyzer — аналіз логів (деталі у відповідному розділі).

Налаштування Grafana-дашборду

Рекомендована структура дашборду для валідатора:

• Рядок 1 (верхній): root slot distance, skip rate, vote success rate — великі цифри з кольоровим кодуванням.
• Рядок 2: графіки CPU, дискового I/O, мережевого трафіку — часові вікна 1 година / 6 годин / 24 години.
• Рядок 3: disk usage (гістограма), peer count, memory usage.
• Рядок 4: snapshot creation time, epoch progress.

Усі панелі повинні мати єдиний часовий діапазон із можливістю швидкого перемикання.

Alerts: які метрики відстежувати

Детальна конфігурація alerts — у відповідному розділі. Коротко: root slot distance, skip rate, disk usage, процес не запущений, snapshot creation failure.

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

1. Prometheus збирає метрики з node_exporter та Agave-експортера.
2. Grafana-дашборд створено та відображає всі ключові метрики.
3. Alertmanager налаштований, маршрути сповіщень перевірені.
4. Логи валідатора доступні через journalctl або централізовану систему.
5. Перевірено, що метрики оновлюються з очікуваною частотою (зазвичай кожні 10–15 секунд).
6. Проведено тестове сповіщення: зупинено процес валідатора та підтверджено отримання alert.

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

Чому alerts критичні для валідатора

Валідатор Solana працює безперервно. Більшість проблем (відставання, пропущені слоти, заповнення диска) мають вікно реагування від кількох хвилин до кількох годин до того, як станеться delinquent. Без автоматичних сповіщень оператор дізнається про проблему занадто пізно.

Ключові події для сповіщення

Канали сповіщень: Telegram, email, Slack

• Telegram — найшвидший канал для мобільного реагування. Рекомендується як основний для critical-алертів.
• Slack — зручно для командної роботи, інтеграції з runbook-процедурами.
• Email — резервний канал, корисний для логування та пост-інцидентного аналізу.

Рекомендована конфігурація: critical — усі три канали; warning — Telegram та Slack.

Налаштування через Prometheus Alertmanager

Передумови: Prometheus та Alertmanager встановлені та запущені. Агресор метрик Agave доступний.

Приклад правила для root slot distance у Prometheus (формат YAML):

groups:
- name: agave-validator
  rules:
  - alert: ValidatorRootSlotLag
    expr: solana_root_slot_distance > 150
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "Валідатор відстає на {{ $value }} слотів"
      description: "Root slot distance перевищує 150. Ризик delinquent."

У конфігурації Alertmanager вкажіть отримувачів (receivers) для кожного рівня серйозності з відповідними webhook-URL для Telegram та Slack.

Очікуваний результат: при перевищенні порогу Alertmanager надсилає сповіщення у вказані канали протягом 30–60 секунд.

Ризики: некоректна конфігурація webhook може призвести до мовчання алертів. Обов'язково протестуйте.

Тестування alerts

1. Зупиніть процес валідатора: sudo systemctl stop agave-validator.
2. Зачекайте 30–60 секунд.
3. Перевірте надходження сповіщення у всіх каналах.
4. Перезапустіть валідатор: sudo systemctl start agave-validator.
5. Перевірте, що alert автоматично зникнув після відновлення метрик.

Ризик тестування: зупинка валідатора на кілька хвилин у нормальному стані не призводить до delinquent, але уникайте цього наприкінці епохи.

Як аналізувати логи валідатора Solana

Де знаходяться логи валідатора

Якщо валідатор запущено через systemd (рекомендований спосіб), логи доступні через journalctl:

sudo journalctl -u agave-validator -f

Для історичних логів:

sudo journalctl -u agave-validator --since "2024-01-01" --until "2024-01-02"

Якщо валідатор запущено без systemd, логи виводяться у stdout/stderr процесу. Перенаправте їх у файл або використовуйте лог-менеджер.

Формат логів Agave

Agave використовує структурований формат логів. Типовий рядок містить:

• Timestamp (UTC)
• Level (INFO, WARN, ERROR)
• Модуль (наприклад, solana_core::validator)
• Повідомлення
• Контекстні поля (slot, hash, peer тощо)

Ключові типи повідомлень

• INFO — slot processed: нормальне підтвердження обробки слота.
• WARN — skip slot: валідатор пропустив лідерський слот.
• WARN — vote failed: голос не був прийнятий мережею.
• ERROR — snapshot failed: збій при створенні snapshot.
• ERROR — bank frozen: критична помилка обробки банку.
• WARN — duplicate slot: отримано дублікат слота (може бути нормою за певних умов, але часте повторення потребує уваги).

Фільтрація та пошук у логах

Знайти всі пропущені слоти за останню годину:

sudo journalctl -u agave-validator --since "1 hour ago" | grep -i "skip"

Знайти всі помилки snapshot:

sudo journalctl -u agave-validator --since "6 hours ago" | grep -i "snapshot" | grep -i "error\|fail"

Підрахувати кількість пропущених слотів за період:

sudo journalctl -u agave-validator --since "1 hour ago" | grep -c "skip"

Інструменти: journalctl, grep, лог-аналізатори

• journalctl — основний інструмент для systemd-сервісів. Підтримує фільтрацію за часом, пріоритетом (-p err), модулем.
• grep / rg — швидкий пошук за патерном у потоці логів.
• lnav — термінальний лог-аналізатор із автоматичним парсингом, фільтрацією за рівнем, пошуком.
• ELK / Loki + Grafana — централізовані рішення для кількох валідаторів. Рекомендується для інфраструктур з 3+ вузлів.

Типові патерни помилок у логах

• "Too many skips" — послідовне пропущення лідерських слотів. Дивіться діагностику skip rate.
• "No snapshot found" — валідатор не знайшов локальний snapshot при запуску. Перевірте шлях до snapshot-директорії.
• "Failed to open accounts file" — пошкодження файлу accounts. Може вимагати відновлення з snapshot.
• "Connection refused" — неможливо підключитися до peer-вузла. Перевірте мережу та фаєрвол.
• "Out of memory" — нестача RAM. Збільште обсяг пам'яті або перевірте налаштування swap.

Як діагностувати snapshot failures

Ознаки snapshot failure

• У логах з'являються повідомлення рівня ERROR з текстом про збій snapshot.
• Розмір snapshot-файлів у директорії не оновлюється (перевірте ls -la /mnt/snapshots/).
• Метрика snapshot creation time різко зростає або зникає.
• При перезапуску валідатор не може знайти актуальний snapshot і починає синхронізацію з нуля.

Типові причини

• Недостатньо місця на диску. Snapshot для mainnet-beta займає значний обсяг (перевірте актуальний розмір у документації Agave, оскільки він змінюється з ростом мережі).
• Дисковий I/O bottleneck. Створення snapshot інтенсивно використовує диск. Якщо %util близький до 100%, snapshot може не встигнути.
• Помилка файлової системи. Рідкісна, але можлива причина — пошкодження файлової системи на розділі зі snapshot.
• Некоректні права доступу. Процес валідатора не має прав запису в snapshot-директорію.
• OOM-kill. Процес створення snapshot був убитий через нестачу пам'яті.

Діагностика через логи

sudo journalctl -u agave-validator --since "6 hours ago" | grep -i "snapshot"

Шукайте повідомлення з рівнем ERROR або WARN. Типові патерни:

• "snapshot error: No space left on device" — заповнений диск.
• "snapshot serialization failed" — проблема з I/O або пам'яттю.
• "snapshot: permission denied" — права доступу.

Перевірте dmesg на наявність OOM-kill:

sudo dmesg -T | grep -i "oom\|killed process"

Ручне завантаження snapshot з альтернативного джерела

Передумови: валідатор зупинено. Вільне місце на диску — не менше розміру snapshot плюс 20% запасу. Кластер: mainnet-beta.

Попередження: завантажений snapshot має бути від надійного джерела. Неперевірений snapshot може містити пошкоджені дані.

1. Зупиніть валідатор: sudo systemctl stop agave-validator.
2. Збережіть поточні snapshot-файли (резервна копія): mv /mnt/snapshots /mnt/snapshots.bak.
3. Створіть нову директорію: mkdir -p /mnt/snapshots.
4. Завантажте snapshot з обраного джерела (перевірте актуальне джерело у спільноті операторів, оскільки URL змінюються).
5. Розпакуйте: tar xzf snapshot-*.tar.gz -C /mnt/snapshots/.
6. Перевірте права: chown -R solana:solana /mnt/snapshots.
7. Запустіть валідатор: sudo systemctl start agave-validator.
8. Перевірте логи на предмет успішного завантаження snapshot.

Відкат: якщо завантажений snapshot некоректний, поверніть резервну копію: rm -rf /mnt/snapshots && mv /mnt/snapshots.bak /mnt/snapshots та перезапустіть валідатор.

Запобігання snapshot failures

• Моніторьте вільне місце на диску (alert при 85% та 93%).
• Використовуйте окремий NVMe-диск для snapshot-директорії.
• Налаштуйте автоматичне видалення старих snapshot-файлів (залиште 2–3 останніх).
• Перевірте права доступу після будь-яких змін конфігурації.

Аварійне відновлення валідатора: стратегії та кроки

Що таке disaster recovery для валідатора

Disaster recovery (DR) — це сукупність процедур, що дозволяють відновити роботу валідатора після критичної аварії: повної втрати сервера, руйнування файлової системи, компрометації ключів або масивного відставання, що робить синхронізацію неможливою.

Типи аварій: апаратні, мережеві, програмні

• Апаратні: вихід з ладу сервера (CPU, RAM, материнська плата), відмова диска, втрата живлення в дата-центрі.
• Мережеві: тривала втрата зв'язку з мережею, DDoS-атака на IP валідатора, блокування порту провайдером.
• Програмні: критичний баг Agave, пошкодження бази accounts, некоректне оновлення, компрометація ключів.

Стратегії відновлення

• Snapshot-відновлення. Основний і найшвидший метод. Підходить для більшості сценаріїв, крім компрометації ключів.
• Повна синхронізація з нуля. Повільний метод (від кількох годин до доби для mainnet-beta). Використовується, коли snapshot недоступний або підозрюється його пошкодження.
• Миграція на резервний сервер. Передбачає наявність підготовленого резервного сервера з встановленим Agave та скопійованими ключами.
• Ротація ключів. Застосовується при компрометації identity або vote-ключа. Це окремий складний сценарій, що виходить за межі інфраструктурного відновлення.

План аварійного відновлення: компоненти

1. Резервне копіювання ключів. Identity keypair, vote keypair, authorized withdrawer keypair — зберігати в зашифрованому вигляді поза сервером валідатора (offline, HSM або зашифроване сховище).
2. Резервний сервер. Мінімально — сервер з встановленою ОС та Agave. Оптимально — повністю налаштований валідатор з актуальними ключами, готовий до запуску.
3. Джерело snapshot. Щонайменше два незалежних джерела snapshot для mainnet-beta (перевірте актуальні джерела у спільноті).
4. Документований порядок дій. Покрокова інструкція для кожного типу аварії (цей розділ є частиною такої інструкції).
5. Контакти та комунікація. Список осіб, яких треба сповістити, та канали зв'язку.

Час відновлення (RTO) та точність (RPO)

• RTO (Recovery Time Objective) — цільовий час відновлення. Для валідатора Solana з резервним сервером та snapshot: 15–30 хвилин. Без резервного сервера: 1–3 години (залежить від швидкості provisioning).
• RPO (Recovery Point Objective) — допустима втрата даних. Для валідатора Solana RPO дорівнює часу між snapshot (зазвичай кілька годин). Це прийнятно, оскільки валідатор не зберігає унікальні користувацькі дані — він відновлює стан з мережі.

Тестування плану аварійного відновлення

Рекомендується проводити тестування DR не рідше ніж раз на квартал:

1. Виберіть тестове вікно (не наприкінці епохи).
2. Імітуйте аварию: зупиніть валідатор, видаліть ledger та accounts.
3. Виконайте відновлення за документованим планом.
4. Зафіксуйте фактичний час відновлення та відхилення від плану.
5. Оновіть план на основі виявлених проблем.

Попередження: не проводьте тестування на production-валідаторі без резервного сервера. Використовуйте окремий тестовий вузол або проводьте тестування під час планового обслуговування з готовністю швидко відкотити.

Як відновити валідатор після повної втрати даних

Коли потрібне повне відновлення

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

Перевірка наявності ключів

Попередження: без identity keypair та vote keypair відновлення неможливе. Якщо ключі втрачено без резервної копії — це незворотна втрата валідатора.

1. Перевірте наявність файлів ключів у резервному сховищі.
2. Перевірте цілісність: порівняйте pubkey з файлу ключа з pubkey, зареєстрованою в мережі.

solana-keygen pubkey <identity_keypair_path> </identity_keypair_path>

3. Результат має збігатися з identity pubkey вашого валідатора (перевірте через solana vote-account або explorer).

Завантаження snapshot з надійного джерела

Дивіться розділ «Як діагностувати snapshot failures» — процедура ручного завантаження snapshot ідентична. Це найшвидший шлях відновлення.

Повторна синхронізація з кластером

Використовується, якщо snapshot недоступний. Передумови: валідатор встановлено, ключі на місці, мережа працює. Кластер: mainnet-beta.

1. Переконайтеся, що директорії ledger та accounts порожні.
2. Запустіть валідатор без snapshot: agave-validator --identity <identity_keypair> --vote-account <vote_account> ...</vote_account></identity_keypair>
3. Валідатор почне завантажувати слоти з нуля. Процес для mainnet-beta може зайняти від кількох годин до доби залежно від швидкості мережі та сервера.
4. Моніторьте прогрес через solana slot та логи.

Ризик: під час тривалої синхронізації валідатор не голосує і не отримує винагороди. Наприкінці епохи є ризик delinquent у наступній епосі.

Перевірка identity та vote account

Після відновлення переконайтеся, що валідатор використовує правильні ключі:

solana vote-account <vote_account_pubkey> --url https://api.mainnet-beta.solana.com </vote_account_pubkey>

Перевірте, що поле node відповідає вашому identity pubkey.

Моніторинг відновлення

• Відстежуйте зростання root slot через solana slot кожні 30 секунд.
• Спостерігайте за логами на предмет помилок під час синхронізації.
• Після досягнення поточного слота мережі перевірте, що валідатор почав голосувати: solana vote-account має показувати оновлення credits.

Запобігання повторній втраті даних

• Використовуйте RAID-1 або RAID-10 для розділів з ledger та accounts.
• Налаштуйте регулярне резервне копіювання ключів (мінімум у два незалежних зашифрованих сховища).
• Майте підготовлений резервний сервер.
• Не зберігайте ключі на тому самому диску, що й дані валідатора.

Incident runbook: типовий план реагування на інцидент валідатора

Що таке incident runbook

Incident runbook — це документований, перевірений порядок дій для реагування на типові інциденти. Мета — мінімізувати час від виявлення проблеми до її усунення, уникнути хаотичних дій та помилок під час стресу.

Класифікація інцидентів

Кроки реагування для кожного рівня

P1 — Critical:

1. Підтвердити інцидент: перевірити метрики та логи, переконатися, що це не хибне сповіщення.
2. Визначити тип: процес впав, сервер недоступний, мережа відсутня.
3. Виконати негайне відновлення за відповідним сценарієм (перезапуск, міграція, snapshot-відновлення).
4. Сповістити команду.
5. Після відновлення — моніторинг протягом мінімум однієї повної епохи.

P2 — High:

1. Підтвердити інцидент та зібрати діагностичні дані (логи, метрики).
2. Визначити причину за діагностичними процедурами (skip rate, snapshot, мережа).
3. Усунути причину або пом'якшити наслідки (наприклад, перезапустити процес, звільнити місце на диску).
4. Моніторити відновлення метрик до норми.

P3 — Medium:

1. Зафіксувати відхилення.
2. Провести діагностику у звичайному режимі.
3. Усунути причину в плановому порядку.
4. Оновити моніторинг, якщо відхилення не було покрите алертами.

P4 — Low:

1. Зафіксувати для аналізу.
2. Включити до звіту при наступному огляді.

Комунікація під час інциденту

• P1: негайне сповіщення всієї команди через основний канал (Telegram/Slack). Координатор призначається негайно.
• P2: сповіщення команди з вказівкою типу проблеми та поточного статусу.
• P3/P4: фіксація в загальному каналі або лог-каналі без негайного реагування.

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

Post-mortem: аналіз після інциденту

Для P1 та P2 інцидентів обов'язково проводьте post-mortem протягом 48 годин після усунення. Структура:

1. Короткий опис. Що сталося, коли, тривалість.
2. Хронологія. Покрокова часов лінія від першого сигналу до повного відновлення.
3. Причина. Коренева причина (root cause), а не лише симптом.
4. Вплив. Скільки епох з винагородами втрачено, чи став delinquent, який вплив на стейкхолдерів.
5. Що спрацювало добре. Алерти спрацювали вчасно, runbook був корисним тощо.
6. Що потребує покращення. Алерт надійшов пізно, діагностика зайняла занадто багато часу, ключі не були під рукою.
7. Дії. Конкретні завдання з відповідальними та термінами.

Оновлення runbook на основі досвіду

Кожен post-mortem має призводити до оновлення runbook:

• Додати новий тип інциденту, якщо він не був покритий.
• Уточнити діагностичні кроки, якщо фактична причина відрізнялася від очікуваної.
• Оновити пороги алертів, якщо вони виявилися занадто чутливими або, навпаки, мовчали.
• Додати нові команди або інструменти, що виявилися корисними.

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

Джерела

• Anza: Agave Validator Requirements
• Anza: Setup an Agave Validator
• Anza: Validator Security Best Practices
• Anza Agave: Releases
• Anza: Install the Solana CLI
• Solana Documentation: Staking
• Solana Documentation: Stake Accounts