[ Часть I. Доставка видеоконтента ] [ Часть II. CDN своими руками ]

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

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

Кроме того, имеет смысл «приблизить» контент к пользователю географически. Это связано с пропускной способностью каналов (отсутствием иногда хороших магистральных каналов), а также с разницей в стоимости локального и внешнего трафика для конечного пользователя (например, в регионах РФ).

Такой шаг необходимо сделать при желании выйти на международный рынок, а также при региональном развитии внутри РФ. Сегодня в регионах очень часто самыми популярными сайтами являются региональные порталы, которые предоставляют различные сервисы, в том числе и сервис видеохостинга, а их популярность обусловлена как стоимостью трафика, так и скоростью доступа/временем отклика. Можно представить, что пользователь готов подождать открытия страницы, загрузки плеера, но тяжело предположить, что пользователь согласится смотреть видео, которые прерывается из-за постоянной буферизации, или смотреть вещание, которое доходит до пользователя в виде слайдшоу (после пропуска пакетов остались только опорные кадры видео).

Таким образом, осознав необходимость географической распределенности для контента, мы покупаем/арендуем сервера в непосредственной близости от потребителя: в Европе, США, Украине, Екатеринбурге и т.д.

Сегодня меня заинтересовал опрос надо ли перевешивать SSH на нестандартный порт. Сам опрос не так интересен как способ автора zivot_je_cudo защищать SSH от подбора пароля: после неверной попытки подключения блокировать новые попытки в течение 20 секунд. Задержка, видимо, выбрана эмпирически, исходя их двух противположных пожеланий: чтобы не заблокировать в случае опечатки себя надолго, и в тоже время усложнить жизнь подбиральщика. Я хочу поделиться своим способом противодействия брут-форсу, который применяю уже несколько лет. Он имеет два преимущества:
— дает мне больше попыток для набора правильного пароля
— но при этом блокирует брутфорсеров «навечно».

Как можно достичь этих двух противоположных целей?

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

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

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

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

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

Ни для кого не секрет, что в Unix системах вся информация предоставляется в виде файлов.
В Linux есть файл /proc/kcore, который является «алиасом» на физическую память системы.
Мануалы говорят, что полная длина этого файла — это размер физической памяти (RAM) плюс 4KB, но повертев этот файл на разных системах я пришел к выводу, что размер файла равен размеру RAM + SWAP.
Аналогично этому файлу можно использовать устройства /dev/mem или /dev/kmem, но взаимодействие с ними в данном топике я не буду рассматривать.

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

Я думаю, многие знают о так называемом операторе диапазона, записывающемся как .. (две точки), с помощью которого можно быстро создавать массивы из набора последовательных элементов. Например, следующий код создаёт массив из 35 чисел: 3, 4, 5, …, 37:

my @arr = 3 .. 37;

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

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

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

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

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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

О, коде

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

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

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

Сегодня скинули код, дропающий на машину штатный вирус «отправьте SMS для разблокировки». Предысторию и методику чистки изложил force

Попробовал расковырять. Взял код, отформатировал, стал дебагать… Хм, интересно… В коде идет вызов (после приведения к читабельному виду)

window['eval'](var2);


А вот в var2 — бинарные данные. Ух ты… Но ведь eval не может выполнять бинарные данные!!!

Супервизор сервисов runit позиционируется как замена стандартным скриптам инициализации Unix.

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

Введение

Супервизор берёт на себя такой функционал, как:

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

Для большинства операционных систем runit уже входит в репозитории пакетов (apt-get install runit). Кроме того, мы имеем уже готовый набор рецептов для популярных сервисов (nginx, apache etc.).

Доброго дня, Хабр!
Довольно давно хотел как то автоматизировать закачки с трекеров любимых сериалов. И вот наконец неделю назад чисто случайно наткнулся на довольно интересную софтинку FlexGet.

Мне довольно часто, даже постоянно приходится обращаться к разным базам данных MySQL. Испробовав немало разных GUI клиентов я понял, что они все меня не удовлетворяют. То проблемы с кодировкой, то отсутствует автодополнение кода, то не работает история запросов. В общем пришел я к использованию консольного клиента mysql. И вроде все хорошо, но была пара проблем.
Во-первых заходя в очередную закладку с открытым соединением mysql я тупо смотрел в строку приглашения и старался понять на каком я сервере нахожусь и к какой базе данных подключен. Во-вторых при выводе большого количества полей или при выводе поля с длиной превышающей ширину терминала получалась каша из черточек, букв и палочек :). На днях я покопался в документации и с кое-чем разобрался.

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

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

Введение

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

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

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

Защита (или отсутствие защиты) от различных типов атак демонстрируется на примере протоколов популярных сегодня систем: Assist, Cyberplat, WebMoney, ChronoPay, Robokassa и PayPal (платёжные системы), а также OpenID, OpenAuth, OAuth (децентрализованная аутентификация).

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

Вслед за первой частью, призванной в первую очередь показать, что «не так страшен чёрт, как его малюют»

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

Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.

Недавно на Хабре пробегала новость "Drupal признан 2009 Best Open Source PHP CMS", но недавно наконец были объявлены итоги по всем номинациям и теперь мы можем оценить результаты конкурса.

Это не шутка. 90% от числа позвонивших в нашу компанию остаются с нами и пользуются услугами нашей компании как минимум еще один раз. Я решил не мудрить с теорией и изложить основное тезисами. Уверен, кому-нибудь пригодится. Наш бизнес — такси, однако большинство «ноу-хау» применимы совершенно в любом бизнесе.