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

К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

Мы продолжаем публиковать лекции курса «Проектирование высоконагруженных систем», который читается студентам Санкт-Петербургского Политехнического университета командой инженеров из Одноклассников в рамках двухлетней программы «Java-разработчик высоконагруженных приложений» проекта Технополис (совместный проект Mail.Ru Group и СПбПУ). В 2017 году были прочитаны и выложены 10 лекций (30 часов видео), но тема Highload настолько обширна, что за один семестр невозможно охватить всё. Мы лишь ненадолго погрузились в основные аспекты Highload-разработки, каждый из которых достоин отдельного курса. В этом году мы продолжаем закрывать белые пятна и представляем вашему вниманию набор из шести лекций на новые темы: начинаем с параллельных вычислений и livecoding первого этапа студенческого курсового проекта, после чего погружаемся в средства мониторинга и диагностики JVM, а потом переходим к проблемам отказоустойчивости. А после лекции о продвинутых алгоритмах, актуальных в высоконагруженных проектах, завершаем цикл лекцией о существующих подходах к репликации и об их применимости к разным задачам.

Первые десять лекций.

Список новых лекций:

1. Actor Model. Future. Reactive Streams (Вадим Цесько incubos)
2. Livecoding второго этапа проекта (Вадим Цесько incubos)
3. Мониторинг и диагностика JVM (Андрей Паньгин apangin)
4. Site Reliability Engineering (Антон Иванов keyplayer)
5. «Современные» структуры данных (Дмитрий Щитинин dormidoncheg)
6. Репликация (Дмитрий Щитинин dormidoncheg)

В последнее время Confluence и sharepoint стали почти безраздельно править на рынке баз знаний. Системы отличные, не спорю, но лично мне не хватает их гибкости да и в целом как-то не срослось: вики-возможности sharepoint остались где-то на уровне 2005 года (про работу с офисными документами молчу, с ними все гуд), а Confluence в силу своих особенностей с ростом числа статей неумолимо превращался в свалку, в которой невозможно найти что-либо нужное (но, может, проблема была во мне).

Не умаляя достоинства этих систем, хотелось бы рассказать о том, какие возможности есть у Mediawiki в роли корпоративной базы знаний. Само собой, mediawiki подойдет не всем — в ней нет модной интеграции с jira/tfs/etc, перенос документов с картинками из пакета Microsoft Office доставляет кучу неудобств, да и сама она написана на PHP, что в последнее время служит отпугивающим фактором для некоторых айтишников. Тем не менее, платформа живее всех живых и над ее развитием работает изрядное количество людей, коль скоро на ней базируется семейство проектов фонда Викимедиа.

Решив попробовать свои силы на зарубежном рынке, я начал отправлять резюме в различные конторы. Даже не с целью найти работу, а просто для расширения кругозора. Выбор пал на вакансии «Java Developer». Промышленного опыта работы с языком у меня нет, только личный опыт, сертификаты с Oracle Certification Center, книги и.т.д. Честно признаться, на последнем месте работы за полтора года ничего кроме «форов» и «ифов» я не писал (но это совсем уже другая история) поэтому решил, почему бы собственно и нет.

Пропустив историю поиска и разговоров с работодателями, перейду к сути. Одна компания К из города Г написала, что заинтересованы в проведении собеседования со мной после того как я решу задачу.

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

Более пяти лет назад компания Backblaze опубликовала первый отчёт по использованию дисковых накопителей в своих серверах. Backblaze предоставляет услугу дешёвого облачного бэкапа. В основе их инфраструктуры — жёсткие диски потребительского класса. Компания собрала большую статистику по отказоустойчивости разных типов HDD. В то время парк накопителей Backblaze состоял в основном из дисков Seagate, Hitachi и WD, а самыми надёжными оказались диски Hitachi.

С тех пор Backblaze публикует статистику ежегодно, и сейчас пришло время очередного отчёта.

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

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

Практические примеры SSH, которые выведут на новый уровень ваши навыки удалённого системного администратора. Команды и советы помогут не только использовать SSH, но и более грамотно перемещаться по сети.

Знание нескольких трюков ssh полезно любому системному администратору, сетевому инженеру или специалисту по безопасности.

Все чаще для рассказа о мероприятии/товаре/услуге компании создают сайты на базе каких либо конструкторов. Либо своими силами, либо привлекая дизайнеров и без участия программиста. Современные конструкторы позволяют собрать классный, яркий, эффектный сайт, но статичный. Любые изменения нужно вносить «ручками в редакторе» и перепубликовать страницу. Но что делать, если данные меняются очень часто или хочется добавить немного автоматизации — вот тут и могут помочь Гугл Таблицы и Charts Query Language (и знакомы программист).

Hello, everyone! Все еще сражаетесь с армией незнакомых слов? В сегодняшней статье мы поделимся боеприпасами, а именно: техники запоминания, о которых вы не знали; как не упустить важное; как сделать процесс обучения увлекательным и как придумать контекст для слов.

Вы уже слова и на карточках писали, и на мебель клеили, и в телефоне напоминания ставили, а они все никак?

Предисловие для читателей Хабра — статья о поиске работы на рынке разработки в Украине (который в основном об аутсорсе на иностранных заказчиков), поэтому некоторые вещи могут показаться странными (LinkedIn, собеседования с заказчиками, обязательное требование разговорного английского, обсуждение ЗП в долларах) или нерелевантными для РФ. Тем не менее, статья имела большой успех на локальных ресурсах, и читатели попросили меня перевести её на русский.

Этой статьей я хочу начать цикл рассказов о том, как я на протяжении нескольких месяцев проходил собеседования в примерно 20-и разных компаниях на разные должности. Тут будут мои мысли о рынке труда, процессе найма, советы а так же несколько самых интересных историй. Цикл будет состоять из нескольких частей — HR собеседования, технические собеседования, финальные собеседования. Итак, первая часть.

Немного о себе. Программирую со школьного возраста, за деньги работаю 10 с хвостиком лет. Работал админом, программистом, тимлидом, РМ-ом, линейным менеджером. Выполнял обязанности SRE/DevOps, архитекта, HR, офис-менеджера, эникейщика.

Работал в кровавом энтерпрайзе, в стартапе, в аутсорсе. В основном занимался формошлёпством и крудами, имел дело с Java и бэкендом. За последние несколько лет пересел на фуллстек микс из Java, Ruby/RoR, Python, Node.js.

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

Всего я прошел примерно 20 собеседований с рекрутерами: половина из которых были из агенств и половина — штатные рекрутеры/HR компаний. Так что, могу сказать что некоторая статистика у меня есть.

Покупка корпорацией Microsoft сервиса GitHub полностью завершена. Недавно новый CEO GitHub, Nat Friedman, поделился вступительным анонсом, который мы выкладываем здесь. Подробности о будущем сервиса под катом.

Добрый день, %username%. Меня зовут Антон Резников, я работаю над проектом Облако Mail.Ru Сегодня я хочу рассказать о технологиях балансировки трафика, проиллюстрировав историей о развитии социальной сети. Все персонажи выдуманы, а совпадения почти случайны. Статья обзорная, составлена по следам доклада на Highload Junior 2017. Некоторые вещи могут показаться элементарными, но опыт проведения собеседований показывает, что это не совсем так. Кое-что будет спорным, не без этого.

Если интересно, добро пожаловать под кат.

Мировой рынок IT стремительно развивается. С каждым годом профессия разработчика софта становится все более востребованной — уже в 2017 году в мире насчитывался примерно 21 миллион программистов различных направлений.

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

Введение

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

Диаграммы — глоток творчества в этом море текста. О диаграммах и пойдет речь в данной статье. Если точнее — о PlantUML — с моей точки зрения, наиболее адекватном инструменте их создания на текущий момент.

Обычно Google translate используют для перевода речи транслируемой микрофоном.

Но в один момент, автору потребовалось перевести подкаст Медузы в текст.

Идея лежала на поверхности и наверняка программы для этого должны были присутствовать. Так -же как сделано в Gogle translate.

Но, гуглением, программы не нашлось, кроме двух сайтов. Которые использовали по уверениям их авторов всю мощь искусственного интеллекта Google.

Первый нашелся русскоязычный сайт https://speechpad.ru/blog/windows-integration/

Но, как бы не было обидно, магия не сработала…

Много статей и сайтов сравнивают шрифты для программирования — всё это отличные ресурсы. Так зачем я опять поднимаю эту тему? Потому что сам всегда терялся в десятках шрифтов и не мог понять, какой лучше. Так что я опробовал много шрифтов и выбрал следующие для вас. Они довольно популярны и их легко получить. И самое главное, все эти шрифты бесплатны!

Я ранжировал шрифты по следующим показателям:

• Насколько различимы схожие символы, такие как 0O, 1lI.
• Легко ли читается шрифт (ширина строк, ширина/высота символов).
• И мои личные предпочтения!

Все скриншоты сделаны в VSCode на одном фрагменте кода. Если не обозначено иное, то везде установлен размер "editor.fontSize": 14.

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

Чтобы из одного процесса создать задачу для следующей стадии обработки, мы просто вызывали в конце обработки dispatch(), примерно так:

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

По статистике, около 33% компаний попадают под DDoS-атаки. Предсказать атаку невозможно, а некоторые из них могут быть действительно мощными и достигать 300-500 Гб/с. Для того чтобы обезопасить себя от DDoS-атак можно воспользоваться услугами специализированных сервисов. Не все владельцы сайтов знают, куда бежать, если попал под атаку — так что я решил собрать несколько вариантов в одном топике.

Примечание: при подготовке к посту использовались англоязычные материалы и публикации на Хабре

Уже довольно много написано статей, по установке и запуску Kubernetes, однако, не всё так гладко (я потратил несколько суток на запуск своего кластера).

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

Что нужно знать

Серверы:
Кластер подразумевает, что у Вас более одного физического сервера, между которыми и будут распределятся ресурсы. Серверы называются нодами (nodes).

Диски:
Обычные харды в k8s не поддерживаются. Работа с дисками происходит по средствам распределенных файловых хранилищ. Это необходимо для того, чтобы k8s мог «перемещать» контейнеры docker на другие ноды в случае необходимости, без потери данных (файлов).

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

Минимальное разумное количество серверов для Ceph — 3 (можно построить и на одном, но в этом мало смысла из-за высокой вероятности потерять данные).

Сеть:
Нам понадобится Flannel — он позволяет организовать программно определяемую сеть (Software Defined Network, SDN). Именно SDN позволяет всем нашим контейнерам общаться с друг другом внутри кластера (установка Flannel производится вместе с k8s и описана ниже).

Подготовка серверов

В нашем примере мы используем 3 физических сервера. Установите Ubuntu 16.04 на все сервера. Не создавайте swap партиции (требование k8s).

Предусмотрите в каждом сервере как минимум один диск (или партицию) для Ceph.

Не включайте поддержку SELinux (в Ubuntu 16.04 он выключен по-умолчанию).

Мы назвали сервера так: kub01 kub02 kub03. Партиция sda2 на каждом сервере создана для Ceph (форматировать не обязательно).