В начале двухтысячных я работал программистом и системным администратором в компании, в которой к настоящему моменту уже 14 лет тружусь простым директором. Интересный это опыт — смотреть спустя много лет на инфраструктуру, которую собирал своими руками, и которую теперь перестраивают другие люди под твоим руководством.

Сейчас наш отдел разработки создаёт единую систему взамен лампового монстра, собранного из отдельных кусков, которые писались и выстраивались отдельно под каждое направление. Понятно, что это решение было вопросом времени: когда мы создавали первое ПО, у нас был один офис агентства недвижимости в одном городе РФ — Новосибирске, а сейчас 153 в разных городах России, а также в Казахстане, Турции и Таиланде. Оставить всё как есть не получилось бы в любом случае. Но ностальгии это не отменяет, так что я решил по‑стариковски поворчать и рассказать, как было в «наши времена».

Раньше было раньше

Понятно, что раньше сервера были выше, флоппи‑диски зеленей, а программисты работали исключительно с ювелирным качеством. Это шутка про стариковское ворчание, конечно, но только отчасти. Недостаток вычислительных мощностей начала нулевых действительно требовал продуманной оптимизации кода и тщательного планирования алгоритмов — каждый лишний килобайт влиял на производительность. В эпоху широкополосного доступа в интернет достаточно сварганить грязный код, не оптимизировать его, потом постепенно наделать миллион костылей. Всё равно будет работать, только мощностей на обработку потребуется больше. Мы себе такого позволить не могли, не было ни процессорного времени, ни памяти, поэтому алгоритмы были всегда наиболее эффективными.

В свой первый рабочий день в октябре 2001 года меня сразу озадачили чёткой задачей по SMART: «Ааааа, ничего не работает». Что именно должно работать, было ещё не очень понятно,так как предыдущий спец пару месяцев как уволился и никаких инструкций не оставил. Минут через 10 всё заработало само, и я начал изучение инфраструктуры: 15 компов, локальная сеть, АТС Panasonic, в качестве программы для работы — файл‑серверное приложение, написанное на Visual Basic.

Странная особенность заключалась в том, что «утром ничего не работало». В результате инвентаризации было выявлено, что в качестве файл‑сервера используется компьютер делопроизводителя, которая перед уходом домой его выключила. А бумажка «НЕ ВЫКЛЮЧАТЬ», заботливо наклеенная предыдущим админом, сиротливо валялась под серваком. В общем, сервер я отобрал, оснастил бесперебойником и спрятал от посторонних.

Открытие второго офиса компании в 2002 году создало проблему обмена информации — в каждом офисе был свой сервер, но между ними не было связи. Поэтому дважды в день приходилось ходить между офисами с дискетой (да, дискетой на 1.44 мегабайта) и обновлять базу вручную. 700 метров туда и 700 обратно — такое вот здоровое решение для бесперебойной работы ИТ‑инфраструктуры.

Зима в Сибири суровая, в декабре 2002 температура опускалась ниже –30 градусов. Отчасти это мотивировало меня организовать канал связи, чтобы не ходить по морозу. Те, у кого детские фото цифровые, наверное, спросят: «А почему не VPN?». А те, у кого детские фото чёрно‑белые, ответят: «Интернет по диалапу на скорости 33 600». Организовать обмен данными через FTN не позволяло ПО, хотя технология была вполне откатанная: в родном Усть‑Каменогорске уже второй год автономно работал FIDO‑узел (поинтам 2:5082/14 привет!).

В результате, через телефонную станцию организовали прямой медный кабель между офисами, поставили с двух сторон SHDSL и получили канал аж 2 мбит/сек. Правда, пришлось пожертвовать номером телефона, чтобы освободить медную пару на телефонной коробке. Третий офис подключили по той же технологии: он соединял точки на расстоянии более 8 км и скорость была 1,5 мбит/сек. Четвертый офис подсоединили по Wi‑Fi с помощью узконаправленных антенн, расположенных на крышах. И только с появлением доступного широкополосного интернета новые точки уже подключались через VPN с использованием ZyWall. Когда количество офисов превысило 10, то сеть на ZyWall начала работать нестабильно, поэтому произвели массовый апгрейд на Cisco.

Файл‑серверное решение на скорости 2 мбит еле шевелилось, работать было невозможно, поэтому в качестве временной меры был поднят терминальный сервер и пользователи допофисов работали в терминальной сессии. 16-битное приложение в 32-битной Windows NT TSE отжирало кучу памяти на каждого пользователя. И следующим этапом стало создание клиент‑серверного приложения на базе MS SQL. В 2004 году мы получили от сторонних разработчиков ПО, протестировали на небольших объемах данных и подписали акт приема‑передачи. За неделю операторы переколотили данные и запустили «боевой сервер».

Поиск по объектам в новой системе работал всё ещё медленно. Вскрытие исходного кода показало, что при поиске выполнялся запрос «SELECT * FROM tblFlats» и далее фильтрация данных производилась на стороне клиентского приложения. Что я в тот момент подумал о разработчиках, цензура Хабра, боюсь, не пропустит. В общем, за пару месяцев переписал код сам и поиск стал летать. К слову, приложение до сих пор работает.

Позже, когда в компании открывались новые направления, для них разрабатывались свои приложения с учетом бизнес‑логики отдела. Это давало возможность быстро запустить работу направления (например, ПО для направления аренды было создано за 1,5 месяца), но создавало проблему в поддержке и развитии всей инфраструктуры.

Тетерича не то что давеча

Итак, приложение, разработка которого началась в 2004 году, у нас работает до сих пор, как и техдиректор Игорь Сагнаев, с которым мы вместе его создавали. Во многом благодаря ему у нас всё это время получается совершенствовать инфраструктуру с учётом требований рынка. Круто, когда IT‑команда понимает суть бизнеса, для которого работает.

С развитием веб‑технологий и запросов на мобильность пользователей стало понятно, что для современной компании Windows‑приложения уже недостаточно. Но невозможно поставить бизнес на паузу, переписать всё с нуля, научить пользователей новым продуктам, а потом запустить бизнес заново. Поэтому решили действовать как нейрохирург при операции на мозге — пациент в сознании и выполняет обычные задачи, а права на ошибку нет. Новые решения сейчас разрабатываем одновременно с поддержкой действующих продуктов, хотя не раз возникала мысль, что стоит разрушить до основания старый мир и построить новый.

Почему старой системы стало недостаточно. Во‑первых, шесть лет назад мы перешли на бизнес по франшизе и увидели, что то, к чему привыкли риелторы в одном регионе, плохо подходит для других. Например, в разных регионах своя терминология: «однёшка» в Новосибирске, «однушка» в Москве и «полуторка» в Усть‑Каменогорске. Плюс везде есть свои особенности в неформальных топонимах, типах объектов и сложившейся деловой практике. Во‑вторых, в общую экосистему оказалось сложно вписать международный бизнес — разные гео, язык и валюта.

И если в Новосибирске изначально была специализация по видам — аренда, продажа жилой недвижимости, коммерческая недвижимость, то в регионах появился запрос на поддержку универсальных агентов. То есть, условно, у нас тракторист ездил на тракторе, а комбайнер на комбайне — отдел аренды занимается арендой, а отдел вторичной недвижимости продажей квартир. А франчайзи нужен уже универсальный тракторо‑комбайн, чтобы и трактористу и комбайнеру было одинаково нормально и понятно.

То ли ещё будет

В общем, сейчас мы на пути создания единой платформы, у нас уже реализована сама база данных, часть бэкэнда и фронта, готовим стратегию запуска. Делаем фокус на интеграции с внешними системами. Например, уже сейчас риелтор по клику может получить выписку из ЕГРН, отправить заявку на ипотеку в банк (реализована прямая интеграция с банками по API). Еще есть возможность использовать ИИ для оценки объектов, генерации описаний и подбора аналогов.

Но где‑то глубоко в душе я буду с теплом вспоминать старую систему, которая проработала у нас почти четверть века — колоссальный срок для ИТ‑продукта, который, на мой скромный взгляд, что‑то да говорит о его качестве. И если произойдет глобальный коллапс и интернета вдруг не станет, мы стряхнем пыль с SHDSL‑модемов и поставим на крышах направленные антенны. В крайнем случае, Яндекс.Курьеры будут возить по офисам дискеты с апдейтами базы.

Александр Чернокульский

Директор компании «Жилфонд»

Комментарии (10)


  1. jobless
    08.09.2024 06:40
    +8

    Вы мне напомнили времена середины 90х и HytechSql. Дело в том, что первые версии сервера использовали файлы в обшей "расшареной" папке для передачи-приёма SQL запросов-ответов. Грамотные юноши с горящими глазами уже в те времена естественно знали о существовании IPX, SPX, ... и плевались в сторону HyTech по поводу использованного доморощенного способа транспортировки сообщений.

    А я показывал свой клиентский софт в руках коллег из соседнего райцентра, которые при потери связи (использовался NETWARE CONNECT) меняли в настройках путь к папке запросов на дискету, копили запросы и отправляли курьера на машине до ближайшего узла имеющего связь. Курьер возвращал дискету и клиентская программа показывала ответы например о судимостях Тяпкина и Ляпкина или отсутствию таковых.


  1. Tarson
    08.09.2024 06:40
    +4

    Надо же, живой еще жилфонд...

    Но как человеку жившему в новосибе в 90-е и 2000-е также интересно узнать от простого директора про отношения с бандосами и под какой "крышей ходило" ваше агентство, ибо этот бизнес в те времена был криминализован не меньше водочного и проституток.


    1. anonymous
      08.09.2024 06:40

      НЛО прилетело и опубликовало эту надпись здесь


  1. VenbergV
    08.09.2024 06:40

    Взаимоотношение разработчиков с SQL, это боль! Особенно если это "одноэсники".
    Один заказчик уверял, что сервера минимум плохо настроены, или вообще плохие. А при стороннем аудите обнаружилось, что "одноэсники" в цикле вытягивают все цены из справочника цен, коих оказалось почти миллион, а потом из них уже выбирают нужные значения. И это происходит при любом подборе товара.


  1. Germanjon
    08.09.2024 06:40
    +2

    В начале нулевых нужно было передать файл в полтора килобайта размером (какой-то драйвер) с компьютера на компьютер. Быстрее и дешевле было перевести его в HEX и продиктовать по телефону


    1. ExiveR
      08.09.2024 06:40

      А вы знаете толк в извращениях...


    1. VenbergV
      08.09.2024 06:40
      +2

      Хм! На заведомо зараженном ПК под DOS вручную создавал исполняемый .com файл, с помощью NC. Чтобы потом его зараженную копию отправить в AIDSTEST и Kaspersky.


  1. ITMatika
    08.09.2024 06:40
    +1

    Помню, заглядывал в одну подобную компанию по недвижимости в центре Нска в начале нулевых. БД Paradox, регулярно крашащиеся индексы, романтика...
    Однако, к моему глубочайшему удивлению, и году так в 2018-м удалось найти торговую компанию, у которой запуск АРМа начинался с полной перестройки индексов в БД Paradox... Около 30 минут на HDD... Замена HDD на SSD ускорила процесс раз в 100. И подозреваю, что это решение их вполне устроило и Paradox живёт там и по сей день.


  1. Genix
    08.09.2024 06:40

    Зашёл сюда лайкнуть комментарий про коробку дискет, которую необходимо таскать с собой чтобы эти 700 Мег туда-сюда передать, но не увидев его сел писать его самостоятельно


    1. VenbergV
      08.09.2024 06:40

      Ничего себе "коробочка"! Аж на ~500-700 дискет.
      Или вы мегабайты с килобайтами перепутали. ;-)