Професійна технічна підтримка блокчейн-проекту під ключ

Блокчейн-інфраструктура ламається інакше, ніж звичайні веб-сервіси. Нода зависає на конкретному блоці через edge case в консенсус-клієнті. Смарт-контракт веде себе коректно при тестуванні, але непередбачувано при взаємодії з іншим протоколом через flash loan. RPC-провайдер повертає застарілі дані без явних помилок. Підтримка таких систем вимагає специфічних знань, яких немає у звичайної DevOps-команди. Наші фахівці мають багаторічний досвід саме в блокчейн-підтримці та обслуговують понад 50 проектів із сукупним TVL понад $50M. Ми гарантуємо стабільність вашої інфраструктури 24/7. Беремо на себе моніторинг, реагування на інциденти, оновлення та консультації — все, щоб ви могли зосередитися на розвитку продукту. Зв'яжіться з нами, щоб обговорити деталі вашого проекту.

Що включає технічна підтримка блокчейн-проекту?

Моніторинг інфраструктури включає відстеження on-chain подій смарт-контрактів (незвичайні виклики, зміни state), стану нод (sync lag, peer count, версія клієнта), стану валідаторів або sequencer, працездатність bridge-контрактів та баланс service-акаунтів (relayer, deployer, keeper). Для on-chain моніторингу ми застосовуємо OpenZeppelin Defender: Sentinel відстежує конкретні події та виклики на контракті, наприклад, pause() або upgradeTo(). При спрацюванні webhook надсилає сповіщення в Telegram або PagerDuty.

Реагування на інциденти включає чергування за розкладом з SLA на першу відповідь, діагностику та виправлення проблем з нодами, emergency pause контрактів при виявленні експлойту та координацію з аудиторами при security-інцидентах.

Обслуговування передбачає оновлення клієнтів (Geth, Lighthouse та ін.) при виході нових версій, застосування hotfix у смарт-контрактах через upgrade mechanism, ротацію ключів сервісних акаунтів та оновлення RPC endpoints при деградації провайдерів.

Які інструменти моніторингу ми використовуємо?

Базовий моніторинг будується на Prometheus + Grafana + Alertmanager. Ось типова конфігурація:

# docker-compose monitoring stack services: prometheus: image: prom/prometheus:latest volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml grafana: image: grafana/grafana:latest ports: ["3000:3000"] alertmanager: image: prom/alertmanager:latest volumes: - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml 

Prometheus правила алертів для типового EVM проекту:

groups: - name: blockchain rules: - alert: NodeSyncLag expr: eth_syncing_current_block - eth_syncing_highest_block > 50 for: 5m labels: { severity: warning } annotations: summary: "Node is {{ $value }} blocks behind head" - alert: ServiceWalletLowBalance expr: eth_balance{account="relayer"} < 0.1 for: 1m labels: { severity: critical } annotations: summary: "Relayer wallet balance critical: {{ $value }} ETH" - alert: ContractPaused expr: contract_is_paused == 1 for: 0m labels: { severity: critical } annotations: summary: "Contract {{ $labels.contract }} is paused" 

Для on-chain моніторингу смарт-контрактів застосовуємо Sentinels. Приклад конфігурації через Defender API:

{ "type": "BLOCK", "network": "mainnet", "addresses": ["0xYOUR_CONTRACT"], "abi": [...], "eventConditions": [ { "eventSignature": "RoleGranted(bytes32,address,address)" }, { "eventSignature": "Upgraded(address)" } ], "functionConditions": [ { "functionSignature": "pause()" } ] } 

Наш моніторинг виявляє проблеми втричі швидше, ніж якби ви покладалися лише на перевірки uptime нод. На одному з наших проектів ми зменшили середній час виявлення інциденту з 15 хвилин до 3 хвилин завдяки налаштованим алертам на конкретні події.

Як ми реагуємо на security-інциденти?

У кожного протоколу з TVL має бути runbook. Типовий сценарій:

1. Виявлення (автоматичний алерт або зовнішній репорт).
2. Оцінка (5–15 хвилин): розмір збитку, чи активний exploit, чи можна поставити на паузу.
3. Пауза (якщо контракт pausable): негайно, не чекати повного аналізу.
4. Сповіщення (15–30 хвилин): команда, власники токенів, аудитори.
5. Розслідування: аналіз транзакцій у Tenderly, trace exploit.
6. Виправлення: hotfix контракту, аудит виправлення.
7. Post-mortem: публічний звіт про подію.

Для кроку "пауза" pauser role має бути налаштована на Gnosis Safe з 1/N threshold (швидке реагування), а upgrade role — на Safe з N/M threshold (повільна, безпечна зміна). Такий підхід дозволяє захистити кошти навіть при активній атаці.

Типові проблеми з нодами та їх вирішення: Geth stuck на блоці:

# Діагностика через debug_traceBlockByNumber curl -s -X POST localhost:8545 \ -d '{"jsonrpc":"2.0","method":"debug_traceBlockByNumber","params":["latest",{}],"id":1}' # Якщо нода зависла — restart з --gcmode archive і --syncmode full # Якщо state corruption — resync від checkpoint geth snapshot prune-state 

Consensus клієнт не бачить peers — перевірте iptables та конфігурацію libp2p-адрес. op-batcher не публікує батчі — перевірте баланс batcher wallet та доступність L1 RPC.

Чому варто обрати аутсорсинг підтримки?

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

Наш сервіс підходить проектам, які хочуть скоротити витрати на підтримку на 30–50% без втрати якості. Бюджет на підтримку в середньому на 40% нижчий, ніж утримання in-house команди з двох інженерів (яка обходиться в $15k-25k на місяць). Економія може становити від $5000 до $20000 на місяць залежно від складності проекту.

SLA та моделі підтримки

Для проектів з TVL > $1M та живими користувачами мінімальний розумний рівень — Production. Ми допоможемо обрати оптимальний SLA під ваші завдання — отримайте консультацію, щоб обговорити ваш проект.