Всем привет!

Бывало ли у вас такое, что ставите файл на закачку, и скорость медленно, но верно возрастает, затем, в какой-то момент, резко снижается, затем опять возрастает? Закачка файла в один поток не обеспечивает полную скорость канала? Запускаете торрент-клиент, и пинг в игре сильно прыгает? Используете 3G-модем (или другую линию с относительно большой потерей пакетов) и не можете это терпеть?
Наверняка вы винили во всем ваш роутер, либо обвиняли своего провайдера в кривой настройке шейпера? Это влияет, но виноваты не они.
Итак, встречайте:

TCP Congestion Control, или TCP Congestion Avoidance Algorithm.

IOPS (количество операций ввода/вывода – от англ. Input/Output Operations Per Second) – один из ключевых параметров при измерении производительности систем хранения данных, жестких дисков (НЖМД), твердотельных диски (SSD) и сетевых хранилища данных (SAN).

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

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

Много лет подряд в качестве системы контроля версий для большого количества проектов использовали только SVN. Но наступил момент, когда количество разработчиков на одном из проектов заметно увеличилось, проект уже запущен в работу, и нужно как активно разрабатывать параллельно несколько фич, так и фиксить уже имеющиеся баги в оперативном режиме. Единый trunk в SVN не позволяет этого делать, а организация бранчей в нем же превращает жизнь разработчиков в ад. Поэтому было принято решение о переезде этого проекта с SVN на Git.

Перевод статьи Vincent Driessen: A successful Git branching model

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



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

Порядка 600 операторов в 4 странах, обрабатывающих звонки клиентов на американские (и немного на российские) номера.
Примерно 200 одновременных разговоров в пиковое время.
Примерно 15 000 звонков в день.
Возможность за несколько минут масштабировать это решение в несколько раз (по нашим прикидкам до ~1000 параллельных звонков, прежде чем начнутся проблемы).

Ну и конечно же, плотная интеграция с внутренними системами (CRM, сопровождение покупок, приоритеты операторов и клиентов и много-много других плюшек).

Кому интересно как это это работает и почему именно так — добро пожаловать

Что такое NAXSI ?

NAXSI = NGINX ANTI XSS & SQL INJECTION
Проще говоря, это файрвол веб-приложений (WAF) для NGINX, помогающий в защите от XSS, SQL-инъекций, CSRF, Local & Remote file inclusions.
Отличительными особенностями его являются быстрота работы и простота настройки. Это делает его хорошей альтернативой например mod_security и апачу.

Зачем нужен NAXSI ?

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

• Низкое качество кода сайта, при отсутствии возможности/ресурсов все выкинуть и переписать нормально.
• “Закрытый” код, в котором невозможно исправить ошибки.
• Неизвестное качество кода в важном для бизнеса участке.

Это первая статья из серии «Сети для самых маленьких». Мы с товарищем thegluck долго думали с чего начать: маршрутизация, VLAN'ы, настройка оборудования.
В итоге решили начать с вещи фундаментальной и, можно сказать, самой важной: планирование. Поскольку цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (более подробно). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.



Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

Недавно мы настраивали SMTP-сервер для нашего проекта. Вопрос стоял так: что нужно сделать, чтобы письма, отправленные нашим пользователям, не попадали в папку со спамом или попадали туда как можно реже?

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

Приведенные советы актуальны только если вы используете свой собственный SMTP-сервер. При использовании, например, SMTP сервера Google всё уже сделано за нас. Как правило. В любом случае рекомендую проверить (см. подразделы Как проверить?).

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

В организации, где я работаю, используется довольно большое количество управляемых свичей, разнесенных по нескольким зданиям. Захотелось видеть MAC-адреса на их портах не только с помощью telnet или ssh, а прямо в веб-интерфейсе системы мониторинга Zabbix.

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

Еще в начале 80-х комитет ISO выделил основные компоненты системы управления сетью. Модель получила название FCAPS. По версии ISO, для успешного управления сетью надо уметь управлять отказами (F), конфигурацией оборудования и сервисов (C ), собирать и обрабатывать статистику по потреблению услуг (A), оценивать производительность (P) и централизованно управлять безопасностью (S). Прошедшие три десятка лет не добавили ничего принципиально нового, и все задачи управления сетью так или иначе прыгают вокруг основных составляющих.

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

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

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

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

Есть одно неплохое кросс-доменное решение, но оно было написано в 2007 году, а с тех пор многое изменилось. Поэтому пришлось разрабатывать решение этой проблемы самостоятельно, основываясь на приведенном решении.

Итак, речь пойдёт про отмену DST для пользователей почты, расположенной на серверах Exchange, а именно, про обработку календарей для сохранения правильного времени встреч и событий. Да, 30 октября уже скоро, и может показаться, что уже поздно опубликовывать подобный топик, но, во-первых, кто-то из администраторов почтовых систем мог и не задумываться ранее о необходимости подобных действий и у них ещё есть время, чтобы всё исправить, во-вторых, это не последняя отмена DST в нашем мире, а русскоязычные люди есть везде, и в-третьих, до вчерашнего вечера у меня не было, к сожалению, всей необходимой информации для описания этого процесса. (Конечно же, пользователи могут переделать встречи и события вручную, но автоматизированно оно же всегда лучше, быстрее и точнее, не так ли?)

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

Я не тестировал применимость данной инструкции к Exchange 2007, только к Exchange 2003, но, судя по оригинальным статьям Microsoft, отличий в процедуре нет. Несмотря на то, что на странице Центра справки и поддержки по переходу на летнее и зимнее время обещается выпуск специального обновления для серверов Exchange, его до сих пор нет и поддержка Microsoft сомневается в его выходе до 30 октября.

Я предполагаю, что на ваши серверы Exchange установлен последний доступный Service Pack.

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

Началось всё с того, что я ушёл от firstvds, где уже ничто не спасёт от тормозов. Ушел на ганди.нет, взял одну шару (1 share), которую дали на месяц бесплатно. Кстати, акция эта (This summer, your server is free!) вроде еще не закончилась. ;) И начал на этой шаре проводить зверские эксперименты с установкой разного ПО. Тестировал результаты с помощью siege.

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

Наш новый фронтенд-сервер сейчас вполне справляется с нагрузкой и в оптимизации не нуждается (чего нельзя сказать о базе данных), но после того, как я очередной раз посмотрел на его top, мне вдруг стало жалко ожесточённо разнашиваемых дисков, и я решил уделить этому пару минут и поставить eAccelerator.

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


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

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

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

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

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

Для достижения описанных выше целей необходимо организовать следующую структуру веток:
release
hotfixes (необязательна)
testing
fixes (необязательна)
default
developers branches (условное название)

Введение

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

Цель поста — показать как Perl можно использовать заместо find, grep, awk, sed. В конце поста будет написано зачем это надо.

Здравствуйте! Сегодня вашему драгоценному вниманию предлагается немного видоизменённый отрывок из свеженапечатанной книги нашего генерального директора Ивана Севостьянова «Поисковая оптимизация».


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