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

1. Чтобы быстро скопировать/переименовать файл с длинным именем, можно набрать:

cp /home/user1/myfile123456789.txt{,-new}

и обратно:

cp /home/user1/myfile123456789.txt{-new,}

2. Бесполезная, но прикольная форк-бомба (правда, не сработает, если у Вас задан ulimit для количества процессов):

:(){ :|:& };:

3. Эмулятор сетевого принтера на локальном компьютере:

nc -l -p 9100 > job.prn

4. Простейшее нагрузочное тестирование веб-сайта:

for i in {1..1000}; do echo ya.ru; done | xargs -P 20 wget &>/dev/null

5. Удобочитаемый вывод команды mount:

mount | column -t

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

Нам, например, круглосуточно требуется мониторить более 46 000 метрик на более чем 500 серверах в 6 дата-центрах и 4 странах, а DAU игры War Robots стабильно переваливает за 1 500 000 человек.

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

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

Таких материалов пока практически нет в сети. Поэтому короткая заметка с рекомендациями в пределах допустимых условиями экзамена.


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

Я же представляю слой населения, который начал с нуля в феврале, а в середине марта сдал с результатом 92%.

В эпоху все большей популярности различных js и css linter'ов, не удивительно появление удобного линтера с автокоррекцией для Python.

Приветствуйте, Yapf — готовое решение, для превращения каши из строк во вполне читаемый код. И поверьте, он вам пригодится.

В ЦРУ правильно понимают набор практик DevOps

В опубликованных документах ЦРУ много сугубо технической информации для программистов. Как работать с Git, как скрыть характерные метки в коде, применять шифрование, использовать вредоносные компоненты из других программ. В архиве есть подсказки с «горячими клавишами» vi/vim, справочный курс Git Immersion. Технические рекомендации ЦРУ в ближайшее время следует внимательно проанализировать, тем более что скоро опубликуют вторую порцию документов. Джулиан Ассанж сказал, что в первый архив на ≈600 МБ (Year Zero) — это всего лишь 1% полученных от информатора документов.

Но уже сейчас ясно одно. Разработчики эксплойтов из подразделения Engineering Development Group (EDG) — такие же простые парни, как все. Они тоже отпускают программистские шуточки и обмениваются мемами, вирусными картинками с текстом, анимированными «гифками», с отсылками к поп-культуре, аниме и компьютерным играм. Пусть это и не самая ценная часть архива, но она там есть.

Кибер-преступники всегда ищут новые способы преодоления систем защиты, установленных на компьютерах, для того чтобы избежать обнаружения и украсть пользовательские данные. В этом смысле хакеры «Black Hat» всегда обращались к вредоносным атакам (фишинг, сетевые черви или страшные трояны с шифровальщиками как самый страшный пример) для достижения своих целей: проникнуть в компании для кражи учетных записей или огромных объемов данных в обмен на выкуп… По крайней мере, так было до сих пор.

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

OpenVAS (Open Vulnerability Assessment System, Открытая Система Оценки Уязвимости, первоначальное название GNessUs) фреймворк состоящий из нескольких сервисов и утилит, позволяющий производить сканирование узлов сети на наличие уязвимостей и управление уязвимостями.

Время не на нашей стороне

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

Действия злоумышленников, с точки зрения временных характеристик

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

Сегодня, 25 ноября 2016 г., запущена новая, 10-я по счету лаборатория тестирования на проникновение в которой примут участие специалисты по информационной безопасности со всего мира.

Лаборатория представляет копию современной корпоративной сети компании, занимающейся разработкой Security продуктов.

Несколько лет назад я понял, что сыт учебой по горло. На получение 2 дипломов я потратил 6 лет. Сразу после этого я занялся бизнесом. И первые два года предпринимательства я тоже активно учился. Но спустя какое-то время я подумал: «Да кому нужно это образование? Просто начни свой бизнес или устройся на работу и получай деньги. Образование — это потеря времени и средств». Так ли это на самом деле?

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

Тем временем, хвала комьюнити Node.js, появились пакеты, которые позволяют принимать почту без боли и страданий – это smtp-server и mailparser. Давайте я покажу, как в пару десятков строк кода создать свой почтовый сервер с поддержкой SSL шифрования, фильтрацией спама с помощь spamassassin и прочими радостями.

Подозреваете, что Linux-сервер взломан? Уверены, что всё в порядке, но на всякий случай хотите повысить уровень безопасности? Если так – вот несколько простых советов, которые помогут проверить систему на предмет взлома и лучше её защитить.

Я искал self-hosted мониторинговое решение с открытым кодом, которое может предоставить хранилище метрик, визуализацию и оповещение для физических серверов, виртуальных машин, контейнеров и сервисов, действующих внутри контейнеров. Опробовав Elastic Beats, Graphite и Prometheus, я остановился на Prometheus. В первую очередь меня привлекли поддержка многомерных метрик и несложный в овладении язык запросов. Возможность использования одного и того же языка для графических изображений и уведомления сильно упрощает задачу мониторинга. Prometheus осуществляет тестирование по методу как черного, так и белого ящика, это означает, что вы можете тестировать инфраструктуру, а также контролировать внутреннее состояние своих приложений.

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

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

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

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



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

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

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

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

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

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

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

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

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

• события могут происходить на разных серверах и в разных датацентрах (восточный и западный берег США, Европа)
• интервал между событиями — от долей секунды до нескольких дней
• к моменту получения завершающего события (например конверсия) информация обо всей цепочке должна быть на руках
• время жизни информации — примерно десять дней, после чего она должна быть удалена, желательно автоматически, через TTL
• темп чтения/записи событий — сотни или тысячи в секунду
• Время ответа: желательное — до 10мс, допустимое — в пределах 50мс, максимальное — до 100мс
• информация должна быть доступна «всегда» — независимо от аварий железа, сети, апгрейдов
• система должна легко масштабироваться: добавление новых серверов, датацентров должно происходить прозрачно для остальных сервисов (допустима деградация времени ответа в заданных пределах).

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