Опенсорс-хелпдеск для сервисного центра: есть смысл поднимать или утонем в хаосе?

Три года назад на таком же энтузиазме подняли себе открытую тикетницу. Восемь месяцев все летало, потом база переполнилась и намертво зависла. Ежедневных бэкапов не было, записи за последние 3 недели с концами улетели — вообще не могли понять чьи запчасти где лежат. После этого сразу переехали на готовое облако.

Если будете ставить, разворачивайте не напрямую в ОС, а в изолированных контейнерах. Берите сервер минимум с 4 ГБ оперативки и обязательно настройте крон-скрипт на ежедневный бэкап базы на внешнее хранилище. Тогда при любом сбое восстановитесь за 10 минут.

Поставить систему — дело полудня вся жесть начнется потом, когда при обновлении версии передерутся плагины.

Сидим на опенсорсе уже два года. Сервер обходится в 12 евро в месяц. По сравнению с облаком сэкономили около 1800 евро за год, но на первичную настройку и доводку шаблонов писем я убил часов сорок.

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

Перед стартом проверьте три момента: 1) сможете ли настроить надежную отправку писем через внешний SMTP? 2) льются ли ежедневные бэкапы на отдельный сторонний сервер? 3) насколько мобильная версия удобна для мастеров?

Мастера будут вбивать данные с компов в мастерской или с телефонов на выезде прямо у клиента? У большинства опенсорс-решений мобильный интерфейс в боевых условиях жутко неудобный.

Верно.

Я думаю иначе. Решения, работающие в малом масштабе, рушатся при росте, я узнал это слишком поздно.

Удачи.

нужно идти по порядку потом ну процесс по которому не ведется учет не улучшается потому что вы не знаете, что именно улучшать.

решения, работающие в малом масштабе рушатся при росте я узнал это слишком поздно.. и честно на этом всё, извините, если затянул.

Краткое резюме для новичков: Процесс, по которому не ведется учет, не улучшается потому что вы не знаете, что именно улучшать.

Надеюсь, это будет полезно.

Я долго занимался этим вопросом. честно если не зафиксировать это письменно с самого начала потом возникнут споры.

График платежей должен быть привязан к этапам работ а не к датам.

Пишу это, чтобы вы не совершили ту же ошибку. Код без документации не принадлежит вам, даже если он у вас есть.

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

После сдачи проекта система продолжает жить; обслуживание — отдельная статья расходов. Это мое мнение, не утверждаю, что оно единственно верное.

В прошлом году мы столкнулись практически с тем же самым. Процесс по которому не ведется учет не улучшается потому что вы не знаете, что именно улучшать.

Если на один вопрос вы получаете три разных ответа вопрос задан неправильно. Пишите, если есть вопросы отвечу по мере возможности.

Мы тоже какое-то время назад застряли на том же месте. Решения, работающие в малом масштабе, рушатся при росте, я узнал это слишком поздно.

Прочитал этот ответ и выдохнул: значит, проблема не только у меня. Пытаться сделать это в одиночку — самый дорогой путь.

Это мое мнение, не утверждаю, что оно единственно верное.

Краткое резюме для новичков: Прежде чем принимать решение, посмотрите, какие данные у вас есть.