ASIC firmware және желі қауіпсіздігі: фермаға арналған тексеру тізімі

ASIC — тұрақты қуат тұтынатын, wallet address пен pool credential сақтайтын желілік құрылғы. Әдепкі пароль, интернетке ашық management port немесе тексерілмеген firmware шабуылшыға хэшрейтті басқа адреске бұруға, құрылғыны тоқтатуға немесе ферманың ішкі желісіне өтуге мүмкіндік береді.

Дерек 2026-08-09 күні тексерілді. BITMAIN және CISA нұсқаулары негіз ретінде берілген; нақты firewall, VPN және recovery архитектурасын қауіпсіздік маманы нысанға сай бекітсін.

Мазмұны

Активтерді түгелдеңіз
Әдепкі пароль мен аккаунт
Желіні сегменттеңіз
Firmware supply chain
Malware белгісі және әрекет
Backup және recovery
Өзгерісті басқару
Қауіпсіздік шекарасын дерек ағынымен белгілеңіз
Құрылғыны есептен шығарғанда басқару дерегін жойыңыз
Жиі қойылатын сұрақтар

Активтерді түгелдеңіз

Әр ASIC үшін serial, MAC/IP, модель, firmware version/hash, rack, owner, pool worker және соңғы patch күні болсын. Белгісіз құрылғы production VLAN-ға қосылмайды. DHCP reservation немесе inventory жүйесі physical serial-мен байланыстырылсын.

Control board ауысса, MAC/IP және credential өзгерісін ticket арқылы жаңартыңыз. «Қай құрылғы қайда?» сұрағына жауап жоқ болса, incident кезінде isolation қауіпсіз орындалмайды.

Әдепкі пароль мен аккаунт

BITMAIN malware prevention құжаты пароль ауыстыру және ресми қалпына келтіруді ұсынады. Әр құрылғыда бірегей немесе қауіпсіз басқарылатын credential қолданыңыз; ортақ пароль leak болғанда бүкіл парк ашылады. Credential spreadsheet-ін жалпы чатта сақтамаңыз.

Remote operator жеке named account, MFA бар jump host/VPN арқылы кіреді. Интернеттен miner web UI-ға port-forward жасалмайды. Қызметкер кеткенде access пен VPN certificate дереу revoke етіледі.

Желіні сегменттеңіз

ASIC VLAN тек қажетті pool endpoint, DNS, NTP және басқару jump host-пен сөйлессін. Office, finance, wallet signing және guest желілерінен firewall арқылы бөлінеді. CISA guidance OT/өндірістік ортада segmentation және бақыланатын remote access тәуекелді төмендететінін атап өтеді.

Egress allow-list күрделі болса да, кемінде miner-дің қажетсіз outbound және lateral traffic-ын бақылаңыз. Firewall deny log, DNS өзгерісі, көп login failure және pool address ауысуы alert тудырсын.

Firmware supply chain

Firmware-ді ресми өндіруші бетінен алыңыз, файл атауы, модель сәйкестігі, жарияланған күні және hash/цифрлық тексеру мүмкіндігін журналдаңыз. Email/чаттан келген белгісіз файлды production-ға салмаңыз.

BITMAIN firmware tips алдымен 10–30 бірлік pilot және кемінде 24 сағат бақылауды ұсынады. Backup configuration, rollback файлы, power interruption тәуекелі және warranty әсері update plan-да жазылсын. Бүкіл фермаға бір мезетте push жасалмайды.

Malware белгісі және әрекет

Белгісіз pool/address, парольдің өздігінен өзгеруі, firmware update сәтсіздігі, қалыптан тыс DNS/traffic немесе hashrate басқа жаққа кетуі — күдік белгісі. Құрылғыны желіден оқшаулаңыз, уақыт/журналды сақтаңыз, wallet/private key қауіпсіздігін бөлек тексеріңіз және ресми recovery процедурасын қолданыңыз.

Күдікті miner-ді reset жасап бірден production-ға қайтармаңыз. Сенімді image, жаңа credential, таза VLAN-дағы сынақ және pool address verification қажет. Incident scope бір құрылғымен шектелмей, сол password/firmware қолданған cohort бойынша тексеріледі.

Backup және recovery

Golden configuration-да pool endpoint, worker naming, network және monitoring параметрі бар, бірақ құпия password/token ашық сақталмайды. Offline ресми firmware көшірмесі, configuration template және recovery runbook нұсқаланады.

Тоқсан сайын бір test miner арқылы factory recovery, firmware install, credential rotation және monitoring-ке қайта қосылу уақыты өлшенсін. Жоспар тек қағазда болса, ransomware немесе жаппай ақауда қалпына келу белгісіз.

Өзгерісті басқару

Әр change request-та себеп, нысана cohort, файл көзі, approval, pilot, success metric, rollback trigger және нәтижесі бар. Success тек «boot болды» емес: 24 сағат hashrate, температура, power, reject және network log қалыпты болуы керек.

Emergency patch те кейіннен құжатталады. Өнімділік үшін қауіпсіздік control-ын үнсіз өшіру no-go болып саналады.

Жиі қойылатын сұрақтар

Miner UI-ды интернетке ашуға бола ма?

Тікелей ашу ұсынылмайды; VPN/jump host және least privilege қолданыңыз.

Барлық ASIC-ке бір пароль ыңғайлы емес пе?

Ыңғайлы, бірақ бір leak бүкіл паркті ашады. Басқарылатын бірегей credential қауіпсіз.

Update сәтті болғанын қашан білеміз?

Тұрақты бақылау терезесінде hashrate, power, температура, reject және log қалыпты болғанда.

Қауіпсіздік шекарасын дерек ағынымен белгілеңіз

ASIC қауіпсіздігін тек «майнерге күрделі пароль қою» деп түсіну жеткіліксіз. Алдымен дерек қайдан келіп, қайда кететінін бір бетке түсіріңіз. Әр құрылғы басқару желісінен конфигурация алады, DNS пен уақыт қызметіне жүгінеді, пулға share жібереді және әкімшіге журнал көрсетеді. Осы ағындардың әрқайсысы үшін иесі, мақсаты, рұқсат етілген бағыты және қалыпты жиілігі жазылуы керек. Белгісіз бағытқа тұрақты қосылатын майнерді қалыпты паркке бірден қайтаруға болмайды.

Қарапайым реестрге мыналарды қосыңыз:

құрылғының asset ID-і, сериялық нөмірі, MAC және бекітілген IP мекенжайы;
модель, firmware нұсқасы, конфигурацияның соңғы тексерілген күні;
қай VLAN немесе физикалық сегментте тұрғаны;
рұқсат етілген pool endpoint-тері және failover реті;
басқаруға құқығы бар рөл және жауапты қызметкер;
журнал мен backup қайда сақталатыны;
қалыпты хэшрейт, reject үлесі және қайта жүктеу жиілігінің базалық мәні.

Бұл карта екі міндетті шешеді. Біріншіден, шабуыл не қате өзгеріс кезінде қай майнердің мінезі өзгергенін тез байқайсыз. Екіншіден, істен шыққан құрылғыны ауыстырғанда ескі IP, ескі пароль немесе бөтен pool адресін байқамай көшіріп жібермейсіз. Реестрді инвентаризациядан бөлек құжат деп қарамаңыз: әр қабылдау, орын ауыстыру және есептен шығару операциясы сол күні жаңартылуы тиіс.

Аккаунттың бүкіл өмір циклін басқарыңыз

Ортақ administrator паролі үлкен фермада кімнің не өзгерткенін анықтауға мүмкіндік бермейді. Құрылғы жеке аккаунттарды қолдаса, күнделікті бақылау, firmware орнату және авариялық қалпына келтіру үшін бөлек рөлдер жасаңыз. Қолдамаса, қолжетімділікті басқару шлюзінде жеке есептік жазба, MFA және сессия журналы арқылы шектеңіз. Майнердің web-интерфейсін ашық интернетке шығармаңыз; қашықтан кіру рұқсат етілген VPN немесе басқарылатын jump host арқылы ғана жүруі керек.

Қызметкер келгенде, рөлі ауысқанда және жұмыстан кеткенде орындалатын қысқа процедура қажет. Жұмыстан шығу күні аккаунтты жабу, API кілтін қайтарып алу, сақталған VPN профилін жою және ортақ құпия сөз қолданылған болса оны ауыстыру — бір ticket ішінде дәлелденсін. Тоқсан сайын белсенді аккаунттарды штат тізімімен салыстырыңыз. Соңғы 90 күн қолданылмаған, иесі белгісіз немесе мердігерге уақытша берілген қолжетімділікті автоматты түрде «қажет» деп қалдырмаңыз.

Авариялық аккаунт бөлек мөрленген тәртіппен сақталсын. Оны пайдалану екі адамның келісімін, нақты себепті және кейінгі пароль ауыстыруды талап етеді. Мұндай аккаунтты күнделікті жұмысқа қолдану — бақылаудың істемей тұрғанының белгісі.

Қашықтан қолжетімділікті уақытпен және мақсатпен шектеңіз

Vendor немесе hosting операторы «диагностика үшін тұрақты кіру керек» деуі мүмкін. Тұрақты рұқсаттың орнына басталу және аяқталу уақыты бар change ticket ашыңыз. Ticket ішінде қандай asset-терге, қандай міндет үшін, кімнің бақылауымен кіретіні көрсетілсін. Сессия аяқталған соң маршрут, аккаунт немесе уақытша сертификат жабылып, жасалған өзгерістердің тізімі тіркелуі керек.

Қашықтан сессияның ең аз дәлел пакеті:

өтініш беруші мен мақұлдаушының аты;
кіруге рұқсат етілген asset ID тізімі;
басталу және аяқталу уақыты;
орындалған команданың мазмұны емес, өзгертілген параметрлер мен нәтиже;
сессия журналының сақталған орны;
қолжетімділіктің шынымен жабылғанын растайтын тексеріс.

Кенеттен шетелдік IP, қалыптан тыс уақытта кіру немесе бірнеше майнерге бірдей конфигурация тарату әрекеті байқалса, бұл жай техникалық ауытқу емес. Басқару желісін уақытша оқшаулап, пулға шығатын өндірістік трафикті бөлек бағалаңыз. Тергеу аяқталмай тұрып барлық құрылғыны жаппай қайта жүктеу журналдағы пайдалы іздерді жоғалтуы мүмкін.

Firmware файлының шығу тегін дәлелдеңіз

Firmware атауының «official» болуы оның түпнұсқа екенін дәлелдемейді. Файл тек өндірушінің ресми доменінен немесе ұйым бекіткен репозиторийден алынсын. Жүктеу кезінде URL, күн, модельге сәйкестік, жарияланған нұсқа және өндіруші берген hash немесе қолтаңба бар болса, оның нәтижесі жазылады. Файлдың өзін өзгермейтін архивке салыңыз; кейін дәл сол файл қай cohort-қа орнатылғанын көрсетуге мүмкіндік болсын.

Үшінші тарап firmware-і өнімділікті арттыруы мүмкін, бірақ лицензия, dev fee, fan control, кернеу шегі және кепілдік шартын өзгертеді. Сондықтан оны «тегін жаңарту» деп емес, жаңа технологиялық жеткізуші деп бағалаңыз. Кодтың шыққан тегі, жаңарту арнасы, қолдау мерзімі, кері қайту мүмкіндігі және pool адресін өзгерту тәуекелі жазбаша тексерілмесе, өндірістік паркке кіргізбеңіз.

Файлды чаттан, форумдағы қысқартылған сілтемеден немесе белгісіз флеш-дисктен алған жағдайда, оны тест құрылғысына да қоймаңыз. Мұндай материал quarantine аймағына жіберіліп, қауіпсіздікке жауапты адам шешім шығарғанша қолданылмайды.

Жаңартуды шағын cohort арқылы өткізіңіз

BITMAIN ресми нұсқаулығы firmware жаңартуын алдымен шағын партияда сынап, кемінде 24 сағат бақылауды ұсынады. Фермаңыз үшін бұл қағиданы нақты gate-терге айналдырыңыз. Алдымен бір модель мен бір аппараттық ревизиядан репрезентативті cohort таңдаңыз. Оның алдында 24 сағаттық хэшрейт, reject, температура, fan RPM, қуат және reboot базасын сақтаңыз.

Жаңартудан кейінгі gate мысалы:

барлық тест майнері басқару желісінде көрінеді;
pool worker атауы мен wallet адресі өзгермеген;
орташа хэшрейт келісілген ауытқу шегінен шықпаған;
reject және hardware error үлесі нашарламаған;
қуат пен температура рұқсат етілген диапазонда;
автоматты қайта жүктеу немесе fan режимінің тосын өзгерісі жоқ;
rollback файлы мен рәсімі нақты тексерілген.

Осы шарттардың бірі орындалмаса, келесі cohort-қа өтпеңіз. «Майнер әлі хэш беріп тұр» деген жалғыз белгі жеткіліксіз: зиянды немесе қате firmware пул адресін кейін өзгертуі, dev fee қосуы немесе басқару арнасын ашық қалдыруы мүмкін. Үлкен партияға тарату үшін техникалық иесі мен операциялық иесінің бөлек мақұлдауы болсын.

Конфигурация тұтастығын күнделікті салыстырыңыз

Жұмыс істеп тұрған құрылғының конфигурациясын «дұрыс» деп қабылдау қауіпті. Бекітілген baseline жасаңыз: pool реті, worker атауының үлгісі, DNS, NTP, fan/қуат профилі, firmware нұсқасы және басқару параметрлері. Күн сайын немесе әр change-ден кейін ағымдағы күйді baseline-пен салыстырыңыз. Айырмашылық автоматты түрде жойылмай, exception ретінде иесіне жіберілсін.

Бірдей өзгерістің көптеген құрылғыда бір мезетте пайда болуы маңызды белгі. Ол жоспарлы rollout та, ұрланған әкімші аккаунты да болуы мүмкін. Сондықтан өзгерістің ticket нөмірі жоқ болса, оны рұқсат етілмеген деп қараңыз. Pool адресі, payout wallet немесе DNS өзгерсе, өндірістік тәуекел жоғары санатқа өтеді және дереу оқшаулау қажет.

Baseline файлын сол майнерлер қол жеткізетін ортада ғана сақтамаңыз. Офлайн немесе бөлек қорғалған көшірме шабуыл кезінде салыстыруға қажет. Ай сайын кездейсоқ бірнеше asset-тің baseline-ы нақты интерфейспен қолмен тексерілсін; бұл автоматтандырудың өзі қате конфигурацияны «қалыпты» деп бекітіп қоймағанын көрсетеді.

Мониторингті операциялық шектермен байланыстырыңыз

Қауіпсіздік оқиғасы әрдайым antivirus ескертуі түрінде келмейді. Хэшрейттің түсініксіз төмендеуі, worker атауының өзгеруі, DNS сұрауларының жаңа бағыты, көптеген login қатесі немесе жоспарсыз reboot — бәрі бірге маңызды сигнал болуы мүмкін. Әр alert үшін кім алады, қанша минут ішінде бағалайды және қандай жағдайда майнер оқшауланады деген playbook жазыңыз.

Сигналдарды үш деңгейге бөлуге болады. Ақпараттық деңгей — бір реттік, өндірісті бұзбайтын ауытқу. Тергеу деңгейі — қайталанған login, firmware drift немесе белгісіз outbound бағыт. Оқшаулау деңгейі — wallet/pool ауысуы, рұқсатсыз administrator, жаппай конфигурация өзгерісі немесе зиянды код белгісі. Соңғы деңгейде кірісті сақтау үшін қауіпті құрылғыны жұмыс істете беру дұрыс емес.

Alert сапасын ай сайын тексеріңіз. Егер оператор күніне жүздеген жалған ескерту алса, шынайы оқиға көзден таса қалады. Шекті мәнді дәлелмен реттеңіз, бірақ ескертуді үндемей өшірмеңіз. Әр өзгеріс тест дерегімен және жауапты адамның мақұлдауымен бекітілсін.

Оқиға кезінде дәлелді сақтап, таза қалпына келтіріңіз

Күдікті майнер табылғанда алдымен уақытты, asset ID-ті, IP-ді, көрінген белгіні және оны кім байқағанын жазыңыз. Мүмкін болса журнал, конфигурация, firmware нұсқасы және желілік метадерек бөлек қорғалған жерге көшіріледі. Тек содан кейін құрылғы басқару және өндірістік желіден оқшауланады. Электр қауіпсіздігіне қатысты әрекетті тек білікті маман орындайды.

Қалпына келтіру «factory reset басып, қайта қосумен» аяқталмайды. Сенімді firmware көзі, жаңа credential, таза baseline және бекітілген pool/wallet конфигурациясы қолданылсын. Құрылғы quarantine cohort-та бақыланып, қалыпты мінез дәлелденгеннен кейін ғана өндіріске қайтады. Сол credential немесе firmware алған басқа майнерлер impact scope ретінде тексеріледі.

Post-incident review кінәлі іздеу үшін емес, бақылаудың қай жерде үзілгенін табу үшін жасалады. Root cause, әсер еткен уақыт, жоғалған хэшрейт, ықтимал бұрылған төлем, қалпына келтіру шығыны және келесі нақты control owner-і көрсетілсін. Жабылған әрекеттің дәлелі болмаса, ticket аяқталды деп саналмайды.

Үшінші тарап пен ерекше жағдай реестрін жүргізіңіз

Hosting, жөндеу шебері, firmware жеткізушісі және мониторинг провайдері әртүрлі қолжетімділік алады. Келісімде олардың қандай деректі көретіні, credential-ды қалай қорғайтыны, оқиға туралы қанша уақытта хабарлайтыны және шарт аяқталғанда деректі қалай жоятыны жазылсын. «Біздің маман бәрін біледі» деген ауызша кепіл бақылау емес.

Кейде ескі ASIC жаңа қауіпсіз firmware-ді қолдамайды немесе өндірісті тоқтатпай сегменттеу мүмкін болмайды. Мұндай жағдайда үнсіз қабылдаудың орнына exception register ашыңыз. Онда тәуекел, себеп, уақытша өтем бақылауы, иесі және аяқталу күні болсын. Мерзімі өткен exception автоматты түрде қайта мақұлданбасын. Құрылғының табысы тәуекелді өтеуге жетпесе, оны парк ішінде мәңгі қалдыруға болмайды.

Тоқсандық дәлел пакетін жинаңыз

Тоқсан соңында қауіпсіздік жағдайын бір бет «бәрі қалыпты» есебімен жаппаңыз. Қысқа дәлел пакеті asset тізімінің өзгерісін, firmware cohort нәтижесін, аккаунт review-ын, ашық exception-дарды, маңызды alert пен incident-терді, backup restore тестін және келесі тоқсанның иелерін қамтысын. Әр тұжырымның артында CSV, ticket, журнал немесе қол қойылған checklist болуы керек.

Басшылыққа берілетін шешім кестесінде кемінде үш таңдау көрсетіңіз: тәуекелді бақылаумен жалғастыру, нақты мерзімде жаңарту немесе asset-ті тоқтату. Қауіпсіздік шығынын тек IT бюджеті деп емес, payout жоғалуы, downtime, жөндеу және бедел тәуекелімен салыстырыңыз. Осылай firmware мен желі жұмысы майнинг экономикасынан бөлек емес, оның қорғау қабаты болады.

Құрылғыны есептен шығарғанда басқару дерегін жойыңыз

Жөндеуге, сатуға немесе бөлшекке жіберілген ASIC өндірістік желіден шыққанымен, оның басқару тәуекелі аяқталмайды. Құрылғыда pool адресі, worker атауы, ішкі IP жоспары, credential қалдығы және журнал сақталуы мүмкін. Сондықтан asset register-дегі «есептен шығарылды» белгісі нақты data sanitization дәлеліне байланыстырылсын. Әдіс модель мен сақтау құрылғысына сай болуы керек; оны өндіруші нұсқаулығы мен қауіпсіздік маманы бекітеді.

Шығару ticket-інде сериялық нөмір, соңғы firmware, конфигурация көшірмесінің сақталған орны, credential-дың ауыстырылғаны және құрылғының жаңа иесіне қандай құжат берілгені көрсетілсін. Pool немесе monitoring жүйесіндегі ескі worker, API кілті және allowlist жазбасы да жабылады. Құрылғыны өшіру жеткіліксіз: бұрынғы IP кейін басқа asset-ке берілсе, ескі monitoring ережесі жаңа құрылғыны қате сенімді деп тануы мүмкін.

Жөндеу мердігеріне толық конфигурация қажет болмаса, ең аз дерек қағидасын қолданыңыз. Диагностика үшін керек журналды ғана беріп, payout wallet, VPN профилі немесе басқа rack туралы мәліметті алып тастаңыз. Қайтарылған майнер таза firmware және жаңа credential арқылы quarantine cohort-қа кіріп, baseline тексерісінен өтсін.

Құпияларды сақтық көшірмеден бөлек басқарыңыз

Configuration backup ішінде пароль, token немесе pool credential болуы мүмкін. Оны кәдімгі техникалық файл сияқты ортақ дискіге салмаңыз. Backup-ты шифрланған қоймада сақтап, оқу құқығын қалпына келтіруге жауапты рөлмен шектеңіз. Көшірменің бар екенін тексеру жеткіліксіз; тоқсан сайын оқшауланған ортада restore жасап, файлдың ашылатынын және дұрыс asset-ке тиесілі екенін растаңыз.

Құпияның жарамдылық мерзімі backup мерзімінен бөлек жүргізіледі. Credential ауысқанда ескі backup жоғалып кетпейді, сондықтан қалпына келтіру рәсімі ескі құпияны қайта іске қоспауға тиіс. Restore checklist соңғы approved credential-ды қауіпсіз қоймадан алуды және қалпына келген майнердің pool/wallet конфигурациясын тәуелсіз тексеруді талап етсін.

Backup әкімшісі мен өндірістік өзгерісті мақұлдайтын адам бір рөл болса, кемінде маңызды restore операциясына екінші адамның review-ын қосыңыз. Бұл кездейсоқ қате мен қасақана конфигурация ауыстыру тәуекелін бірдей азайтады.

Қауіпсіздік көрсеткішін өндіріс нәтижесімен бірге оқыңыз

Тек «incident саны нөл» деген KPI әлсіз: оқиға табылмауы monitoring істемейтінін де білдіруі мүмкін. Басқарушылық панельге firmware baseline-нан ауытқыған asset үлесі, мерзімі өткен аккаунт review, жабылмаған жоғары тәуекелді exception, сәтсіз restore тесті, рұқсатсыз change және alert-ке жауап беру уақытын қосыңыз.

Көрсеткіштің иесі мен denominator-ы анық болсын. Мысалы, «95% compliant» деген сан қай asset тізіміне, қай күнге және қандай firmware baseline-ға қатысты екені көрсетілмесе, салыстыруға жарамайды. Бір көрсеткіш жақсарғанда басқа шығынды тексеріңіз: alert санын азайту false positive-ті қысқартуы мүмкін, бірақ белгісіз outbound трафиктің көрінбей қалуына жол бермеуі керек.

Қауіпсіздік пен майнинг экономикасын бір review-да байланыстырыңыз. Firmware drift байқалған cohort-та хэшрейт, reject, dev fee белгісі және payout айырмасы қатар қаралсын. Сонда қауіпсіздік тобы техникалық белгімен шектелмей, кіріске ықтимал әсерді көрсетеді; қаржы тобы да түсініксіз variance-ті жай pool luck деп жаппайды.

Көрсеткіштерді ай сайын бірдей cut-off уақытымен бекітіңіз. Asset саны өзгерсе, алдыңғы айдың пайызын жаңасымен тікелей салыстырмай, қосылған және шығарылған құрылғыларды бөлек көрсетіңіз. Ерекше жағдайға уақытша рұқсат берілсе, оның иесі, аяқталу күні және өтемдік бақылауы панельде көрінсін. Мерзімі өтіп кеткен exception автоматты түрде қалыпты күйге айналмауы керек. Басшылыққа берілетін қорытындыда тәуекелдің ақшалай ықтимал әсері, қалпына келтіру уақыты және шешімге қажет ресурс бірге жазылсын.

Жыл сайын оқиға сценарийін үстел үстінде сынаңыз

Tabletop жаттығу нақты желіні бұзбай, шешім тізбегін тексереді. Сценарий ретінде бірнеше worker-дің pool адресі өзгеруі, vendor аккаунтының жұмыс уақытынан тыс кіруі немесе жаңартудан кейін хэшрейттің біртіндеп төмендеуі алынады. Қатысушылар кім оқшаулайды, кім payout-ты тексереді, клиентке немесе hosting серіктесіне кім хабарлайды және қандай дәлел сақталатынын қағаз жүзінде жүргізеді.

Жаттығу нәтижесі «сәтті өтті» деген бір жолмен жабылмасын. Байланыс тізіміндегі ескі нөмір, белгісіз asset owner, табылмаған rollback файлы немесе шешімі жоқ заңдық хабарлау сұрағы action register-ге түседі. Әр action-ның иесі мен мерзімі болады, келесі жаттығу бұрынғы gap-тың жабылғанын қайта тексереді.