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

Если, скажем, через полгода после того, как был написан некий «одноразовый» скрипт, кто-то спросит его автора о том, почему этот скрипт даёт сбои, об этом может не знать и автор скрипта. Происходит подобное из-за того, что к такому скрипту не была написана документация, из-за использования параметров, жёстко заданных в коде, из-за того, что скрипт ничего не логирует в ходе работы, и из-за отсутствия тестов, которые позволили бы быстро понять причину проблемы.



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

Автор материала, перевод которого мы сегодня публикуем, собирается продемонстрировать подобное «превращение» на примере классической задачи «Fizz Buzz Test». Эта задача заключается в том, чтобы вывести список чисел от 1 до 100, заменив некоторые из них особыми строками. Так, если число кратно 3 — вместо него нужно вывести строку Fizz, если число кратно 5 — строку Buzz, а если соблюдаются оба этих условия — FizzBuzz.

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

• как писать логи из приложения;
• куда писать логи;
• как доставлять логи для хранения и обработки;
• как обрабатывать и хранить логи.

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

Как раз об этом расшифровка доклада Юрия Бушмелева "Карта граблей на поле сбора и доставки логов"

Кому интересно, прошу под кат.

Зачем вообще делать столярную мастерскую? Однозначного ответа у меня нет. Если вам просто хочется делать что-то руками из дерева, то есть мастерские, в которые можно прийти, заплатить деньги за аренду станков и рабочего места, и сделать всё там. Необязательно иметь свое помещение и собственное оснащение. Если же вы хотите заниматься деревообработкой как бизнесом, то конкуренция здесь высокая, найти свою нишу сложно. Поэтому я начну с объяснения моих собственных мотивов.

В прошлой статье мы рассмотрели разработанное приложение на Ethereum. Но обошли стороной вопрос как происходит процесс разработки. Ясно, что это не просто написание кода, который сразу работает. Большую часть времени придется потратить на то, чтобы доводить код, который “почти готов”, до рабочего состояния. Деплой, тестирование, отладка — все это в той или иной мере уже затрагивалось здесь например в этих неплохих статьях: раз, два, три (список не полный). В этой статье мы дадим небольшой обзор и возможно в чем-то повторимся, но постараемся сфокусироваться на тех моментах, которые нам показались важными или недосказанными. Плюс за последнее время некоторые штуки изменились, и огромное количество инструкций оказалось устаревшим. Постараемся немного подправить ситуацию.

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

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

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

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

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

Относительно недавно наша компания организовала программу стажировки для молодых специалистов по направлениям:

1. Основы сетевых технологий (Cisco).
2. Серверное администрирование (Windows, Linux).
3. Технологии виртуализации и систем хранения данных (VMware, Microsoft Hyper-V).
4. Современные средства защиты информации (UTM, NGFW, Sandbox и т.д.).
5. Этичный хакинг (CEH) и Pentest.
6. Обработка машинных данных (Log management — Splunk, MaxPatrol SIEM)

Если взять сетевое направление, то в ходе практики, почти у всех начинающих сетевых инженеров или студентов данного направления возникает вопрос: “Что нужно знать сетевому инженеру? На чем сосредоточить силы?”. Я всегда начинал советовать какие-то темы и направления, затем понял, что было бы неплохо составить некий чек-лист, для молодых инженеров, чтобы у них был ясный вектор развития. Кроме того я попытаюсь дать ссылки на ресурсы, где эти навыки можно получить. Естественно универсального списка нет и все что я могу предложить это свое представление о необходимых навыках любого сетевого инженера. Данный список составлялся на основе личного опыта и отражает то, с чем чаще всего приходится сталкиваться в работе. Уверен, что у большинства есть свое мнение на счет обязательных навыков и скорее всего оно не совпадает с моим. Если вас заинтересовала данная тема, то добро пожаловать под кат…

Во время собеседований на роль linux/unix администратора во многих IT-компаниях спрашивают, что такое load average, чем nginx отличается от apache httpd и что такое fork. В этой статье я постараюсь объяснить, что рассчитывают услышать в ответ на эти вопросы, и почему.

Здесь важно очень хорошо понимать основы администрирования. В идеальной ситуации при постановке задачи системному администратору выставляют ряд требований. Если же ситуация не идеальная, то, по сути, требование к администратору одно: «Хочу, чтобы всё работало». Иными словами, сервис должен быть доступен 24/7 и, если какое-то решение не удовлетворяет этим требованиям (масштабирование и отказоустойчивость относятся к доступности), то можно сказать, что администратор плохо сделал свою работу. Но если разные решения двух администраторов работают 24/7, как понять, какое из них лучше?

Хороший системный администратор при выборе решения при заданных требованиях ориентируется на два условия: минимальное потребление ресурсов и их сбалансированное распределение.

Вариант, когда одному специалисту нужно 10 серверов для выполнения задания, а второму всего 2, мы рассматривать не будем, что тут лучше – очевидно. Далее под ресурсами я буду понимать ЦПУ (cpu), ОЗУ (ram) и диск (hdd).

Давайте рассмотрим ситуацию: один администратор создал решение, которое требует 10% cpu, 5% ram и 10% hdd от всего вашего оборудования, а второй использовал для этого 1% cpu, 40% ram и 20% hdd. Какое из этих решений лучше? Тут все становится уже не так очевидно. Поэтому хороший администратор всегда должен уметь грамотно подобрать решение, исходя из имеющихся ресурсов.

A Thief on the Run by Manweri

Привет, Хабр! В этом посте мы снова поговорим о проблеме подделки отправителя (или так называемом спуфинге). В последнее время такие случаи очень участились: подделывается все: письма со счетами за ЖКХ, из налоговой инспекции, банков и так далее. Решить эту проблему помогает настройка строгой DMARC-политики. Мы как почтовая служба проверяем все приходящие к нам письма на DMARC начиная с февраля 2013 года. Мы были первым в рунете почтовым сервисом, поддержавшим стандарты DMARC. Однако чтобы минимизировать число поддельных писем, этого, к сожалению, недостаточно. Главное, чтобы строгий DMARC был поддержан на стороне отправителя. Вот почему мы не устаем качать эту тему, ведем активную разъяснительную работу и всячески призываем всех включать у себя строгий DMARC.

Позитивные сдвиги уже есть: с каждым месяцем мы видим прирост числа корпоративных отправителей, прописавших DMARC, на десятки процентов. Однако безусловно, еще есть над чем работать. Практика показывает, что IT-культура находится на очень разном уровне. Кто-то слышал краем уха про DMARC, но пока не собирается его внедрять. Есть и такие, для кого факт, что в транспортных протоколах электронной почты отсутствует какая-либо проверка и защита адреса отправителя, до сих пор является настоящим откровением. Кроме того, поддержка DMARC — задача непростая. Только на первый взгляд кажется, что достаточно опубликовать запись в DNS, и не требуется никакого дополнительного софта или технических средств (подробнее в нашей статье DMARC: защитите вашу рассылку от подделок). На практике в крупной компании с многочисленными потоками электронной почты и развесистой структурой почтовых доменов все гораздо сложнее. И есть моменты, которые следует предусмотреть и продумать заранее. Именно для таких сложных случаев мы написали эту статью, постаравшись собрать в ней все нюансы.

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 1.0 Играем с Busybox
  
  • 1.1 Docker Run
    
  • 1.2 Терминология
    
  
  
• 2.0 Веб-приложения и Докер
  
  • 2.1 Статические сайты
    
  • 2.2 Образы
    
  • 2.3 Наш первый образ
    
  • 2.4 Dockerfile
    
  • 2.5 Docker на AWS
    
  
  
• 3.0 Многоконтейнерные окружения
  
  • 3.1 SF Food Trucks
    
  • 3.2 Сети Docker
    
  • 3.3 Docker Compose
    
  • 3.4 AWS Elastic Container Service
    
  
  
• 4.0 Заключение
  
  • 4.1 Следующие шаги
    
  • 4.2 Фидбек автору
    

Вопросы и ответы

Что такое Докер?

Определение Докера в Википедии звучит так:

программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы; позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, а также предоставляет среду по управлению контейнерами.

Ого! Как много информации.

8 апреля в Екатеринбурге прошла конференция DUMP. Под катом — видео 60-и докладов про frontend, serverside, devops, mobile, дизайн, управление разработкой и тестирование, плюс все презентации и фотографии с прошедшей конференции. А вот короткий отчетный ролик про DUMP-2016.

На днях мы анонсировали включение строгой DMARC-политики на всех доменах, принадлежащих Почте Mail.Ru. На некоторых доменах, включая bk.ru и mail.ua, политика p=reject включена уже сейчас. В этой статье мы хотим пояснить некоторые технические детали такого включения и дать рекомендации владельцам сервисов, почтовых серверов и списков рассылки.

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

Сегодня почти в каждой компании, активно использующей ИТ для поддержки бизнеса, существует свой центр обработки данных (ЦОД). Повышение требований к надежности ЦОД – одна из тенденций рынка. Поскольку дата-центр нередко является ключевым элементом бизнеса компании, специалисты давно ищут экономичные способы повышения его надежности. Причем рано или поздно возникает необходимость обеспечить не только аппаратную надежность ЦОД, но и его катастрофоустойчивость.

Мы в «Латере» занимаемся созданием биллинга для операторов связи и рассказываем на Хабре о разработке своего продукта, а также публикуем интересные технические переводные материалы. И сегодня мы представляем вашему вниманию адаптированный перевод одной из глав книги «Архитектура open-source-приложений», в которой описываются предпосылки появления, архитектура и организация работы популярного веб-сервера nginx.

Наконец-то у нас появились видео выступления наших спикеров на Highload 2015, которые мы с удовольствием выкладываем.

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

1. «Near-realtime аналитика событий в высоконагруженном проекте», доклад Александра Крашенинникова

Схема отработки аварии первого уровня в «Мультикарте»

Есть такой миф, что у нас отказоустойчивых инфраструктур у крупных компаний не было примерно до 2007 года. Мол, именно тогда начали появляться документы DRP (аварийного восстановления), выделяться отделы риск-менеджмента и так далее.

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

А теперь поехали развеивать другие мифы про DRP и непрерывности. Ну и заодно расскажу про наш последний проект — аварийные планы «Мультикарты», то есть той системы, через которую идут все ваши оплаты картами в России.

Ну и, конечно, истории былинных провалов.

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

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

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Как известно, для обработки соединений NGINX использует асинхронный событийный подход. Вместо того, чтобы выделять на каждый запрос отдельный поток или процесс (как это делают серверы с традиционной архитектурой), NGINX мультиплексирует обработку множества соединений и запросов в одном рабочем процессе. Для этого применяются сокеты в неблокирующем режиме и такие эффективные методы работы с событиями, как epoll и kqueue.

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

Каждый процесс расходует память и каждое переключение между ними требует дополнительных циклов процессора, а также приводит к вымыванию L-кэшей

У медали есть и обратная сторона. Главной проблемой асинхронного подхода, а лучше даже сказать «врагом» — являются блокирующие операции. И, к сожалению, многие авторы сторонних модулей, не понимая принципов функционирования NGINX, пытаются выполнять блокирующие операции в своих модулях. Такие операции способны полностью убить производительность NGINX и их следует избегать любой ценой.

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