В конце декабря 2008 года меня пригласили в одну из служб такси г.Перми с целью автоматизации существующих бизнес-процессов. В целом передо мной были поставлены три фундаментальные задачи:?
- Разработать программный комплекс для call центра с мобильным приложением для водителей такси и автоматизировать внутренние бизнес-процессы.
- Сделать все надо было в максимально сжатые сроки.
- Иметь собственное, а не купленное у сторонних разработчиков, программное обеспечение, которое в дальнейшем по мере развития бизнеса можно было самостоятельно масштабировать под постоянно меняющиеся условия рынка.
На тот момент я не понимал, как устроен этот рынок и его нюансы, но тем не менее очевидными для меня были две вещи. Call центр необходимо строить на базе программной АТС asterisk с открытым исходных кодом. Обмен информацией между call центром и мобильным приложением по сути является клиент-серверным решением со всеми соответствующими паттернами проектирования архитектуры будущего проекта и его программирования.
После предварительной оценки поставленных задач, сроков выполнения и затрат на реализацию проекта, согласовав все необходимые вопросы с владельцем службы такси, в январе 2009 года я приступил к работе.
Забегая вперед скажу сразу. В итоге получилась масштабируемая платформа, работающая на 60+ серверах, в 12 городах России и 2 Казахстана. Общая прибыль компании составляла 100+ млн.руб/месяц.
Этап первый. Прототип
Поскольку на тот момент у меня не было практического опыта в ip телефонии, а с asterisk был знаком поверхностно в рамках «домашних» экспериментов, было принято решение начать работу с разработки мобильного приложения и серверной части. Попутно закрывая пробелы в знаниях по остальным задачам.
Если с мобильным приложением более-менее все было понятно. На тот момент оно могло быть написано только на java для простых кнопочных телефонов, то с написанием сервера, обслуживающего мобильных клиентов, вопрос стоял несколько сложнее:
- Какая серверная ОС будет использоваться;
- Исходя из логики, что язык программирования выбирается под задачу, а не наоборот и с учетом п.1, какой язык программирования будет оптимальным для решения задач;
- При проектировании необходимо было учесть предполагаемые в будущем высокие нагрузки на сервис;
- Какая база данных сможет гарантировать отказоустойчивость при высоких нагрузках и как сохранить быстрое время отклика БД при росте количества обращений к ней;
- Определяющим фактором являлась скорость разработки и возможность быстрого масштабирования кода
- Стоимость оборудования и его обслуживания в дальнейшем (одним из условий заказчика – сервера должны находиться на подконтрольной ему территории);
- Стоимость разработчиков, которые понадобятся на следующих этапах работы над платформой;
А также множество других вопросов, связанных с проектированием и разработкой.
Перед началом работы над проектом я предложил владельцу бизнеса следующее стратегическое решение: поскольку проект достаточно сложный, его реализация займет заметное количество времени, поэтому сначала я создаю MVP версию, на которую уйдет не так много времени и средств, но которая позволит его компании получить конкурентное преимущество на рынке уже «здесь и сейчас», а также расширит его возможности как службы такси. Мне-же в свою очередь такое промежуточное решение даст время более обдуманно спроектировать конечное решение и время на технические эксперименты. При этом, реализованное программное решение не будет гарантированно правильно спроектировано и возможно в последующем будет кардинально переделано или заменено, но оно точно будет выполнять минимально необходимый функционал для «отрыва от конкурентов». Идея основателю такси понравилась, поэтому в итоге так и поступили.
Первые две недели я потратил на изучение бизнес-процессов в компании, и изучение работы такси «изнутри». Провел бизнес-анализ, где, что и как можно автоматизировать и нужно ли вообще. С какими сложностями и проблемами сталкиваются сотрудники компании. Как их решают. Как организован рабочий день у работников компании. Какие инструментами пользуются.
К концу третьей недели после начала работы и изучения интересующих вопросов в интернете, с учетом пожеланий владельца бизнеса, а также моих собственных знаний и возможностей на тот момент, было принято решение применить следующий стек:
- Сервер БД: MsSQL (бесплатная версия с ограничением файла БД до 4Гб);
- Разработка сервера, обслуживающего мобильных клиентов, в Delphi под windows, так как уже имелся windows сервер на котором будет установлена БД, а также сама среда разработки способствует быстрой разработке;
- С учетом низких скоростей интернета на мобильных телефонах в далеком 2009 году — протокол обмена между клиентом и сервером должен быть бинарным. Это позволит уменьшить размер передаваемых пакетов с данными и как следствие повысит стабильность работы клиентов с сервером;
Еще две недели ушли на проектирование протокола и базы данных. Получилось 12 пакетов, обеспечивающих обмен всеми необходимыми данными между мобильным клиентом и сервером и около 20 таблиц в БД. Эту часть работы я делал с учетом на будущее, даже если придется изменить стек технологий полностью, структура пакетов и БД должна остаться неизменной.
После подготовительных работ можно было приступать к практической реализации идеи. Чтобы немного ускорить процесс и освободить себе время для остальных задач я сделал черновую версию мобильного приложения, наброски UI, частично UX и привлек к проекту знакомого java программиста. А сам сосредоточился на разработке серверной части, проектировании и тестировании.
К концу второго месяца работы над MVP, была готова первая версия прототипа сервера и клиента.
А к концу третьего месяца после синтетических тестов и полевых испытаний, фикса багов, небольших доработок протокола и БД приложение было готово для вывода в продакшен. Что и было сделано.
С этого момента начинается самая интересная и самая сложная часть работы над проектом.
В процессе перехода водителей на новое ПО было организованно круглосуточное дежурство. Так как не все могли приехать днем в рабочее время. К тому-же административно, волевым решением основателя компании, было организовано так, что логин/пароль вводил менеджер службы такси и водителю они не сообщались. С моей стороны была нужна техническая поддержка пользователей на случай сбоев и непредвиденных ситуаций.
Закон Мэрфи говорит нам: «Все, что может пойти не так, пойдет не так». И именно не так все и пошло… Одно дело, когда я, да несколько таксистов протестировали приложение на нескольких десятках тестовых заказов. И совсем другое дело, когда 500+ водителей на линии работают в режиме реального времени на настоящих заказах реальных людей.
Архитектура мобильного приложения была простой и багов в нем оказалось заметно меньше, чем в сервере. Поэтому основной фокус работ был на серверной части. Самым критичным глюком в приложении была проблема дисконнекта от сервера при пропадании интернета на телефоне и повторном восстановлении сессии. А интернет пропадал довольно часто. Во-первых, сам по себе в те года интернет на телефоне не был достаточно стабильным. Во-вторых, было много слепых зон, где интернет просто не работал. Эту проблему мы выявили почти сразу и в течении суток устранил и обновил все установленные ранее приложения.
На сервере в основном были ошибки в алгоритме распределения заказов и не корректной обработкой некоторых запросов от клиентов. По факту выявления глюков, исправлял и обновлял сервер.
На самом деле технических проблем на этом этапе было не так уж и много. Вся сложность была в том, что почти месяц я дежурил в офисе, лишь изредка выбираясь домой. Раза 4-5, наверное. И спал урывками, так как над проектом на тот момент работал один и кроме меня никто исправить ничего не смог бы.
Месяц, это не значит, что все постоянно глючило в течении месяца и я, не переставая что-то там кодил. Просто мы так решили. Ведь бизнес уже работал и приносил прибыль. И лучше перестраховаться, и отдохнуть потом, чем терять клиентов и прибыль сейчас. Мы все это прекрасно понимали, поэтому всей командой сообща уделили максимальное внимание и время введению нового ПО в систему такси. А с учетом текущего трафика заказов, за месяц мы точно устраним все недостатки. Ну а скрытые баги, что могут остаться уж точно не будут иметь критических последствий на бизнес процесс и их при необходимости можно исправлять в рабочем порядке.
Здесь надо отметить неоценимую помощь со стороны директоров и бригадиров служб такси, которые с максимальным пониманием сложности ситуации перевода водителей на новое ПО круглосуточно работали с водителям. По факту, после завершения работ по установке новых программ на телефоны мы не потеряли ни одного водителя. И не критично увеличили процент не вывоза клиентов, который в скором времени вернули к нормальным показателям.
На этом был завершен первый этап работы над проектом. И надо заметить результат не заставил себя ждать. За счет автоматизации раздачи заказов водителям без участия человека — среднее время ожидания такси клиентом сократилось на порядок, что естественным образом повысило лояльность клиентов к службе. Это привело к увеличению количества заказов. Следом увеличилось и количество таксистов. Как следствие увеличилось и количество успешно завершенных заказов. И как результат — увеличилась прибыль компании. Разумеется, здесь я забегаю несколько вперед, так как весь этот процесс прошел не моментально. Сказать, что руководство было довольно — ничего не сказать. Мне был открыт безлимит в дальнейшем финансировании проекта.
Продолжение следует..
Комментарии (93)
PopovGP
09.06.2019 19:24Многое читается между строк. Эта автоматизация, какая она и должна быть.
Автор молодец.
nomadmoon
09.06.2019 20:07Такси Максим чтоли? Они тоже на Урале вроде начинались где то.
Siddthartha
09.06.2019 23:51ну я вот, скажем, такое же mvp кому-то(!) собирал еще под мобильный html, где-то в те же времена. так что это как грибы) возникало. даже не знаю кто в итоге вырос из того mvp))
Denilen Автор
11.06.2019 04:59Рынок то привлекательный был в те года. Все хотели свою часть пирога :)
К слову до сих пор, не смотря на Яндекс и Uber нет нет, да появляются энтузиасты. Наверное это даже хорошо.
saipr
09.06.2019 20:44Сервер БД: MsSQL
А почему вы не использовали SQLite?
хотя
Мне был открыт безлимит в дальнейшем финансировании проекта.
HSerg
09.06.2019 23:38Запись в один поток и возможные блокировки чтения — проще взять полноценную серверную СУБД. Конкретно MS SQL видимо из-за опыта автора, т.к. в Delphi-мире гораздо чаще Firebird встречается.
Denilen Автор
11.06.2019 05:01К сожалению не из-за опыта. MsSQL уже использовался. Я лично PostgreSQL предпочитаю.
firedragon
10.06.2019 08:46ORACLE и MS SQL это 2 относительно дешевые коммерческие базы с очень широкими возможностями. Плюс отлично масштабируются по вертикали. В отличие от других.
Плюс довольно часто вместо усложнения приложения часть бизнес логики переносят в БД.Sioln
10.06.2019 11:24В отличие от других.
Какая БД по вертикали не масштабируется?
Вы, наверное, перепутали.
vanyas
10.06.2019 12:03+2Дешевые? Вы ничего не перепутали?
А за перенос логики в БД по рукам бить надо, т.к. потом хрен мигрируешь на другую БД.elisoffka
11.06.2019 04:34Что простите? А для чего тогда СУБД с возможностью хранения бизнес логики в виде хранимых процедур?
DatUser
11.06.2019 04:35Абсолютно с вами солидарен насчёт битья по рукам. Особенно нужно бить тех, кто часть логики трансформации данных опускают в БД при живом ETL-средстве, в итоге тебе в базу положили одно, а вытащил ты непонятное нечто. Теория информации подсказывает, что любая обработка информации узлом приводит к её потере. Имеем снижение надёжности интеграции и так или иначе однажды возникновение ошибки о получении недопустимых данных.
elisoffka
11.06.2019 10:43бить надо по головам, эникейщикам, которые в СУБД не бум бум. Логика в СУБД существует именно для того чтобы в БД лежало то что должно лежать, а данные предоставлялись именно те которые нужно предоставить. Для этого средствами СУБД реализуются всевозможные API.Если вам не нужно РСУБД, то тогда текстовые файлики или BigData.
fogree
11.06.2019 11:11В моей практике встречались не раз очень элегантные решение на ХП. Если тоже самое делать на уровне приложения, было бы и неудобнее (больше кода) и медленнее. Почему же вы категорически против такого подхода, только потому, что кто-то его неправильно применяет?
И никто не запрещает, например, всю бизнес логику вынести на уровень БД, если это хорошо подходит под задачу.
Denilen Автор
11.06.2019 05:02По рукам бы бить не стал, вполне себе практикуется. Но я вот тоже не люблю, когда бизнес логику не оправданно в БД переносят.
GarfieldX
11.06.2019 16:55После MS SQL на Oracle чувствовал себя со связанными руками. Одно только отсутствие нормальных времянок было огромным минусом. Как там в последних версиях — не в курсе.
Sovetnikov
09.06.2019 21:15+3Странный перечень вопросов для выбора технических решений на стадии MVP. Да и далее вы кажется просто взяли то, что знали сами :)
И я так понимаю эти вопросы с обратным приоритетом? Выбор ОС кажется менее приоритетное, чем выбор стека технологий по наличию достаточного количества специалистов?
И сразу хочется узнать, какие из критериев оказались полезные, а какие нет?
Вот выбор бинарного протокола на MVP вам помог?
Авральная работа запоем, поддержка директоров и пользователей это прекрасно, но напишите сразу как этого стоило избежать :)AleXP3
09.06.2019 23:43+2Авральная работа запоем, поддержка директоров и пользователей это прекрасно, но напишите сразу как этого стоило избежать :)
А почему подобного надо избегать? Это же безумно интересно: иногда работать в подобном «боевом режиме».
Denilen Автор
11.06.2019 05:10— Сейчас я бы другими критериями руководствовался. Наверное они покажутся странными. Но тогда именно они были ключевыми;
— Порядок критериев != приеоритету.
— Остаться на MsSQL было верным решением, в плане экономии времени в дальнейшей работе. В противном случае переход на новую бд добавил бы еще больших бессонных ночей :)
— Бинарный протокол теперь уже кажется сомнительным решением. По правде и json простой хорошо бы себя показал;
— Напишу все ошибки, и свои и в целом. Хотел это на последок оставить.
stalker1984
09.06.2019 21:32В общем история из разряда Русского Бизнеса — а 16 шапок можешь?
tersuren
10.06.2019 04:31Вот это вы зря. Это история из разряда реального бизнеса. Приходится работать с неидеальными инструментами и в неидеальной ситуации. Но на эту тему есть в классике (а на какую нет? :) )
You have to make the good out of the bad because that is all you have got to make it out of. (С) All the King's Men.
Wesha
10.06.2019 23:00Это история из разряда реального бизнеса.
"Вот тебе тонна *овна, к завтраму (звук передёргиваемого затвора) приду за конфеткой"?
(Кстати, интересно, в цифре "100+ миллионов" чьих заслуг больше — автора или инфляции? :)
Denilen Автор
11.06.2019 05:14(Кстати, интересно, в цифре «100+ миллионов» чьих заслуг больше — автора или инфляции? :)
Я сейчас банальную вещь скажу. Но заслуга всей команды, что трудилась со мной тогда. Данные реальные по цифрам. Вот только не смотря на то, что и компании уже не существует, показать их в открытом доступе будет немного необдуманным решением.
Denilen Автор
11.06.2019 05:11Вот это вы зря. Это история из разряда реального бизнеса. Приходится работать с неидеальными инструментами и в неидеальной ситуации. Но на эту тему есть в классике (а на какую нет? :) )
You have to make the good out of the bad because that is all you have got to make it out of. (С) All the King's Men.
Верно подмечено :)
alexander_8901
09.06.2019 21:57+1Примерно по тому же пути шел, только сфера другая и стек, а общий подход тот же.
И спал урывками, так как над проектом на тот момент работал один и кроме меня никто исправить ничего не смог бы.
Все же незаменимым быть плохо.
furtaev
09.06.2019 21:59+6В продолжении статьи очень хотелось бы прочитать, в кого маленькая программа превратила маленького человека из мира IT, то есть автора.
lasc
10.06.2019 06:51+2Ну так пару кликов в гугле и оп www.upwork.com/o/profiles/users/_~01495906cc55b050dc
16.25 в час.Paskin
10.06.2019 07:27-2Похоже, федеральная программа лично автору не очень помогла.
Mel
10.06.2019 12:41+2Ну как обычно, месяцами не спишь, потом бегаешь по больничкам, читаешь (или даже пишешь) статьи про выгорание, а в это время владелец бизнеса спокойно смотрит на свои 100м в отчетах :) Участь любого наемного работника с горящими глазами.
Denilen Автор
11.06.2019 05:17В продолжении статьи очень хотелось бы прочитать, в кого маленькая программа превратила маленького человека из мира IT, то есть автора
Кульминация и развязка истории, надеюсь, получится куда более неожиданной, чем просто название компании.
Norrius
10.06.2019 08:41Статья кончилась весьма внезапно. Выглядит интересно, но хотелось бы всё же хоть какие-нибудь технические подробности об архитектуре этой системы, какие были проблемы и прочее.
Это всё в следующих сериях?Denilen Автор
11.06.2019 05:19Статья кончилась весьма внезапно. Выглядит интересно, но хотелось бы всё же хоть какие-нибудь технические подробности об архитектуре этой системы, какие были проблемы и прочее.
Это всё в следующих сериях?
Да, обязательно. Без стыда за совершенные ошибки и с приятными воспоминаниями о победах ))
SbWereWolf
10.06.2019 09:23Автор хорошо поработал и у автора всё получилось, молодец автор. Спасибо что поделился.
Denilen Автор
11.06.2019 05:19Автор хорошо поработал и у автора всё получилось, молодец автор. Спасибо что поделился.
Спасибо
Tomasina
10.06.2019 09:40+1На тот момент я не понимал, как устроен этот рынок и его нюансы, но тем не менее очевидными для меня были две вещи. Call центр необходимо строить на базе программной АТС asterisk с открытым исходных кодом.
Не очевидно. Поясните.Denilen Автор
11.06.2019 05:23Не очевидно. Поясните.
Про freeswitch тогда не слышал. Asterisk комюнити было доступнее. Возможно ошибусь, но до зари расцвета облачных АТС (которые в большинстве своем на том-же asterisk реализованы)
Это было единственное доступное для разработчиков открытое решение. Хотя и тогда найти нормального специалиста было, ну, далеко не просто. Другие решения не рассматривал. Нужна была программная АТС, которую можно масштабировать под «свои уникальные» задачи :)
402d
10.06.2019 11:47Из стихотворения «Мне ни к чему одические рати...» (1940) Анны Андреевны Ахматовой (1889—1966):
Когда б вы знали, из какого сора
Растут стихи, не ведая стыда.
Как желтый одуванчик у забора,
Как лопухи и лебеда.
Сердитый окрик, дегтя запах свежий,
Таинственная плесень на стене…
И стих уже звучит, задорен, нежен.
На радость всем и мне.
По моему мнению любой удачный коммерчески проект вырастает из ужасного сляпанного
на коленке прототипа. А академически правильные остаются предметом докладов на конференциях.
Denilen Автор
11.06.2019 05:24По моему мнению любой удачный коммерчески проект вырастает из ужасного сляпанного
на коленке прототипа. А академически правильные остаются предметом докладов на конференциях.
Я вот как раз об этом и хотел бы донести до читателей. Благодарю за понимание :)
hssergey
10.06.2019 12:43Как-то слишком мало подробностей. Я сам занимался похожим проектом, и подводных камней было весьма немало:
— плохая связь. Как это отследить? Как корректно восстановить состояние?
— каким водителям отослать новый заказ? Как выбрать водителя или водителей, кому отослать новый заказ в первую очередь*
— одновременный прием одного и того же заказа несколькими водителями. Как корректно обработать на сервере, чтобы не было логических гонок? Как корректно обработать это на клиенте в условиях нестабильной связи?
— прием координат от водителей. Как корректно строить траекторию с учетом того, что координаты сильно зашумлены, могут не приходить из-за проблем со связью, или водитель заехал в туннель, а могут «телепортироваться» вообще на другой конец города?
— прием событий от сервера клиентом. Как лучше реализовать — периодический запрос событий клиентом, или отсылку сервером по своей инициативе? Как быть, если связь оборвалась, и событие не дошло. Когда перепосылать? Как сделать, чтобы из-за перепосылок клиенту не пришло одно и то же событие несколько раз?
— построение маршрутов. Как и когда их строить, чтобы при этом не разориться на запросах к гуглу или яндексу? Что из этого можно закэшировать?
и так далее. И тут уже не важно, будет ли сервер под windows или использован другой стек…Denilen Автор
11.06.2019 05:27Как-то слишком мало подробностей. Я сам занимался похожим проектом, и подводных камней было весьма немало:
Спасибо за наводящие вопросы. Отвечу на них в следующей статье.
2PAE
10.06.2019 13:25Самый животрепещущий вопрос, для меня, вам заплатили за работу?
Столько сколько вы хотели?
Читать это как радостную историю или трагичную?Denilen Автор
11.06.2019 05:29Самый животрепещущий вопрос, для меня, вам заплатили за работу?
Столько сколько вы хотели?
Читать это как радостную историю или трагичную?
Ну, вообще история скорее драма. Не про одного конкретного человека.
За работу заплатили. Машину подарили. Надо было просить больше сразу.
Но все-же это история не про меня…
varton86
10.06.2019 14:28«Прибыль 100+ млн.руб/месяц». В такси. Странно, что еще никто не засмеялся.
402d
10.06.2019 14:48если с заказа брать хотя бы 50 руб.
то нужно 2*10^6 заказов
считаем 10 заказов на водителя в смену. 20 дней в месяц.
получаем 10 000 таксистов в системе.
Вполне реальная цифра для федеральной сети.
varton86
10.06.2019 14:57Чем прибыль от выручки отличается, знаете?
402d
10.06.2019 15:321. Расчет условный.
2. Это агрегатор. Он просто берет свою долю за заказ.
3. Расходы при автоматизации на один заказ быстро снижаются.
Условно прораммистам и за сервера нужно платить в месяц 500тыс. Обслужили
1 млн заказов. 50р — 0.50
4. Агрегатор забирает себе в среднем 30% от стоимости поездки
5. Средная стоимость поездки выше 240 рублей.
Ну или все можно пересчитывать гораздо точнее. А для оценки порядка достаточно и
грубого расчета.
А вот, немного статистики про яндекс такси. Если у них доля хотя бы в четверь, то таксистов смело можно увеличить до 100-200 тысяч.
taxi.yandex.ru/blog/billion-tripsvarton86
10.06.2019 16:01Ну то есть, по Вашему, у агрегатора почти никаких затрат нет. Ни лицензий, ни аренды помещений под те же сервера, ни рекламы, ни зарплат персоналу и т.д. и т.п. Не забудьте еще, что с каждым водителем нужно оформить договор, провести расчеты, организовать прием платежей и т.д. Налоги я в счет не беру, будем считать, что это валовая прибыль.
402d
10.06.2019 16:24все остальные числа в расчете можно увеличивать.
Современный таксист 6-8 часов пашет на агрегатора и автопарк у которого взял
в аренду автомобиль. И в оставшиеся 3-4 часа на себя.
Т.е. вместо 10 поездок можно заложить 20-25 (10 часов / и средняя продолжительность в 30 минут)
по данным википедии
На конец 2018 года в Москве работает порядка 100 тыс. таксистов, которые получили разрешение в Москве и Московской области
Сколько по России быстро не нашел.
Хоть это не приветствуется, но в основном у таксиста запущены приложения 2х агрегаторов.
www.audit-it.ru/buh_otchet/7704340310_ooo-yandeks-taksi
когда числа будете смотреть НЕ ЗАБЫВАЙТЕ что все в ТЫСЯЧАХ
Denilen Автор
11.06.2019 05:36«Прибыль 100+ млн.руб/месяц». В такси. Странно, что еще никто не засмеялся.
Достаточно ознакомится с налоговой отчетностью Uber (где указана его текущая доля yandex) и улыбка может пропасть.
Почему именно налоговой отчетностью Uber, а не Yandex.Taxi пусть между строк читается.
Vengant
10.06.2019 15:58Интересно было бы еще послушать, какой процент от этих прибылей достался автору… :)
legolegs
10.06.2019 16:03Что интересно, продвинутый голосовой интерфейс вызова такси был уже тогда, в далёком 2008 году. А у известных сегодня лидеров рынка такой фичи до сих пор нет :)
Denilen Автор
11.06.2019 05:38Что интересно, продвинутый голосовой интерфейс вызова такси был уже тогда, в далёком 2008 году. А у известных сегодня лидеров рынка такой фичи до сих пор нет :)
Не зашло тогда. Сам не понимаю почему. Общество не принимает имхо.
alan008
10.06.2019 16:08Стоит уточнить, что в бесплатной редакции SQL Server 2005 допустимый размер базы не 2 ГБ (как написано в статье), а 4 ГБ, а во всех более новых версиях SQL Server'а — ограничение на размер базы 10 ГБ. При этом можно создавать несколько баз внутри одного сервера без ограничений по их количеству, а также не учитывается объем данных, хранимый по технологии FILESTREAM (это когда в базе объявлено поле с типом BLOB, а данные этого поля хранятся не внутри mdf/ndf файлов базы, а валяются рядом с базой в виде кучи мелких файлов, при этом целостность транзакций соблюдается, т.е. этими файлами SQL Server управляет целиком сам, а работа с данными по-прежнему идет через SQL-запросы).
Denilen Автор
11.06.2019 05:43Стоит уточнить, что в бесплатной редакции SQL Server 2005 допустимый размер базы не 2 ГБ (как написано в статье), а 4 ГБ, а во всех более новых версиях SQL Server'а — ограничение на размер базы 10 ГБ. При этом можно создавать несколько баз внутри одного сервера без ограничений по их количеству, а также не учитывается объем данных, хранимый по технологии FILESTREAM (это когда в базе объявлено поле с типом BLOB, а данные этого поля хранятся не внутри mdf/ndf файлов базы, а валяются рядом с базой в виде кучи мелких файлов, при этом целостность транзакций соблюдается, т.е. этими файлами SQL Server управляет целиком сам, а работа с данными по-прежнему идет через SQL-запросы).
Поправил, спасибо. Много воды утекло. Почему-то цифра в 2Гб ограничения в памяти засела.
varton86
10.06.2019 16:10«Во-вторых, было много слепых зон, где интернет просто не работал. Эту проблему мы выявили почти сразу и в течении суток устранил и обновил все установленные ранее приложения.»
«Ох уж эти сказки, ох уж эти сказочники» (с)
Alcpp
11.06.2019 00:51Я так понимаю для связи с водителем Астериск не задействовался.
Он просто заедйствовался для логирования времени звонка и номера и создания заказа по Айди звонка. Вряд ли вы делали горячий и холодный трансфер, конференции тож вряд ли создавали.Denilen Автор
11.06.2019 07:40Да, все верно. Астериск использовался для входящих звонок в основном и по сути все agi скрипты были заточены на входящую связь и пиковые нагрузки. Позже уже его функционал стали расширять. Логирование и учет времени трансферов и конференций — это достойно отдельной статьи имхо.
negasus
Что ж за мода такая, «продолжение следует». Вроде бы нету лимита на количество символов в статье?
vvzvlad
1)Недостаток мотивации на написание большой статьи
2)Желание собрать комментарии и плюсы два раза
sim3x
Только два раза?
rexen
vvzvlad
Как показывает практика, нет. Большая статья собирает больше, чем разделенная на пару частей.
Другое дело — действительно сериалы из 5 и больше частей, каждая из которых читается как самостоятельная статья…
Denilen Автор
Вообще так и задумывал. Вводную часть, дальше побольше конкретики ну и кульминация с развязкой :)
vvzvlad
Ну, у вас не получилось «каждая читается как отдельная статья», обрывается на самом интересном месте.
dmitryredkin
Так а почему сейчас все деньги не в кино, а в сериалах, как вы думаете? (А в кино — в киносериалах).
mrClin
Что ж за мода такая, в русском языке нет слова «нету»…
White_Scorpion
Любой язык развивается. Сегодня нету, а завтра — появится. Вон "в смысле" тоже не было, а теперь — в предлоги ввели.
trolley813
Как минимум, в моем "Словаре русского языка" под ред. Ожегова (1983 года издания) слово "нету" есть, и с тех пор оно никуда не девалось.
kubk
ru.wikisource.org/wiki/Я_к_вам_пишу_случайно,_—_право_(Лермонтов)
Лермонтов использовал это слово в своих стихотворениях, а теперь вдруг решили, что слово не существует? Слово зафиксировано в различных словарях: gramota.ru/slovari/dic/?word=%D0%BD%D0%B5%D1%82%D1%83&all=x
iHateCpp
Во-первых, простыни читать не очень удобно
Во-вторых, написать сразу все означает потратить куда больше времени. А так можно посмотреть, если ли интерес у аудитории, и если его нет — время на вторую часть на тратить.
xPomaHx
Программистский подход, сделал что-то выкатил тут же.
Lamaster
Ни тесты не написал, ни нагрузочное тестирование не проводил.
Хотя и такие практики в те годы не были распространены.
Хорошо, конечно, что у автора всё получилось, но лучше было хотя бы клиентов-ботов написать, чтобы потестили под нагрузкой.
legolegs
Клиентов ботов, чтобы на машинах по городу колесили под мостами да туннелями? Ну вы слишком много хотите от провинциала-одиночки.
Denilen Автор
Боты были. Нагрузочное тестирование тоже. Многие моменты опускаю умышленно, дабы не вдаваться совсем в детали. Хотелось все более менее в художественном стиле изложения истории описать, но не забывая про ключевые детали.
Denilen Автор
custdev скорее, но можно и так назвать, не спорю
NiPh
Мне кажется на пикабу это зародилось, как попытка минимальными усилиями понять хорошо ли получается, и набрать рейтинга и подписчиков за серию коротких заметок. Плюс специфика ресурса, когда цели написать законченный пост в общем то и не стоит. Я тоже никак не привыкну к этому на техническом хабре (
evocatus
Вообще-то это нормальный формат, который идёт ещё от серий газетных колонок, периодических изданий и пр.
NiPh
Формат-то существует, но Хабр набрал свою аудиторию за счет технических статей, где всё рассказывается за раз. И возникла привычка, в контексте хабра, читать всю историю целиком.
У газетных колонок и периодических изданий есть физическое ограничение размеров издания, в цифровом же виде это или намеренный ход для рейтинга, либо отсутствие времени у автора, отчего страдает восприятие истории.
Denilen Автор
Это моя первая статья. Не судите строго. Замечания учту.
Denilen Автор
За модой не гонюсь. Пишу в свободное время.