В начале двухтысячных я работал программистом и системным администратором в компании, в которой к настоящему моменту уже 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‑модемов и поставим на крышах направленные антенны. В крайнем случае, Яндекс.Курьеры будут возить по офисам дискеты с апдейтами базы.
Александр Чернокульский
Директор компании «Жилфонд»
Автор: alexchernokulsky