Представляем вашему вниманию очередную порцию лекций Технотрека. В рамках курса будут рассмотрены основы системного администрирования интернет-сервисов, обеспечения их отказоустойчивости, производительности и безопасности, а также особенности устройства ОС Linux, наиболее широко применяемой в подобных проектах. В качестве примера будут использоваться дистрибутивы семейства RHEL 7 (CentOS 7), веб-сервер nginx, СУБД MySQL, системы резервного копирования bacula, системы мониторинга Zabbix, системы виртуализации oVirt, балансировщика нагрузки на базе ipvs+keepalived. Курс ведёт Сергей Клочков, системный администратор в компании Variti.

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

Наш хакспейс полон энтузиастов, и был лишь вопрос времени, когда мы проведем такое грандиозное мероприятие. Это время настало весной текущего года. Прохладным утром 11 апреля 2015-го, хакспейс MakeItLab вместе с сетью магазинов оптики «Четыре глаза» и несколькими другими организациями запустили метеозонд в «уральскую» стратосферу!

Надо сказать, мы решили сделать из запуска хорошее шоу, и организовали прямой видеолинк с зонда на большой телевизор. Куча школьников смогли наблюдать за собой сверху, с высоты полета быстро удаляющегося воздушного аппарата. Было очень круто! Разумеется, на борту была и обычная action-камера, которая запечатлела красоты почти-космоса. Наконец, мы отсняли наш марш бросок на 200 км за упавшим зондом. Обо всем этом читайте/смотрите под катом.

В последний четверг этого лета приглашаем гостей в московский офис Mail.Ru Group на третий Tarantool meetup. Наша компания разрабатывает Tarantool — opensource NoSQL In-Memory СУБД, которая ориентирована на максимально возможную производительность. Об этой базе данных вы неоднократно могли читать в нашем блоге. Мы поговорим об основных отличиях и преимуществах Tarantool, поделимся опытом использования и планами на будущее. Событие будет интересно разработчикам, системным администраторам Unix и другим IT-специалистам, работающим с базами данных. В программе встречи три доклада, подробности и программу встречи читайте под катом.

Привет, Хабр! Сегодня я хочу рассказать, как мы построили с нуля гибкую и расширяемую систему для выполнения автотестов на Android-смартфонах. Сейчас у нас используется около 60 устройств для регрессионного тестирования мобильного приложения Почты Mail.Ru. В среднем они тестируют около 20 сборок приложения ежедневно. Для каждой сборки выполняется около 600 UI-тестов и более 3500 unit-тестов.

Автотесты доступны круглосуточно — они экономят очень много времени тестировщиков и позволяют нам выпускать качественное приложение. Без них мы бы тестировали каждую сборку 36 часов (с учетом ожидания) или примерно 13 часов без ожидания. Вместе со сборкой, актуализацией переводов, при рабочей загрузке агентов с автотестами тестирование в среднем занимает 1.5 часа, что ежедневно позволяет нам экономить недели работы тестировщиков.

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

Сегодня мы начинаем серию публикаций новых мастер-классов Технопарка. И первая из них — мастер-класс Алексея Рыбака на свободную тему, в котором он поделился со студентами соображениями о том, чем работа в реальной жизни отличается от учебы. Видео смотрите на нашем сайте, а адаптированную расшифровку — ниже.

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

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

Мартин Л. Эббот и Майкл Т. Фишер, авторы книги «Искусство масштабируемости», перечисляют наиболее распространенные архитектурные, организационные и технологические проблемы масштабировании в product-группах. Список был сформирован на основе их опыта, а также в ходе коммуникаций с клиентами и лег в основу первой книги.

Архитектурные ошибки

Наша новая статья представляет собой список рекомендаций и советов. Из неё вы узнаете:

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

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

Как облегчить процесс тестирования?

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

• Набор интеллект-карт на все случаи жизни: test insane, ministry of testing
• Эвристики, мнемоники: I SLICED UP FUN (моя любимая), COP FLUNG GUN, SFDPOT, LONG FUN CUP

2. Скриншоты, логи и видео — лучшие аргументы тестировщика!
К сожалению, с логами «общения» с сервером зачастую не всё так гладко, как с клиентскими логами. Обычно они добавляются скорее для удобства разработчика при отладке работы с сервером, чем для работы тестировщика.

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

И снова в эфире наша постоянная рубрика «Лекции Технопарка». На этот раз предлагаем вам ознакомиться с материалами курса «Проектирование высоконагруженных систем». Цель курса — получение студентами навыков проектирования высокоэффективных программных систем.

Привет Хабр! Последние 1.5 года я работал над своим проектом, которому был необходим надежный облачный хостинг. До этого момента я больше 10 лет занимался веб-программированием и когда я решил построить свой хостинг у меня были относительно поверхностные знания в этой области, я и сейчас не являюсь системным администратором. Все что я буду рассказывать может выполнить обычный программист в течение 5 минут, просто запустив набор сценариев для Ansible, которые я подготовил специально для вас и выложил на GitHub.

В продолжение об своих экспериментах с хранением логов на ELKR пишу некий «мануал» по установке и базовой настройке.

Те статьи, которые ОЧЕНЬ помогли:
Собираем, парсим и отдаём логи с помощью Logstash — матчасть
Собираем и анализируем логи с помощью Lumberjack+Logstash+Elasticsearch+RabbitMQ — хороший пример реального использования

Спасибо авторам!

Итак, мы будем разворачивать следующую архитектуру:
Device => HAProxy => Logstash-Listener => RabbitMQ => Logstash-Filter => Elasticsearch-Balancer => Elasticsearch DATA/MASTER

В программировании самокритика – это умение распознать контрпродуктивные решения в дизайне, коде, процессах и поведении. Знание о вредных шаблонах решений полезно для программиста. В этой статье я опишу анти-паттерны, которые я встречал на своём личном опыте время от времени.

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

1 Преждевременная оптимизация

В 97% случаев надо забыть об эффективности малых частей программы: преждевременная оптимизация – корень всех зол. Но в 3% случаев об оптимизации забывать не нужно.
Дональд Кнут

Хотя никогда зачастую лучше, чем прямо сейчас
Тим Питерс, Зен языка Python

Что это

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

Почему плохо

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

Как избежать

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

Уважаемые читатели! Представляю вашему вниманию перевод методологии создания веб-приложений The Twelve-Factor App от разработчиков платформы Heroku. Мои комментарии скрыты спойлерами по ходу статьи.

Введение

В наши дни программное обеспечение обычно распространяется в виде сервисов, называемых веб-приложения (web apps) или software-as-a-service (SaaS). Приложение двенадцати факторов — это методология для создания SaaS-приложений, которые:

• Используют декларативный формат для описания процесса установки и настройки, что сводит к минимуму затраты времени и ресурсов для новых разработчиков, подключенных к проекту;
• Имеют соглашение с операционной системой, предполагающее максимальную переносимость между средами выполнения;
• Подходят для развертывания на современных облачных платформах, устраняя необходимость в серверах и системном администрировании;
• Сводят к минимуму расхождения между средой разработки и средой выполнения, что позволяет использовать непрерывное развертывание (continuous deployment) для максимальной гибкости;
• И могут масштабироваться без существенных изменений в инструментах, архитектуре и практике разработки.

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

UPDATE: Всем привет! Сегодня с удивлением узнал от коллег об этой записи. Выяснилось, что мой аккаунт взломали — представители Хабрахабра это подтвердили и восстановили мне доступ и сейчас разбираются, как так получилось. Но я оставляю эту запись как есть, для истории.
В комментариях уже отметились представители Яндекса: говорят, что уязвимость закрыта, ведётся аудит безопасности софта.

И, пользуясь случаем, хочу напомнить, что у нас в Badoo уже несколько лет идет программа "Проверь Badoo на прочность" и мы платим за найденные уязвимости.

Все вокруг постоянно рассуждают о коррупции. А я хочу рассказать Вам о случае, на коррупцию очень похожем, но в среде чистого IT-бизнеса, на государство никак не завязанного.

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

Начну с нетехнической части.