Trading platform disaster recovery development — platformanın ciddi infrastruktur, məlumat, təhlükəsizlik və ya üçüncü tərəf nasazlığından sonra yalnız yenidən açılmasını deyil, nəzarətli şəkildə ticarətə qayıtmasını layihələndirməkdir. Bu, orderlərin, fill-lərin, mövqelərin, balansların, limitlərin və audit sübutlarının ardıcıl vəziyyətinin qorunmasını tələb edir. Faylların və ya verilənlər bazasının backup-ı bu nəticəni təkbaşına təmin etmir.
Trading mühitində əsas sual “sistem ayağa qalxdımı?” deyil. Doğru sual budur: hansı ticarət funksiyaları nə qədər vaxtda, nə qədər məlumat itkisi ilə və hansı yoxlamalardan sonra təhlükəsiz aktivləşdirilə bilər? Bu cavab texniki dizayn, əməliyyat prosedurları, biznes prioritetləri və müntəzəm bərpa sınaqlarının birlikdə nəticəsidir.
Disaster recovery, backup və OMS recovery eyni anlayış deyil
Backup məlumatın müəyyən andakı surətidir. Silinmə, korlanma və ya fidyə proqramı hadisəsindən sonra bərpada vacibdir, lakin canlı replikanın aktuallığını, tətbiq konfiqurasiyasını, şəbəkə marşrutlarını və xarici əlaqələrin yenidən qurulmasını həll etmir.
OMS recovery isə order life-cycle məntiqinin bərpasıdır: qəbul edilmiş order, venue-a göndəriş, cancel/replace, qismən fill və rədd cavabları necə yekun vəziyyətə gətiriləcək? Bu, çox vacib komponentdir, amma trading platform business continuity architecture daha genişdir: identifikasiya, ledger, risk, market data, broker API-ləri, likvidlik provayderləri, bildirişlər, müşahidəetmə alətləri və əməliyyat komandası da bərpa zəncirinə daxildir.
Disaster recovery (DR) isə əvvəlcədən müəyyən edilmiş məqsədlərlə kritik funksiyaların alternativ mühitdə işlədilməsi, state-in yoxlanması və normal əməliyyatın bərpasıdır. Bəzi insidentlərdə ən təhlükəsiz qərar dərhal tradingi açmaq yox, yeni order qəbulunu dayandırmaq, mövcud orderləri yoxlamaq və yalnız reconciliation-dan sonra mərhələli açılış etməkdir.
RTO və RPO: texniki rəqəm yox, biznes müqaviləsi
RTO (Recovery Time Objective) kritik funksiya üçün qəbul edilən maksimum dayanma müddətidir. Məsələn, müşahidə və insident komandanın aktivləşməsi 15 dəqiqədə, daxili əməliyyat ekranları 60 dəqiqədə, yeni order qəbulu isə yalnız state reconciliation tamamlandıqdan sonra bərpa edilə bilər.
RPO (Recovery Point Objective) qəbul edilən maksimum məlumat itkisi pəncərəsidir. “RPO sıfırdır” iddiası yalnız source-of-truth yazılarının davamlı replikasiyası, journal və ya event log saxlanması, commit semantikası və bərpa sınaqları ilə sübut edilə bilər. Yalnız hər gecə alınan backup üçün RPO praktik olaraq son backup ilə insident arasındakı intervaldır.
Platforma üzrə vahid RTO/RPO yazmaq çox vaxt yanlış yanaşmadır. Əvəzində business impact analysis funksiyaları ayırmalıdır:
- order qəbul etmə, routing və execution statusları;
- mövqe, P&L, marja və pre-trade risk nəzarətləri;
- müştəri pul vəsaiti, ledger və ödəniş əməliyyatları;
- market-data qəbul etmə, normallaşdırma və quote yayımı;
- əməliyyat, support, compliance və müştəri kommunikasiya kanalları.
Hər sətir üçün owner, asılılıqlar, RTO, RPO, minimum təhlükəsiz əməliyyat rejimi və aktivləşdirmə meyarı yazılmalıdır. Bu cədvəl “DR plan” sənədinin əlavəsi deyil; arxitektura və prioritet seçimlərinin əsas girişidir.
Dependency mapping: bərpa planının başlanğıc nöqtəsi
Failover dizaynına keçməzdən əvvəl komanda request və state axınlarını xəritələməlidir. Bir orderin client tətbiqindən API gateway, OMS, risk xidməti, liquidity bridge və broker/venue-a keçdiyi yolu göstərin. Sonra onun execution report kimi geri dönərək order state, position, ledger, reporting və client notification komponentlərinə yazılmasını göstərin.
Xəritədə hər asılılıq üçün bu suallar cavablandırılmalıdır:
- Primary və DR mühitində endpoint, credential, sertifikat və şəbəkə çıxışı varmı?
- Bu xidmət stateful-dur, yoxsa deterministik şəkildə yenidən qurula bilir?
- Əlaqə qırılarkən mesajlar harada saxlanır və təkrar çatdırılma idempotentdirmi?
- Vendor və ya venue DR endpoint təqdim edirmi; sınaq pəncərəsi və əlaqə proseduru necədir?
- Market data gecikərsə və ya stale olarsa, pricing və risk nə etməlidir?
Bu mərhələ FinTech və trading sistemləri üçün delivery işində xüsusilə əhəmiyyətlidir: tətbiqin yüksək əlçatan olması, brokerin, market-data vendorunun və ya identity provider-in bərpa olunacağı anlamına gəlmir.
Trading system failover design: “switch” deyil, nəzarətli proses
Aktiv-passiv, aktiv-aktiv və ya zonalararası dizayn seçimi məhsulun risk profilindən, verilənlər bazası semantikasından, latency tələbindən və xarici counterparties imkanlarından asılıdır. Hər halda failover aşağıdakı qoruyucuları tələb edir.
Fencing və tək yazıçı qaydası
Primary və DR mühitinin eyni zamanda order göndərməsi split-brain riskidir. Lider seçimi, fencing token-ləri, routing ownership, DNS və ya load-balancer dəyişiklikləri “köhnə” mühitin yazmasını və execution bağlantısını kəsməlidir. Failover qərarı yalnız health check siqnalı ilə verilməməlidir; partial network partition zamanı primary hələ işlədiyini düşünə bilər.
Mesaj jurnalı və idempotency
Order intent, outbound execution request və inbound execution report üçün dayanıqlı, sıralana bilən qeydlər lazımdır. Eyni mesajın təkrar emalı duplicate order və ya duplicate ledger posting yaratmamalıdır. Unikal client order ID, venue order ID, correlation ID və idempotency açarları həm bərpa, həm də sonrakı araşdırma üçün saxlanmalıdır.
Degraded mode və təhlükəsiz dayanma
DR mühitində bütün xidmətlər eyni anda hazır deyil. Dizayn “yalnız oxu”, “cancel-only”, “new orders disabled” və ya seçilmiş alət/hesab qrupları üçün məhdud trading kimi açıq rejimlər təyin etməlidir. Bu yanaşma bərpa sürətindən daha vacib olan nəzarətli risk profilini qoruyur.
Order, position və maliyyə state-i necə bərpa edilməlidir
Platformanın daxili snapshot-ı tək həqiqət mənbəyi sayıla bilməz. Bərpa workflow-u ən azı üç baxışı müqayisə etməlidir: platformanın event log-u, broker/venue-dan alınan authoritative execution və open-order məlumatı, habelə immutable ledger və ya cash record-ları.
- Yeni order göndərişini dayandırın və bərpa vaxtını qeyd edin.
- DR mühitində son təsdiqlənmiş checkpoint-dən state-i yükləyin; event log-u ardıcıl replay edin.
- Broker, liquidity provider və venue-lardan open orders, fills, positions və cash məlumatını soruşun.
- Uyğunsuzluqları təsnif edin: çatışmayan fill, duplicate report, pending cancel, unknown order, qiymət və ya FX fərqi.
- Yalnız risk, operations və lazım olduqda compliance sahibinin təsdiqi ilə balanslaşdırıcı tədbir və ya mərhələli trading açılışı edin.
Bu, ayrıca ESFX layihəsi kimi analitika və inteqrasiya yönümlü trading məhsullarında da önəmlidir: ekranın işləməsi ilə mövqenin etibarlı olması eyni şey deyil. Recovery dizaynı reconciliation prosesini sonradan əlavə olunan hesabat deyil, əsas əməliyyat qabiliyyəti kimi qəbul etməlidir.
Rehearsed incident runbook nələri əhatə etməlidir
Runbook uzun ümumi sənəd deyil; təzyiq altında izlənə bilən, rol və qərar sərhədləri aydın olan əməliyyat prosedurudur. Hər ssenaridə incident commander, technical lead, trading operations, risk owner, support/comms owner və vendor əlaqələndiricisi təyin edilməlidir.
- Hadisənin elan olunması, severity meyarı, vaxt qeydləri və qərar jurnalı;
- Primary mühitdə yazıların və outbound routing-in təhlükəsiz dayandırılması;
- DR mühitinin texniki readiness yoxlaması: versiyalar, secrets, bağlantılar, queue lag, replication lag;
- Broker, liquidity provider və market-data vendoru ilə əlaqə və status təsdiqi;
- State recovery və reconciliation üçün ölçülə bilən sign-off siyahısı;
- Müştərilərə, introducing broker-lərə və daxili rəhbərliyə vaxtında, fakt əsaslı kommunikasiya;
- Tradingin mərhələli açılması, heightened monitoring və primary-ə geri qayıtma şərtləri;
- Hadisədən sonrakı sübutlar: timeline, nəticələr, açıq risklər, corrective-action owner və tarixlər.
Müştəri mesajında spekulyasiya yox, təsir dairəsi, mövcud məhdudiyyət, növbəti yeniləmə vaxtı və əlaqə kanalı göstərilməlidir. Texniki status səhifəsi, support skripti və relationship-manager məlumatı eyni faktlara əsaslanmalıdır.
DR drill-ləri: sübut yaradan sınaq proqramı
İllik “backup restore uğurlu oldu” testi kifayət deyil. Sınaqlar real bərpa məqsədlərini və xarici asılılıqları yoxlamalıdır. SEC-in Regulation SCI çərçivəsi müəyyən ABŞ bazar infrastrukturu subyektləri üçün BC/DR testing tələbləri qoyur; bütün broker və platformalara avtomatik tətbiq edilən ümumi qayda kimi qəbul edilməməlidir. Amma prinsiplər faydalıdır: yazılı prosedurlar, iştirakçı testləri və nəticələrin sübutu.
Praktik proqram tabletop məşqindən başlayıb, komponent bərpası, planlı partial failover və nəhayət tam funksional drill-lərə keçə bilər. Ssenarilər arasında region outage, database corruption, credential compromise, market-data kəsilməsi, broker API gecikməsi, qeyri-müəyyən execution statusu və primary-ə failback olmalıdır.
Hər drill üçün sadəcə “keçdi/qaldı” yox, real RTO/RPO, itirilmiş və ya gecikmiş mesajların sayı, reconciliation break-ləri, manual addımlar, vendor cavab müddəti və müşahidə boşluqları ölçülməlidir. Nəticələr runbook, arxitektura backlog-u və release planına çevrilmirsə, drill dəyər yaratmır.
Delivery checklist: procurement və remediation üçün
- Kritik business function-lar üçün təsdiqlənmiş RTO/RPO cədvəli varmı?
- Order, fill, position, ledger və risk state-i üçün source-of-truth açıqdırmı?
- Broker, liquidity, market-data, KYC, payment və identity asılılıqları DR xəritəsindədir?
- Split-brain və duplicate execution-u önləyən fencing və idempotency mexanizmləri varmı?
- Failoverdən sonra mütləq reconciliation və human sign-off varmı?
- Runbook-lar rol, kommunikasiya, rollback/failback və sübut tələblərini əhatə edirmi?
- Son drill ölçülə bilən nəticə və düzəliş planı yaradıb?
POLADO recoverable trading mühitinin arxitekturası, stateful inteqrasiyaları, test ssenariləri və əməliyyat readiness-i üzərində işləyir. Yeni məhsul üçün istehsalat hazırlığını qiymətləndirmək və ya mövcud platformada DR boşluqlarını prioritetləşdirmək üçün FinTech və trading sistemləri xidmətimizə baxın, davamlı əməliyyat modeli üçün isə texniki dəstək və konsaltinq komandası ilə əlaqə saxlayın.