Оптимізація Сервера
Надалі в разі потреби буду працювати з ним.
Всім рекомендую - справжній майстер своєї справи.
10/10
На сервері лежать 2 сайти, останнім часом сайти істотно сповільнились і 2/3 рази в день падають з 503 помилкою. Допомагає лише CTRL+ALT+DEL, після чого сайти зазвичай приходять в норму, рідше - хард ресет. Потрібно знайти причину та виправити помилку, оптимізувати сервер для збільшення швидкодії.
Сайти працюють на OpenCart, панель керування хостингом - Plesk
Бюджет: 1500 UAH Термін: 7 днів
Добрий день . Увас досить вражаюча залізяка (судити за посиланням в обговоренні)
Потрібен root ssh доступ і потрібно подивитися детальніше...
Бюджет: 3000 UAH Термін: 1 день
Готов виконати вашу задачу, у мене є досвід налаштування серверів під opencard.
Бюджет: 1000 UAH Термін: 3 дні
Доброго дня налаштую ваш сервер для правильної роботи, потрібен ssh доступ читати логі і т.п. щоб зрозуміти, в чому проблема
Опис проекту: Шукаємо досвідченого 1С-розробника для реалізації CRM-функціоналу (модуль «Звернення») в нетиповій конфігурації 1С. База кастомна, успішно працює і розвивається вже 7 років. Доопрацювання ведуться під контролем Архітектора бази (штатного 1С-програміста), який виступить куратором проекту, погодить архітектуру і проведе Code Review. Ми займаємося продажем шин, дисків та послугами шиномонтажу. Мета модуля — об'єднати всі вхідні канали (Asterisk, сайт, Telegram-бот, агрегатор месенджерів, візити) в єдину систему обробки лідів. Що потрібно зробити: Новий документ «Звернення» — центральне робоче місце менеджера (поля, воронка статусів, UTM-мітки, форма підбору шин). Модуль «Заявка на Самовивіз» — облік точок видачі, слотів часу та статусів готовності товару. Логіка інтеграції з Asterisk — автоприв'язка вхідних/вихідних дзвінків і аудіозаписів до Звернень за номером телефону та часом. Історія взаємодій і KPI — хронологічний реєстр контактів (дзвінки, повідомлення), розрахунок часу взяття в роботу та циклу угоди. Введення на підставі — зв'язок Звернення з накладними, записом на шиномонтаж, бланками зберігання та ТТН. Інтерфейс — єдиний CRM-журнал з кольоровою індикацією, фільтрами та вкладкою історії в картці Клієнта. Докладне і детально опрацьоване Технічне Завдання (ТЗ) надамо кандидатам, які пройдуть первинний відбір. Наші вимоги до виконавця: Відмінне знання керованих форм і архітектури 1С (8.3). Досвід створення нетипових CRM-систем / модулів обліку лідів всередині 1С. Розуміння роботи HTTP-сервісів, Webhook'ів та інтеграцій з АТС (Asterisk) / месенджерами. Чистий, зрозумілий код і вміння працювати в зв'язці з Архітектором бази. Дотримання дедлайнів і адекватна комунікація. Умови роботи: Формат: Віддалена робота через Безпечну Угоду (Seir/Escrow) на Freelancehunt. Бюджет: Готові вислухати ваші оцінки щодо вартості та термінів після ознайомлення з ТЗ. За результатами цього проекту можливе довгострокове співробітництво по наступним завданням та інтеграціям. В відповіді, будь ласка, вкажіть: Ваш досвід роботи з нетиповими (кастомними) конфігураціями 1С. Приклади схожих завдань (CRM-модулі, інтеграції з телефонією або сайтами). Напишіть кодове слово «ШИНА» на початку відповіді, щоб ми знали, що ви уважно прочитали опис проекту. Чекаємо ваших відповідей! Умови оплати: Працюємо строго через Сейф (Freelancehunt) з розбиттям на 3 етапи: Етап 1 (30%): Базова архітектура — документи «Звернення», «Заявка на самовивіз», довідники, введення на підставі. Етап 2 (40%): Логіка інтеграцій — API/HTTP-сервіси (Сайт, Бот), прив'язка дзвінків Asterisk, реєстр взаємодій. Етап 3 (30%): Інтерфейси — робочий стіл CRM, індикація, статистика/KPI, картка клієнта, фінальне тестування. Кожен етап резервується в Сейфі окремо і виплачується після перевірки коду нашим Архітектором бази.
Потрібне автоматичне відображення схеми руху товарно-грошових потоків за приблизним шаблоном наведеним у прикріпленому файлі. Вихідні файли в яких міститься вихідна інформація це файли вивантаження з баз даних в excel.
Потрібна підтримка програми самотуру, серверів каталожників баз данних та серверу онлайну. Серверів баз данних 5 шт
База клієнтів збиралася кілька років із різних джерел, тому телефони записані в різних форматах, один клієнт існує під кількома ID, міста введені вручну різними мовами, область майже ніде не заповнена. Через це неможливо нормально сегментувати базу. Що потрібно зробити: 1. Аудит бази (оплачується окремо, перший етап). Скільки карток, скільки телефонів поза форматом, скільки дублів, скільки унікальних написань міст. За результатом — уточнена оцінка решти робіт. 2. Стандартизація телефонів. Усі номери привести до формату +380XXXXXXXXX. Номери, які неможливо однозначно розпізнати, — не видаляти й не вгадувати, а винести в окремий список. 3. Злиття дублів. Правило: один номер телефону = один ID клієнта. При цьому одному клієнту може належати необмежена кількість номерів. Історія замовлень, email, адреси, теги та кастомні поля мають зберегтися. 4. Розбір карток, на яких «навішано» багато номерів. 5. Міста та області. Назви населених пунктів — з єдиного довідника українською (API Нової Пошти або КАТОТТГ). Область має заповнюватися завжди, щоб одним фільтром можна було вивантажити всіх клієнтів Києва та області, а не окремо Бровари, окремо Ірпінь тощо. 6. Захист від повторного засмічення: нормалізація телефону та міста на вході (форми сайту, інтеграції, ручне введення) + регулярна фонова перевірка нових записів. Вимоги: — практичний досвід роботи з API SIMLA / RetailCRM (v5): вивантаження, оновлення, об'єднання карток, ліміти запитів; — досвід задач з дедуплікації даних; — розуміння українських адресних довідників. Умови роботи: повний бекап до будь-яких змін; спочатку dry-run зі звітом про заплановані зміни на погодження, і лише потім запуск на бойовій базі; лог усіх операцій із можливістю відкату. Без безповоротних видалень без погодження. У відгуку напишіть: — строки та вартість
Потрібно розробити централізовану серверну систему збору та зберігання даних із Planfix, 1С, Meta Ads і Google Ads, а також веб-дашборд для їх відображення та аналізу. Усі дані, історія змін, розрахунки та агреговані показники повинні зберігатися виключно в серверній базі даних. Дашборд не повинен зберігати або дублювати бізнес-дані. Він має отримувати необхідну інформацію із серверної бази через API відповідно до запитів користувача та відображати її у вигляді KPI, графіків, таблиць і деталізованих звітів.