- Зачем давать пароли и какие они нужны
- Стартовый аудит кода и сервера
- У нас старый (11, 12, 13, 14, 15) Битрикс, мы не хотим тратить деньги на обновление / продление
- Оценка задач, малая порция вначале и почасовка потом. Риски при обслуживании чужого кода
- Мониторинг, резервирование и SLA
Суть статьи одной фразой: “если вам нужны доработки сайта, мы попросим у вас все пароли и данные, решим несколько небольших задач, изучим проект, и потом будем готовы к крупным задачам”
Для кого статья? У вас:
-
сайт или интернет-магазин на Битриксе,
-
большое желание развивать сайт, вы хотите доработать-поменять-сделать редизайн-продвинуть;
-
нет постоянной команды разработчиков или вы хотите ее сменить;
-
есть ответственный за сайт, который не боится зайти в админку Битрикса и поставить пару галочек, но “я сам не программист”.
Зачем давать пароли и какие они нужны
Нельзя чинить машину, не открыв капот.
Битрикс (и любой современный веб-фреймворк) позволяет решить любую задачу и очень хорошо, и очень плохо. Есть сотня способов вывести новости на главной странице вашего сайта, не говоря даже об интеграции с 1С или каком-нибудь конфигураторе комплектов. Никакой вменяемый специалист не даст правдивую оценку доработки или исправления логики без доступов к коду и серверу.
Это невозможно.
Впрочем – возможно. Если всегда оценивать доработку как “создание заново”. Согласитесь, это способ потратить ваши деньги впустую.
Может все-таки стоит дать пароль?
Какие пароли нужно дать:
-
Административная панель Битрикса
-
Ftp-ssh доступ к серверу (желательно)
Если у вас есть dev-копия для разработчика, песочница, с точки зрения кода идентичная основному сайту – давайте доступ к ней.
Если вы боитесь давать доступ к своим ресурсам – мы готовы подписать NDA.
Мы гарантируем аккуратную работу специалистов.
Если вы все еще боитесь – сделайте резервную копию сайта и пришлите архив. Мы развернем копию на своей площадке и займемся оценкой.
Важно: смените пароль к админке и базе данных вашего сайта, иначе пароли подойдут и к копии, и к оригиналу.
Стартовый аудит кода и сервера
У стоматолога сначала открывают рот, а потом кошелек.
Иногда сайты сделаны очень странно. Порой разработчики не знают о существовании стандартных компонент и все пишут на php, применяется экзотическая архитектура, все данные хранятся не на сайте, а подгружаются снаружи. В половине случаев сайт жестоко тормозит в отсутствие явных причин к этому.
Вывод: по итогам первичного осмотра сайта мы можем отказаться оценивать задачи до проведения аудита качества кода. Это значит, что нужно сначала понять как все устроено и почему тормозит, а потом начать действовать.
Статьи про аудит: https://www.intervolga.ru/support/tekhnicheskiy-audit-sayta/ и https://www.intervolga.ru/blog/support/bitrix-code_review-audit/
У нас старый (11, 12, 13, 14, 15) Битрикс, мы не хотим тратить деньги на обновление / продление
А можно так оставить? На старом Битриксе?
Можно. По двойной цене и без гарантии.
Теоретически мы можем поддерживать сайты с непродленной лицензией и необновленным кодом ядра 1С-Битрикс.
Категорически не отказываем.
Но практически такой режим работы неудобен и для Заказчика, и для исполнителя:
-
Старые версии программного кода менее понятны для программистов, могут содержать ошибки и устаревшие решения. Решение любой задачи будет на 10-20-50% дольше.
-
Любое обращение в техническую поддержку 1С-Битрикс с вопросами или за устранением проблем будет приводить к ответу “сначала обновите платформу”. Это логично, производитель платформы в новых версиях устраняет старые проблемы, и странно ждать иного пути решения проблем.
Как следствие – если ваш Битрикс старой версии (отличается больше чем на 1 цифру в версии от актуальной), бюджет решения задач будет выше в среднем на 50%.
Рекомендуем обновить лицензию и платформу. Это быстро окупится.
Запросить приобретение любых продлении вы можете по почте alena@intervolga.ru или info@intervolga.ru
Оценка задач, малая порция вначале и почасовка потом. Риски при обслуживании чужого кода
Наш сайт как стена рейхстага – расписался каждый.
Задачи поддержки по определению выполняются на существующем программном коде. В нем минимум 2 слоя: код Битрикса и код первого разработчика.
Бывает как в эпиграфе – слоев много, “на стене рейхстага расписался каждый кто дошел”.
Поэтому мы НЕ можем предсказать время решения задачи до диагностики. Этот тезис часто вызывает споры и недоумение Заказчиков: как так, вы же специалисты?
Рассмотрим пример: Нужно добавить поле “город” в форму заявки и включить его в почтовые уведомления.
Сайт на Битриксе, доступов нет, нужна оценка.
Будем для начала оптимистами.
Сайт на свежем Битриксе, работает на эталонной виртуальной машине, форма сделана на стандартном компоненте “добавление элемента инфоблока” (или на веб-формах), изменение включает 1 час на настройки и правку верстки, 1 час на добавление поля в код и 30 минут на оргвопросы.
Итог 2.5 часа.
Теперь представим что может оказаться в реальности:
-
Там 12 версия платформы Битрикс;
-
Вместо эталонной виртуальной машины на CentOS применяется windows+IIS или docker;
-
Места на сервере 1 мегабайт, бекап снять нельзя;
-
Форма написана без компонентов на API Битрикс или чистом PHP или
-
Форма вообще сделана не на Битриксе и вставляется внешним кодом;
-
Параллельно с нами над сайтом работает еще 2 команды и они не используют git (на самом деле если они используют git, ситуация не намного проще – погружение в чужую логику работу и внедрение процедуры “деплоя” (выгрузки, публикации) кода на сервер трудоемко);
-
Форма отображается не только на desktop-экранах, но и многих мобильных устройствах, та же верстке внедрена в мобильное приложение и менять ее просто так опасно;
-
Javascript формы заказа задействован еще в нескольких местах и при изменениях все непредсказуемо ломается.
Можно продолжать.
Каждый пункт из списка выше добавит несколько часов (а то и дней) к реальным затратам времени.
Поэтому во всех случаях, когда сайт делала не ИНТЕРВОЛГА, мы перед приемом сайта на обслуживание делаем аудит качества кода, а потом начинаем с небольших задач.
Это позволит выдерживать сроки.
Мы не даем необоснованных наивных обещаний.
Мониторинг, резервирование и SLA
У нас мигалка работает?
Работает… не работает… работает… не работает...
В идеальном мире сайты не ломаются, место не кончается, жесткие диски не разрушаются, сервера не виснут.
В реальности причиной остановки работы интернет-магазина может быть много причин, и ошибки программистов – только одна из них.
Если вы хотите повысить доступность интернет-ресурса хотя бы до 99% времени (лучше, конечно, еще несколько “девяток”), нужно:
Культура – значит:
- отдельный сервер разработки для каждого программиста (песочницу);
- сервер тестирования (stage, test);
- процесс тестирования (сценарии тестирования общие и частные, выделенный человек и время на это);
- режим публикации (цикл релизов);
режим работы с hotfix’ами.
Хотфикс – срочное изменение, которое в обход стандатных процедур было выполнено прямо на боевом сайте.
В реальной активной работе это неизбежно, важно эти хотфиксы корректно потом включать в тестовую среду или осмысленно перезатирать.
B. Установить режим снятия и (ВАЖНО!) развертывания резервных копий.
Это может делаться автоматически, может – вручную. Отвечать за бекапы может сотрудник Заказчика или мы, но это процесс должен быть осмыслен, реализован, запущен и протестирован. Многие владельцы сайтов не знают что резервные копии неполны или хранятся на том же сервере (то есть удалятся вместе с сайтом).
Даже если копия в порядке, она часто требует нескольких часов для развертывания и не включает настройки сервера и регулярных задач.
C. Создать систему мониторинга работы сайта.
Мониторинг следит за нагрузкой, свободным местом, доступностью отдельных сервисов, посещаемостью, заказами. Эта система не требует больших расходов, но видит кучу мелочей, которые нужно своевременно исправлять.
Можно без этого всего жить? Да, но доступность сайта не превысит 90% времени и в какой-то момент сайт может погибнуть совсем. Просто на хостинге разрушится файловая система и никто ничего не сможет сделать.
Прекрасно, если вам IT-департамент решит вопросы А, В, С. Если нет – мы готовы поддерживать сайты по соглашению о качестве обслуживания – SLA.
Статьи по теме
