Примеры работ и кейсы по направлению «DevOps»

**Избирательная маршрутизация Google Gemini через SSH SOCKS5** **Задача:** дать FreeLLMAPI на VPS в Латвии доступ к Gemini API через VPS в США, сохранив прямые подключения других AI-провайдеров и сервисы американского сервера. **Что сделано:** Провёл аудит Ubuntu, портов, firewall, SSH forwarding и сервисов. Настроил SSH SOCKS5: туннель инициируется из Латвии, выход к Google идёт через США. Создал отдельные учётные записи и SSH-ключ; ограничил доступ IP латвийского VPS и адресом generativelanguage.googleapis.com:443. Запретил интерактивный вход, команды и обратный forwarding. Настроил systemd-сервис с автозапуском и восстановлением туннеля. Прокси слушает только 127.0.0.1:1080. В FreeLLMAPI направил через него только Google, остальные API оставил напрямую. Сохранил бэкапы и инструкцию отката. Маршруты проверил по логам: интерфейс показывал пример URL как заполненное поле, а исключения требовали проверки. **Результат:** Подтверждены IP США, проверка ключа Google и запрос к Gemini 3.1 Flash-lite. При отключении туннеля Google выдавал ошибку SOCKS5, другой провайдер работал напрямую. SSH, xRDP, nginx, Docker и Python REST API (HTTP 200) в США продолжили работать. Новые публичные порты не открывал, маршруты, DNS, firewall и исходники не менял. Сеанс XFCE отдельно не проверял. Выявлен риск прямого fallback при ошибке прокси-агента FreeLLMAPI: нужна отдельная доработка, полного запрета обхода пока нет. **Стек:** Ubuntu, OpenSSH, SOCKS5, systemd, FreeLLMAPI, Gemini API.

Что сделал: диагностировал по фактам — память, swap, службы, автозапуск. Нашёл службу с 931 перезапуском и зависшие процессы сборки, разобрал конфигурацию памяти и спланировал апгрейд, настроил резервные копии и контроль. Результат: отчёт с замерами «до» и «после», машина перестала упираться в память.

Задача: перевести боевой и тестовый кластеры на новую минорную версию и не уронить то, что на них крутится. Рабочие узлы, базы, очереди, входной контроллер, выкатка через GitOps. Сначала разобрал изменения новой версии и проверил каждый компонент на совместимость: из пяти потенциально ломающих изменений нас не касалось ни одно, и это выяснилось до работ, а не во время. Дальше обновление по одному узлу - выселение нагрузки, обновление, возврат в строй. Перед работой с управляющими узлами снимал резервную копию хранилища конфигурации кластера. По дороге поймал четыре сбоя: гонку в предварительных проверках, сорвавшуюся загрузку бинарников, блокировку выселения из-за политики доступности и сетевой глюк на одном узле. Все разобраны на месте, без отката. Результат: оба кластера на одной версии, все узлы в строю, базы и очереди в порядке. Тем же заходом обновил операционную систему и ядро на всех восьми узлах - окно недоступности управляющего слоя составило пару минут, рабочая нагрузка не прерывалась.

Собрал рабочий контур для команды на Linux-сервере: общее файловое хранилище, почта и корпоративный чат. Задача была типичная для малого бизнеса: файлы разъезжаются по почте и мессенджерам, непонятно, у кого актуальная версия, бэкапам верить нельзя. Нужен свой контур, а не ещё один «диск в облаке непонятно где». Как делаю: • подбираем сервер и домены; • поднимаю файловое хранилище для сотрудников (права, общие папки, доступ из браузера и с компьютера); • подключаю почту и чат; • настраиваю бэкапы с проверкой восстановления и короткую инструкцию «что делать, если что-то упало». Большие проекты режу на этапы: сначала пилот, который можно принять и начать пользоваться, потом почта, связь, офисные документы, мониторинг и сопровождение. Так заказчик видит результат раньше и не платит сразу за весь объём. Стек: Linux, Nextcloud, почта (Mailcow или клиент к существующим ящикам), Talk, бэкапы, при необходимости Proxmox и reverse proxy. Результат: команда работает в одном месте с файлами и перепиской, доступы понятные, копии проверяемые.

Своя инфраструктура: несколько серверов (в т.ч. почта, VPN, бэкапы) и Docker-стеки. Задача: видеть нагрузку и доступность до аварии, получать алерты в Telegram. Сделано: • дашборд Grafana — CPU / RAM / диск / сеть по хостам • отдельный обзор Docker-контейнеров • мониторинг почтового стека (Mailcow/Postfix): веб-почта UP, очередь писем, ресурсы • правила алертов и уведомления Результат: понятная картина инфраструктуры + реакция на сбои без «угадайки». Срок: 1–2 дня на базовый контур.

Задача: бэкапы «на всякий случай» не проверялись, restore никто не делал. Сделано: автобэкап БД и томов, выгрузка в объектное хранилище, ротация, тестовое восстановление, короткая инструкция. Результат: понятный процесс «что где лежит и как поднять». Срок: 2 дня.

Kейс — Cloud Security / DevSecOps: https://github.com/w88005215-ctrl/yandex-cloud-security-remediation-program В нём есть архитектура, модель угроз, реестр рисков, матрица контролей, Kubernetes security, IAM, NetworkPolicy и подтверждённые результаты устранения проблем. Репозиторий подготовлен именно как публичный портфельный кейс.

Делал для себя, изначально был использован старый шаблон написанный еще 8 лет назад на PHP7. Был полностью переписан функционал, добавлена админка для управления новостями и СЕО настройками и настройки для вставки рекламы или скриптов. Добавлен отдельный worker, который отслеживает состояние ТС сервера и записывает в базу данных PostgreSQL. Так же был сделан редизайн. Проект завершен, все задачи - выполнил.