Спас прод из поезда "Тальго" Алматы-Астана: 10 команд Cloud Shell, которые спасут ваш DevOps без ноутбука

11.08.2026

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

Пятница. Вечер. Степь. И упавший PROD.

Представьте себе ситуацию, до боли знакомую многим IT-специалистам в Казахстане. Вы едете в поезде «Тальго» по маршруту Алматы — Астана. За окном проносятся бескрайние степи Сарышагана. Долгожданные выходные. Вы решили расслабиться, ноутбук лежит на верхней полке, благополучно разряженный в ноль (а розетка в купе, по закону подлости, не работает). Сеть на смартфоне прыгает от бодрого LTE до унылого Edge и обратно в «Поиск сети».

И тут смартфон вибрирует от Telegram-уведомления. Бот мониторинга бьет тревогу: [CRITICAL] PROD IS DOWN. HTTP 502 Bad Gateway на основном API.

Вы работаете в крупном e-commerce проекте, прямо сейчас идет вечерняя распродажа, каждая минута простоя — это сотни тысяч тенге упущенной выручки и седые волосы бизнес-оунера. Звонить джуниорам бесполезно, они уже паникуют в рабочем чате. Вам нужно поднять прод. Из инструментов у вас только смартфон с диагональю 6.5 дюймов и мобильный интернет, который пропадает каждые 10 минут.

В этой ситуации вас спасет не молитва, а Google Cloud Shell.

Что такое Cloud Shell и почему это ультимативное оружие DevOps?

Для тех, кто не в курсе: Cloud Shell — это бесплатная виртуальная машина на базе Linux (Debian), которая предоставляется всем пользователям Google Cloud. Она запускается прямо в браузере. Вам не нужен SSH-клиент, не нужны VPN-ы. Вы просто открываете приложение Google Cloud на телефоне (или мобильный Chrome), нажимаете иконку терминала, и через 5 секунд у вас есть:

Полноценный Bash (или Zsh).
Предустановленные и авторизованные инструменты: gcloud, kubectl, bq, gsutil, docker, terraform, git.
5 ГБ постоянного хранилища (Persistent Home) для ваших скриптов.
Доступ к приватной сети вашего VPC.

Это значит, что вам не нужно вводить пароли, настраивать ключи доступа, скачивать логи. Вы УЖЕ внутри своей инфраструктуры с правами вашего аккаунта.

В этой статье я поделюсь хроникой реального спасения прода и 10 командами, которые я набрал потными пальцами на экранной клавиатуре айфона, пока поезд качало на стыках рельс. Эти команды должен знать каждый DevOps-инженер наизусть.

Хроника инцидента: 10 шагов к воскрешению

Команда 1: Выбираем правильный проект

В Cloud вы часто имеете доступ к десяткам проектов (dev, stage, prod). Первая заповедь: убедись, где ты находишься. Чтобы не пристрелить stage вместо prod, жестко задаем контекст.

gcloud config set project my-ecommerce-prod-kz

Совет: В Cloud Shell можно настроить кастомный prompt для bash (в файле .bashrc), чтобы текущий проект всегда светился красным цветом. На экране телефона это спасает от фатальных опечаток.

Команда 2: Читаем логи на лету (Traceroute для бедных)

У нас 502 ошибка на API Gateway (который крутится на Cloud Run). Загружать UI-консоль Cloud Logging (Logs Explorer) на слабом 3G-интернете — это смерть. Страница весит несколько мегабайт. Поэтому мы читаем логи прямо в консоли.

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 и искать pid тяжелого запроса (pg_stat_activity), чтобы сделать pg_terminate_backend. Самое быстрое решение для восстановления доступности сервиса для покупателей — жесткий рестарт базы. Да, аналитики потеряют свой запрос, но покупатели смогут оплачивать корзины.

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)

Но у нас есть фоновые воркеры (Background Workers), которые обрабатывают отправку email-уведомлений о заказах. Они крутятся в Google Kubernetes Engine (GKE). Из-за падения базы воркеры могли зависнуть в состоянии CrashLoopBackOff. Нужно их пнуть.

Cloud Shell имеет встроенный kubectl, который автоматически подтягивает credentials кластера, если вы сделаете:

Рекомендуем к прочтению

Почему GA4 врет на 30% при оплате через Kaspi? Чиним атрибуцию транзакций с помощью Server-Side GTM и Cloud Functions

09.08.2026

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

Смотрим поды в неймспейсе воркеров:

kubectl get pods -n background-workers

Видим кучу подов в статусе Error. Перезапускаем деплоймент одной изящной командой (rollout restart):

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: Блокировка DDoS через Cloud Armor

Возвращаемся в реальность. База жива, воркеры живы, но мониторинг снова пищит. Оказывается, падение базы было не из-за аналитиков. Нас начали парсить или DDoS-ить боты конкурентов (парсят цены на товары в дни распродаж). Трафик идет с одного конкретного пула IP-адресов.

Открывать UI Google Cloud Armor на телефоне невыносимо. Пишем правило фаервола прямо в терминале:

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

Все запросы из этой подсети теперь разбиваются о гранитный фаервол на edge-нодах Google, даже не доходя до нашего Cloud Run. Нагрузка на базу моментально падает.

Команда 9: Выдача прав (IAM) на ходу

Я понимаю, что связь скоро совсем пропадет (поезд подъезжает к зоне без сети). Мне нужно передать дежурство Lead-разработчику, но у него нет прав на рестарт базы (по политикам безопасности). Выдаем ему роль Cloud SQL Admin на 2 часа.

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

Пишу ему в телегу: "Права выдал, следи за коннектами. Я оффлайн".

Команда 10: Управление секретами (Secret Manager)

Последний штрих. Пока мы лежали, истек срок действия API-ключа внешнего сервиса отправки SMS. Нужно срочно его обновить в 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 — это не просто «игрушка для студентов». Это enterprise-grade инструмент, который стирает грань между мобильным телефоном и полноценной рабочей станцией DevOps-инженера.

Главные инсайты:

Учите CLI (Command Line Interface). Веб-интерфейсы (UI) — это красиво, удобно для графиков и дашбордов. Но в критических ситуациях, при плохом интернете, UI вас убьет таймаутами. CLI — это ваш скальпель.
Используйте Cloud Shell. Не пытайтесь ставить gcloud на телефон через Termux и танцы с бубном. Cloud Shell дает вам идеальную, чистую и безопасную среду в один клик.
Пишите Runbooks (инструкции). У вас должны быть готовые шаблоны команд на случай инцидентов. Когда прод лежит, вы не вспомните точный синтаксис gcloud compute security-policies. Держите шпаргалку в Notion (в оффлайн-доступе) или прямо в текстовом файле внутри вашего Cloud Shell (он там сохранится навсегда).

Следующий раз, когда поедете в отпуск без ноутбука, спите спокойно. Главное — чтобы был заряжен PowerBank. А инфраструктуру мы и с калькулятора поднимем.

А у вас были случаи экстремального деплоя или спасения серверов? Делитесь историями в комментариях!

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

Автор инженерного блога

Эксперт в области архитектуры Google Cloud и Senior Full-Stack разработчик с более чем 15-летним опытом. Специализируется на отказоустойчивых архитектурах, оптимизации высоконагруженных проектов и интеграции AI (Vertex AI).

Экспертность: GCP, Kubernetes, Микросервисы, React, Node.js