Моя основная работа — системный анализ и архитектура интеграций в сфере платных парковок и контроля доступа. Со стороны это звучит узко, но на деле здесь пересекаются сразу несколько миров: парковочные серверы, СКУД-оборудование, видеонаблюдение, 1С и личные кабинеты конечных пользователей — и всё это должно работать друг с другом без единой точки отказа.
Аналитик, который не боится архитектуры
Формально моя роль — системный аналитик, но на практике это означает: писать технические задания, проектировать API-контракты между разнородными системами, а затем следить, чтобы получившаяся архитектура действительно доживала до продакшена без переписывания с нуля. Я участвую и в согласовании условий работы с подрядчиками, и в детальном проектировании компонентов биллинга — от гостевых пропусков и событийной модели до тарификации.
Интеграции — это про границы систем
Самая содержательная часть работы — не про код внутри одной системы, а про то, что происходит на границах: как парковочный сервер сообщает статус проезда в биллинг, как СКУД-платформа подтверждает права доступа через gRPC, как события синхронизируются с 1С без гонок и дублей. Каждая такая граница — источник потенциальных проблем при реальной нагрузке, и львиная доля системного анализа здесь — заранее продумать, что произойдёт, если одна из сторон окажется недоступна на пару секунд.
Встраиваемые контроллеры въезда и выезда
Отдельное направление — участие в проектировании архитектуры собственных контроллеров для стоек въезда/выезда на встраиваемых платформах: модульная программная архитектура с чётким разделением на ядро, работу с периферией (шлагбаум, считыватели, купюроприёмник, принтер билетов) и логику взаимодействия с сервером парковки. Здесь системный анализ спускается на уровень конкретных событий и состояний устройства — и это ощутимо отличается от привычной работы с веб-API, но использует те же принципы: чёткие контракты между модулями и предсказуемая обработка ошибок.
Самое ценное, что я вынёс из этой работы: хорошая архитектура интеграции — это не про красивую диаграмму, а про то, что произойдёт в 3 часа ночи, когда один из компонентов на объекте клиента внезапно перезагрузится.
Почему домашняя лаба здесь тоже пригодилась
Опыт администрирования собственной инфраструктуры — firewall, reverse-proxy, мониторинг — напрямую переносится в рабочие задачи: легче разговаривать с инженерами заказчика на одном языке, когда сам вживую настраивал похожие вещи, и легче закладывать в ТЗ реалистичные требования к отказоустойчивости, а не абстрактные пожелания «чтобы работало стабильно».
Чему это меня научило
- Границы между системами — самое дорогое место для ошибок, и именно туда стоит направлять основное внимание при анализе.
- ТЗ без продуманной обработки сбоев — это ТЗ только наполовину.
- Опыт эксплуатации собственной инфраструктуры делает архитектурные решения на работе более приземлёнными и реалистичными.
Комментарии