On‑prem қосымшасының ақауға төзімділігі: сессиялар және кэш

Қай жерде күй жоғалады және неліктен бұл мәселе\n\nАқау әдетте жүйенің толық құлауы сияқты болмайды. Көбінесе бір ғана қосымша түйіні құлайды немесе тәуелді жүйе баяулайды. Күй (state) мәселені байқататын болғандықтан проблемалар шығады: адам кірген, бірдеңе таңдаған, батырмаға басқан, ал сервис кенеттен оны «ұмытып» қалады.\n\nЕң ауыр көріністер көбінесе ұқсас болады. Қысқа желі үзілуінде пайдаланушы разлогин болады, себет босайды, төлемде "қайтадан әрекет етіңіз" шығады, іздеу кейде нәтиже көрсетеді, кейде жоқ. Әдетте мұның себебі кодтың нашарлауы емес, state нақты процесске, түйіннің жадына немесе тұрақсыз тәуелділікке байланғанында.\n\nТүйіннің құлауымен және тәуелділіктің деградациясымен маңызды айырмашылық бар. Бір экземпляр құлса, балансировщик сұрауды басқаға жібереді, бірақ солайша локальды сессия, локальды кэш және жадыдағы есептегіштер жоғалады. Ал ештеңе құламай, бірақ кэш, дерекқор немесе сыртқы сервис баяу жауап берсе, қосымша формальды түрде "тірі", бірақ пайдаланушыға нашар: таймауттар, сұраныстарды қайталау, оғаш кешігулер.\n\nТиптік белгілер:\n\n- Кіру өтіп жатыр, бірақ келесі сұраныс қайта авторизация сұрайды.\n- Себет немесе фильтрлар бетті жаңартқанда «қайта орнатылады».\n- Төлем бекітіп қалуы немесе қате беруі, тапсырыс статусы анық емес.\n- Іздеу мен каталогтар кейде бос, кейде ескі деректер көрсетеді.\n- Қателер жүктеме шегінде «толқындармен» пайда болады.\n\nМәселе мынада: осындай сценарийлерді локалда көшіру қиын. Олар продада, нақты on‑prem кластерлерде және серверлерде шығады, желі үзілістері, процестердің қайта іске қосылуы және тәуелділіктердің кешігулері жиі, тіпті қысқа болса да орын алады.\n\n## Мақсаттар мен шекаралар: не есептеледі ақау және не сақталуы тиіс\n\nOn‑prem қосымшасының ақауға төзімділігі шексіз жобаға айналмауы үшін алдымен мақсатқа келісіңіз. «Түсіп қалмасын» деп емес, жеке түйіндер істен шыққанда негізгі пайдаланушы әрекеттері жұмысын жалғастыруы керек.\n\nКритикалық ағындардан бастаңыз. Интернет‑банк үшін бұл «кіру және баланс көру», мемлекеттік қызмет порталында — «ұсыным жіберу», ішкі жүйеде — «өтініш жасау және деректерді жоғалтпау». Әр ағын үшін пайдаланушыға қандай ақау саналатынын анықтаңыз: 500 қатесі, ұзақ жүктелу, разлогин, себетті жоғалту.\n\nСодан кейін екі метрика қажет:\n\nRTO — сервис қанша уақыт жартылай қолжетімсіз болуы мүмкін, сіз ауысқанша немесе қалпына келтіргенше (мысалы, 5 минут).\n\nRPO — апатта қанша деректерді жоғалтуға дайынсыз (мысалы, төлемдер үшін 0, аналитика үшін 5 минут).\n\nКомпоненттер тізімін жазып алу пайдалы, сонда кейін «балансировщик те болмай ма?» деген дау шықпайды. Әдетте тізімде балансировщик пен DNS, веб‑түйіндер (қосымша), сессия мен кэш сақтау орны, дерекқор, сыртқы сервистер (пошта, SMS, төлемдер, LDAP) бар.\n\nСоңында күйді маңыздылыққа бөліп алыңыз:\n\n- Сессия — «сіз кімсіз» және кейде «қай қадамдасыз».\n- Кэш — жылдамдатқыш, оны қайта жасауға болады, бірақ ол кешігулер мен жүктемеге әсер етеді.\n- Пайдаланушы деректері — жоғалтуға болмайтын нәрселер (тапсырыстар, құжаттар).\n- Уақытша деректер — жоғалтуға болатын нәрселер (черновиктер, маңызды емес қадамның прогрессі).\n\nМысал: кэш құлағанда ұсыныстар мен кеңейтілген іздеуді өшіруге болады, бірақ кіру және өтініш сақтау жұмыс істеуі тиіс, тіпті баяу болса да. Бұл — шекара: не үшін бәрін қымбатқа сақтаймыз, не нәрсені деградировать етеміз сервис өмір сүруі үшін.\n\n## Күй моделі: сессиялар, кэш және жоғалтпаған деректер\n\nАқауға төзімділік көбіне «темірде» емес, күйде (state) бұзылады. Сондықтан қосымшаның деректерін үш қабатқа бөлу пайдалы: сессия, кэш және «шындық» (ұзақ мерзімді деректер).\n\nStateless тәсіл түйінді құлау жеңіл өткізуге мүмкіндік береді: кез келген сұранысты кез келген сервер өңдей алады. Толық stateless әрдайым мүмкін бола бермейді, бірақ практикалық қадам — сұраныстар арасында жадыны қажет етпейтін нәрселерді stateless ету: беттерді рендерлеу, анықтамаларды оқу, тауарлар тізімі, іздеу, бұрын сақталған деректерден есептерді құру.\n\nСессия — пайдаланушыға «қазір керек» нәрсе: кім, қандай құқықтары бар, қандай сценарий орындауда. Сессияны сақтау тәсілі апат кезіндегі мінезге әсер етеді:\n\n- Түйіннің жадысы (жылдам, бірақ қайта іске қосқанда бәрі жоғалады және sticky sessions қажет).\n- Ортақ стор (таратылған сессиялар сақтау) — түйін құлағанымен сақталады, бірақ желіге тәуелділікті қосады.\n- Токендер (мысалы, қолтаңбаланған) — сервер жағындағы ағымды state‑ты минимумға түсіреді, бірақ қайтару мен бақылау қиындау.\n- Дерекқор — сенімді, бірақ кешігулер мен жүктемені арттырады.\n\nКэш — жылдамдатқыш, шынайылық көзі емес. Ол локальды (процесс ішінде), таратылған (түйіндер арасында), HTTP‑прокси кэші немесе сервис ішіндегі прикладной кэш болуы мүмкін. Кэш тазаланса немесе қолжетімсіз болса не болатынын алдын ала шешіңіз: жүйе жайлап баяулайды, бірақ «тарихты қайта жазбауы» тиіс.\n\nҚайта іске қосылғанда қандай шығындар қабылдау керектігі туралы қарапайым ереже: іздеу шығаруын немесе прогретті анықтамаларды жоғалтуға болады; расталған операцияларды, құқықты, төлем статустарын, дауыс беруді жоғалтуға болмайды. Пайдаланушы өтініш толтырып жатса, черновик дерекқорда (немесе сенімді бөлек қоймада) тұруы керек, түйін жадысында емес — әйтпесе сервер істен шыққанда жұмыс жоғалады.\n\n## Sticky sessions: қашан жарайды және қандай бағаға\n\nSticky sessions (липкі сессиялар) — балансировщик конфигурациясы, онда бір пайдаланушы дәл сол түйінге бағытталады. Әдетте cookie, IP немесе арнайы идентификатор арқылы жасалады. Бұл процесс жадысында күй сақтайтын қосымшаны тез «жұмыс істетуге» жиі қолданылатын ең жылдам жол.\n\nАртықшылығы анық: тәуелділіктер аз. Ортақ сессия қоймасын бірден шығарудың қажеті жоқ, желілік шақырулар аз, отладка оңай. On‑prem контексте бұл тартымды көрінеді — кодты үлкен өзгеріссіз тез өшіруге болады.\n\nБағасы да түсінікті. Егер түйін құлса, пайдаланушы сессиясын жоғалтып, қайта кіруі немесе әрекеттерін қайталауы керек. Масштабтау болжанбауы мүмкін: трафикті еркін қайта бөлу қиын, «ыстық» түйін шамадан тыс жүктелуі мүмкін, ал басқа түйіндер бос отыруы мүмкін. Өшіру кезінде кейбір қолданушылар түйінге «байланған» болып шығады, сондықтан оны пулдан жұмсақ шығару қиын.\n\nSticky sessions қабылдауға болатын жағдайлар: сессиялар қысқа, қайта кіру маңызды емес, функция ақшалай емес және қауіпсіздікке әсер етпейді, трафик салыстырмалы түрде тұрақты және сізде миграция жоспары бар.\n\nШығу жоспарын алдын ала белгілеңіз, әйтпесе «уақытша шешім» жылдарға созылады:\n\n- Сессияларды ортақ сторға шығару және cookie‑де тек кілт сақтау.\n- Сессиядағы деректерді минимизациялау: токен, рөлдер, бірнеше флэг, бірақ үлкен объектілер емес.\n- Сессия жоғалғанда черновиктер мен қадамдарды дерекқорда сақтау.\n- Түйінді құлату тесттерін өткізу: пайдаланушыға не бұзылады және қанша сұранысты қайталау қажет.\n- Кезең-кезеңімен көшіру: бір бөлігі пайдаланушылар sticky жоқ режимге, бір бөлігі әлі sticky режимде, қателер бойынша метрикалармен.\n\nОсылайша sticky sessions тұзақ емес, бақылаудағы өткелге айналады.\n\n## Қадамдық: сессияларды түйін құлауына төзімді ету\n\nТұрақты сессиялардан басталатын қарапайым ереже: веб‑түйін алмастырылатын болу керек. Бір сервер қайтыс болса, басқа сервер жұмысын жалғастырып, ештеңе болмағандай етуі тиіс. Бұл on‑prem жүйелер үшін аса маңызды, себебі жаңартулар, электр үзілістері және желі қателері жиі болады.\n\n### Орнату қадамдары\n\n1) Сессия сақтау моделін таңдаңыз. Немесе ортақ session store (бөлек сервис немесе база), немесе «серверсіз» токен формасы — кез келген түйін тексере алады. Күрделі сценарийлер үшін ортақ стор ыңғайлы, ал кішкентай сессиялар үшін токендер оңай.\n\n2) Сессияны минималды ұстаңыз. Тек идентификаторларды сақтаңыз: user_id, рөлдер, себет немесе черновик id. Барлық «ауыр» нәрселер (себет құрамасы, анкета қадамдары, файлдар) дерекқорда немесе бөлек сенімді черновик‑сховищеде болу керек, сонда түйін құлаған кезде прогресс жоғалмайды.\n\n3) TTL мен жаңарту ережелерін анықтаңыз. TTL пайдаланушылардың нақты әрекетіне сай болуы керек (мысалы, ұзын формалар үшін ұзағырақ). Кіруден кейін және сезімтал әрекеттерде сессия идентификаторын ауыстыруды енгізіңіз, сондай‑ақ шығу мен пароль өзгерткенде айқын инвалидизация болсын.\n\n4) Өлшем мен жазу жиілігін шектеу. Сессиялар асып кетсе, олар кешігулер мен қателер көзіне айналады. Лимит қойыңыз (мысалы, килобайттарда) және өзгерістерді әр сұраныста емес, тек қажет кезде жазыңыз.\n\n5) Ақау кезінде мінезді ойластырыңыз. Егер session store уақытша қолжетімсіз болса, жаңа сессиялар құрып, дубликаттар өсіргенше жақсырақ — пайдаланушыға анық хабар беріп, кейбір функцияларды «тек оқу» режиміне ауыстыру.\n\n### Жүйенің жұмысын қалай тексеруге болады\n\nШынайы апатты моделдеңіз: пайдаланушы 5 қадамдық форманы толтырады, сосын сіз бір түйінді мәжбүрлеп өшіресіз (немесе сервис қайта іске қосылады) және басқа түйіннен жалғастырады. Дұрыс нәтиже: пайдаланушы разлогин болмайды, черновик орнында қалды, максимум — бір рет сұранысты қайталау және деректер жоғалмауы. Егер сіз on‑prem инфрақұрылымды өз серверлеріңізде құрып жатсаңыз (көптеген GSE.kz тапсырыс берушілеріне ұқсас), мұндай тесттерді релиз алдындағы тұрақты прогонына қосыңыз.\n\n## Кэш: күтпеген жағдайларсыз TTL, прогрев және лавинадан қорғау\n\nКэш жиі сұрауларды жылдамдатады және дерекқорды жүктемеден сақтайды. Бірақ кэш «кездейсоқ» орнатылса, ол өзі инциденттер көзіне айналады: кілттердің массалық жойылуы, дерекқорға лавина сұраныстар, "бар да жоқ" жағдайлары.\n\nАлдымен нені кэшейтіндігіңізді және неге екенін келісіңіз. Жақсы кандидаттар: анықтамалар, рөлдер/рұқсаттар, тауар карточкалары, ауыр есептер нәтижелері. Нашар кандидаттар: әр секунд өзгеретін және дәлдік талап ететін нәрселер — баланстар немесе транзакция статустары.\n\nЖазу тәсілі бойынша әдетте үш нұсқа таңдалады. Cache‑aside (қосымша өзі кэштен оқиды, промахта дерекқордан алып, кэшке құяды) on‑prem үшін жиі қолайлы. Write‑through (сол уақытта кэш пен дерекқорға жазамыз) оқылымды жаңа күйде береді, бірақ қиынырақ және қымбат. Write‑behind (алдымен кэшке, кейін дерекқорға асинхронды) деректерді жоғалтатын орындарда қауіпті.\n\n### TTL және прогрев: массалық жұмылуды болдырмау\n\nTTL деректердің мәніне сәйкес болуы керек: анықтамалар үшін минуттар немесе сағаттар, динамика үшін секундтар. Кілттердің бір уақытта мерзімі бітуін болдырмау үшін джиттер қосыңыз (TTL‑ге кездейсоқ қосымша не азайту).\n\nПрогревті тек шынымен «ыстық» кілттер үшін жасаңыз. Мысалы, түйін қайта іске қосылғаннан кейін танымал анықтамалар мен рөлдерді алдын ала толтырыңыз, қалғанын сұраныстар бойынша толтыра берсін.\n\n### Лавинадан қорғау және кэш құлғанда жоспар\n\nКілттің жойылуы кезінде жүздеген сұраныс дерекқорға жүгінуі мүмкін. Қарапайым тәсілдер жұмыс істейді: single flight, кілтке қысқа блокировка және таймаут, soft TTL (жаңа есептеу жүріп жатқанда сәл ескірген мән беру), дерекқорға промахтарда параллелизмді шектеу, «табылмады» үшін негативті кэштеу.\n\nКэш қолжетімсіз болса, "дерекқорға айналып өту" режимін қосыңыз, бірақ шектеулермен: rate limit, кезек, ауыр беттер үшін жеңілдетілген жауап. Бұл on‑prem қосымшасының ақауға төзімділігінің бөлігі: уақытша баяулау және қосымша функцияларды қысқарту дерекқорды және бүкіл сервисті құлатпаудан жақсы.\n\n## Консистенттілік: қайсысын жұмсартып, қалай деректерді жоғалтпау\n\nКонсистенттілік — бұл келісім: қандай деректер дәл қазір дұрыс болуға тиіс, ал қайсысы аздап ескірген болуы мүмкін. On‑prem жүйеде бұл ережелерді алдын ала анықтамау кэш немесе түйін ақауында қосымша қайшылықтар мен қосымша шығындарға алып келеді.\n\n### Қай жерде қатты консистенттілік керек\n\nҚатал консистенттілік қаржылық немесе заңдық тәуекел тудырған жерлерде міндетті: төлемдер, лимиттер, құқықтар, тапсырыстарды растау, токен шығару. Мұндай операциялар шынайылық көзіне (әдетте дерекқор) сүйеніп, қайталанудан қорғалуы керек.\n\nБасқа жерлерде «ең азырақ ескірген» деректер жеткілікті: тауар каталогы, жаңалықтар лентасы, бос слоттар тізімі, агрегатталған метрикалар. Бұл жерлерді кэштен беруге болады, егер сіз қабылдаған уақыттық терезені бекіткен болсаңыз.\n\n### Кэш пен қайталаулар кезінде деректерді қалай жоғалтпау\n\nНегізгі қауіп — кэш пен дерекқордың десинхрондау болуы және жазбалардың дубльділігі. Кэшті екінші шынайылық көзіне айналдырмаңыз. Егер жазу дерекқорға өткен болса, кэш дерекқордан қайта есептелуі немесе нақты ережемен жаңартылуы керек.\n\nЖұмыс істейтін практикалар:\n\n- Жазбалар үшін идемпотенттілік: сұранысқа idempotency key (UUID операция) беру. Қайта орындау дубль жасамайды, бұрын жасалған нәтижені қайтарады.\n- Оқиға бойынша инвалидизация: дерекқорда commit болғаннан кейін "объект жаңартылды" оқиғасын жариялап, оқырмандар кэшті кілт бойынша тазалайды.\n- TTL — сақтандыру: оқиға жоғалса да, кэш жазбасы өзі ескіріп кетеді.\n- Версиялау: нысанның нұсқасы немесе timestamp сақталсын. Кэштегі нұсқа ескірген болса, оны өзекті деп қабылдамаңыз.\n- Write‑through ақырын: кэш пен дерекқорды бірге жаңартсаңыз, бұл коммиттен кейін жасалсын және кэштің әрдайым жаңартылмауын қабылдауға дайын болыңыз.\n\nМысал: on‑prem кластерде бір түйін қайта іске қосылып, клиент "өтініш жасау" сұрауын қайталайды. Идемпотенттілік дубль жасамайды, ал оқиға арқылы кэш тізім жаңартылады. Егер оқиға жетпесе, TTL ақырындап бәрін орнына келтіреді.\n\nӨндірісте дау тумасын үшін қабылдауларды құжаттаңыз: не ескіруі мүмкін, қанша секунд/минутқа дейін және пайдаланушы не көреді (мысалы, "тізім 30 секундтан кейін жаңарады", "төлем статусы тек дерекқордан алынады").\n\n## Функцияларды деградациялау: компоненттер істен шыққанда сервис қалай сақталады\n\nФункцияларды деградациялау — алдын ала ойластырылған жұмыс режимі, онда кейбір мүмкіндіктер өшіріледі, бірақ сервистің «ядросы» қолжетімді қалады. Идея қарапайым: 1–2 секундта негізгі операцияны беру жақсырақ, чем 30 секунд ұстап алып, содан кейін құлау.\n\nАлдымен деградация деңгейлерін және "ядро" не екенін бекітіңіз. Мысалы, ішкі портал үшін ядро — кіру, карточканы қарау, өтініш жасау. Ұсынымдар, тарих, кеңестер, кеңейтілген іздеу және ауыр дашбордтар бірінші өшірілетіндер.\n\nРежимдерді осылай сипаттау ыңғайлы:\n\n- Норма: барлық функциялар, кэш пен сыртқы тәуелділіктер жұмыс істейді.\n- Жеңіл деградация: қосымша блоктар өшіріледі, оқу және жасау қалдырылады.\n- Қатты деградация: ауыр операциялар (іздеу, есептер) өшіріледі, негізгі операциялар мен жеңілдетілген экрандар қалады.\n- Апат режимі: тек критикалық әрекеттер қалдырылады, қалғаны пайдаланушыға түсінікті хабармен жабылады.\n\nБір компоненттің қателігі басқаларын «жарқылатпау» үшін шектеулі таймауттар мен лимиттер керек. Circuit breaker тәуелділікті «жатып қалғанда» азайтуға және сақтандырылған сценарийге (кэш, жеңілдетілген жауап, кезек) ауысуға көмектеседі.\n\nПрактикалық мысал: іздеу бөлек сервис пен кэшке тәуелді. Кэш қолжетімсіз болса, іздеуді «минимум» режимге ауыстырып немесе интерфейстен уақытша алып тастауға болады, бірақ өтініш беру жұмыс істейді.\n\nБұрын дайындап қою керек: әр тәуелділікке таймауттар, сұранысқа жалпы уақыт лимиті, circuit breaker‑лер прагматикалық праорогтармен, кешікті тапсырмалар үшін кезек (хабарландырулар, индексация), пайдаланушыға түсінікті хабарлар, қауіпсіз қайта әрекеттер (идемпотенттілік немесе сұраныс кілті).\n\n## Продада жиі кездесетін қателіктер: сессиялар мен кэш\n\nКүймен ең жиі болатын проблема — оның байқамай өсуі. Сессияға профильдер, құқықтар, себеттер, сұраныс нәтижелері жиналады, бәрі бір түйіннің жадысында қалады. Қайта іске қосқанда немесе апатта пайдаланушы «шетке шығады», ал жүктеме жоғарылайды, өйткені әр сұраныс бұрын сессиядан алынатын нәрсені қайта есептеуі керек.\n\nSticky sessions‑ты жиі сақтандыру деп ойлайды, бірақ бұл жай құрал. Түйіндер тірі болғанда бәрі тұрақты көрінеді. Бірақ бір сервер құлаған кезде бірқатар пайдаланушылар басқа түйінге өткенде олардың сессиясы жоқ. Регулярлы ақаулық тесттерін (түйінді өшіру, логин, себет, тапсырыс тексеру) жүргізбесеңіз, мұндай сценарийлер тек продада шығады.\n\nКэш жағында типтік қате — бәріне бір TTL. Түрі әр түрлі деректер (анықтамалар, авторизация, қалдықтар, тарифтер) бір уақытта ескіріп, кэш «нөлге» түседі. Егер джиттер жоқ болса, дерекқорға сұраныстар лавинасы пайда болады.\n\nТағы бір қате — ақау кезіндегі мінез. Таймауттар жоқ, ретрайлер шексіз немесе тым агрессивті, және мәселе көбейеді: бір баяу компонент барлық контурды құлатады. Код пен клиенттерде сақтандыру болуын тексеріңіз: әр желілік шақыруға таймаут, кэшке және тәуелділікке шектеулі ретрайлер, thundering herd‑тен қорғаныс (кілтте лок, single flight, кезектер), түсінікті фолбэк.\n\nЕң қымбаты — кэшті «шындық көзіне» айналдыру. Егер критикалық деректер тек кэште тұрса, қайта іске қосу, тазалау немесе түйін ауыстыру деректерді жоғалтумен аяқталады. Қарапайым ереже: кэш жылдамдатады, бірақ жоғалтатын нәрсені сақтамайды.\n\n## Релиз алдында және жүктеме тесттері алдындағы қысқа чеклист\n\nРелиз алдында бірнеше тексерістен өткізу пайдалы, олар қосымшаның түйін құлауы, кэш проблемалары және шоқтық жүктеме шыдауын тез көрсетеді. Мұны проданың ұқсас стендінде жасап, нәтижелерді жазып алыңыз: не сынатыны, қанша уақыт қалпына келуі, қандай функцияларды қысқарту керек.\n\n### Жылдам ақауға төзімділік тексерістері\n\nБір түйінді қайта іске қосуға болатынын тексеріңіз, пайдаланушыға «жанама эффект» болмауы керек. Қарапайым сценарий: пайдаланушы кірді, себетке тауар салды, екінші қойынды ашып, тағы әрекеттер жасады. Осы кезде бір түйін қайта іске қосылады. Күтілетін мінез: логин қалпында, себет сақталған, сұранысты қайталау дубль жасамайды.\n\nТағы бір міндетті тексеріс: кэш қолжетімсіз немесе баяу болса не болады. Қатты таймауттар және әдепкі тәртіп: аздап ескірген деректерді көрсету, қосымша блоктарды өшіру, бірақ барлық сұранысты іліп қоймау. Деградация кезінде кешігулер қалай өзгеретінін және қанша сұраныс дерекқорға кететінін өлшеңіз.\n\n### Жүктеме: бірінші не бұзылады\n\nЖүктеме кезінде көбіне кілттердің мерзімі өтуі кезінде лавина шығады: көптеген сұраныстар бір мәнді қайта есептеу үшін дерекқорға жүгінеді. Қорғаныс бар-жоғын тексеріңіз (TTL‑ге джиттер, қайта есептеуде блокировка, stale‑while‑revalidate) және қайта есептеу дерекқордың қосылым пулын бітетпесін.\n\nАйырбас сұраулардың ( төлем, өтініш жасау, шегеру, резерв ) идемпотенттілігін жеке тексеріңіз. Балансировщик немесе клиент ретрайлерінен туындаған қайталауды модельдеп, нәтиженің дубль жасамайтынын тексеріңіз.\n\nСоңында мониторинг пен алармдардың шынымен көмектесетінін тексеріңіз: p95/p99 кешігулері, қателер үлесі, кэш пен дерекқор таймауттары, кезек ұзындықтары, және түсінікті праорогтар. Егер сіздің on‑prem инфрақұрылымыңыз өз теміріңізде болса, алармдар пайдаланушыларға байқатпай бұрын келетінін тексеріңіз.\n\n## Өмірден мысал: түйін құлау және кэш проблемаларын қалай өткізуге болады\n\nТаңғы 9:05. Мемлекеттік органда қызметкерлер ішкі порталға көптеп кіреді: табель, өтініштер, келісімдер. Пик 20–30 минутқа созылады. Қосымша on‑prem екі түйінде балансировщик артында, жанында бөлек кэш кластері. Дерекқор біреу, және пиковтарда ол әдетте «ауырлайды».\n\nСол күні бір түйін (мысалы, жады ағып кетуден) құлайды. Сонымен бірге кэш баяу жауап беруді бастайды: сұраныстар кезегі өседі, кэшке жазудың бір бөлігі үлгермейді. Пайдаланушы әсері сессия қалай сақталғанына байланысты.\n\nЕгер sticky sessions қосылған және сессия тек түйін жадысында сақталса, бір бөлік адамдар дереу разлогин немесе черновик жоғалтуын көреді. Олар қайта кіруге тырысып, сұраныстарды қайталайды да, кэш пен дерекқорға жүктеме қосады. Балансировщик тірі түйінге жаңа пайдаланушыларды бағыттаса да, "байланған" пайдаланушылар күйін жоғалтады.\n\nЕгер sticky sessions болмаса және сессия ортақ қоймада (кэш немесе ағымдық session store) сақталса, түйін құлау көбіне қысқа үзіліспен және бір рет сұранысты қайталаумен өтеді. Пайдаланушы авторизацияланған күйінде қалады, басқа түйін оны қабылдап алады.\n\nДеградация сақтауға көмектеседі. Мониторинг кэштің қателері мен кешігулерінің өскенін көргенде қосымша уақытша түрде екінші деңгейлі блоктарды өшіреді: жаңалықтар, виджеттер, статистика, автоподсказки, фондық есептеулер. Маңыздысы қалады: кіру, негізгі формалар, өтініш жіберу. Егер кэш жауап бермесе, оқу функциялары персонализациясыз немесе жеңілдетілген режимге өтеді, ал критикалық жазбалар тікелей дерекқорға шектеулі түрде жазылады.\n\nЖоспардың жұмыс істегенін метрикалар көрсетеді: кілттік эндпоинттердегі (логин, форма жіберу) 5xx және таймауттардың үлесі, олардың p95 уақыты, күшпен разлогиндер мен сессия қайта құрулары, кэш хит‑коэффициенті және кешігулер, операция қателері, дерекқор жүктемесі (QPS, блокировкалар, сұраулар уақытының өсуі).\n\nЕгер түйін құлағанда пайдаланушылар негізінен жұмысын жалғастырып, дерекқор «қызыл аймаққа» өтпесе, демек state пен деградация схемасы жұмыс істеп тұр.\n\n## Келесі қадамдар: енгізу жоспары және инфрақұрылымды не тексеру керек\n\nOn‑prem қосымшасының ақауға төзімділігі қағазда қалмауы үшін қысқа жұмыс жоспарын бастаңыз. Мақсат — state қайда тұрады, ол апатты қалай көтереді және бір компонент жоғалғанда пайдаланушы не көреді — осыны түсіну.\n\nАлдымен компоненттер мен тәуелділіктер картасын жинаңыз. Міндетті түрде идеал архитектураны салудың қажеті жоқ. Маңыздысы — қайда күй сақталатынын шынайы көрсету: сессиялар, кэш, локальды жады, файлдар, кезектер, фондық тапсырмалар. Көп жағдайда 2–3 ең қауіпті нүктені анықтау жеткілікті.\n\nСодан кейін енгізу тәртібін бекітіңіз:\n\n- Кіру, себет, құқықтар немесе төлемдерге жауап беретін 2–3 state‑нүктесін таңдаңыз.\n- Түйін құлағанда не болатынын сипаттаңыз: сессия қалай қалпына келеді, sticky sessions‑ты не істейміз, пайдаланушы не көреді.\n- Деградация режимдерін анықтаңыз: ең бірінші не өшіріледі, не әрдайым қалдырылады.\n- "Жинақтау ережелерін" қосыңыз: қателер немесе кешігулер өссе жүктемені азайту, таймауттарды қысыңыз, жеңілдетілген жауаптарды қосыңыз.\n\nПараллельді түрде апат тесттерін қайталанатын процедураға енгізіңіз: қосымша түйінін өшіру, кэшті ажырату, сервис пен сақтау арасындағы желіге жасанды кешігулер. Осындай тесттерде on‑prem жағдайында ақауға төзімділік шынайы ме, әлде бақытқа сеніп тұрғаныңыз ба — тез көрінеді.\n\n### On‑prem инфрақұрылымында не тексеру керек\n\nСессиялар мен кэштің тұрақтылығы темірге және базалық платформаға байланысты: резервтеу бар ма, кластер бар ма, CPU, RAM, дискіде қор бар ма, сақтау және сервис үшін бөлек желілер бар ма, шектеулер мен мониторинг бар ма.\n\nПрактикалық өлшем: бір түйінді жоғалтқанда қажетті жүктемені ұстай алмасаңыз, деградация «тыныш» болмай, апаттық болады.\n\nЕгер сырттан көзқарас пен сервер таңдау керек болса, бұл жүйелік интеграторлармен бірге істеледі. GSE.kz‑те жеткізу мен интеграциядан басқа 24/7 қолдау және отандық жабдық негізінде инфрақұрылым құру тәжірибесі бар. Бұл жергілікті өндіруші талаптары және жеткізу мөлдірлігі бар ұйымдарға ыңғайлы.