Ведущий инженер по инфраструктуре и надёжности — на часть занятости

Надёжность боевых систем и понятный план изменений

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

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

Схема: клиент обращается к API, основная база недоступна, путь ведёт к резервной базе
Проверяем зависимости, сценарии отказа и пути восстановления.

Когда полезен

Релизы, восстановление и рост требуют внимания

Релиз рискован

Выкатка руками, откат нигде не описан, всё держится на одном человеке. Вопрос не в том, что плохо, а с чего начинать.

Инциденты повторяются

Копии снимаются, оповещения приходят. А вот проверял ли кто-нибудь, что восстановление вообще отработает, — обычно выясняется в худший момент.

Команда растёт

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

Услуги

Начинаем с ограниченной платной диагностики

Выбираем один вопрос и согласованную выборку систем. Объём, исключения, результаты, сроки и стоимость фиксируем до начала работы.

Макет платформы под увеличительным стеклом

Диагностика инфраструктуры

Где инфраструктура и доставка изменений создают риск для продукта?

  • Текущая архитектура и исходные данные
  • Выбранные проверки сборки и доставки, инфраструктуры как кода, Kubernetes и наблюдаемости
  • Находки с подтверждениями и ограничениями
  • Что делать в первую очередь: план на 30, 60 и 90 дней

Первый проектОтчёт, короткая выжимка для руководства и разбор с командой

Обходной мост соединяет модули при отказе одного из них

Разбор надёжности

Какие сценарии отказа влияют на пользователей и как расставить приоритеты?

  • Один критичный пользовательский путь
  • История сбоев, оповещения и ответственные
  • Показатели и цели по надёжности, подтверждения восстановления
  • Риски, неизвестные значения и план измерений

Первый проектПлан надёжности с ответственными и зависимостями

Новый модуль закрывает разрыв в платформе; старый заменён

Внедрение одного улучшения

Реализовать одно выбранное улучшение после согласования приоритетов.

  • Отдельный объём и критерии приёмки
  • Например: откат, инструкция восстановления или порядок выката
  • Проверка результата в согласованной среде
  • Документация и передача знаний

Следующий этапФиксированная стоимость за согласованный результат

Диагностика идёт с доступом только на чтение. Внедрение и активные проверки согласуются отдельно. Если потребность окажется регулярной, договариваемся о постоянном участии с оговорённым месячным объёмом. Круглосуточного дежурства не предлагаю ни в одном варианте.

Опыт

Александр Сапон — инженер, который ведёт проект

Больше 13 лет в разработке и эксплуатации: серверная часть на Go и Python, платформы, надёжность, инфраструктура в облаке и на своём железе. Разговор, работу и передачу результата веду сам — субподрядчиков и стажёров в проекте не будет.

Kubernetes, инфраструктура как код, сборка и доставка изменений, PostgreSQL, очереди сообщений, наблюдаемость и восстановление. Инструмент выбирается под задачу и под то, что команда сможет поддерживать дальше сама.

Собственный продукт · 2026

Аренда инструмента через постаматы

Связь с железом на Go, аренда и платежи на Python, между ними очередь событий. Плюс двойник шлюза, чтобы ловить сбои связи не на объекте.

Как это устроено
Собственный продукт · 2026

Платформа проката под чужим брендом

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

Как это устроено
Собственная автоматизация · 2020

Стенды для команд разработки

Весь парк стендов описан одной переменной, список хостов для Ansible собирается сам. Ручной перенос адресов исчез.

Как это устроено

Это собственные продукты и внутренняя автоматизация. Клиентские проекты под соглашением о неразглашении я не показываю.

Как работаем

От вопроса до отчёта и следующего решения

01

Разговор

За 30 минут уточняем проблему, срочность, владельца и ограничения. Выбираем один следующий шаг.

02

Предложение и техническое задание

Фиксируем выборку, исключения, результаты, стоимость и критерии приёмки. Отдельно указываем трудозатраты и календарные даты.

03

Старт и исходные данные

После согласования условий старта определяем роли, доступы и исходные данные. Неизвестное отмечаем явно.

04

Проверка и отчёт

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

05

Передача

Разбираем отчёт и план, передаём материалы, подписываем приёмку и закрываем доступы. Внедрение — отдельный этап.

Один основной проект одновременно. Цена и даты зависят от согласованного объёма и доступности команды. Условия договора и оплаты определяются для конкретного проекта.

Контакт

Начнём с вашей задачи

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

Первый разговор — 30 минут для уточнения задачи. Технический разбор и архитектурные рекомендации входят в согласованную платную работу.

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