Инженерлік блог

"Тальго" Алматы-Астана пойызынан продты құтқардым: ноутбуксіз сіздің DevOps-ты құтқаратын 10 Cloud Shell командасы

11.08.2026
Шарафутдинов Р.

Жұма. Кеш. Дала. Және құлаған PROD.

Қазақстандағы көптеген IT-мамандарға таныс жағдайды елестетіп көріңізші. Сіз Алматы — Астана бағытындағы «Тальго» пойызында келе жатырсыз. Терезе сыртында Сарышағанның ұлан-ғайыр даласы зулап өтіп жатыр. Көптен күткен демалыс күндері. Сіз демалуды ұйғардыңыз, ноутбугыңыз жоғарғы сөреде жатыр, қуаты толық біткен (ал купедегі розетка, заңдылық бойынша, жұмыс істемейді). Смартфондағы желі қуатты LTE-ден көңілсіз Edge-ге, одан қайтадан «Желіні іздеу» режиміне секіріп тұр.

Кенет смартфон Telegram-хабарламасынан дірілдейді. Мониторинг боты дабыл қағуда: [CRITICAL] PROD IS DOWN. Негізгі API-де HTTP 502 Bad Gateway.

Сіз ірі e-commerce жобасында жұмыс істейсіз, дәл қазір кешкі жаппай сатылым жүріп жатыр, әрбір тоқтап тұрған минут — бұл жоғалған жүздеген мың теңге табыс және бизнес-оунердің шашының ағаруы. Джуниорларға қоңырау шалудың пайдасы жоқ, олар жұмыс чатында дүрбелеңге түсіп жатыр. Сізге продты көтеру керек. Құралдардан сізде тек 6.5 дюймдік диагоналі бар смартфон және әр 10 минут сайын жоғалып кететін мобильді интернет қана бар.

Бұл жағдайда сізді дұға емес, Google Cloud Shell құтқарады.

Cloud Shell деген не және ол неліктен DevOps-тың ультимативті қаруы?

Білмейтіндер үшін: Cloud Shell — бұл барлық Google Cloud пайдаланушыларына берілетін Linux (Debian) негізіндегі тегін виртуалды машина. Ол тікелей браузерде іске қосылады. Сізге SSH-клиент, VPN қажет емес. Тек телефоныңыздағы (немесе мобильді Chrome) Google Cloud қосымшасын ашасыз, терминал белгішесін басасыз, сонда 5 секунд ішінде сізде келесілер пайда болады:

  • Толыққанды Bash (немесе Zsh).
  • Алдын ала орнатылған және авторизацияланған құралдар: gcloud, kubectl, bq, gsutil, docker, terraform, git.
  • Скрипттеріңіз үшін 5 ГБ тұрақты сақтау орны (Persistent Home).
  • VPC-дің жеке желісіне қол жеткізу.

Бұл дегеніміз, сізге құпия сөздерді енгізудің, кілттерді баптаудың, логтарды жүктеудің қажеті жоқ. Сіз ӨЗІҢІЗДІҢ аккаунтыңыздың құқықтарымен инфрақұрылымыңыздың ішіндесіз.

Бұл мақалада мен пойыз рельс түйіспелерінде шайқалып келе жатқанда, iPhone-ның экрандық пернетақтасында терлеген саусақтарыммен терген 10 команданың және продты құтқарудың шынайы хроникасымен бөлісемін. Бұл командаларды әрбір DevOps-инженер жатқа білуі тиіс.

Инцидент хроникасы: Тірілтуге арналған 10 қадам

1-команда: Дұрыс жобаны таңдаймыз

Cloud-та сізде ондаған жобаларға (dev, stage, prod) қолжетімділік болуы мүмкін. Бірінші өсиет: қай жерде екеніңізге көз жеткізіңіз. Prod орнына stage-ді атып тастамас үшін, контекстті қатаң түрде орнатамыз.

gcloud config set project my-ecommerce-prod-kz

Кеңес: Ағымдағы жоба әрқашан қызыл түспен жанып тұруы үшін Cloud Shell-де bash-қа арналған кастомды prompt-ты (.bashrc файлында) баптауға болады. Телефон экранында бұл фатальды қателерден сақтайды.

2-команда: Логтарды жол-жөнекей оқу (Кедейлерге арналған Traceroute)

Біздің API Gateway-де (Cloud Run-да айналып тұрған) 502 қатесі бар. Әлсіз 3G-интернетте Cloud Logging (Logs Explorer) UI-консолін жүктеу — бұл өлім. Бет бірнеше мегабайт тартады. Сондықтан біз логтарды тікелей терминалда оқимыз.

gcloud logging read 'resource.type="cloud_run_revision" AND severity>=ERROR' --limit=5 --format=json

Нәтижесі: "Connection refused. Database prod-pg-db is not responding.". Аха, мәселе API кодында емес, PostgreSQL (Cloud SQL) дерекқорында екен. Қосымша оған қосыла алмай жатыр. Ары қарай жүреміз.

3-команда: Cloud SQL диагностикасы (Базада не болды?)

База құлап жатыр. Оның толық құлағанын, CPU бойынша шамадан тыс жүктелгенін немесе дискіде орын қалмағанын түсіну керек. Инстанстар тізімін және олардың статусын қараймыз.

gcloud sql instances list --filter="name=prod-pg-db"

Статусы: RUNNABLE. Демек, виртуалка тірі. Соңғы операцияларды қараймыз (мүмкін біреу пик сағаттарында бэкап немесе миграцияны іске қосқан шығар):

gcloud sql operations list --instance=prod-pg-db --limit=3

Күдікті ештеңе жоқ. Сірә, базаны барлық коннекттерді (connection pool exhaustion) жеп қойған ауыр сұраумен "жауып" тастаған сияқты. Бұл классика: аналитиктер сатылым кезінде мастер-базадан сату туралы есепті тікелей жүктеп алуды ұйғарған. Қолдарын жұлып алу керек еді.

4-команда: Cloud SQL экстренный рестарты

Локтарға байланысты базада 100% CPU болған кезде және 3G интернет жоғалып кеткенде, psql арқылы қосылып, pg_terminate_backend жасау үшін ауыр сұраудың pid-ін (pg_stat_activity) іздеуге уақыт жоқ. Сатып алушылар үшін сервистің қолжетімділігін қалпына келтірудің ең жылдам шешімі — базаға қатаң рестарт жасау. Иә, аналитиктер өз сұрауын жоғалтады, бірақ сатып алушылар қоржындарын төлей алады.

gcloud sql instances restart prod-pg-db

Команда кетті. 30 секунд күтеміз. База көтеріледі, коннекттер пулы қалпына келеді. Сайттағы 502 қатесі жоғалады. Прод тірі! Бірақ енді трафик жаңа күшпен құйылатынын түсінеміз.

5-команда: Cloud Run-ды шатырға дейін масштабтаймыз

Кейінге қалдырылған сұраныс (адамдар отырып, 502 қатесі бар бетті жаңартқан) қазір біздің API-ді ұрады. Cloud Run CPU-троттлингінен құлап қалмауы үшін инстанстардың максималды санын превентивті түрде көбейтеміз.

gcloud run services update api-gateway --max-instances=200 --region=europe-west3

Енді біз кез келген серпілісті (всплеск) қорытуға дайынбыз. Cloud Run контейнерлерді автоматты түрде таратады.

6-команда: Kubernetes-пен (GKE) жұмыс

Бірақ бізде тапсырыстар туралы email-хабарламаларды жіберуді өңдейтін фоновые воркерлер (Background Workers) бар. Олар Google Kubernetes Engine-де (GKE) айналып жатыр. База құлағандықтан воркерлер CrashLoopBackOff күйінде ілініп қалуы мүмкін. Оларды тебу керек.

Cloud Shell-де кіріктірілген kubectl бар, егер сіз мынаны жасасаңыз, кластердің credentials-терін автоматты түрде тартады:

Оқуға ұсынамыз

Неліктен GA4 Kaspi арқылы төлем жасағанда 30% өтірік айтады? Server-Side GTM және Cloud Functions көмегімен транзакциялар атрибуциясын жөндейміз

09.08.2026
gcloud container clusters get-credentials prod-cluster --region=europe-west3

Воркерлер неймспейсіндегі (namespace) подтарды қараймыз:

kubectl get pods -n background-workers
Error</code> статусындағы бірнеше подты көреміз. Деплойментті бір ғана әдемі командамен (rollout restart) қайта іске қосамыз:</p>
<pre><code class="language-bash">
kubectl rollout restart deployment/email-worker-deployment -n background-workers

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

7-команда: Деплойды бір батырмамен кері қайтару (Rollback)

Мәселе базада емес, джуниор 15 минут бұрын құйған қисық релизде болған сценарийді елестетіп көрейік (ол бақытымызға орай сол күні болған жоқ, бірақ бұрын болған). Cloud Run-да кері қайтару трафикті алдыңғы тұрақты ревизияға ауыстыру арқылы лезде жасалады.

Алдымен ревизиялар тізімін қараймыз:

gcloud run revisions list --service=api-gateway

Алдыңғысын (мысалы, api-gateway-00042-v1x) тауып, оған трафиктің 100%-ын аударамыз:

gcloud run services update-traffic api-gateway --to-revisions=api-gateway-00042-v1x=100 --region=europe-west3

Бум! 2 секундтан кейін бүкіл трафик ескі, жұмыс істеп тұрған кодқа өтеді. Экстремалды жағдайлар үшін мінсіз.

8-команда: Cloud Armor арқылы DDoS-ты бұғаттау

Шындыққа оралайық. База тірі, воркерлер тірі, бірақ мониторинг қайтадан шырылдап жатыр. Сөйтсек, базаның құлауы аналитиктерге байланысты болмапты. Бізді бәсекелестердің боттары парсингтей немесе DDoS-тай бастаған (жаппай сатылым күндерінде тауар бағаларын парсингтейді). Трафик бір нақты IP-мекенжайлар пулынан келе жатыр.

Телефонда Google Cloud Armor UI ашу мүмкін емес. Терминалда фаервол ережесін тікелей жазамыз:

gcloud compute security-policies rules create 1000 \
    --security-policy=prod-armor \
    --src-ip-ranges="45.22.12.0/24" \
    --action=deny-403

Бұл ішкі желідегі (subnet) барлық сұраулар енді біздің Cloud Run-ға жетпей-ақ, Google-дың edge-нодаларындағы гранитті фаерволға соғылады. Базадағы жүктеме лезде төмендейді.

9-команда: Құқықтарды (IAM) жол-жөнекей беру

Мен байланыстың жақында мүлдем үзілетінін түсінемін (пойыз желісіз аймаққа жақындап келеді). Мен кезекшілікті Lead-әзірлеушіге тапсыруым керек, бірақ онда базаны рестарттауға құқық жоқ (қауіпсіздік саясаттары бойынша). Оған 2 сағатқа Cloud SQL Admin рөлін береміз.

gcloud projects add-iam-policy-binding my-ecommerce-prod-kz \
    --member="user:lead.dev@ozat.kz" \
    --role="roles/cloudsql.admin"

Оған телеграмға жазамын: "Құқықтарды бердім, коннекттерді қадағала. Мен оффлайн".

10-команда: Құпияларды басқару (Secret Manager)

Соңғы штрих. Біз құлап жатқан кезде, SMS жіберуге арналған сыртқы сервистің API-кілтінің мерзімі өтіп кетіпті. Оны Secret Manager-де шұғыл жаңарту қажет, әйтпесе пайдаланушылар тапсырыстарды растай алмайды. Жаңа кілтті телефондағы қорғалған құпия сөздер сейфінен (чассик) көшіріп алып, құпияның жаңа нұсқасын жасаймын:

echo -n "sk_live_new_sms_key_123456" | gcloud secrets versions add sms-api-key --data-file=-

Маңызды: echo -n (жол тасымалдаусыз) қолдану және pipe (|) арқылы --data-file=- ішіне беру кілттің өзі bash-командалар тарихында (history) қалмауына кепілдік береді. Пойызда болса да, қауіпсіздік бірінші орында.

Дем алдық. Қорытынды.

Бүкіл операция шамамен 12 минутты алды. Осы уақыт ішінде пойыз бір-екі станциядан өтті. Grafana-да прод жап-жасыл болып тұр. Бизнестің ақшасы құтқарылды.

Google Cloud Shell — бұл жай ғана «студенттерге арналған ойыншық» емес. Бұл мобильді телефон мен DevOps-инженердің толыққанды жұмыс станциясы арасындағы шекараны жоятын enterprise-grade құрал.

Негізгі инсайттар:

  1. CLI (Command Line Interface) үйреніңіз. Веб-интерфейстер (UI) — бұл әдемі, графиктер мен дашбордтар үшін ыңғайлы. Бірақ сыни жағдайларда, интернет нашар болғанда, UI сізді таймауттармен өлтіреді. CLI — бұл сіздің скальпеліңіз.
  2. Cloud Shell қолданыңыз. Termux және бубенмен билеу (танцы с бубном) арқылы телефонға gcloud орнатуға тырыспаңыз. Cloud Shell сізге бір рет басу арқылы мінсіз, таза және қауіпсіз орта береді.
  3. Runbooks (нұсқаулықтар) жазыңыз. Инциденттерге арналған дайын командалар шаблондарыңыз болуы тиіс. Прод құлап жатқанда, сіз gcloud compute security-policies-тің нақты синтаксисін есіңізге түсіре алмайсыз. Шпаргалканы Notion-да (оффлайн қолжетімділікте) немесе тікелей Cloud Shell ішіндегі мәтіндік файлда (ол сонда мәңгі сақталады) ұстаңыз.

Келесі жолы ноутбуксіз демалысқа бара жатсаңыз, тыныш ұйықтаңыз. Ең бастысы — PowerBank қуатталған болсын. Ал инфрақұрылымды біз калькулятормен-ақ көтеріп аламыз.

Ал сізде экстремалды деплой немесе серверлерді құтқару жағдайлары болды ма? Оқиғаларыңызбен түсініктемелерде бөлісіңіздер!

Рустам Шарафутдинов

Рустам Шарафутдинов

Инженерлік блог авторы

Google Cloud архитектурасы саласындағы сарапшы және 15 жылдан астам тәжірибесі бар Senior Full-Stack әзірлеушісі. Ақауға төзімді архитектураларға, жоғары жүктемелі жобаларды оңтайландыруға және AI (Vertex AI) интеграциясына маманданған.

Сараптама: GCP, Kubernetes, Микросервистер, React, Node.js

Пікірлер (0)