Евгений Крамсаков
CV

Инженер программных систем · Санкт-Петербург

Евгений Крамсаков

Проверяю, готов ли ваш сервис к запуску и дальнейшей работе.

Написать в TelegramНаписать на почту

Нахожу причины сбоев и проверяю работу под нагрузкой. Объясняю риски и что исправить первым.

С чем ко мне приходить

  • Основное

    Независимая проверка сервиса перед запуском или приёмкой

    Подрядчик или ваш разработчик говорит «готово». Смотрю код, конфигурацию, тесты и поведение под нагрузкой и возвращаю список рисков с приоритетами: какие важнее и что исправить до запуска.

    Что получите: Письменный список рисков с приоритетами и план действий до запуска. Вы поймёте его без технического образования, разработчик возьмёт как есть.

  • Поиск причин торможения и сбоев

    Сервис тормозит, растёт по памяти или падает раз в неделю. Воспроизвожу проблему на стенде и проверяю гипотезы по очереди, отделяя подтверждённое от предположений.

    Что получите: Причина, подтверждённая на стенде, либо суженный круг причин и план следующей проверки. Исправление или инструкция к нему и метрики, которые покажут сбой заранее.

  • Оценка зависимости от одного разработчика

    Если проект держится на одном человеке, оцениваю, что произойдёт при его уходе: документация, доступы, сборка, развёртывание. Итог: список того, что нужно зафиксировать, чтобы проект можно было передать.

    Что получите: Перечень того, что нужно зафиксировать: доступы, сборка, развёртывание, документация. Плюс оценка, сколько займёт передача проекта другому человеку.

Дополнительно

  • Запуск на сервере и контроль работы

    Настраиваю работу сервиса на вашем сервере или в облаке: защищённое соединение, мониторинг, логи, резервные копии. Настройка разовая, передаю её вместе с доступами и инструкцией; дежурство и дальнейшее сопровождение в неё не входят, о них договариваемся отдельно.

  • Практики разработки с ИИ-агентами

    Если код пишут ИИ-агенты, нужна дисциплина: требования, тесты, проверка кода. Настраиваю этот процесс и показываю, как команда поддерживает его сама.

Инженерные ситуации

  • Взломанный сайт вернулся в работу меньше чем за сутки

    • Joomla
    • PHP
    • SQL
    • Docker
    Проблема
    Сайт туристической компании и админка перестали открываться: вместо них появилась поддельная страница обслуживания, а мобильных посетителей перенаправляло на чужие сайты. Заражены были все 11 сайтов одного аккаунта хостинга. Закладки остались не только в файлах, но и в базе данных.
    Что сделал
    Сохранил полный снимок аккаунта и разбирал заражение в изолированном окружении. Восстановил файлы из чистой копии, удалил поддельных администраторов и 316 профилей редактора, через которые можно было снова загрузить вредоносный код. Вернул права доступа, обновил движок и расширения, сменил доступы к сайту и базе. Проверил результат двумя независимыми проверками и наблюдением после открытия.
    Результат
    Сайт открылся меньше чем через сутки после начала работ. Две проверки не нашли действующих закладок; в течение часа наблюдения после открытия файлы, база и страницы не изменились. Заказчик получил отчёт с причинами, выполненными работами и рекомендациями: восстановление завершено, но переход с устаревших Joomla 3 и PHP остаётся отдельной задачей.

    Одной замены файлов было бы недостаточно: поддельные профили редактора и изменённые права в базе оставляли возможность повторного заражения. Точный способ первого проникновения установить не удалось: журналы хостинга сохранились только за последние две недели.

    Обезличенный отчёт о восстановлении сайта (PDF, 10 страниц)

  • Сервис приёма сетевых данных отключался из-за нехватки памяти

    • Rust
    • tokio
    • NetFlow
    • Docker
    Проблема
    Сервис, принимающий данные о сетевом трафике, в продакшене равномерно рос по памяти и перезапускался, когда она заканчивалась. Причину не знали: подозревали логирование и блокировки.
    Что сделал
    Воспроизвёл сбой на стенде под нагрузкой и проверил гипотезы по очереди: логирование и блокировки оказались ни при чём. Причина была в приёме данных без ограничения: на каждый пакет создавалась отдельная задача с копией буфера, и при нагрузке выше пропускной способности они занимали всю память. Ограничил очередь обработки и добавил учёт потерянных данных.
    Результат
    На стенде при той же нагрузке пик памяти снизился с 863 до менее 100 МБ, сервис продолжил работать, а потери стали видны в метрике. Изменение покрыто тестом и вошло в релиз.

    Две гипотезы не подтвердились. Я записал их так же подробно, как подтвердившуюся, чтобы следующий инженер видел, что уже проверяли и почему.

  • Сетевой фильтр незаметно пропускал часть трафика

    • Rust
    • eBPF
    • XDP
    • TRex
    Проблема
    Фильтр работает в ядре Linux и при любой ошибке пропускает трафик дальше, чтобы не ронять сеть. Снаружи это выглядит как исправная работа, поэтому без отдельной проверки никто не узнает, что фильтр не справляется.
    Что сделал
    Собрал нагрузочный стенд: виртуальные машины, генераторы трафика, запуск одной командой. На стенде нашёл три скрытых отказа: большая часть потоков обходила фильтр в боевой сборке из-за настройки очередей сетевой карты, повреждение памяти после рефакторинга и гонку при очистке состояния после блокировки. Написал методику, которая переводит синтетическую нагрузку в число реальных пользователей и показывает, какой ресурс исчерпается первым.
    Результат
    Все три отказа исправил, стенд остался в проекте для повторных проверок. Методика даёт число пользователей для конкретного железа вместо оценки «должно выдержать».

  • Зеркало сервиса для ИИ-агентов, которое переживает падение оригинала

    • TypeScript
    • Bun
    • SQLite
    • nginx
    Проблема
    Доска объявлений для ИИ-агентов существует в одном экземпляре и без интерфейса для людей. Если она недоступна, агенты теряют канал связи, а человек не видит, что на ней происходит.
    Что сделал
    Сделал self-hosted зеркало: оно хранит полную копию доски, говорит на протоколе оригинала, так что агенту достаточно сменить адрес, и пересылает записи в оригинал от имени самого агента. Если оригинал недоступен, зеркало работает на своей копии. Рядом читалка для людей. Сервер на Bun и TypeScript, SQLite с полнотекстовым поиском, nginx для статики. Каждое изменение выходит тегированным релизом с описанием, что именно исправлено.
    Результат
    Зеркало открыто всем и живёт на моём сервере: агенту достаточно сменить адрес, а при недоступности оригинала оно продолжает отдавать свою копию. На первых реальных выборах на доске пересчёт голосов разошёлся с оригиналом; расхождение нашёл по данным, исправил и выпустил в тот же день.

    Исходный код открыт: github.com/geibos/agent-board.

    Подробнее

  • Выгрузка отчёта упиралась в размер машины

    • Rust
    • PostgreSQL
    • Kafka
    • S3
    Проблема
    Сервис собирал сводный отчёт по двум миллионам записей целиком, прежде чем отдать. Контейнеру под это выделяли до 2 ГБ, и с ростом числа записей отчёт перестал бы собираться.
    Что сделал
    Собрал стенд с воспроизводимым набором данных и замерил, во что обходится выгрузка. Переписал обработку на потоковую: сервис читает записи из базы и отдаёт их по мере готовности, поэтому объём отчёта больше не упирается в размер машины. Одну гипотезу ускорения отбросил: замер её не подтвердил.
    Результат
    На тех же двух миллионах записей сервис отдаёт отчёт за 8 секунд вместо 21, а на пике ему нужно 61 МБ вместо 849. Замерял до и после на одном стенде; контейнеру теперь хватает четверти прежнего лимита.

  • Перевод работающего сервиса на другой язык

    • Rust
    • Java
    • Kafka
    • PostgreSQL
    Проблема
    Работающий сервис на Java нужно было переписать на Rust, сохранив поведение до мелочей: за годы оно обросло особенностями, на которые опирались соседние системы, а известные ошибки нельзя было исправлять молча.
    Что сделал
    Зафиксировал поведение старого сервиса до мелочей, включая известные ошибки, и записал каждое сознательное отступление отдельно. Новый сервис работает на той же базе данных, что и старый. Помимо обычных тестов сравнивал ответы старой и новой версий на одинаковых запросах.
    Результат
    Сравнение выявило два расхождения в ответах, которые отдельные тесты пропустили; оба исправлены до запуска. В основе: сорок зафиксированных правил поведения, 268 модульных и 38 контрактных тестов, 21 задокументированное решение. От анализа до работающего сервиса прошло около недели; второй, меньший сервис по той же схеме занял день. Разработку вёл с ИИ-агентами, решения принимал и проверял сам.

  • Инструмент для оценки задач, который забрали как есть

    • React
    • TypeScript
    • Node.js
    • socket.io
    Проблема
    Команде нужен был простой способ оценивать задачи в story points на встречах: без регистрации, с постоянными комнатами и анонимным голосованием.
    Что сделал
    Сделал веб-приложение Planning Poker: комнаты в реальном времени, постоянные комнаты по адресу, режим инкогнито. Клиент на React и TypeScript, сервер на Node с socket.io, модульные тесты и сквозные тесты в браузере. Развернул на своём сервере.
    Результат
    Приложение работает и открыто всем. Инструмент как есть встраивают в корпоративный таск-трекер.

    Исходный код открыт: github.com/geibos/poker-plan.

    Подробнее

Как строится работа

  1. Рамки

    Договариваемся, что именно проверяем, в каком объёме и какой ответ вам нужен: список рисков, оценка готовности к запуску или план исправлений. Срок и стоимость фиксируем до начала.

  2. Проверка

    Смотрю код, конфигурацию и то, как сервис ведёт себя под нагрузкой и при сбоях. Гипотезы проверяю на стенде и замером. Что воспроизвести не удалось, так и записываю.

  3. Результат

    Отдаю письменный отчёт: что нашёл, насколько это серьёзно и что делать первым. К цифрам прилагаю способ их воспроизвести. Если делаю что-то сам, первую рабочую версию показываю рано, на тестовом стенде или на вашей площадке, чтобы вы могли открыть и попробовать.

  4. Передача

    Разбираем отчёт с вами или вашим разработчиком. Дальше могу помочь с исправлениями и передать настройку так, чтобы вы не зависели от меня.

Пример отчёта

Реальный отчёт о восстановлении сайта туристической компании. Название, адрес сайта и сведения о заказчике скрыты. Ниже — краткая выдержка; полный обезличенный отчёт доступен в PDF.

Читать полный обезличенный отчёт (PDF, 10 страниц)

Заключение

Сайт вернулся в работу меньше чем через сутки после начала работ. Две независимые проверки не нашли действующих закладок. Восстановление завершено, но устаревшую платформу ещё предстоит заменить.

  1. Возможность повторного заражения оставалась в базе данных

    Последствие
    Даже после замены файлов злоумышленник мог вернуться через поддельные учётные записи и профили редактора, разрешавшие загрузку программного кода.
    Как проверил
    В базе нашёл 4 поддельных главных администратора, 13 скрытых учётных записей и 316 поддельных профилей редактора JCE. Права доступа позволяли любому посетителю управлять плагинами.
    Что сделано и что дальше
    До открытия удалил поддельные записи и профили, вернул права доступа и выключил выполнение PHP в Sourcerer.

  2. Все 11 сайтов аккаунта работали от одного пользователя

    Последствие
    Взлом любой старой копии открывал доступ к остальным сайтам. Чистка только основного сайта оставила бы соседние источники заражения.
    Как проверил
    Проверил весь аккаунт: кроме основного сайта, там были три тестовые копии и ещё семь сайтов и поддоменов. В тестовых копиях лежали бэкдоры, а временная папка основного сайта указывала в одну из них.
    Что сделано и что дальше
    Сохранил полный снимок аккаунта, по решению заказчика удалил остальные 10 сайтов и вынес временную папку за пределы сайта.

  3. После восстановления платформа осталась устаревшей

    Последствие
    Удаление закладок не устраняет уязвимости движка и расширений. Без перехода на поддерживаемые версии риск нового взлома сохраняется.
    Как проверил
    После обновлений сайт работает на Joomla 3.10.12 и PHP 7.4. В полном отчёте отдельно перечислены оставшиеся риски платформы.
    Что сделано и что дальше
    Обновил доступные компоненты. Переход на поддерживаемые версии рекомендовал выполнить отдельной работой в течение месяца.

Рекомендации по срочности

  • Критично

    В ближайшие дни

    Сменить учётные данные эквайринга и пароль почтового ящика

    Они хранились в файлах и настройках сайта. Злоумышленник мог их прочитать.

  • Высокий

    В течение месяца

    Перейти с Joomla 3 и PHP 7.4 на поддерживаемые версии

    Устаревшая платформа не получает исправлений безопасности. Восстановление сайта не заменяет обновление платформы.

  • Средний

    В течение квартала

    Раз в месяц обновлять движок и расширения, следить за изменениями файлов

    Сканеры приходят на сайт каждый день. Обновления и наблюдение нужны и после завершения восстановления.

  • Низкий

    По возможности

    Загрузить недостающие картинки

    На страницах остались пустые места. Для недостающих файлов подготовлен список для повторной загрузки.

Границы проверки

Точную дату и способ первого проникновения установить не удалось: журналы сохранились только за последние две недели. Проверку триггеров и событий базы, системных настроек PHP и истории входов в панель хостинга рекомендовал запросить у провайдера.

Обо мне

Живу в Санкт-Петербурге, работаю удалённо. Делаю backend-сервисы и сетевые системы на Rust: от REST-сервисов с базой данных до фильтрации трафика в ядре Linux.

Сейчас ведущий Rust-разработчик в продуктовой команде: отвечаю за проектирование сервисов, их поведение под нагрузкой и за то, чтобы код людей и агентов можно было проверить и сопровождать.

Большую часть кода пишу с ИИ-агентами. Результат проверяю тестами, стендами и замерами до и после. Так же проверяю чужой код.

Держу домашний сервер с обратным прокси, единым входом и мониторингом: на нём отрабатываю развёртывание и восстановление из резервных копий.

Небольшие открытые проекты

  • check_inet · диагностика интернет-соединения одним бинарём, показывает, какой слой сломан
  • ozi-rs · настольный редактор растровых карт и треков, работает без сети
  • audio-test · проверка раскладки колонок многоканальной аудиосистемы прямо в браузере

Контакты

Напишите в Telegram: коротко опишите сервис и что вас беспокоит. Я разберу вводные, задам вопросы и предложу объём, срок и стоимость, а решение останется за вами.

Написать в TelegramНаписать на почту

Или опишите задачу здесь

Сообщение не сохраняется на сервере, оно только пересылается.

Telegram
@sobieg
GitHub
github.com/geibos · основные проекты
GitHub
github.com/Sobieg · старые проекты
Ник
Sobieg