Средства для резервного копирования информации можно разделить на несколько категорий:
— Для домашнего/офисного применения (резервирование важных документов, фотографий и пр. на NAS либо в облако);
— Для средних и крупных (offline) предприятий (резервирование важных документов, отчетности, баз данных и пр. как на серверах так и на рабочих станциях сотрудников);
— Для малых веб-проектов (резервирование файлов и баз данных с хостинговой площадки либо VPS/VDS на удаленный хост (или наоборот));
— Для крупных веб-проектов с распределенной архитектурой (почти то же самое, что и на offline-предприятиях только с учетом работы в глобальной сети, а не локальной, и как правило с использование open source средств).

С программными продуктами для дома и офиса все достаточно просто есть масса решений как открытых так и проприетарных, от cmd/bash скриптов до решений известных производителей ПО.
В enterprise секторе все достаточно скучно есть масса программных продуктов которые давно и успешно работают на многих предприятиях, в крупных банках и пр, рекламировать никого не будем. Многие из этих продуктов хорошо упростили жизнь системных администраторов, за достаточно «скромные деньги» по меркам некоторых предприятий.
В данной статье более подробно рассмотрим open source решения для резервного копирования веб-проектов разного масштаба, а также проведем тест на скорость резервирования файлов.
Статья будет полезна веб-мастерам, небольшим веб-студиям, ну и возможно даже бывалый админ найдет здесь что-то полезное.

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



Наша система мониторинга преследует несколько целей:

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

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

Главная задача отдела эксплуатации Sports.ru и Tribuna.com — масштабирование сетевой инфраструктуры в условиях постоянного роста трафика (за 1,5 года трафик и кол-во запросов в секунду выросло в два раза), регулярных пиковых нагрузок и аудитории, распределенной по разным странам. Для решения этой задачи мы используем разные технологии; одна из них — создание собственной CDN (сети доставки контента), которая позволяет сократить нагрузку, усилить защиту от DDoS-a и ускоряет загрузку сайта в удаленных регионах. Мы решили поделиться своим опытом в этой области и составили краткое практическое руководство для системных администраторов по разворачиванию и эксплуатации своей CDN.

На прошлых выходных отгремели AgileDays 2014 и я спешу поделиться слайдкастами с посетителями Хабра.
На конференции было поднято много различных тем по гибким методологиям: от разработки продуктов до управления командами и мотивации, поэтому на AgileDays 2014 собралось около 900 человек на 70 докладов. Видео всех докладов будет позднее, но часть докладов уже сейчас доступны в формате слайдкастов.

История: Эта статья впервые появилась в журнале Better Software в марте 2006. Она была переведена на несколько языков.

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

Чем больше я пользовался TDD, тем больше я понимал, что не столько оттачиваю своё мастерство, достигая новых его вершин, сколько то, что это было движение в слепую. Я помню, как мне все чаще приходила мысль: «Эх, вот бы мне кто-нибудь сказал это раньше!», чем мысль: «Отлично, дорога ясна». Я решил, что нужно найти способ обучать TDD, показывающий, как верно работать с ним сразу и без ошибок.

И этот способ — это программирование через поведение. Оно выросло из выработанных agile практик и призвано сделать их доступнее и эффективнее для команд, незнакомых с ними. Со временем, BDD стало включать в себя agile анализ и автоматическое приемочное (прим. acceptance) тестирование.

Год назад мы отказались от всех публичных счетчиков в пользу закрытых сервисов и собственной инфраструктуры обработки данных. Собирая на Олимпиаде по 10 млн. хитов в сутки, мы нащупали предел доброты Google Analytics, за которым бесплатное обслуживание уже не возможно. Но теперь у нас есть свой лунапарк со сверткой и графиками, поэтому мы можем легко снизить интенсивность использования GA, сохранив за ним только аудиторские функции. О том, как мы собираем данные и как используем их в своей работе – в простыне с веселыми картинками внутри.

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

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

Repetitio est mater studiorum
Старинная латинская пословица

Если вам периодически приходится собирать образы операционных систем на базе Linux для разных сред виртуализации или даже облаков, или, тем более, вы пользуетесь Vagrant, то вам стоит взглянуть на новый инструмент от Митчела Хашимото (это создатель Vagrant) — Packer.

Packer — это инструмент для создания одинаковых образов ОС для различных платформ из одного описания.

На понимание факта, что юнит тесты это не только инструмент борьбы с регрессией в коде, но также и отличная инвестиция в качественную архитектуру меня натолкнул топик, посвященный модульному тестированию в одном англоязычном .net сообществе. Автора топика звали Джонни и он описывал свой первый (и последний) день в компании, занимавшейся разработкой программного обеспечения для предприятий финансового сектора. Джонни претендовал на вакансию разработчика модульных тестов и был расстроен низким качеством кода, который ему вменялось тестировать. Он сравнил увиденный им код со свалкой, набитой объектами, бесконтрольно создающими друг друга в любых непригодных для этого местах. Также он писал, что ему так и не удалось найти в репозитории абстрактные типы данных, код состоял исключительно из туго переплетенных в один клубок реализаций, перекрестно вызывающих друг друга. Джонни, понимая всю бесполезность применения практики модульного тестирования в этой компании, обрисовал ситуацию нанявшему его менеджеру и, отказавшись от дальнейшего сотрудничества, дал напоследок ценный, с его точки зрения, совет. Он посоветовал отправить команду разработчиков на курсы, где бы их смогли научить правильно инстанцировать объекты и пользоваться преимуществами абстрактных типов данных. Я не знаю, последовал ли менеджер совету (думаю, что нет), но если вам интересно, что имел в виду Джонни и как использование практик модульного тестирования может повлиять на качество вашей архитектуры, добро пожаловать под кат, будем разбираться вместе.

На одном из давних тренингов мы отрабатывали кейс “Сотрудник не присылает вовремя отчеты”. Кейс абсолютно не привязанный к реальной жизни — ведь такого же не бывает, чтобы люди не присылали вовремя отчеты, верно?

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

Моим собеседником оказался молодой человек, назовем его Егор, технический директор небольшой компании.

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

— Александр, как же так, почему Вы не присылаете мне отчеты?

Я стоял, думал-думал, чего сказать. И потом ляпнул первое, что пришло в голову:

— Егор, а чего ты хочешь, если ты такой хреновый менеджер?!

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

— Что значит “хреновый менеджер”?!!! Это недопустимо — так разговаривать с руководством…

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

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

Как устроен процесс организации разработки в крупном интернет-проекте на всех этапах его роста? Что происходит, когда из стартапа компания перерастает в проект с более чем 190 миллионами пользователей.

В прошлом году на конференции Whalerider Алексей fisher Рыбак рассказывал о том:

• как у нас Badoo сейчас устроена разработка;
• как в процессе развития проекта её перестраивали;
• какие проблемы решали;
• как преодолевали кризисы роста;
• на какие грабли наступали.

В секции вопросов есть интересная информация о том, как в Badoo устроена система мотивации и бонусов.
Сейчас у нас появилось видео и мы хотим поделиться им с вами.

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

Почему ты не можешь дать точную оценку трудоемкости разработки?
Почему ты не можешь завершить все работы в два раза быстрее?

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

Один из самых заметных трендов рунета — стремительный рост мобильной аудитории. По данным на конец 2013 года, каждый четвертый хит сети совершается из мобильного браузера. Ежемесячная мобильная аудитория рунета составляет уже свыше 130 миллионов человек, а ежедневно в сеть со смартфонов и планшетов выходят 20-25 миллионов пользователей.

В связи с этим множество e-commerce-компаний и подразделений задумываются над тем, нужно ли сражаться за мобильную аудиторию. Ответ «да» порождает целый вал вопросов. Какие проблемы предстоит решить перед созданием своего первого приложения? Какие риски учесть? Как появление приложения повлияет на бизнес компании и на отдел разработки? К чему готовиться и как жить дальше?

Чтобы избежать больших затрат на развертывание сред разработки и тестирования, приближенных к среде эксплуатации (development stage vs production stage parity), всё большую популярность приобретает виртуализация сред.

В этой статье я расскажу, как создавал соответствующую репродуцируемую среду разработки на примере своего проекта runit-man с использованием Vagrant.

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

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



В конечном итоге большинство наших проблем удалось решить при помощи Agile Board и Scrum, но пришли мы к этому далеко не сразу, а поэтапно.

Каждый раз, когда я смотрю на диаграммы Ганта [1], меня мучает один и тот же вопрос. Как? Вот как можно быть уверенным, что ресурс А, выполнит задачу Б за 5 дней? Нет, я понимаю, что есть исторические данные, есть, не побоюсь этого слова, статистика. Но вот как можно на основе всего этого делать уверенные прогнозы? Я не понимаю.
Если для вас термины «взаимозависимость событий» и «статистические отклонения» говорят что-то не только по отдельности, но и в совокупности, то статья вас вряд ли заинтересует. А вот если эти термины, употребленные в одном контексте, не говорят вам в чем проблема диаграмм Ганта, то приглашаю под кат, где на простом примере мы это и обсудим.

Если вам понадобится алгоритм сортировки массива, который:

• Работал бы гарантированно за O(N*log(N)) операций (обменов и сравнений);
• Требовал бы O(1) дополнительной памяти;
• Был бы устойчивым (то есть, не менял порядок элементов с одинаковыми ключами)

то вам, скорее всего, предложат ограничиться любыми двумя из этих трёх пунктов. И, в зависимости от вашего выбора, вы получите, например, либо сортировку слиянием (требует O(N) дополнительной памяти), либо пирамидальную сортировку (неустойчив), либо сортировку пузырьком (работает за O(N²)). Если вы ослабите требование на память до O(log(N)) («на рекурсию»), то для вас найдётся алгоритм со сложностью O(N*(log(N)²) — довольно малоизвестный, хотя именно его версия используется в реализации метода std::stable_sort().

На вопрос, можно ли добиться выполнения одновременно всех трёх условий, большинство скажет «вряд ли». Википедия о таких алгоритмах не знает. Среди программистов ходят слухи, что вроде бы, что-то такое существует. Некоторые говорят, что есть «устойчивая быстрая сортировка» — но у той реализации, которую я видел, сложность была всё те же O(N*(log(N)²) (по таймеру). И только в одном обсуждении на StackOverflow дали ссылку на статью B-C. Huang и M. A. Langston, Fast Stable Merging and Sorting in Constant Extra Space (1989-1992), в которой описан алгоритм со всеми тремя свойствами.

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

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

Одна из главных проблем руководителя — это получение актуальной информации о ходе проектов, за результаты которых он отвечает. По моей практике, до внедрения PPM руководители тратят очень много времени просто на то, чтобы проверить, что всё везде идёт по плану. Грубо говоря, 60% рабочего времени может уходить просто на то, чтобы понять, что все справляются, и вмешиваться не надо. С другой стороны, после внедрения PPM всю эту работу делать уже не надо – она делается автоматически системой. А вам только приходят алерты для ситуаций, в которых требуется внимание. Получается удобный и очень практичный инструмент управления по исключениям.

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