Школа менеджеров Стратоплан представляет:

Константин Дубровин, бизнес-тренер, работа с людьми и руководством, создание отделов продаж.

Недавно ко мне пришли коллеги из Школы менеджеров «Стратоплан» и предложили выступить в роли спикера на онлайн-конференции PRO+People, где нужно будет говорить о работе с людьми: именно этой теме и посвящена вся Конференция. Вместе с другими спикерами (Александром Орловым, Вячеславом Панкратовым, Дмитрием Коткиным и Иваном Селиховкиным) мы будем рассказывать о сложностях и проблемах, которые часто встречаются в компаниях, коллективах и просто в жизни.

Когда я выбирал тему для своего выступления, первое, что мне пришло в голову — это…

Продажи! Уверен, я своим выбором никого сейчас не удивил. Но тему продаж я выбрал не зря. Есть одна вещь, которую порой сложнее всего продать. Это идея.

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

Вот даже написалось «пару слов» о том, почему это происходит и что с этим делать…

«Как продать идею»

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

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

Яндекс.Почта — большое и сложное веб-приложение. Для первоначальной загрузки ей необходимо более 1 МБ статических ресурсов (JS/CSS/Шаблонов). При этом Яндекс.Почта обновляется два раза в неделю, а иногда и чаще.

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

• включаем gzip;
• выставляем заголовки кэширования;
• фризим CSS, JS, шаблоны и картинки;
• используем CDN;
• загружаем статику параллельно через кроссдоменные AJAX-запросы.

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

Мы подумали: «А что если хранить где-то старую версию файлов (например, в localStorage), а при выходе новой передавать только diff между ней и той, которая сохранена у пользователя?» В браузере же останется просто наложить патч на клиенте. О том, что из этого получилось и каким выводам мы с Panya пришли, читайте под катом.

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

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

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

Основная задача внедрения любой системы управления конфигурацией, будь то Chef, Puppet или что-то еще, — повторяемо воспроизводить и обновлять окружение всех сред, использующихся при разработке ПО (dev, CI, QA, stage, production). Отсюда следует, что само описание конфигурации необходимо однозначно хранить и обновлять. К сожалению, возможности по версионированию, которые есть в Chef, достаточно ограничены. Поэтому в связке с Chef в последнее время стали активно использовать Librarian. Но перед тем, как рассказать о нем, поговорим немного о кукбуках.

Продолжаю знакомить сообщество с переводом Bash Pitfalls.
Часть первая.
Первоначальная публикация перевода.

11. cat file | sed s/foo/bar/ > file

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

Есть несколько идентичных серверов (4 ноды) на Amazon EC2 с Ubuntu. Каждый генерирует и хранит у себя на диске кэш, который хотелось бы синхронизировать. Но простой rsync тут не подойдет — файлов несколько миллиардов, nfs — слишком медлителен, и т. д. Полный список рассмотренных вариантов с пояснениями ниже.

К тому же, время от времени нужно удалять устаревшие файлы сразу на всех серверах, что пока делается вручную и занимает несколько суток. Вопрос наиболее быстрой для такого Use Case файловой системы планирую описать позже. Оговорюсь только, что по нескольким причинам была выбрана XFS.

После теста нескольких кластерных технологий и файловых систем, по совету старшего товарища, решили использовать тот же rsync, но в связке с inotify. Немного поискав в интернете готовое такое решение, дабы не изобретать велосипед, наткнулся на csyncd, inosync и lsyncd. На хабре уже была статья о csyncd, но он тут не подходит, т.к. хранит список файлов в базе SQLite, которая вряд-ли сможет сносно работать даже с миллионом записей. Да и лишнее звено при таких объемах ни к чему. А вот lsyncd оказался именно тем, что нам и было нужно.

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

Один из ресурсов, за которым я присматриваю, вдруг стал неожиданно популярным как у хороших пользователей, так и у плохих. Мощное, в общем-то, железо перестало справляться с нагрузкой. Софт на сервере самый обычный — Linux,Nginx,PHP-FPM(+APC),MySQL, версии — самые последние. На сайтах крутится Drupal и phpBB. Оптимизация на уровне софта (memcached, индексы в базе, где их не хватало) чуть помогла, но кардинально проблему не решила. А проблема — большое количество запросов, к статике, динамике и особенно базе. Поставил следующие лимиты в Nginx:

на соединения

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 100;

и скорость запросов на динамику (fastcgi_pass на php-fpm)

limit_req_zone $binary_remote_addr zone=dynamic:10m rate=2r/s;
limit_req zone=dynamic burst=10 nodelay;

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

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

Сначала сам парсил логи, и особо настырных добавлял через iptables в баню. Потом парсил уже по крону каждые 5 минут. Пробовал fail2ban. Когда понял, что плохишей стало очень много, перенёс их в ipset ip hash.

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

Нужно было придумать как быстро добавлять нарушителей в черный список. Сначала была идея написать/дописать модуль к Nginx + демон, который будет ipset-ы обновлять. Можно и без демона, но тогда придётся запускать Nginx от рута, что не есть красиво. Написать это реально, но понял, что нет столько времени. Ничего похожего не нашёл (может плохо искал?), и придумал вот такой алгоритм.

При привышении лимита, Nginx выбрасывает 503-юю ошибку Service Temporarily Unavailable. Вот я решил на неё и прицепиться!

Для каждого location создаём свою страничку с ошибкой

error_page 503 =429 @blacklist;

И соответствующий именованный location

location @blacklist {
    fastcgi_pass    localhost:1234;
    fastcgi_param   SCRIPT_FILENAME    /data/web/cgi/blacklist.sh;
    include         fastcgi_params;
}

Дальше интересней.
Нам нужна поддержка CGI-скриптов. Ставим, настраиваем, запускаем spawn-fcgi и fcgiwrap. У меня уже было готовое для collectd.

Сам CGI-скрипт

Всем привет!

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

Как известно, в облаке Amazon виртуальные инстансы запускаются на основе образов (так называемые AMI). Amazon предоставляет большое их количество, также можно использовать публичные образы, подготовленные сторонними организациями, за которые облачный провайдер, естественно, никакой ответственности не несёт. Но иногда нужен образ чистой системы с нужными параметрами, которого нет в списке образов. Тогда единственный выход — сделать свой AMI.

В официальной документации описан способ создания «instance store-backed AMI». Минус такого подхода заключается в том, что готовый образ нужно будет ещё и сконвертировать в «EBS-backed AMI»

О том, как создать свой EBS-backed AMI в облаке Amazon без промежуточных шагов, пойдёт речь в этой статье.

При большом количестве серверов и виртуальных машин и еще большем количестве кода в постоянном деплое, неизбежно возникают проблемы администрирования всего этого огромного хозяйства. Существует множество инструментов, позволяющих организовать continuous integration. В нашем списке точно уже есть GIT, Jenkins, Chef, Proxmox, Graylog2. Сегодня мы расскажем еще об одном удобном инструменте для автоматизации рутинных задач с помощью сценариев — rundeck. Эта статья — не подробный мануал с примерами конфигов, а скорее размышления на тему.

Здравствуйте!

В этой статье я хочу рассказать об автоконфигурации в облаке. Для примера запустим ec2-инстанс, на котором «приготовится» WordPress.

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

In God we trust, the rest we automate
— unknown DevOps Engineer

Использование виртуализации и облачных платформ позволяет в десятки раз сократить время, затрачиваемое на запуск и обслуживание IT инфраструктуры. Один человек может манипулировать десятками, сотнями и даже тысячами виртуальных серверов, с легкостью их запускать, останавливать, клонировать, изменять конфигурацию оборудования и создавать на их основе готовые образы систем. Если все ваши сервера имеют одинаковую конфигурацию, то особых проблем нет, можно один раз вручную настроить сервер, сделать на его основе образ и запускать столько машин, сколько вам необходимо. Если же у вас большое количество разных операционных систем с разным набором программного обеспечения или если вам необходимо быстро запускать и останавливать сложные кластерные конфигурации, то обслуживание даже нескольких десятков таких серверов будет занимать очень много времени. Можно, конечно иметь набор разных скриптов и образов на все случаи жизни, которые необходимо будет сопровождать и обновлять, но более рационально использовать один скрипт и несколько образов, а все необходимые параметры передавать при старте системы. Многие платформы для облачных вычислений предлагают, так называемый, механизм метаданных (metadata) или пользовательских данных (user-data), используя этот механизм, вы можете передать скрипту все необходимые данные по настройке конкретной виртуальной машины или даже передать сам скрипт, чтобы он выполнился при старте.

Добрый день, жители хабра! Я занимаюсь фрилансом (хотя это слово не очень люблю) на протяжении последних четырёх лет. В этом небольшом топике мне хотелось бы рассказать о различных способах вывода заработанных непосильным трудом денежных средств. Для начала стоит сказать о том, как именно организована моя работа. Я использую всего два варианта – oDesk и работа напрямую. С клиентами из России работать ещё не доводилось, так что о таких знакомых вариантах вывода денег, как WebMoney и Яндекс.Деньги речь идти не будет.

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

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

Лирика

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

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

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

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

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

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

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

Здравствуйте!

Хочу рассказать о том, как мы используем у себя Proxmox Virtual Environment.

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

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

Proxmox работает с двумя типами виртуализации: уровня операционной системы, на основе OpenVZ и аппаратной, на основе KVM. В этих двух типах используется разный подход к утилизации дискового пространства. Если в случае с OpenVZ-контейнерами работа с диском виртуальной машины осуществляется на уровне файловой системы хоста, то в случае с KVM-машинами используется образ диска, в котором находится собственная файловая система виртуальной машины. Операционная система хоста не заботится о размещении данных внутри KVM-диска. Этим занимается гипервизор. При организации работы кластера вариант с образами диска реализуется проще, чем работа с файловой системой. Данные KVM-машины с точки зрения операционной системы хоста могут просто находиться "где-то" в хранилище. Эта концепция замечательно ложится на схему работы LVM, когда образ KVM-диска находится внутри логического тома.

В случае же с OpenVZ мы имеем дело с файловой системой, а не просто с областями данных на Shared Storage. Нам нужна полноценная кластерная файловая система.

О кластерной файловой системе речь пойдет не в этой части статьи. О работе с KVM — тоже. Сейчас поговорим о подготовке кластера к работе с общим хранилищем.

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

Итак, я просил ответить на вопрос какие книги из статьи вы читали?

Результаты опроса:

Название книги	Количество голосов	Процент
Том ДеМарко. Deadline. Роман об управлении проектами	247	54%
Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы	174	38%
Джоэл Спольски. Джоэл о программировании	165	36%
Том Демарко и Тимоти Листер. Человеческий фактор. Успешные проекты и команды	148	32%
Джейсон Фрайд, Дэвид Хайнемайер Хенссон. Rework. Бизнес без предрассудков	108	24%
Джеффри Янг и Уильям Саймон. iКона. Стив Джобс	94	21%
Том ДеМарко, Тимоти Листер. Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения	70	15%
Том Демарко, Тимоти Листер. Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд	51	11%
Кармин Галло. iПрезентация. Уроки убеждения от лидера Apple Стива Джобса	48	11%
Патрик Ленсиони. Смерть от совещаний	21	5%
Патрик Ленсиони. Пять пороков команды. Притчи о лидерстве	19	4%
Патрик Ленсиони. Пять искушений руководителя: притчи о лидерстве	16	4%
Патрик Ленсиони. Три признака унылой работы. История со смыслом для менеджеров (и их подчиненных)	11	2%

А теперь еще один бонус — список книг по заданной тематике, которые прислали нам читатели:

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

Полезные советы от британского миллиардера под катом.

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

В отечественном IT я часто наблюдаю следующую картину: тимлидом часто становился лучший (?) разработчик из команды (aka 23-летний сеньор). А чтобы стать руководителем проекта (project manager) иногда достаточно просто знать английский и «павэрпойнт» на уровне пользователя. Это реалии отечественного аутсорсинга и с этим нужно как-то жить.

В итоге часто получается как-то так:

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