В этом тексте я опишу часть истории проекта в весьма бурно сейчас развивающемся домене TNC (Transportation Network Companies), а более точно – ROD (Ride on Demand). Если совсем по-простому, сервис заказа такси. В середине прошлого года одна достаточно крупная западная TNC (далее – «Энтерпрайз») приобрела в России игрока регионального уровня, б.ч. бизнеса которого была сосредоточена в средней полосе России. У этого игрока, назовём его «Такси 666», имелось семейство продуктов собственной разработки: приложения на Андроиде для клиентов и водителей, а также ряд Delphi-приложений, необходимых для управления таким бизнесом (принятие водителей, просмотр статистики и пр.). Отдельно стоит упомянуть Delphi-приложение для операторов, принимающих заявки по телефону. Особенностью, отличавшей модель бизнеса Такси 666 от наиболее известных TNC вроде Uber’а, было то, что телефонные заказы занимали долю около 80%, при этом никакой тенденции к увеличению доли заказов через приложение не наблюдалось. Тем не менее, Энтерпрайз воспринял такое положение вещей не как проблемную ситуацию (за которой много чего скрывалось – см. ниже), а как своего рода конкурентное преимущество для России с её необъятными просторами и в целом ещё низкой (но быстро растущей) долей проникновения мобильного Интернета.
Итак, аудит, в т.ч. технологический, был проведён, и сделка состоялась. Первые ошибки были допущены ещё в тот момент:
Ошибка №1. У агентов Энтерпрайза не было никакого запасного плана на случай, если основатель Такси 666 и его бессменный гендиректор (далее – «Генерал») решил бы покинуть компанию. Искать замену ему даже не начинали. Поняв это, Генерал использовал данный факт для постепенного установления почти полного контроля над агентами. Так «хвост стал вилять собакой».
Ошибка №2. IT-аудит был проведён поверхностно, и не выявил один из двух основных рисков для осуществления наполеоновских планов Энтерпрайза по экспансии вглубь России. Имя этому риску – «Firebird». Все Delphi-приложения были завязаны на использование данной СУБД, выбранной в качестве стандарта главой команды R&D (далее – «Главный Гад», «ГГ») Такси 666 около 15 лет назад. Основной проблемой, в дальнейшем постоянно тревожившей весь комплекс, стала нестабильность работы, обусловленная неспособностью Firebird справиться с резкими пиковыми нагрузками в ЧНН (Часы Наибольшей Нагрузки). Особенно же трудноустранимый характер данная проблема имела в свете наличия в БД хранимых процедур, в которых была сосредоточена б.ч. логики комплекса. Численность этих «хранимок» измерялась сотнями. Был и второй важный риск, не выявленный аудитом. О нём будет сказано ниже.
Как уже было сказано, в Такси 666 существовал собственный R&D отдел, бессменно возглавляемый ГГ. Отношения между ГГ с его отделом и остальной частью бизнеса были сложными. Настолько сложными, что некоторые рядовые члены отдела приторговывали «на сторону» продуктами компании, а сам ГГ незадолго до сделки с Энтерпрайзом сговорился с конкурентом. В результате, спустя без малого 2 месяца со дня закрытия сделки, весь R&D в полном составе снялся с места, сел на самолёт и улетел к конкуренту в далёкие тёплые края. Справедливости ради скажу, что такой форс-мажор трудно было предугадать, и это был риск, который ни в какие матрицы не укладывался. Тем не менее, его можно было минимизировать по крайней мере двумя способами:
Способ №1. Прописать требованием к сделке создание подробной документации комплекса. Оной документации в Такси 666 не существовало от слова «вообще», и как потенциальный риск данный факт также воспринят не был.
Способ №2. Прописать для продавца приобретаемой компании обязанность обеспечить сохранение R&D отдела в течение некоторого переходного периода. С драконовскими санкциями в случае невыполнения. Спецы по M&A, если вы меня читаете – возьмите это на заметку.
Прежде чем продолжить, мне следует сказать пару слов о «наполеоновских планах» Энтерпрайза на момент приобретения Такси 666. Они предполагали увеличение кол-ва городов присутствия с десятков до сотен в срок, измеряемый 1,5-2 годами. Иметь амбициозные планы – это хорошо. Не иметь процесса пересмотра таких планов в случае резкого изменения обстоятельств – очень плохо. Вот так и была сделана ещё одна ошибка:
Ошибка №3. Внезапная полная потеря отдела разработки не была расценена как резкое изменение обстоятельств. Наполеоновские планы остались прежними.
Тем не менее, не признать, что в компании разразился кризис, было невозможно: комплекс элементарно требовал людей для техподдержки. Поскольку медлить было нельзя, агентами, срочно прибывшими из Москвы, были наняты несколько толковых специалистов за умопомрачительные зарплаты. Они смогли стабилизировать работу комплекса. Это, кстати, стало одним из немногих правильных шагов на протяжении всего проекта.
Правильный шаг №1. Под угрозой worst case scenario надо действовать стремительно и не считаться с расходами.
В то же время, после прохождения пика кризисной ситуации не было предпринято необходимых мер по сворачиванию «антикризисного штаба»: замены крайне дорогих спецов на более дешёвых и нахождения постоянного руководителя в отдел. Так была допущена следующая ошибка:
Ошибка №4. Антикризисный IT-менеджер Энтерпрайза был назначен IT-директором Такси 666. Это было плохим решением по целому ряду причин. Во-первых, человеку, имеющему троих маленьких детей, приходилось бывать в командировках по графику «4 дня через 3» на протяжении нескольких месяцев. Во-вторых, этот человек совершенно не знал местной специфики рынка труда в IT-сфере, что привело как к досадным ошибкам (вроде найма Junior Developer’а на позицию Senior’а за з.п. в 100 т.р.), так и в целом очень медленному процессу найма персонала. В-третьих, его назначение прошло «мимо» Генерала, в результате чего работа обоих вскоре дополнительно осложнилась тлеющим конфликтом.
Дальнейшее развитие событий проще всего описать как ряд следствий из ранее сделанных предпосылок:
- Ошибки №2 и №3 привели к тому, что вместо необходимой паузы на глубокую переработку архитектуры комплекса, когда все ресурсы команды были бы направлены на решение этой задачи, команда была разделена на тех, кто поддерживал комплекс, остававшийся для них «чёрным ящиком», и тех, кто готовил его к переводу «в облако» (где ждали такие прогрессивные вещи, как удалённое открытие новых городов, распределённые диспетчерские центры, недосягаемость для Кровавой Гэбни и пр.). В результате, за следующие полгода не было качественно решено ни одной из этих задач.
- Ошибка №4 обусловила «дыры» в штатном расписании, которые долгое время не давали «расшифровать» тот самый «чёрный ящик» внутри комплекса, что порождало всё новые проблемы со стабильностью его работы. Это злило Генерала и подталкивало его ко всё более активному противодействию планам Энтерпрайза.
- Ошибки №1, №2 и №4 привели к тому, что инвесторы из Энтерпрайза, устав от не приносящих никакого профита расходов, смирились, наконец, с крахом наполеоновских планов. Тем самым они полностью уступили инициативу Генералу, который (под предлогом «сокращения расходов») с радостью вычистил лишь недавно доукомплектованный R&D отдел от всех, кто мешал вести бизнес «как раньше». Т.е. без «облаков» и обладающих собственным видением менеджеров. Включая и меня, бывшего Product Manager’а.
Безусловно, примером полного провала данная история не является. Оставшаяся часть команды наверняка сможет, наконец, разобраться в запутанной архитектуре комплекса и стабилизировать его работу. Бизнес продолжит быть прибыльным ещё долгое время – пока не уйдёт старшее поколение, которому привычнее делать заказ голосом, нежели через экран смартфона. В то же время, мечте сделать Best Product силами региональной команды сбыться не суждено…
Для кого я написал этот текст? В первую очередь, для высшего руководящего звена. Коль скоро в вашем распоряжении большие финансовые ресурсы, убедитесь, что управляют ими компетентные менеджеры, которые умеют находить скрытые риски и понимают, что на каждый из них должен быть заранее разработан план действий. Во вторую – для амбициозных молодых людей вроде меня, которые думают, что своими идеями могут изменить мир к лучшему. Прежде чем пускаться в новое предприятие, здраво оцените не только цели и ресурсы ваших партнёров, но также адекватность и профессионализм их менеджеров. Работать надо в команде единомышленников.
Комментарии (30)
lis_man
10.07.2017 15:23открыл для себя сокращение б.ч.
DmitryKuzmenko
10.07.2017 18:08+1>Все Delphi-приложения были завязаны на использование данной СУБД
Приложения обычно не бывают абстрактными, для любой СУБД. Если СУБД менять, приложения придется переписывать.
А Delphi сама по себе не завязана ни на какие СУБД. Для нее они все одинаковы, разница только в используемых компонентах доступа, и умении разработчика приложений работать с СУБД.
Насчет Firebird — «обидные ваши слова» :-). Firebird тут являлся «зоной риска», видимо, только потому, что при разработке и сопровождении не было специалистов, действительно знающих эту СУБД. Я не припомню, чтобы компании в этой сфере обращались за оптимизацией к нам, например.
Хотя, может, в лучшем случае на известный профильный форум ходили.
Firebird, к сожалению, позволяет админу не знать даже как померять дисковый ввод-вывод. Не говоря про разработчика, который может не знать специфику версионности, оптимизатора, и прочего, что надо знать для любой СУБД.
Например — для Оракла было бы неплохо какие-то сертификаты иметь, а «Firebird фигня, и так сойдет».
Отсюда — на начальном этапе проект рвет и мечет, а при появлении серьезной нагрузки «почему-то» все идет наперекосяк. Это же для любой СУБД справедливо.farafonoff
13.07.2017 16:57У фб реально что-то с производительностью (не упирается в дисковый io, но начинает тормозить), и с надежностью (периодически появляются невосстановимые бэкапы).
DmitryKuzmenko
13.07.2017 17:24невосстановимые бэкапы сами по себе не появляются. Они являются следствием или повреждения БД, или определенных действий разработчика.
А насчет «реально что-то с производительностью» — у какой версии ФБ и архитектуры? Мы работаем с пользователями самых разнообразных систем на ФБ — и сотни пользователей, и сотни гиг, и т.д. Но никаких таких «что-то» не наблюдаем.
Разумеется, бывает всякое, например, какой-то редкий баг, который приводит к проблемам в 1-2 случаях на тысячу или десятки тысяч. Но делать из этого вывод, что «начинает тормозить», некорректно.
Я вам могу привести две явных причины торможения — не отключенный авто-свип и накопление мусорных версий. Но это не является дефектом Firebird. Это следствие непонимания архитектуры сервера при разработке приложений, и неумение администрировать сервер.
Подобные вещи можно встретить в любой СУБД.farafonoff
14.07.2017 10:45К счастью я уже не занимаюсь фб, но могу сказать, что в регламентные процедуры входил бэкап и восстановление его на рабочую базу (в противном случае начинала падать производительность. Автосвип был отключен, ручной свип делался вместе с бэкапом еженочно, показатели мусора мы отслеживали). Кроме того БД «повреждалась» примерно раз в полгода — год, причины мы так и не выяснили.
nikolayv81
10.07.2017 18:10+3Энтерпрайз пришёл в компанию и объявил разработчику что успешно работающее в течении 15 лет это то что нужно уничтожить (по сути аргументом было "сейчас модно в облака", а у вас тут болото), а потом называет ГГ, хотя по сути тот сделал самый правильный вывод из ситуации (собрался и ушёл, захватив с собой тех кто не согласен с подходом нового владельца).
p.s. думаю проблема не технологиях, статья думаю не сильно бы поменялась будь там что-то другое.
DmitryKuzmenko
10.07.2017 18:23Кстати, мы как-то одной конторе помогли с оптимизацией. Через год там у них появилась проблема с железом. Тоже помогли. Параллельно смотрим — а ни один совет по оптимизации приложений и запросов не был сделан.
А почему?
Оказалось, что эта контора решила купить несколько других контор, у которых софт того же типа написан на другой СУБД. Начальство решило «унифицировать» имеющуюся систему с приобретаемыми путем переделки имеющейся. Соответственно, у разрабов пропал смысл что-то делать с текущей системой.
Areso
10.07.2017 21:10Сильно зависит от версии FB. Если там что-то типа 1.5, которое не умеет в многопоточность, 64 бита, и даже в utf-8 строчки, то да, определенные проблемы у них есть. Особенно в пиковые нагрузки.
Можно конечно брать рекорды, разгоняя процессор и оперативную память, менять хранилище (SAS->SSD->NVMe), и так далее, но это не сильно поможет. 1 поток останется 1, 2 гигабайта памяти 3200MHz останутся 2 гигами памяти.
В компании, где я работал, решили перейти с Delphi7+FB1.5 на VS2013+FB3. Тоже вылилось в большое количество головняка и денег. Причем железо так и не поменяли, даже не пробовали.DmitryKuzmenko
10.07.2017 21:501.5 и 2.5 суперсервер не-многопоточный. Суперсервер и не используют обычно при количестве пользователей больше 5-10, особенно при наличии длительных расчетов. Классик любой версии — распараллеливается, и как раз используется в массе для средне и сильно нагруженных систем.
32бит 64бит — не принципиально, особенно для классика. И разница в производительности 32-64 бит не больше 7%.
Суперсервер у ФБ стал многопоточным только в 3.0. И вот только его уже рекомендуют использовать вместо классика.nikolayv81
10.07.2017 22:13В 2.5 же гибрид ещё, superclassic он отлично справлялся с работой и насколько помню тянул неплохо.
DmitryKuzmenko
10.07.2017 22:24+1я не стал упоминать суперклассик 2.5 именно потому что гибрид — классик в одном процессе. Но он распараллеливался, да, и еще давал прирост на 10-15%, если было много запросов с сортировкой.
Собственно, у нас документ «Руководство по аппаратному обеспечению для СУБД Firebird» опубликован еще в 2015 году.
http://www.ibase.ru/files/firebird/Firebird_Hardware_Guide_2015_rus.pdf
с описанием всех архитектур, как их тюнить, и т.д.
PastorGL
10.07.2017 22:02Такси 373 и Gett. История наделала некоторого шуму в ижевском айтишном болотце. Искали народ, и предлагали не просто бабки, а БАБЛИЩЕ. Но очень уж мутно всё как-то выглядело насчёт перспектив.
Я тоже ходил к ним в гости, и на унаследованный код одним я глазом успел глянуть — прямая дорога в мусорку такому легаси. Итог закономерен, если автор не приукрашивает.
AlexeyKovyazin
10.07.2017 22:46+1Даже Firebird 2.5 на правильном железе держит 1500 и выше коннектов, во вполне себе нагруженных проектах, когда есть грамотные ДБА или профессиональное сопровождение. И кстати, на Firebird действительно много такси-сервисов написано и работает, обычно на дефолтных конфигурациях, т.е. вообще без оптимизации и без ДБА.
junkerSchmidt
11.07.2017 11:33Мда. Решили бабла заработать немножко. Закрыв глаза на анализ, риски и т.д. Поимели проблем и… обвинили во всем firebird. К успеху шли, ребята…
y90a19
12.07.2017 14:26Итак, пришел человек на готовый работающий 15 лет, приносящий доход бизнес.
И захотел он бизнесом крутить-вертеть по своему хотению, по инвесторов велению.
Естественно обосрался, за что был пидорнут на мороз. Кто виноват? Все, кроме него. Включая «генерала», и «ГГ», которые всё это создавали с нуля
roman-77
12.07.2017 21:07+1По поводу отсутствия документации и “черного ящика” автор тоже лукавит (пытаясь объяснить этим свои неудачи) либо действительно был не в курсе, что она есть: во- первых — это исходный код программ, комментарии к таблицам и хранимым процедурам БД, во-вторых — система управления проектами в Redmine.
Конечно для непосвященного в тонкости работы Такси человека вся эта бизнес-логика может показаться сложной и запутанной, как и архитектура (стандартная трех и местами двухзвенная), но это уже другая история…
Кстати, по словам ИТ-директора “Энтерпрайза” именно простая архитектура ПО стала одной из причин, по которой их выбор пал именно на эту компанию. И конечно, автору, следовало бы сравнить сложность настройки на примерах других систем (например “Такси… стер”, где количество настроек в системе приближается к тысячам).farafonoff
13.07.2017 16:15Скажем честно, high-level описания процессов никогда не создавалось.
Lucky82
13.07.2017 16:19Скажу больше, у меня есть сведения, что описаний не создавали намеренно, по указанию руководства. Типа, если кто сопрёт, чтобы не смог разобраться. Хитрый план по выкапыванию ямы себе :)
gbg
Предлагаю пойти глубже и искать ошибки в ваших ошибках: вы обозначили проблему — Firebird и логика в хранимых процедурах.
Более того, вы указали, что «решение», которое предлагалось, было, видимо, «снести рассадник» Firebird. (Потому что в этом случае, портирование процедур над другую платформу потребует ручной работы).
Не было ли менее радикального (и дешевого по времени и ресурсам) решения, вроде тюнинга сервера, переноса базы на SSD (или даже в RAM)?
Lucky82
Два очень матерых (на мой непрофессиональный взгляд) админа, которые в течение полугода держали всё это безобразие, предлагали много чего по части железа (в т.ч. и SSD), но именно такого предложения в качестве решения той проблемы не было. По какой-то причине, видимо, они не считали это выходом, даже половинчатым.
gbg
У меня вызывает опасение такой «наскок». Когда видят морально устаревшие технологии (а эта сладкая парочка, это как раз вот оно, хрестоматийный пример), и вместо их модернизации, предлагают все снести, не оглядываясь на то что:
1) Разработка нового (и чтобы было в точности, как старое!)- мероприятие, требующее денег, времени и никогда не попадающее в план.
2) Это работало 15 лет, а теперь вдруг «шеф, все пропало, ААААААААА!!!!»
3) Персонал придется переучивать.
И вот тут у нас все эти затраты на одной чаше весов, а на другой части — какой-нибудь тормозящий запрос. Так вот, может, сначала стоит в консерватории поправить?
gbg
Добавлю, что проблема с производительностью базы должна быть проиллюстрирована результатами профилирования планов запросов (а в IBExpert очень наглядный анализ производительности), метриками загрузки диска/RAM/CPU, но никак не мнением
Что же за админы без метрик?Lucky82
Согласен полностью. В то же время, мы боролись за появление другого, более фундаментального инструмента: Регламента работы техподдержки. В рамках которого появился бы SLA, с нужными бизнесу показателями, а следом и релевантные метрики. Первую рабочую версию Регламента мы написали, но когда Генерал увидел, что по тексту у него не одни только права, а внезапно появились обязанности и ограничения, он стал активно динамить процесс. Ну подумайте сами, зачем привыкшему к самодурству начальнику ограничивать себя в возможности устроить нагоняй сотруднику?
gbg
Вот вам в качестве примера адекватный отчет о проблемах производительности. Это фактические данные, с указанием способа и средств измерения. Любой желающий может проанализировать и воспроизвести.
Lucky82
Интересный отчёт, спасибо.
roman-77
Что касаются метрик, то они конечно велись (и надеюсь ведутся) в Нагиос. Без периодической переиндексации БД, например, начинал вырастать показатель Context Switches. Но само зависание могло произойти внезапно: при большом количестве транзакций в секунду резко возрастала нагрузка (CPU load) и СУБД просто переставала отвечать. Мы собирали отладочную версию FB, дабы выгружать дамп памяти, но его анализ ничего особенно не дал (судя по всему в этом был виноват механизм блокировок).
Проблема в том, что смоделировать подобную ситуацию на тестовом стенде не получалось, а на проде, когда разом отваливаются несколько тысяч водителей, клиенты не могут сделать заказ, любому сисадмину (даже самому матерому) проще и дешевле перезагрузить несколько сервисов, FB или виртуальную машину, чем пытаться выяснить причину зависания.
gbg
Версия была 1.5? Она это любит. И да, это блокировки.
roman-77
Версию старались обновлять на последнюю 2.5.4 на тот момент, если не ошибаюсь. За пару недель до "отъезда" даже успели адаптировать бакенд и клиентов к FB 3.0 и перейти на него на одном из городов. Но результаты промониторить как следует уже не получилось...
roman-77
Может вы они не считали это выходом, так как они (SSDs) уже использовались в течение некольких лет? Интересуюсь как тот самый ГГ, которого вы вскользь упомянули в середине статьи. Кстати тема ГГ не раскрыта до конца и основана на Ваших домыслах, ну или слухах...
Lucky82
Совершенно верно, Роман, на мнениях других людей, но нескольких и не из одной «обоймы». Ничто не мешает вам написать статью-дополнение со своей версией событий, происходивших где-то так между началом нулевых и летом 2016 года.