ASIC тоқтап қалуы мен жөндеу шығынын қалай есептеу керек

ASIC «онлайн» болып көрінгенімен, қалыпты хэшрейт бермеуі мүмкін. Сондықтан тоқтап қалу шығынын тек толық өшкен сағатпен өлшеу жеткіліксіз. Желі үзілуі, overheat салдарынан жиілік төмендеуі, rejected share, қайта жүктеу және жөндеу кезегінде күту де жоғалған өндіріс болып саналады. Дұрыс бюджет осы оқиғаларды себеп, уақыт және ақша бойынша бөледі.

Дерек 2026-08-09 күні тексерілді. Кепілдік пен жөндеу шарттары модельге қарай өзгереді; сатып алу құжатын және өндірушінің ағымдағы нұсқауын қайта тексеріңіз.

Мазмұны

Uptime-ды дұрыс өлшеу
Тоқтап қалудың төрт себебі
Жоғалған өндіріс пен тікелей шығын
Жөндеу резервін құру
SLA және жөндеу кезегі
Жөндеу ме, ауыстыру ма
Айлық операциялық есеп
Оқиға уақытын бір стандартпен тіркеу
Жиі қойылатын сұрақтар

Uptime-ды дұрыс өлшеу

тиімді uptime = қабылданған хэшрейт-сағат / жоспарланған хэшрейт-сағат. Бұл көрсеткіш «құрылғы ping-ке жауап берді» дегеннен пайдалырақ. Мысалы, бір тәулікте машина 24 сағат қосулы болып, бірақ 4 сағат бойы номиналдың жарты хэшрейтімен жұмыс істесе, оны 100% uptime деп белгілеуге болмайды.

Pool жағындағы 15 минуттық және тәуліктік hashrate, rejected share, құрылғы журналы, smart PDU немесе электр есептегіштің уақыт белгісі бір уақыт белдеуінде сақталуы керек. Әр оқиғаға басталу, анықталу, қалпына келу және қалыпты өндіріске оралу уақыты жазылады.

Тоқтап қалудың төрт себебі

Электр оқиғасына сыртқы ажырату, breaker жұмысы және сапасыз қуат кіреді. Желі оқиғасына ISP, router, DNS немесе pool endpoint мәселесі жатады. Жылу оқиғасы ауа ағыны, шаң, желдеткіш және ambient температурамен байланысты. Құрылғы оқиғасы hashboard, PSU, control board, firmware немесе сенсор ақауын қамтиды. Себептерді араластырсаңыз, резерв ақшаны дұрыс жерге бағыттай алмайсыз.

BITMAIN тазалау нұсқаулығы профилактиканың маңызын көрсетеді, ал Canaan log guidance журналдан қате белгісін ажыратуға көмектеседі. Бірақ журналдағы бір код автоматты түрде бөлшекті ауыстыру үкімі емес: қауіпсіз электр тексерісі, ресми troubleshooting реттілігі және кепілдік шектеуі сақталуы тиіс.

Жоғалған өндіріс пен тікелей шығын

жоғалған BTC = базалық BTC/сағат × тиімді тоқтау сағаты. Оны оқиға күніндегі басқарушылық BTC/KZT мәніне көбейтіп, «opportunity cost» ретінде көрсетіңіз. Одан бөлек тікелей шығынды жазыңыз: диагностика еңбегі, бөлшек, жеткізу, кеден, мердігер, қайта орнату және сынақ электрі. Екі соманы қоспай көрсету маңызды: жоғалған өндіріс — төленген шот емес, бірақ шешім сапасына әсер етеді.

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

Жөндеу резервін құру

Тарих жоқ кезде жалған дәлдік қолданбаңыз. Алғашқы резервті айына күтілетін оқиға саны × бір оқиғаның орташа тікелей құны бойынша белгілеңіз және оған жедел жеткізу қорын қосыңыз. Үш айдан кейін median және 90-процентиль мәнін нақты жұмыс тапсырыстарынан қайта есептеңіз.

Қосалқы бөлшек қоры ABC қағидасымен бөлінеді: тез ауысатын арзан бөлшек; сирек, бірақ өндірісті толық тоқтататын бөлшек; қымбат және кепілдік арқылы алынатын модуль. Әр SKU үшін қолданылған саны, жарамды донор, сатып алу уақыты және min/max деңгейі болсын. «Көбірек бөлшек — қауіпсіз» емес: ескі модельге байланған өтімсіз қор да шығын.

SLA және жөндеу кезегі

Ішкі немесе hosting SLA төрт уақытты бөлуі керек: ақауды анықтау, алғашқы әрекет, диагноз, қызметке қайтару. Тек «24 сағатта жауап береміз» деген шарт өндірістің қашан қайта басталатынын айтпайды. Сондай-ақ демалыс күні, қоймаға қолжетімділік, remote reset өкілеттігі және клиент мақұлдауын күту тәртібі жазылады.

Қайтарылған машина үшін 15 минуттық hashrate жеткіліксіз. Кемінде тұрақты сынақ терезесі, температура, rejected share және қуат мәні тіркелсін. Қайталама ақау бөлек incident ретінде емес, сол жөндеудің failure-on-return көрсеткіші ретінде талдансын.

Жөндеу ме, ауыстыру ма

Шешім формуласы: жөндеуден кейінгі консервативті ақша ағыны × қалған айлар + қалдық құн − жөндеу құны − жөндеу кезіндегі жоғалған өндіріс. Бұл нәтиже істейтін балама құрылғының нарықтық құнымен және жабдықты бөлшекке сату нұсқасымен салыстырылады.

Stop-rule мысалы: бір құрылғы 60 күнде екі рет қайталама ақау берсе; жөндеу құны стресс сценарийдегі алты айлық маржадан асса; ресми қауіпсіз firmware немесе бөлшек қолжетімсіз болса — жөндеуді автоматты жалғастырмай, техникалық және қаржылық қайта қарауға жіберіңіз.

Айлық операциялық есеп

Есепте парк саны, жоспарланған және тиімді хэшрейт-сағат, себеп бойынша downtime, MTTR, қайталама ақау, бөлшек шығыны, жоғалған BTC және SLA бұзылуы бірге тұрсын. Тек орташа uptime көрсету ең нашар құрылғыларды жасырады; модель, партия және rack бойынша бөлу қажет.

Тиімді нәтиже — «uptime 99%» деген әдемі сан емес. Нәтиже: ең көп жоғалту әкелетін екі себеп, оларды азайтатын нақты әрекет, иесі, мерзімі және күтілетін KZT әсері.

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

Құрылғы жұмыс істегенімен табыс әкелмеген бөлігі ретінде тиімді downtime есебіне кіреді.

Кепілдіктегі ASIC үшін резерв керек пе?

Иә. Жеткізу, күту, қайта орнату және жоғалған өндіріс кепілдікпен өтелмеуі мүмкін.

Uptime-ды құрылғыдан ба, pool-дан ба алу керек?

Екеуін салыстырыңыз. Pool қабылдаған хэшрейт табысқа жақын, ал құрылғы журналы себепті табуға қажет.

Оқиға уақытын бір стандартпен тіркеу

Тоқтап қалудың ұзақтығы «қашан біреу байқады» деген уақыттан басталса, шығын төмен көрінеді. Әр оқиға үшін кемінде бес белгі керек: қалыпты көрсеткіштен алғаш ауытқу, мониторинг дабылы, жауапты адамның қабылдауы, техникалық қалпына келу және pool-да қабылданған хэшрейттің тұрақтануы. Бұл уақыттардың арасы detection gap, response time, repair time және validation time болып бөлінеді.

Барлық жүйе бір уақыт белдеуін қолдансын. ASIC log, router, PDU, pool dashboard және жұмыс тапсырмасы әртүрлі time zone-да тұрса, бір оқиғаны екі рет санау немесе бірнеше сағатты жоғалту оңай. NTP күйі бақыланып, экспортта timezone көрсетіледі. Қолмен енгізілген уақытқа кім және қай дерекке сүйеніп түзету жасағаны жазылады.

Оқиға идентификаторы барлық дәлелді байланыстырады: rack пен serial, alert, log файлы, фото, қолданылған бөлшек, техник аты, кепілдік өтінімі және тұрақтандыру тесті. Бір ақау қайта ашылса, оны жаңа оқиға етіп жасырудың орнына бастапқы ticket-пен байланыстырыңыз. Сонда repeat failure мен first-time fix rate шынайы болады.

Базалық өндірісті әділ анықтау

Жоғалған өндірісті ең жақсы өткен күнмен есептеу артық көрсетеді, ал ақаулы күннің орташа мәні төмен көрсетеді. Базалық хэшрейт үшін сол модельдің қалыпты қуат режиміндегі жақын 7–30 күндік медианасын, жоспарлы downtime-ды алып тастағаннан кейін пайдалану орынды. Difficulty немесе pool method өзгерсе, BTC-ге айналдыру кезеңін де сәйкестендіріңіз.

Толық өшкен уақытпен бірге partial loss есептеледі. Мысалы, құрылғы сегіз сағат бойы базалық хэшрейттің 60%-ын ғана берсе, effective downtime төрт сағат емес, 8 × (1 − 0,60) = 3,2 сағат болады. Rejected share қалыпты 0,5%-дан 3%-ға өссе, тек артық бөлігі жоғалған accepted work ретінде енгізіледі.

Бір оқиғаның жоғалған gross BTC-ін жөндеу тиімділігін бағалау үшін қолдануға болады, бірақ оны бухгалтерлік шот-фактура деп көрсетуге болмайды. Бағалау бағамы, difficulty snapshot және pool дерегі тіркеледі. Егер BTC/KZT бағамы міндеттемені өтеу үшін қажет болса, жоспардағы консервативті бағам мен оқиға күніндегі нақты бағам бөлек көрсетіледі.

Жөндеудің толық құнын шығару

Тікелей бөлшек пен еңбек ақысы тек бастамасы. Толық жөндеу құнына диагностика, қауіпсіз тоқтату, бөлшектеу, қаптау, екі жақты логистика, кеден, мердігер, қайта орнату, сынақ электрі және күту кезеңіндегі жоғалған contribution margin кіреді. Hosting келісімінде remote hands бөлек тарифтелсе, әр әрекет саны да есептеледі.

Кепілдік өтінімі қабылданғанға дейін «бөлшек құны нөл» деп қоймаңыз. Модельде үш нәтиже болсын: өндіруші толық қабылдайды; тек бөлшекті өтейді; өтінім қабылданбайды. Әр нәтиженің ықтималдығын ойдан шығармай, тарихи ticket дерегі болмаса белгісіз деп қалдырыңыз және cash reserve-ті ең қолайсыз ақылға қонымды нәтижеге есептеңіз.

Жөндеу үшін басқа машинаның hashboard немесе PSU-ы алынса, donor құрылғының жоғалған құны мен оны қайта жинау жоспары болады. «Қоймада тегін бөлшек бар» деген жазба активтің басқа жерден шығарылғанын жасырады. Әр бөлшекке source serial және жаңа destination serial белгіленеді.

Қосалқы бөлшек қорын тәуекел бойынша құру

ABC бағасынан бөлек criticality керек. Арзан fan жиі істен шығып, машинаны тоқтатуы мүмкін; қымбат hashboard сирек керек, бірақ оны ұзақ сақтаудың техникалық және капитал шығыны бар. Әр бөлшек үшін айлық пайдалану, жеткізу lead time, ең аз қауіпсіз қор, максималды қор және compatible model тізімі жазылады.

Reorder point-ты lead time кезіндегі күтілетін сұраныс + safety stock арқылы есептеуге болады. Бірақ бір жылдық тарихы жоқ ферма дәл ықтималдық жасамауы тиіс. Алғашқы кезеңде өндіруші ұсынысы, парк саны және ең ұзақ ақылға қонымды жеткізу уақыты қолданылады; үш-алты ай сайын нақты тұтынумен қайта калибрленеді.

Қоймадағы бөлшек те тексеріледі. Ылғал, шаң, ESD қорғауы, пломба, сатып алынған күн және соңғы тест белгісі сақталады. Ескі модельге сәйкес келмейтін қор «бар» деп көрінгенімен, ағымдағы паркке көмектеспейді. Тоқсан сайын obsolete inventory бөлек шығарылады.

Профилактикалық қызметтің терезесін таңдау

Тазалау немесе тексеру үшін жоспарлы тоқтау да шығын, бірақ ол апатты жөндеуден аз болуы мүмкін. Терезе electricity contract, ауа райы, pool payout немесе difficulty болжамымен емес, нақты қауіп пен қолжетімді маманға қарай белгіленеді. Бір rack-ты толық өшірмей, шағын cohort арқылы процедура мен уақыт нормасын тексеріңіз.

Қызмет тізімі өндіруші мен алаң қауіпсіздігіне сәйкес жасалады: қуатты ажырату және lockout, ауа жолын тексеру, шаңды қауіпсіз алу, fan/connector күйі, температура сенсоры, кабельдің қызуы, firmware/config backup және іске қосқаннан кейінгі accepted hashrate. Компрессор немесе тазарту әдісі өндіруші талабына қайшы болса, өз бетінше қолданылмайды.

Профилактикадан кейін 15 минуттық «online» белгі жеткіліксіз. Кемінде алдын ала бекітілген soak window ішінде хэшрейт, температура, fan speed, қуат және reject тұрақтануы керек. Тексеруден өтпеген машинаны өндіріске қайтару maintenance completion көрсеткішін әдемілейді, бірақ кейінгі failure-on-return-ды көбейтеді.

Hosting пен мердігер жауапкершілігін бөлу

Келісімде электрдің сыртқы үзілісі, алаң ішіндегі breaker, желі, салқындату, құрылғы ақауы және клиент бұйрығы бойынша тоқтату бөлек кодталсын. Әр код үшін кім дабыл береді, кім әрекет етеді, қандай дәлел береді және қандай жағдайда service credit қолданылатыны анықталады. Жалпы «форс-мажор» тармағы күнделікті операциялық жауапкершілікті жоймауы керек.

Мердігерге қашықтан басқару құқығы берілсе, рұқсат ауқымы, екі факторлы қорғау, әрекет журналы және төтенше жағдайда кім бекітетіні жазылады. Password немесе pool address өзгерісі ticket-сіз жасалмайды. Жұмыс аяқталған соң уақытша қолжетімділік қайтарылады.

SLA-дағы availability пайызын есептеу формуласын нақтылаңыз: бөлгішке жоспарлы maintenance кіре ме, partial hashrate қалай саналады, клиенттің кеш approval уақыты кімге тиесілі, өлшем көзі қайсы. Формула анық болмаса, 99% уәде екі тарап үшін екі түрлі мағына береді.

Жөндеу немесе ауыстыру жөніндегі кезеңдік шешім

Алдымен қауіпсіздік stop-rule қолданылады: күйік, қайталанған қысқа тұйықталу, оқшаулау немесе өндіруші қолдамайтын қауіпті firmware жағдайында экономикалық есепке дейін құрылғы ажыратылады. Содан кейін ғана жөндеу, donor, сату немесе ауыстыру cash flow-ы салыстырылады.

Гипотетикалық мысал: ақаулы машинаны жөндеу 220 000 KZT, логистика 60 000 KZT, күту кезіндегі консервативті жоғалған margin 90 000 KZT болсын. Толық repair exposure — 370 000 KZT. Егер жөндеуден кейінгі алты айлық консервативті cash contribution 420 000 KZT, ал қайта ақау тәуекеліне резерв 100 000 KZT болса, артықшылық небәрі -50 000 KZT деңгейіне түседі. Бұл ойдан алынған әдістемелік сандар; нақты шешім үшін өз ticket, тариф және өндіріс дерегі қолданылады.

Repair-vs-replace кестесінде жаңа машинаның тек бағасы емес, жеткізу уақыты, электр инфрақұрылымына сәйкестігі, кепілдігі, J/TH және ескі машинаның бөлшек құны да бар. Шешімді бастапқы сатып алу бағасына байламаңыз: ол sunk cost.

Оқиғадан кейінгі тексеріс

Маңызды оқиғадан кейін бес сұраққа жауап беріңіз: нақты не болды; неге мониторинг оны сол уақытта көрді; неге қорғаныс немесе резерв тоқтатпады; қай әрекет қалпына келтірді; қай өзгеріс қайталануды азайтады. «Оператор қатесі» түбір себеп емес — процедура, интерфейс, рұқсат немесе оқытудағы жағдайды көрсету керек.

Әр action-ға иесі, мерзімі және тексеру дәлелі беріледі. Мысалы, «желіні жақсарту» орнына «rack 4 failover endpoint-ін жүктемемен тексеру, accepted hashrate қалпына келуін 2026-09-01T10:00:00+05:00 дейін журналмен растау» сияқты нақты нәтиже жазылады. Уақыт міндетті түрде timezone-пен сақталады.

Айлық есепте оқиға санының азаюымен бірге loss per incident, detection gap, MTTR, repeat failure, first-time fix және maintenance backlog қаралады. Бір KPI жақсарғаны басқа шығынды жасыра алмайды. Осы тәртіп тоқтап қалуды жай пайыздан нақты басқарылатын ақша және техникалық тәуекелге айналдырады.

Жөндеуден кейін жаңа базаны бекіту

Жөндеуден өткен ASIC-ті бұрынғы атаулы хэшрейтке бірден теңестірмеңіз. Soak test аяқталған соң 24–72 сағаттық бақылау терезесінде accepted hashrate, қуат, температура, fan speed және reject медианасы жазылады. Нақты ұзақтық өндіруші талабы мен ақау түріне сай таңдалады; мақаладағы аралық әмбебап кепілдік емес.

Егер жаңа baseline бұрынғысынан төмен болса, «онлайн» мәртебесі ақау толық жойылды дегенді білдірмейді. Қуат режимі әдейі төмендетілді ме, board саны азайды ма, pool немесе difficulty өлшемге әсер етті ме — себебі бөлек белгіленеді. Қалпына келген қуат тұтынуы мен accepted hashrate негізінде J/TH қайта есептеледі.

30 күн ішінде сол симптом қайталанса, екінші оқиғаның шығыны алғашқы жөндеу шешіміне қосылады. Бұл warranty claim, мердігер сапасы және repair-vs-replace талдауына әсер етеді. Қысқа мерзімді қайта ақауды бөлек «сәтті жөндеу» деп санау first-time fix көрсеткішін жасанды көтереді.

Жаңа baseline актив тізіліміне де беріледі: күтілетін өндіріс, қалған пайдалы мерзім және қалдық құн қайта қарауды қажет етуі мүмкін. Осы байланыстың арқасында техникалық ticket тек жабылып қалмай, қаржы моделін жаңартатын дәлелге айналады.