Совсем недавно я наткнулся на очередное обсуждение DevRel в «Разборе Полетов», в котором услышал странно знакомое слово «карго-культ». Потом оно же всплыло и в Telegram-канале Алексея 23derevo Федорова. Потом еще где-то… Всё это привело меня к мысли, что карго-культ охватил умы людей во всех сферах: от HR до разработки, от выбора диеты до принятия решения о выборе фреймворка или профессионального инструмента.

Про диеты, пожалуй, говорить не будем, а вот проблему несознательного принятия профессиональных решений хотелось бы обсудить. Еще ниже по тексту расскажу о том, как мы в JUG.ru Group пытаемся с этим явлением бороться, а в комментах можете сказать мне, какой я плохой/хороший, и заодно поделиться своими наблюдениями: замечали ли за собой склонность к «культизму»?

Под катом нет кода, нет котиков и нет ничего про разработку. Зато есть немного размышлений про маркетинг, HR, философию потребления и принятия решений. А еще там есть анонс нашего открытого семинара Карго Культ, на котором выступит, например, Boomburum.

Все мы встречались со сложными ошибками на продакшне, которые сложно поймать обычными средствами мониторинга. BPF — это технология ядра Linux, которая позволяет делать быструю и безопасную динамическую отладку прямо на запущенной работающей системе, без необходимости готовиться к этому заранее. JVM сама по себе имеет множество точек мониторинга для отслеживания сборки мусора, выделения объектов, вызовов JNI, даже вызовов методов — и всё это без необходимости в дополнительном инструментировании. Когда этих точек мониторинга недостаточно, ядро Linux и всевозможные бибилиотеки позволяют отслеживать системные вызовы, сетевые пакеты, события планировщика, время потраченное на доступ к диску, и даже запросы к базам данных.

В этом хабрапосте мы сделали текстовую расшифровку доклада Sasha Goldshtein, посвященного тому, как инструменты BPF можно использовать для мониторинга JVM-приложений на GNU/Linux, и чеклисту проверки производительности с использованием классических инструментов, таких как fileslower, opensnoop, strace — но всё это с использованием неинвазивной, быстрой и безопасной технологии BPF.

После ката будет множество картинок со слайдами. Осторожно, трафик! Картинки ужаты насколько можно, но не более того. Все они действительно нужны.

Это практическое пособие познакомит вас c Ansible. Вам понадобится виртуальная или реальная машина, которая будет выступать в роли узла для Ansible. Окружение для Vagrant идет в комплекте с этим пособием.

Ansible — это программное решение для удаленного управления конфигурациями. Оно позволяет настраивать удаленные машины. Главное его отличие от других подобных систем в том, что Ansible использует существующую инфраструктуру SSH, в то время как другие (chef, puppet, и пр.) требуют установки специального PKI-окружения.

Пособие покрывает такие темы:

1. Установка Ansible и Vagrant
2. Файл инвенторизации
3. Модули shell, copy, сбор фактов, переменные
4. Запуск на группу хостов
5. Плейбуки
6. Пример: поднимаем кластер, устанавливаем и настраиваем Apache и балансировщик нагрузок HAproxy
7. Обработка ошибок, откат
8. Шаблоны конфигурации
9. Роли

Ansible использует так называемый push mode: конфигурация «проталкивается» (push) с главной машины. Другие CM-системы обычно поступают наоборот – узлы «тянут» (pull) конфигурацию с главной машины.

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

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

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

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

Со всеми сложностями, о которых идет речь выше, мы хорошо знакомы на собственном опыте: у нас имеется 10 точек присутствия с NS-серверами, расположенные в разных точках планеты. На них необходимо регулярно вносить различные изменения: обновлять операционную систему, устанавливать и обновлять различное ПО, изменять конфигурцию и т.п. Мы решили все эти операции автоматизировать и внедрить систему удаленного управления конфигурациями. Изучив имеющиеся решения, мы остановили свой выбор на Ansible.

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

За мной, за мной, читатель, и я проведу тебя в чарующий мир автоматизации разворачивания окружения на серверах под управлением Linux семейства RHEL.

Один из наших java-проектов вырос, стал совсем взрослым и сейчас занимает 4 контура:

Dev — контур для команды разработки,
Qa — контур для команды тестирования,
Stage — контур для демонстрации новых фич заказчику,
Production — боевой контур.

Каждый контур содержит два одинаковых сервера с идентичным набором компонентов окружения для нашего приложения:

linux Oracle — операционная система,
jdk — комплект приложений Java,
haproxy — proxy сервер,
nginx — веб-сервер для отдачи статики,
mysql — субд.

Перед командой эксплуатации встал резонный вопрос: как настроить управление окружением на восьми серверах и сохранить оптимистичное отношение к жизни.

После краткого сравнения систем управления конфигурациями был выбран Ansible. В его пользу сыграли простота, гибкость и отсутствие агентов на управляемых серверах.

Мы начинаем публиковать курсы лекций Технополиса — образовательного проекта команды Одноклассников в Санкт-Петербургском Политехническом университете Петра Великого. Создание высоконагруженных приложений — это не только проектирование и написание кода, но и огромное количество других аспектов на всём протяжении жизненного цикла продукта. Мы пройдём по всему процессу создания и использования высоконагруженной системы. Особое внимание будет уделено особенностям эксплуатации, сетям, балансировке нагрузки, иерархии памяти, повседневным инструментам. Также поговорим о мониторинге, аудите и многом другом. Лекции курса читает команда экспертов под руководством ведущего разработчика в Одноклассниках Вадима Цесько.

Список лекций:

1. Введение (Вадим Цесько incubos)
2. Типовые архитектуры (Александр Христофоров)
3. Эксплуатация (Илья Щаников)
4. Сетевой стек (Дмитрий Самсонов dmitrysamsonov)
5. Балансировка (Андрей Домась)
6. Процессоры и память (Алексей Горбов)
7. Хранилища данных (Сергей Егоричев)
8. JVM (Андрей Паньгин apangin)
9. Мониторинг (Сергей Шарапов Sharapoff)
10. Облака (Леонид Талалаев)

С предыдущей частью статьи можно ознакомиться, перейдя по ссылке

III Определение понятия архитектор

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

Зачастую в ИТ отрасли, говоря об ИТ архитекторе, подразумевают продвинутого разработчика, способного самостоятельно спроектировать, а главное реализовать большую сложную систему. А иногда попросту полагают, что это следующая ступенька в профессиональной иерархии разработчиков. Например, начал молодой специалист свою карьеру разработчика, ему присвоили скромное, но почетное звание Junior. Он учится, развивается профессионально, растет над собой и коллегами, и ему, в качестве компенсации за труд и упорство, торжественно присваивается звание Middle. Но он неугомонный и дальше не останавливается в развитии, совершает ряд подвигов, самоотверженно взвалив на себя ответственность за принимаемые решения. Глядишь, и его уже удостаивают высочайшего звания Sinior. А дальше? А если он не желает почивать на лаврах успеха и хочет развиваться, ему что присвоят под звуки фанфар генеральское звание Архитектора? Так ли это?

Специально ИТ архитекторов, насколько мне известно, не готовят в вузах. Чаще всего архитекторы получаются путем селекции из уже маститых специалистов в какой-либо ИТ области, «прокачивая» дополнительными знаниями до определенного уровня.

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

I. Вступление

Архитектура распределяет массы и объемы.
Вдохновение превращает инертный камень в драму.
Ле Корбюзье.

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

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

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


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

Павел Филонов (Лаборатория Касперского)

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

Введение

Любому системному администратору постоянно приходится иметь дело с данными, представленными в форме временных рядов (time series): статистика скачивания файлов, статистика запросов к серверам, данные об использовании системных и аппаратных ресурсов виртуальными машинами…

Чтобы все это хранить и обрабатывать, нужен адекватный и производительный инструмент.

Большинство разработчиков имеет только примерное представление о том что происходит внутри Spring Security, что опасно и может привести к появлению уязвимостей.

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

Меня зовут Аркадий, я Android-разработчик в Badoo. В последнее время в нашем блоге много постов про Go, PHP, JS, QA, и я решил разбавить их темами по мобильной разработке. Как раз занимался портированием одного Android-проекта с RxJava 1 на RxJava 2 и читал всё, что можно найти на эту тему в интернете. В частности, доклад Джейка Вортона с конференции GOTO Copenhagen 2016. Мне показалось, что это достойный кандидат на перевод – думаю, многие Android-разработчики задумываются о переходе на RxJava 2, и им интересно, что изменилось по сравнению с первой версией.

Джейк сделал достаточно объёмное введение о реактивном программировании, так что знание RxJava 1 не требуется для понимания статьи. Доклад был подготовлен, когда RxJava2 ещё только готовилась к выпуску (на текущий момент уже выпущена версия 2.1.0).

Ну что ж, вы решили выучить новую вещь, которая называется Реактивное программирование (Reactive Programming), а в частности — его имплементацию в виде Rx, Bacon.js, RAC или чего-то другого.

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

Под катом небольшой обзор восьми книг. Темы следующие:

1. RxJava
2. Потоки в Android
3. Разработка под Android на Java
4. Kotlin. Обзор языка
5. Kotlin. Практика
6. Kotlin. Обзор языка с уклоном на Android
7. Разработка под Android на Kotlin
8. Rx в Kotlin

Недавно коллега задал привычные уже вопросы про «зачем ходить на конференции» и «зачем смотреть записи на YouTube». Так как это друг, а не просто какой-то произвольный человек, захотелось ответить более обстоятельно, детально и по чесноку. К сожалению, в режиме онлайн, при живом общении, сделать это сложно: просто не упомнишь всех подробностей. С другой стороны, это отличная тема для хабрапоста: можно один раз написать развёрнутый обзор и потом, как истинный социофоб, отвечать на все вопросы ссылками на Хабр.

Идея проста: надо взять наиболее популярные доклады с JPoint 2017, кратенько пересказать, о чём там речь, почему это круто и зачем нужно лично мне. Каждый из этих докладов заслуживает отдельного разбора, но вначале — краткий обзор первой десятки. Поехали!

В сегодняшнем материале мы собрали одни из наиболее популярных книг, отобранных самими разработчиками — резидентами Reddit, Quora, Stack Exchange, Stack Overflow и Hacker News.

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

В Playrix приходит много новых сотрудников и большинство из них не работали с Git. Особенно это касается гейм-дизайнеров и художников. Хотя и для программистов это не редкость – опыт работы с другими системами контроля версий не слишком помогает. Например, часто встречается опыт работы с SVN. Но Git заметно отличается по идеологии. Заучить, какие кнопки нажимать, в большинстве случаев не сложно, но шаг в сторону – и уже трудно понять, что происходит.



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

Из блога Netflix Technology

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

Один из вариантов решения проблемы — принять в учёт картинки или обложки для фильмов. Если картинка выглядит убедительно, то она служит толчком и неким визуальным «доказательством», что фильм достоин просмотра. На ней может быть изображён известный вам актёр, захватывающий момент вроде автомобильной погони или драматическая сцена, передающая суть фильма или сериала. Если мы покажем идеальную обложку фильма на вашей домашней странице (как говорится, картинка стоит тысячи слов), то возможно, только возможно, вы решитесь выбрать этот фильм. Это просто ещё одна вещь, в которой Netflix отличается от традиционных медиа: у нас не один продукт, а более 100 млн разных продуктов, а каждый из пользователей получает персональные рекомендации и персональные обложки.


Главная страница Netflix без обложек. Так исторически наши алгоритмы рекомендаций видели страницу

Этот пост является продолжением предыдущего. Мониторинг прогнозированием – не стандартный метод мониторинга. Поэтому и оповещения необходимо использовать не совсем стандартные. Рассмотрим, как это делается и почему именно так.