В преддверии старта нового потока по курсу «Разработчик Golang» подготовили перевод интересного материала.

---

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

dnsflood — это небольшой инструмент, способный генерировать огромное количество udp запросов.

# timeout 20s ./dnsflood example.com 127.0.0.1 -p 2053

Мониторинг систем показал, что использование памяти нашим сервисом росло так быстро, что нам пришлось остановить его, иначе мы столкнулись бы с OOM ошибками. Это было похоже на проблему утечки памяти; существуют различные причины «похожих на» и «реальных» утечек памяти в go:

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

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

Как быть, если дерево поиска разрослось на всю оперативку и вот-вот подопрет корнями соседние стойки в серверной? Что делать с инвертированным индексом, жадным до ресурсов? Завязывать ли с разработкой под Android, если пользователю прилетает «Память телефона заполнена», а приложение едва на половине загрузки важного контейнера?

В целом, можно ли сжать структуру данных, чтобы она занимала заметно меньше места, но не теряла присущих ей достоинств? Чтобы доступ к хэш-таблице оставался быстрым, а сбалансированное дерево сохраняло свои свойства. Да, можно! Для этого и появилось направление информатики «Succinct data structures», исследующее компактное представление структур данных. Оно развивается с конца 80-х годов и прямо сейчас переживает расцвет в лучах славы big data и highload.

А тем временем на Хабре найдется ли герой, способный пересковоговорить три раза подряд
[səkˈsɪŋkt]?

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

Дальше я приведу несколько наборов слов, сгруппированных по типовым ошибкам. К каждому слову будет приложена транскрипция, приблизительная транскрипция на русском и ссылка на более детальную информацию в словаре. Так как большинство IT компаний все-таки работает с Северной Америкой, то транскрипции будут из US English.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Scheduling In Go: Part I — OS Scheduler» автора Билла Кеннеди, о том, как работает внутренний планировщик Go.

Это первый пост в серии из трех частей, который даст представление о механике и семантике, лежащей в основе планировщика в Go. Этот пост посвящен планировщику операционной системы. Начнем!

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

В интернете есть много статей с описанием алгоритма градиентного спуска. Здесь будет еще одна.

8 июля 1958 года The New York Times писала: «Психолог показывает эмбрион компьютера, разработанного, чтобы читать и становиться мудрее. Разработанный ВМФ… стоивший 2 миллиона долларов компьютер "704", обучился различать левое и правое после пятидесяти попыток… По утверждению ВМФ, они используют этот принцип, чтобы построить первую мыслящую машину класса "Перцептрон", которая сможет читать и писать; разработку планируется завершить через год, с общей стоимостью $100 000… Ученые предсказывают, что позже Перцептроны смогут распознавать людей и называть их по имени, мгновенно переводить устную и письменную речь с одного языка на другой. Мистер Розенблатт сказал, что в принципе возможно построить "мозги", которые смогут воспроизводить самих себя на конвейере и которые будут осознавать свое собственное существование» (цитата и перевод из книги С. Николенко, «Глубокое обучение, погружение в мир нейронный сетей»).

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

Если ваша работа требует держать множество SSH-сессий к разным серверам, вы наверняка знаете, как они легко ломаются при переключении на другой Wi-Fi или при временной потере интернета. Но что, если я скажу вам, что все эти проблемы давно решены и можно забыть про сломанные сессии и постоянные переподключения?

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

Чтобы попасть в игровую индустрию, мало уметь хорошо делать своё дело. Для ребят из Banzai.Games учеба не заканчивается никогда. А все потому, что голод до новых знаний — штука посильнее творческих амбиций.

Сегодня мы поделимся с вами самым ценным (после своих игр, конечно же), что есть у разработчика видеоигр — знаниями и опытом. Катя, художник студии, расскажет о 5 книгах, которые необходимо прочитать каждому, кто хочет прокачать своё мастерство.

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

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

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

Интервьюер прервал меня на последнем слове, дополнив свой вопрос: «Предположим, что данные нам не нужны, это просто дебаг лог, но приложение не работает из-за того, что не может записать дебаг»?

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

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

Интервьюер остался доволен, а я нет.

Тогда я подумал, почему человек, проверяющий мои знания, не копает глубже? А что, если данные все-таки важны? Что если мы не можем перезапускать процесс, и при этом этот процесс пишет на файловую систему в раздел, на котором нет свободного места? Что если мы не можем потерять не только уже записанные данные, но и те данные, что этот процесс пишет или пытается записать?

У нас в Mail.ru Group есть Tarantool — это такой сервер приложений на Lua, который по совместительству ещё и база данных (или наоборот?). Он быстрый и классный, но возможности одного сервера всё равно не безграничны. Вертикальное масштабирование тоже не панацея, поэтому в Tarantool есть инструменты для горизонтального масштабирования — модуль vshard [1]. Он позволяет шардировать данные по нескольким серверам, но придётся повозиться, чтобы его настроить и прикрутить бизнес-логику.

Хорошие новости: мы собрали шишек (например [2], [3]) и запилили очередной фреймворк, который заметно упростит решение этой проблемы.

Тarantool Cartridge — это новый фреймворк для разработки сложных распределённых систем. Он позволяет сфокусироваться на написании бизнес-логики вместо решения инфраструктурных проблем. Под катом я расскажу, как этот фреймворк устроен и как с его помощью писать распределённые сервисы.

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

Надо понимать, часто недостаточно полистать go-database-sql.org. Лучше вооружиться чужим опытом. Еще лучше, если это будет опыт, полученный кровью и потерянными деньгами.

Едва ли будет неверным сказать, что лучшие из людей
обретают радость через страдание.
Людвиг ван Бетховен

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

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

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

В статье я приведу цифры и расчеты. А еще свой вариант решения проблемы и устройство, собранное для этого. Кому интересно, прошу под кат…

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

В данной статье я расскажу о своём опыте "заворачивания" Laravel-приложения в Docker-контейнер да так, что бы и локально с ним могли работать frontend и backend разработчики, и запуск его на production был максимально прост. Так же CI будет автоматически запускать статические анализаторы кода, phpunit-тесты, производить сборку образов.

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

• "Использую докер для локальной разработки. Ставлю laradock и беды не знаю". Круто, но как обстоят дела с автоматизацией и запуском на production?
• "Собираю один контейнер (монолит) на базе fedora:latest (~230 Mb), ставлю в него все сервисы (nginx, бд, кэш, etc), запускаю всё супервизором внутри". Тоже отлично, прост в запуске, но как на счёт идеологии "один контейнер — один процесс"? Как обстоят дела с балансировкой и управлением процессами? Как же размер образа?
• "Вот вам куски конфигов, приправляем выдержками из sh-скриптов, добавим магических env-значений, пользуйтесь". Спасибо, но как же на счёт хотя бы одного живого примера, который я бы мог форкнуть и полноценно поиграться?

Для нетерпеливых — ссылка на репозиторий, склонировав который ты сможешь запустить Laravel-приложение одной командой. Так же не составит труда его запустить на том же rancher, правильно "слинковав" контейнеры, или использовать продуктовый вариант docker-compose.yml как отправную точку.

Всем привет,

В предыдущей статье я писал о том, что мы сделали новую in-memory БД — быструю и с богатыми функциональными возможностями — Reindexer.

В этой статье хочу рассказать как при помощи Reindexer можно реализовать полнотекстовый поиск по сайту, написав минимум application кода.

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

TL;DR В статье описывается процесс создания системы контроля доступа (СКУД), в которой в качестве идентификатора могут использоваться карты Тройка, любые бесконтактные банковские карты EMV, а также телефоны с Apple Pay и Android Pay. Управление системой происходит через Telegram-бота.

Основные задачи системы

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

В конце прошлого года компания Buoyant, уже прославившаяся выпуском одного из популярнейших решений категории service mesh (т.е. «сетки», обеспечивающей взаимодействие между сервисами) — Linkerd, — анонсировала своё второе детище под названием Conduit. Можно было бы удивиться, что новый продукт — это ещё один service mesh с открытым кодом, но есть тому причины.

Всем доброго!

Мы возвращаемся к нашей любимой традиции — раздача полезностей, которые мы собираем и изучаем в рамках наших курсов. Сегодня у нас на повестке дня курс по DevOps и один из его инструментов — Kubernetes.

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

Распределенные системы сложны сами по себе, а управление сервисами на распределенных системах — одна из сложнейших проблем, с которыми сталкиваются команды управления. Мы очень серьезно относимся к вводу нового программного обеспечения в производство и обучению его надежному управлению. В качестве примера важности управления Kubernetes (и почему это так сложно!), почитайте отличный постмортем часового перебоя в работе, вызванного багом в Kubernetes.

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

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

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

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