Сам я не очень люблю заголовки вроде «Покемоны в собственном соку для чайников\кастрюль\сковородок», но это кажется именно тот случай — говорить будем о базовых вещах, работа с которыми довольно часто приводить к купе набитых шишек и уйме потерянного времени вокруг вопроса — «Почему же оно не работает?». Если вы до сих пор боитесь и\или не понимаете Юникода — прошу под кат.

До недавнего времени в Одноклассниках в качестве основного Linux-дистрибутива использовался частично обновлённый OpenSuSE 10.2. Однако, поддерживать его становилось всё труднее, поэтому с прошлого года мы перешли к активной миграции на CentOS 7. На подготовительном этапе перехода для CentOS были отработаны все внутренние процедуры, подготовлены конфиги и политики настройки (мы используем CFEngine). Поэтому сейчас во многих случаях миграция с одного дистрибутива на другой заключается в установке ОС через kickstart и развёртывании приложения с помощью системы деплоя нашей разработки — всё остальное осуществляется без участия человека. Так происходит во многих случаях, хотя и не во всех.

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

Если невежество – это благословление, значит ли это, что высокий IQ приравнивается к страданию? В массовом представлении это так и есть – гениев обычно представляют, как людей, страдающих от страхов, неудовлетворённости и одиночества. Вспомните Вирджинию Вулф, Алана Тьюринга и Лизу Симпсон – одинокие звёзды, изолированные в своей яркости. По словам Хемингуэя: «Счастье у умных людей – самое редкое явление из всех, что я знаю».

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

Первые шаги в поисках ответа на этот вопрос сделали ещё 100 лет назад, в эпоху джаза. В то время инновационный тест на IQ набирал популярность, после того, как оправдал себя в вербовочных центрах Первой Мировой. В 1926 году психолог Льюис Терман решил использовать его для проверки группы одарённых детей. Собрав сливки учащихся с калифорнийских школ, он отобрал 1500 учеников с IQ не менее 140. 80 из них имели IQ более 170. Их назвали «Термитами», и истории их жизней изучают по сей день.

Конечно, многие Термиты достигли богатства и успеха. Например, Джесс Оппенгеймер, написавший классический ситком 50-х «I Love Lucy». В те времена, когда его крутили на CBS, средняя зарплата у Термитов вдвое превышала среднюю зарплату тогдашних «белых воротничков». Но не все люди из этой группы оправдали ожидания – многие занялись более скромным делом, стали полицейскими, моряками и машинистками. Поэтому Терман заключил, что «интеллект и достижения очень слабо коррелируют». Их выдающийся ум не гарантировал им личного счастья. Количество разводов, алкоголизма и самоубийств в их среде совпадало со средними уровнями.

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

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

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

Сегодня мы предлагаем вашему вниманию очередную публикацию в рамках постоянной рубрики «Лекции Техносферы». В этот раз вы можете изучить материалы по курсу «Методы использования СУБД в интернет-приложениях». Цель курса — изучение топологии, многообразия и основных принципов функционирования систем хранения данных, а также алгоритмов, заложенных в основу как централизованных, так и распределённых систем, демонстрация фундаментальных компромиссов присущих тем или иным решениям. Преподаватели курса: Константин Осипов kostja, Евгений Блих bigbes, Роман Цисык.

По моему глубокому убеждению, в особенности в сфере IT, важнейшим качеством любого из специалистов является способность к самообучению. Именно потому в нашей небольшой компании стало хорошей традицией уделять ежедневно время этому процессу, собственному развитию. Даже менеджер должен понимать, как устроена и функционирует сеть. Не давнее, как вчера, обсуждая проблему с BGP, коллега сказал «Вот не был бы я лентяем — прошел бы в студенческие годы курс CCNA и знал бы ответ на твой вопрос». И я задался задачей помочь коллеге, найти способ получить знания в этой области самому, хотя бы начального уровня, чтоб лучше понимать с чем мы работаем. На Хабре, введя в поиск CCNA, можно встретить массу рекомендаций, но все же, англоязычный Интернет — основной источник знаний в области IT-коммуникаций.



Я просто обожаю YouTube! Ведь он предоставляет волшебную возможность удаленного «посещения» тематических конференций и семинаров, причем абсолютно бесплатно. В этот раз, как оказалось, там уже месяца 2 существует бесплатный канал, на котором лектор Imran Rafai, четко и доступно излагает материал из 30-дневного CCNA-курса, весьма доступно и увлекательно!

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

Описанная проблема присуща только ветке OpenVPN 2.3, в 2.4 размеры буферов не меняются без требования пользователя.

Время от времени, мне встречаются темы на форумах, в которых люди соединяют несколько офисов с использованием OpenVPN и получают низкую скорость, сильно ниже скорости канала. У кого-то это может быть 20 Мбит/с при канале в 100 Мбит/с с обеих сторон, а кто-то еле получает и 400 Кбит/с на 2 Мбит/с ADSL/3G и высоким пингом. Зачастую, таким людям советуют увеличить MTU на VPN-интерфейсе до чрезвычайно больших значений, вроде 48000, или же поиграться с параметром mssfix. Частично это помогает, но скорость внутри VPN все еще очень далека от канальной. Иногда все сваливают на то, что OpenVPN — userspace-решение, и это его нормальная скорость, учитывая всякие шифрования и HMAC'и. Абсурд!

Немного истории

На дворе июль 2004 года. Типичная скорость домашнего интернета в развитых странах составляет 256 Кбит/с-1 Мбит/с, в менее развитых — 56 Кбит/с. Ядро Linux 2.6.7 вышло не так давно, а 2.6.8, в котором TCP Window Scale включен по умолчанию, выйдет только через месяц. Проект OpenVPN развивается уже 3 года как, к релизу готовится версия 2.0.
Один из разработчиков добавляет код, который устанавливает буфер приема и отправки сокета по умолчанию в 64 КБ, вероятно, чтобы хоть как-то унифицировать размер буфера между платформами и не зависеть от системных настроек.

Продолжаем путешествовать по офисам крупных компаний, зарегистрированных на «Хабрахабре». Недавно мы заехали в гости в московский офис Badoo — если кто не в курсе, это одна из самых крупных социальных сетей для знакомств, а вместе с этим — одна из самых успешных IT-компаний в Европе.



Заходите под кат, познакомимся.

ВВЕДЕНИЕ

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

КАПЧА МОЕГО ОПЕРАТОРА

Установив PHP, решил начать его изучение с какой-нибудь задачки. Тут-то и вспомнились школьные годы. Сейчас у меня сотовый оператор Теле2, самый дешевый в моем регионе. Вот значит с ним и будем работать. Зашел на сайт бесплатной отправки. Увидел, как обстоит дело с смс. Довольно простые картинки.

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

Зачем это мне?

Типичная ситуация. У админа (или группы админов) в хозяйстве уже не одна стойка с оборудованием — серверы, маршрутизаторы, дисковые полки и массивы, PDU, и так далее. Вполне логично предположить, что необходимо владеть информацией о том, что где стоит, какие сервисы где крутятся, сколько жестких дисков воооон в том сервере. Самый простой вариант учета серверного оборудования — какая-нибудь табличка в excel. Но это не интересно. Статично, ненаглядно. Не вэб-два-нольно. А вот в RackTables…

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

Статья “Как обсуждать деньги с руководством или почему иногда останавливаются карьеры?” неожиданно набрала +165 и под 100 тысяч просмотров, и мы решили продолжить переговорно-зарплатную тематику.

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

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

Дмитрий Коткин “Переговоры о зарплате. Практические рекомендации.”

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

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

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

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

Нет смысла говорить о том, насколько это актуальный вопрос. Сегодня мы расскажем, как у нас организовано резервное копирование баз данных mysql.
И одно их самых важных – это проверка, а сделался ли бекап? А успешно ли прошел дамп? А были ли ошибки? А знаю ли я о них?

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

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

Вот уже много лет пользователей Nginx мучает один и тот же вопрос: «Как можно ограничить скорость в целом для IP адреса независимо от числа сессий (соединений)? Почему Nginx этого не умеет? Почему разработчики Nginx так упорно не хотят реализовать этот простой функционал?» И ответить мне им нечего, о чём думают разработчики Nginx — не понятно и известно, наверное, только господу богу.

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

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

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

Как-то раз коллеги из отдела HR i-Free обратились ко мне с просьбой написать небольшую статью для молодых специалистов, которые стремятся устроиться в IT-компанию. Причины, побудившие их это сделать в целом понятны, в компании основным нанимателем молодых специалистов является отдел под моим управлением, мы берем только что закончивших вуз ребят (а иногда и студентов последних курсов), и у нас они проходят некий курс «молодого бойца».
Естественно, я не претендую на объективность, а лишь хочу дать несколько советов для тех, кто хочет начать свой путь с работы в IT-компании. Статья выражает сугубо моё мнение о том, как нанимать молодого специалиста, и очень надеюсь, что кому-то из студентов старших курсов сей краткий опус поможет в будущей карьере.
В общем, тех, кому интересно, прошу под кат.

Приветствую вас, Хабражители!

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

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



Помните 7 шагов?

Большинство статей в наш блог пишут разработчики. Мы решили исправить эту несправедливость и добавить немного DevOps. Сегодня поговорим о важном ― о бэкапах.
Так как Badoo активно развивается и количество сотрудников постоянно увеличивается, мы пришли к выводу, что централизованное резервное копирование гораздо удобнее, чем частичное копирование и хранение информации в различных местах.
В статье мы рассмотрим, как различными способами «забэкапить» довольно большое количество рабочих станций с помощью одного хранилища, не прибегая к серьёзным вложениям и избегая громоздкой реализации.
Заранее оговоримся, что бэкап не охватывает 100% сотрудников, так как не все хранят свои данные на локальных машинах, поэтому у нас не было цели сделать бэкап обязательно-принудительным.
Одной из основных сложностей централизованного бэкапа стало то, что сотрудники используют разные операционные системы.

Как же мы смогли собрать всех на одном сервере?