Установка скрипта на хостинг пошаговая инструкция

Здравствуйте, дорогие читатели блога web-zarabotok.info.

Хотите иметь свою инвестиционную игру? Хотите почувствовать себя в роли администратора проекта? А не знаете, как правильно установить скрипт? Не переживайте… В этой статье я всё подробно об этом расскажу.

Итак, поехали…

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

А мы двигаемся дальше…

Как установить скрипт на хостинг?

Мы скачали готовый скрипт, который находится в архиве. Открываем его и копируем все файлы в отдельную папку. Далее, нам нужно купить себе хостинг и домен. Я пользуюсь Hostia. Качественный, надёжный и что главное, очень дешёвый. Одним словом «Рекомендую».

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

Мой хостинг поддерживает Direct Admin, но знайте, что у вас может быть совсем другая система управления (например: ISPManager, ZPanel, WHM/CPanel).  Если у вас одна с них, то в этом нет ничего страшного. Весь процесс установки скрипта ничем не отличается.

Инструкция установки скрипта (инвестиционной игры, хайпа, букса)

Шаг 1. Заливаем сам скрипт на хостинг

Для этого нам понадобится одна с программ: [urlspan]FileZilla[/urlspan] (рекомендую), [urlspan]Total Commander[/urlspan] или [urlspan]Notepad++[/urlspan]. Скачиваем любую себе на компьютер, запускаем и создаем подключение по FTP. Забыл сказать, что панели управления хостингом также имеют «встроенный» загрузчик файлов. Можете воспользоваться им. Я, выбрал для себя FileZilla. Программа стабильна в работе и полностью бесплатна.

Что касается FTP, то здесь нам понадобятся некие данные, которые без проблем, можно узнать у своего хостера:

1. Логин.
2. Пароль.
3. IP Адрес.

Если будут проблемы с входом в админку, напишите в комментарии. Помогу!

Дальше открываем папку со скриптом и указываем путь для заливки на хостинг: /domains/ваш домен/public_html/скрипт. Например, у меня это выглядит так (использую FileZilla):

Ждём завершение загрузки…

Шаг 2. Создаем базу данных

Переходим в раздел «Базы данных (MySQL)» и нажимаем «Создать новую» или «Создать базу данных». Прописываем имя и пароль. Поля: Имя Базы Данных и Имя Пользователя БД можно заполнить одинаково. Внимание! Логин и пароль запомните или где-нибудь запишите. Они нам понадобятся, когда будем изменять файл config. На примере покажу, как это выглядит в Direct Admin. Смотрите:

Шаг 3. Импортируем SQL в нашу базу данных

[adsense1] Каждый скрипт имеет файл в формате «SQL». Возможно, могут быть исключения и такового файла попросту нет. Не знаю, у меня такое не встречалось. Но! Если вам так повезло, то просто-напросто пропускайте его (смотрите Шаг 4).

Сейчас нам нужно найти в своем личном кабинете «[urlspan]PhpMyAdmin[/urlspan]». Утилита служит для импорта или редактирования баз СУБД MySQL. Заходим в неё, подключаемся (если нет аккаунта, то обязательно проходим несложную регистрацию).

Заходим, и слева видим список созданных нами баз данных. Выбираем ту, которую создали во втором шагу. А дальше все делаем по скриншотам:

Шаг 4. Изменяем файл config

В папках скрипта ищем файл с названием config. В хайпах ищите файл в папке «classes». Нашли? Отлично! Открываем его. Видим:

public $HostDB = «localhost»;
public $UserDB = «Имя Пользователя БД»;
public $PassDB = «пароль»;
public $BaseDB = «Имя Базы Данных»;

Заменяем свои данные и сохраняем. Этим самым, мы подключили скрипт к нашей базе данных.

Всё друзья! Я вас поздравляю! Скрипт полностью установлен!

А сейчас небольшое дополнение…

Бесплатные скрипты с интернета зачастую бывают с дырами. Будьте осторожны! Проверяйте файлы на вирусы. Также удалите все дополнительные ссылки в файлах скрипта. Зачастую они выглядят так:

Вот и всё, чем хотел сегодня с вами поделиться. Надеюсь, что статья вам помогла.

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

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

Под кодом страницы обычно подразумевается совокупность элементов на языке разметки HTML, которые служат для ее форматирования и отображения в удобном виде. Чаще всего употребляется вариант названия – HTML-код. Просмотреть код любой веб-страницы можно прямо в браузере.

Для создания страниц необходимо использовать языки веб-программирования. Среди них наиболее широко распространены PHP, Python и Ruby on Rails для Unix-систем, а для Windows характерна разработка динамического контента с использованием средств .NET. Это все касается серверной части, а для программирования на клиентской стороне чаще всего используется JavaScript. Подробнее об этом поговорим в статье ниже.

<script>...</script> с атрибутом src="".
<script src="/js/neiros.js"></script>

<script src="https://neiros.ru/js/neiros.js"></script>

<h1><?php echo 'Заголовок' ?></h1>

<?php echo 'Слон<br>Наполеон'; ?>

<div><?php echo 'Строка1' ?></div>
<span><?php echo '<strong>Строка2</strong>' ?></span>

<div class="result"></div>
<script>
$(document).ready(function() {
$(".result").load("/main.php");
});
</script>

Нашли ошибку в тексте? Выделите нужный фрагмент и нажмите
ctrl
+
enter

В данной статье показан процесс загрузки и запуска скриптов ботов на бесплатный хостинг.

С инструкцией подвязки скриптов ботов можно ознакомиться по ссылкам:
Для страничных ботов studio-petukh.ru/article?id=50
Для ботов на сообществах studio-petukh.ru/article?id=26

Переходим к установке скрипта на хостинг. Им может быть как платный или бесплатный хостинг, линуксовый или виндовый VPS/VDS, домашний ПК и т.д.

В данной статье пример установки будет показан на беслатном хостинге https://www.pythonanywhere.com/. Данный хостинг идеально подойдет для начального уровня. Из его минусов можно назвать необходимость раз в 2-3 дня перезапускать скрипты.

Итак: перейдя по ссылке сперва нужно будет создать учетную запись. Нажимаем в правом верхнем углу на «Log in» (Рисунок 1). Затем жмём на «Sign up here!» (Рисунок 2). Затем жмём на «Create a Beginner account» (Рисунок 3) и проходим регистрацию.

После создания учётной записи переходим во вкладку «Consoles» и выбираем Bash консоль (Рисунок 4).

В Bash консоли необходимо установить необходимые библиотеки для работы скрипта бота. В базовых скриптах требуется только установка библиотеки vk_api. Вбиваем в консоли команду pip3.9 install —user vk_api (Рисунок 5), жмём Enter и ждём установки библиотеки. Если необходимы ещё бибиотеки, то вместо vk_api указываем название необходимой библиотеки.

После установки всех необходимых библиотек закрываем данную консоль, нажав на крестик в списке запущенных консолей и переходим к соседнему каталогу «Files».

В каталоге «Files» загружаем нужный скрипт с ботом нажав на кнопку «Upload a file». После загрузки файла со скриптом в списке файлов нажимаем на него. Откроется редактирование файла, если ранее не указали в скрипте id и токен от страницы, то делаем это сейчас. После того как скрипт будет готов к запуску, нажимаем на кнопку «Run» (Рисунок 6) и ждем запуска скрипта в консоли. Если вместо консоли появится сообщение о лимите одновременно запущенных консолей, то во вкладке «Consoles» закрываем ранее запущенные консоли и повторяем действие.

После всех верно-проделанных действий наслаждаемся работой собственного бота.

• Использование готовых скриптов
• Написание простейшего CGI-скрипта
• Просмотр установленных модулей PERL
• Установка дополнительных модулей PERL
• Возможные ошибки

1. Использование готовых скриптов

Если у вас уже есть написанные CGI-скрипты, то прежде чем скопировать их на сервер, вы должны сделать следующие действия:

• Убедиться, что в скриптах указан правильный путь к интерпретатору:

Perl: /usr/bin/perl
Python: /usr/local/bin/python

• Если вашему скрипту требуется доступ к базе данных MySQL, то необходимо указать параметры доступа (см. статью Подключение к серверу MySQL)
• В разделе Управление веб-сервером панели управления хостингом включить модуль CGI.

Теперь вы можете скопировать свои скрипты на сервер.
Загружать файлы необходимо в каталог ваш_домен/cgi. Файлы из данного каталога будут доступны по адресу http://ваш_домен/cgi-bin/имя_файла. Для того чтобы CGI-скрипты запускались из корневого каталога сайта ваш_домен/docs, необходимо создать в нем файл .htaccess со следующим содержимым:

AddHandler cgi-script .cgi .pl .py
Options +ExecCGI

На скрипты необходимо установить права доступа 755 или -rwxr-xr-x.
Права доступа можно изменить с помощью файлового менеджера панели управления.

2. Написание простейшего CGI-скрипта

Рассмотрим написание простого CGI скрипта на Perl.
Если вы работаете под управлением ОС «Windows», то для работы с кодом скриптов вам необходимо использовать специализированный текстовый редактор, например, Notepad++. Стандартную для Windows программу «Блокнот» лучше не использовать. Для демонстрации работы CGI скрипта необходимо создать два файла. Первый файл представляет собой html-документ с формой ввода текста:

            <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
              <html>
              <head>
               <meta http-equiv="Content-Type" content="text/html; charset=windows-1251">
               <title> Пример работы с Perl</title>
              </head>
              <body>
                <form method='post' action='/cgi-bin/hello.pl'>
                  Введите ваше имя:<input type='text' name='name'>
                  <input type='submit'>
                </form>
              </body>
              </html>

Второй файл является CGI-скриптом

#!/usr/bin/perl
use CGI;
print "Content-type: text/htmlnn";
$my_cgi = new CGI;
$your_name = $my_cgi->param('name');
print "Hello $your_name!!!";

Первый файл вы можете разместить в каталоге ваш_домен/docs. Второй файл вы должны разместить в директории ваш_домен/cgi. Обязательно проверьте права на ваш CGI-скрипт. Они должны быть установлены в значение -rwxr-xr-x или 755.

3. Просмотр установленных модулей PERL

Для проверки установленных PERL-модулей необходимо последовательно выполнить следующие действия:

• Подключитесь к хостингу по SSH и выполните команду:

vim modules.pl

Таким образом будет создан файл modules.pl

• Теперь необходимо его отредактировать, для этого нажмем Insert, напишем следующее:

Для выхода из редактора с сохранением только что набранного текста, нажимаем Esc и затем :wq

• Можем посмотреть установленные модули:

perl ./modules.pl

4. Установка дополнительных модулей PERL

Вы можете установить на хостинг дополнительные модули PERL из исходных кодов. Прежде чем приступать к установке, подключите последнюю версию PHP в разделе Управление веб-сервером → Управление модулем PHP панели управления хостингом, при этом будет подключен обновленный набор программного обеспечения, который может включать в себя нужный вам модуль Perl.
Перед установкой требуется задать переменные окружения, чтобы установленные модули были доступны интерпретатору.

• Для этого подключитесь к хостингу по SSH и создайте в домашнем каталоге файл .bashrc с помощью команды:

• Чтобы изменения вступили в силу, выполните команду:

source ~/.bashrc

Для того чтобы установить выбранный модуль для PERL, необходимо выполнить следующую последовательность команд:

• на странице http://search.cpan.org/ найдите нужный модуль, например, Net::SMPP и скопируйте ссылку для загрузки архива с исходными кодами модуля,
• подключитесь к хостингу по SSH и перейдите в каталог для временных файлов

cd ~/tmp

• загрузите архив на хостинг по найденной ссылке с помощью wget

wget http://search.cpan.org/CPAN/authors/id/S/SA/SAMPO/Net-SMPP-1.12.tar.gz

• распакуйте архив и перейдите в каталог с исходными кодами модуля

tar -xf Net-SMPP-1.12.tar.gz
cd Net-SMPP-1.12

Установку необходимо выполнять в отдельный каталог, например, /home/login/PERL, где login — идентификатор услуги хостинга, указав переменную INSTALL_BASE.

• Для установки модуля с помощью файла Makefile.PL используйте команды:

perl Makefile.PL INSTALL_BASE=$HOME/PERL
make
make install

• Для установки модуля с помощью файла Build.PL используйте команды:

perl Build.PL
./Build --install_base $HOME/PERL
./Build install --install_base $HOME/PERL

Для использования установленных модулей в perl-скрипте нужно их подключить, добавив следующие строки в файл скрипта:

use lib "/home/login/PERL/lib";
use lib "/home/login/PERL/lib/perl5";
use Net::SMPP;

Для того чтобы веб-сервер Apache мог работать с дополнительными модулями, необходимо в панели управления хостингом включить модуль env_module и добавить следующие строки в файл .htaccess в корневом каталоге сайта или в каталоге с CGI-скриптами:

SetEnv PERL5LIB /home/login/PERL/lib:/home/login/PERL/lib/perl5

где login — идентификатор услуги хостинга.

5. Возможные ошибки

Ошибка 403

Если при обращении к скрипту вы видите сообщение об ошибке 403, это значит, что на скрипт установлены некорректные права доступа. На CGI-скрипты необходимо установить атрибут исполнения (права доступа 755 или -rwxr-xr-x). Атрибуты можно изменить с помощью файлового менеджера панели управления.

Ошибка 500

Если во время запуска своего скрипта вы видите сообщение о 500-ой ошибке, это значит, что в скрипте есть ошибка из-за которой транслятор Perl’а не может успешно завершить свою работу. Ошибка может быть как синтаксическая (например, вы забыли где-то закрыть кавычку или фигурную скобку), так и логическая, например, в результате каких-либо ваших действий происходит деление на ноль. Для того, чтобы понять причину ошибки, вам необходимо посмотреть лог-файлы веб-сервера, которые хранятся в каталоге /var/log/.

Как подключить скрипт на сторонний сайт

Привет, Хабр! Это первый пост в нашем блоге. Многие знают нас как чат для сайта, именно с него мы начинали, а сейчас занимаем лидирующие позиции в сфере бизнес-мессенджеров. Мы постепенно эволюционировали в комплексное бизнес-решение, которое предоставляет множество возможностей для клиентов: callback, общение с клиентами через мессенджеры, соцсети, мобильные приложения, виртуальная АТС, CRM-функции и многое другое.

За несколько лет мы успешно решили множество технических проблем, накопили много интересного, а местами и уникального опыта, конечно же, писали свои костыли и велосипеды. Этим постом мы начинаем серию статей, в которых будем делиться своим опытом разработки, выстраивания процессов в полностью удаленной команде, расскажем про нашу архитектуру, технические решения, которые позволяют нам эффективно обслуживать сотни тысяч клиентов по всему миру.

Jivosite сегодня это:

• 250К клиентов по всему миру;
• 150М показов виджета в сутки;
• 3.5М сообщений в сутки;
• 10М чатов в месяц;
• 1М одновременных коннектов;
• 250+ серверов в production.

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

Входная точка

Театр начинается с вешалки, а подключаемый сервис с кода-вставки. Он является входной точкой для любого сервиса или модуля на сайт. Как правило, его можно найти в инструкции установки, после чего необходимо добавить его в HTML-код сайта, а дальше происходит «магия», которая определенным образом загружает и инициализирует скрипт.

<script src="https://site.com/file.js"></script>

Казалось бы, что может быть проще подключения скрипта на сайт? По стандарту, необходимо просто добавить тег script в HTML-код страницы. Но на самом деле это важный этап, скрывающий много подводных камней. Например, идентификация пользователя, реализация резервного канала загрузки скрипта, настройка внешнего вида или логики, скорость загрузки страницы и так далее. Но давайте обо всем по порядку.

Идентификация

Просто так подключать скрипт мало кому интересно, наверняка скрипт выполняет какую-либо логику, а эта логика привязана к пользователю. Например, ID счетчика, APP_ID от соцсети, в нашем случае это ID созданного канала связи. То есть скрипт должен идентифицировать пользователя в запросах на сервер. Для идентификации клиента через код-вставки есть три варианта реализации.

Вариант #1

<script async src="https://site.com/file.js?id=123"></script>

Передавать ID прямо в ссылке на файл и на стороне сервера каким-либо способом прокидывать его в скрипт. В этом случае серверу на лету придется прописывать ID в файл или формировать JS-строку c ID, которая будет загружать file.js. Эта логика похожа на реализацию JSONP-запросов.

Долгое время мы работали по такому принципу, но минусы этого подхода в том, что добавляется «холостая» нагрузка на сервер и необходимость реализации серверного кэширования.

Вариант #2

<script src="https://site.com/file.js" [async]></script>
<script type=”text/javascript”>
	window.serviceNameId = “123”;
	//или
	ServiceNameModule.init({id: “123”});
</script>

Атрибут async — говорит браузеру о том, что не нужно дожидаться загрузки скрипта для построения DOM, скрипт надо выполнить сразу после загрузки. Это уменьшает время загрузки страницы, но есть и обратная сторона медали: скрипт может выполняться до того, как DOM будет готов к работе.

Одна из самых популярных реализаций, так делают в том числе и крупные сервисы, отличается только синтаксис, но суть у всех одна.

У такого подхода есть два основных минуса, первый — усложняется код-вставки, а второй — очень важен порядок выполнения данного кода, в противном случае ничего работать не будет. К тому же необходимо делать выбор между скоростью (async) и стабильностью (без async), большинство выбирают 2-й вариант.

Вариант #3

<script async src="https://site.com/file.js?id=123"></script>

Аналогично первому варианту передавать ID в ссылке на файл, но извлекать его в браузере, а не на сервере. Это не так просто, как кажется, но возможно. В API браузера есть свойство document.currentScript, оно возвращает ссылку на скрипт, который загружен и в данный момент выполняется в браузере. Зная это, можно вычислить ID, для этого надо получить свойство document.currentScript.src и регуляркой вытащить из него ID.

Есть одно но: document.currentScript поддерживается не всеми браузерами. Для браузеров, не поддерживающих это свойство, мы придумали интересный хак. В коде file.js можно выбросить специальное «фейковое» исключение, обернутое в try/catch, после чего в стеке ошибки будет URL скрипта, в котором произошла ошибка. URL будет содержать ID, который мы получаем той же регуляркой.

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

Настройки

В большинстве случаев у подключаемых скриптов есть какие-либо настройки, отвечающие за внешний вид или логику работы. Эти настройки необходимо «прокидывать» в подключаемый скрипт, для этого существуют два принципиально разных подхода.

Подход #1

<script async src="https://site.com/file.js"></script>
<script type=”text/javascript”>
	window.serviceName = {color: “red”, title: “Заголовок”, ...};
	//или
	ServiceNameModule.init({color: “red”, title: “Заголовок”, ...});
</script>

К этому подходу также относится передача настроек в GET параметрах url скрипта, аналогично варианту #1 из раздела «Идентификация». Подход заключается в том, что если клиент хочет поменять настройки, то ему необходимо отредактировать код-вставки и обновить его на сайте.

Это хорошо тем, что все настройки хранятся на клиенте и их не надо хранить на сервере, разрабатывать и обслуживать всю связанную с этим бизнес-логику. Главным минусом такого подхода является неудобство для клиента, ему приходится все делать вручную, а если настроек много, то код-вставки превращается в сложно поддерживаемую простыню, в которой легко допустить ошибку. А чтобы обновления вступили в силу, надо обновлять сайт, это лишние телодвижения разработчиков и админов.

Подход #2

<script async src="https://site.com/file.js?id=123"></script>

Второй подход заключается в том, что в случае необходимости изменения настроек клиенту не надо модифицировать код-вставки, все настройки хранятся на сервере. Для того чтобы поменять настройки, надо зайти в графическую панель, изменить нужные параметры и нажать кнопку «Сохранить». После этого настройки автоматически применятся для его сайта!

Не надо разбираться в коде и делать ради этого деплой, этим может заниматься человек, далекий от JavaScript, например менеджер. Конечно для пользователей такой вариант гораздо удобнее и проще, поэтому именно его мы используем. Но за удобство надо платить, такой подход требует разработки и поддержки логики на сервере и подразумевает дополнительную нагрузку на него. В следующих статьях мы обязательно расскажем, как мы ежедневно обрабатываем 150М таких запросов.

Обратная совместимость

Очень важно максимально быстро прийти к зрелой версии кода-вставки. Потому что обновлять уже установленные коды-вставки будет крайне сложно. Пример из нашей практики: в первых версиях мы использовали числовые ID, но по соображениям безопасности заменили их на число-буквенные. Оказалось, что очень сложно добиться изменения уже установленного кода-вставки. Многие даже не знают, что такое HTML и как устроены сайты. Например, сайт делали фрилансеры, студия или сайт создавался через CMS/конструктор и т. д. В большинстве случаев наши клиенты работают только с панелью настроек виджета. С тех времен у нас до сих пор в nginx работает мапа реврайта старых ID на новые, в которой около 40К записей.

....
/script/widget/config/15**90 /script/widget/config/bqZB**rjW5;
/script/widget/config/15**94 /script/widget/config/qtfx**xnTi;
/script/widget/config/15**95 /script/widget/config/fqmpa**4YX;
/script/widget/config/15**97 /script/widget/config/Vr21g**nuT;
/script/widget/config/15**98 /script/widget/config/8NXL5**F8E;
/script/widget/config/15**00 /script/widget/config/Th2HN**6RJ;
....

Из-за этой особенности мы вынуждены сохранять обратную совместимость кода-вставки при всех рефакторингах, которых на нашей памяти было около 5.

Изоляция кода

Так как скрипт подключается на сторонний сайт, на котором уже есть JavaScript и CSS код сайта и других сервисов, первостепенной целью является не навредить сайту, чтобы наш код не изменил логику, а тем более не сломал ее. Это может быть JavaScript-ошибка, которая останавливает поток выполнения, или стили, которые переопределяют стили сайта. Но и код сайта может саффектить подключаемый скрипт, например используется библиотека которая модифицирует браузерное API, после чего код перестает работать или работает не так, как мы ожидаем.

<script type="text/javascript">
   // код mootools.js
   var JSON = new Hash({
       encode: function () {},
       decode: function () {}
       // ...
   });
   // код подключаемого скрипта
   JSON.parse(json); // Uncaught TypeError: JSON.parse is not a function
</script>

<style type="text/css">
   // код библиотеки или разработчика сайта
   body * {
       padding: 20px;
   }
   form input {
       display: block;
       border: 2px solid red;
   }
</style>

Есть разные варианты изоляции кода. Например можно использовать префиксы в JS переменных, замыкания, чтобы не засорять глобальный контекст, использовать что-то наподобие БЭМ для стилей. Но самый простой способ — это выполнения кода в iframe, он решает большинство проблем изоляции, но накладывает определенные ограничения. Мы используем гибридный вариант, про изоляцию кода расскажем подробнее в следующих статьях.

Блокировка загрузки сайта

Событие onload — наступает после того, как веб-страница полностью загружена, включая изображения, стили и внешние скрипты. Важная особенность в том, что на большинстве сайтов JS-логика, сторонние скрипты и реклама начинают работать по наступлению этого события. Очень важным пунктом для всех подключаемых скриптов является не допустить негативного влияния на это событие.

Это происходит в тех случаях, когда сервер, с которого грузится скрипт, отвечает долго или вовсе не отвечает: тогда событие onload откладывается и дальнейшая загрузка страницы по сути блокируется. В случае, когда сервер недоступен, событие onload наступит только по истечении таймаута запроса, который больше 60 с. Таким образом, проблемы на сервере отдачи скрипта по сути «ломают» сайты, что является недопустимым.

Личный опыт
В прошлом я работал в компании, у которой был сайт с одновременным онлайном 100К, онлайн-знакомства. В те времена были попопулярны кнопки «Поделится в соцсетях». Чтобы они появились на сайте, надо было подключить скрипт (sdk) от нужных соцсетей. В один прекрасный день к нам прибежали коллеги и сказали, что наш сайт не работает! Мы посмотрели в мониторинги, в которых все было нормально, и сначала не поняли, в чем проблема. Когда начали разбираться глубже, поняли, что cdn-сервера Twitter прилегли, и их SDK не мог загрузиться, это блокировало нам загрузку сайта на ~1.5 минуты. То есть после открытия сайта загружался небольшой HTML(остальное SPA) и только через 1.5 минуты все прогружалось, срабатывал тот самый таймаут запроса. Нам пришлось экстренно организовывать хотфикс и убирать их скрипт с сайта. После повтора этой ситуации мы решили убрать блок «Поделиться» совсем.

В первых версиях кода-вставки у нас не было это учтено, и в случае технических проблем на нашей стороне мы, мягко говоря, доставляли неудобства нашим клиентам, но со временем мы это исправили.

Решение

<script type='text/javascript'>
   (function(){
       var initCode = function () {
         // insert script tag
       };
       document.readyState === 'complete' ?
           initCode() :
           w.addEventListener('load', initCode, false);
   })();
</script>

Решение простое, надо подписаться на событие полной загрузки сайта и только потом загружать скрипт, для этого надо использовать код-вставки, а не тег script.

Google Pagespeed

Результаты анализа мобильной версии habr.com

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

Это означает, что надо использовать современные техники оптимизации загрузки страниц. Например использовать Gzip, кешировать статические файлы и запросы, использовать асинхронную загрузки скриптов, сжатие статики современными алгоритмами такими как WebP/Brotli/etc и использовать другие оптимизации. Мы регулярно проводим аудит и реагируем на предупреждения и рекомендации, чтобы соответствовать современным требованиям.

CDN

В первых версиях мы загружали статику с серверов приложения. Но у такого подхода есть минусы: дорогой трафик, удаленность от посетителей сайтов и излишняя нагрузка на канал серверов. Можно легко забить канал серверов приложения при хабр-эффекте сайтов, так как трафик статики очень «тяжелый».

С целью экономии бюджета, стабильности и уменьшения сетевой задержки оптимально загружать статику со специально предназначенных для этого серверов. Можно использовать готовые CDN-провайдеры, но на больших масштабах это недешево и приходится ограничиваться возможностями, которое предоставляет тот или иной провайдер.

Мы реализовали это просто, заказали недорогие сервера в России, Европе и Америке с безлимитным трафиком и широким каналом. Это дешево, не накладывает на нас никаких ограничений, мы можем настроить все под себя, а отказоустойчивость обеспечивается за счет механизма, работающего в браузере. В данный момент с наших CDN-серверов загружается 1ТБ статики ежедневно.

Отказоустойчивость

К сожалению, мир не идеален, случаются пожары, аплинки падают, ДЦ целиком уходят под воду, РКН блочит подсети, а люди совершают ошибки. Тем не менее, необходимо уметь обрабатывать такие ситуации и продолжать работать.

Мониторинг
Сначала надо понять, что что-то пошло не так. Можно, конечно, подождать, пока пользователи придут и пожалуются, но лучше настроить мониторинг и алерты, а после релизов, проверять все ли в порядке. Мы мониторим много различных параметров, как серверных, так и клиентских, и если что-то пошло не так, мы сразу это видим. Например, уменьшилось количество загрузок виджета или аномальный всплеск трафика на CDN-серверах.

Суммарное кол-во загрузок виджета по каждой версии

Сбор ошибок
JavaScript очень специфичный язык, и допустить в нем ошибку несложно. К тому же зоопарк браузеров в современном вебе очень большой; то, что работает в последнем Chrome, не факт, что будет работать в Safari или Firefox. Поэтому очень важно настроить сбор ошибок из браузера и вовремя реагировать на всплески. Если ваш код работает в iframe, то сделать это можно отслеживая глобальный обработчик window.onerror и в случае ошибки отправлять данные на сервер. Если код работает вне iframe, то реализовать сбор ошибок очень сложно.

Суммарное кол-ва ошибок со всех сайтов и браузеров

Информация по конкретной ошибке

CDN Failover
Выше я уже писал, что все имеет свойство падать, поэтому важно обрабатывать эти ситуации и лучше — автоматически. Мы прошли несколько этапов фаллбека CDN-серверов, начинали с ручного, а в итоге нашли способ делать это автоматически и оптимально для браузера.

В ручном режиме это работало просто: админам приходило СМС о том что CDN прилег, они совершали определенные манипуляции, после чего виджет начинал загружаться с серверов приложения. Это могло занять от 5 минут до 2 часов времени.

Для реализации автоматического фаллбека необходимо как-то детектить, что загрузка скрипта началась, но сделать это не так просто, как кажется. Браузер не дает возможности отслеживать промежуточные состояния загрузки тега script, как например событие onprogress в XMLHttpRequest, а сообщает только событие по окончанию загрузки и выполнения скрипта. Также нельзя за приемлемое время узнать, что сервер в данный момент недоступен, единственное событие onerror срабатывает по истечении таймаута запроса, больше 1 минуты. За минуту посетитель может уже покинуть страницу, а скрипт так и не загрузится.

Мы пробовали разные варианты, простые и сложные, но в итоге пришли к решению с ping-запросом CDN-сервера. Работает это так: мы сначала пингуем CDN-сервер, если ответил, то тогда мы загружаем виджет с него. Чтобы реализовать эту схему оптимально для браузера и наших серверов, мы используем легкий HEAD-запрос (без тела), а при последующих загрузках мы его не делаем, пока не обновится версия виджета, т. к. виджет уже в кеше браузера.

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

Loader

Чтобы загрузить свой скрипт на сторонний сайт, надо учесть множество моментов, но реализовать эту логику в коде-вставки сложно, так как он просто превратится в «мясо». Но делать это все равно надо, для этого мы создали небольшой модуль, который управляет всей этой логикой «под капотом» и загружает основной код виджета. Он загружается в первую очередь и реализует CDN Failover, кеширование, обратную совместимость со старыми кодами-вставки, А/Б тестирование, постепенную выкладку новой версии виджета и множество других функций.

Таким образом поэтапно мы пришли к схеме, которая покрывает основные кейсы загрузки и инициализации виджета. Она доказала свою эффективность за годы использования на большом количестве различных сайтов. При этом код-вставки остается простым и универсальным, так как в нем нет никакой логики и мы в любой момент можем ее поменять, при этом не заставляя пользователей менять код-вставки.

Сторонние сервисы

Ну и напоследок стоит упомянуть про сторонние сервисы, которые подключаются на сайт или каким-либо образом взаимодействуют с сайтами: поисковые боты, аналитика, различные парсеры и так далее. Эти сервисы оставляют отпечаток на работе, про это тоже не стоить забывать. Расскажу несколько случаев из нашей практики.

GoogleBot
В нашем приложении оператора есть функция «Посетители», в которой можно посмотреть посетителей, в данный момент просматривающих сайт, и различную информацию по ним: время на сайте, страницу, число просмотренных страниц и так далее. В определенный момент клиенты начали жаловаться, что у них «висят» посетители с других сайтов, то есть на сайте по продаже айфонов, клиент, у которого якобы открыта страница «Купить крем для лица». Когда начали разбираться, выяснили, что это GoogleBot, который при переходе от сайта к сайту кешировал LocalStorage первого и впоследствии передавал неправильные данные на сервер.

Решение простое, на сервере начали игнорировать данные от GoogleBot.

Яндекс.Метрика
В метрике есть замечательная функция — вебвизор, которая позволяет посмотреть, что видел и делал пользователь, в виде скринкаста. Для этого метрика записывает все действия пользователя, а после специальный бот метрики ходит по сайтам, совершает те же действия и записывает это. Проблема была в том, что для эмуляции мобильного браузера пользователя, по нашим данным, включался Firefox в режиме мобильной эмуляции, но при этом userAgent у бота был десктопный.

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

Примеров намного больше, но, думаю, этого будет достаточно для понимания сути.

Заключение

Надо очень внимательно относиться к коду, который вы отдаете клиентам для вставки на сайт. Мы кратко рассказали, с какими проблемами мы столкнулись и как их решали. В следующих статьях мы более подробно расскажем про некоторые упомянутые темы и другие участки нашей системы, например, как мы используем NodeJS в качестве бэкенда, как держим нагрузку всех 270К сайтов за счет продуманного кеширования и не боимся хабра-эффекта подключенных к нам сайтов, как работаем в полностью распределенной команде и многое другое.

Спасибо за внимание, будем рады ответить на ваши вопросы и комментарии!