Привет!

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

Зачем всё это и для чего?

У нас было: 10 самых простых конфигураций серверов на DigitalOcean, мобильные устройства на базе iOS, сервер для сбора статистики, никакого опыта в настройке VPN-серверов, а также неукротимое желание сделать быстрый, надёжный и простой в использовании VPN-сервис, которым будет приятно пользоваться. Не то, чтобы всё это было категорически необходимо, но если уж начали, то к делу надо подходить серьёзно.

Привет, Хабр! Меня зовут Паша Доронин и бóльшую часть жизни я работаю в индустрии переводов и локализации. Я долгое время проработал в компании Smartcat, где прошел путь от аналитика до менеджера по продукту. Несколько месяцев назад я переехал в Дублин и решил заняться дальнейшим развитием своей карьеры.

На этот раз я решил сменить схему поиска вакансий – раньше я просто смотрел на то, «что есть», и выбирал интересные варианты. Теперь же хотелось исходить из того, что хочу получить на новом месте я, и уже соответственно фильтровать объявления. За период активного поиска я связался с 17 компаниями из Европы и США, и устроился в AI-стартап Intento (недавно поднял новый раунд инвестиций). Вот что я понял по итогам этого процесса.

Привет, Хабр! Когда-то наша команда решила собрать список важных источников для расширения кругозора наших сотрудников в IT-индустрии.

Поэтому мы подумали и решили опубликовать наш список используемых ресурсов и здесь:

Все дистрибутивы Linux поставляются с функциональным и кастомизируемым эмулятором терминала. В интернете, а порой даже в самом терминале, есть масса готовых тем, чтоб он красиво выглядел. Однако, чтоб сделать из стандартного терминала (в любом DE, любого дистрибутива) нечто красивое и одновременно удобное и простое в использовании я потратил много времени. Итак, как же сделать дефолтный терминал удобным и приятным в использовании?

Бывает, что нужно получить полную копию тома в рамках одной системы хранения данных (СХД), не снимок, клон, а именно полноценный том. Но не всегда СХД дает это сделать внутри себя собственными средствами. Вроде единственный вариант копировать через сервер, но при этом весь объем данных будет гоняться через сам сервер, сеть до СХД и порты СХД, нагружая все эти компоненты. Но есть SCSI команды, которые могут позволить сделать все в рамках самой СХД и если ваша система поддерживает VAAI от VMware, то практически 100%, что поддерживается команда XCOPY (EXTENDED COPY), которая и говорит массиву что и куда скопировать, не вовлекая в этот процесс сервер и сеть.

Валентин Нык, Руководитель отдела систем управления ИТ-инфраструктурой, КРОК

В «КРОК» появилась идея создать систему комплексного мониторинга (СКМ), которая заменит существующие промышленные решения. Такая потребность возникла, потому что бизнесу стало невыгодно пользоваться иностранными разработками. Они подорожали, не учитывают потребности российских клиентов и могут попасть под санкции.

На дворе 2020 год и фоновым шумом вы уже привыкли слышать: «Кубернетес — это ответ!», «Микросервисы!», «Сервис меш!», «Сесурити полиси!». Все вокруг бегут в светлое будущее.

Подходы в том, что касается баз данных, в нашей компании более консервативны, чем в прикладных приложениях. Крутится база данных у нас не в кубернетесе, а на железе или в виртуалке. Для изменений базы данных процессинга платежных сервисов у нас есть устоявшийся процесс, который включает в себя множество автоматических проверок, большое ревью и релиз с участием DBA. Количество проверок и привлекаемых людей в этом случае негативно влияет на time-to-market. С другой стороны, он отлажен и позволяет надежно вносить изменения в продакшен, минимизируя вероятность что-то сломать. А если что-то сломалось, то нужные люди уже включены в процесс починки. Этот подход делает работу основного сервиса компании стабильнее.

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



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

Написать подобный пост меня сподвигло потраченное время на решение проблемы.

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

Прежде чем найти решение я искал проблему в обновлении видео-драйверов, в ssd, в самой виртуалке, но никак не в том, что явилось причиной — обновление до версии 2004.

Долго разбирал лог vbox.log на предмет ошибок, пока не наткнулся на это:

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

Intro

Напомню некоторые вводные:

• мы строим сервис, который получает информацию из логов серверов PostgreSQL
• собирая логи, мы хотим что-то с ними делать (парсить, анализировать, запрашивать дополнительную информацию) в режиме онлайн
• все собранное и «наанализированное» надо куда-то сохранить

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

Более полно о принципах работы сервиса можно посмотреть в видео доклада и прочитать в статье «Массовая оптимизация запросов PostgreSQL».

^{Люцерн на фото Олега Ненашева}

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

А в случае с IT-эмиграцией всё ещё хитрее. Российский разработчик, даже никуда не уезжая, постоянно имеет дело с английским. В эмиграции он может столкнуться с другим языком, но и английский никуда не денется. И при этом, поскольку большая часть жизни проходит в онлайне, можно не бросать русский (например, писать на Хабр или записывать подкаст). Получается жонглирование тремя языками.

Как тогда выглядит жизнь IT-эмигранта с языковой точки зрения? И как в этой жизни присутствует русскоговорящее IT-сообщество? Я расспросил шестерых человек, уехавших в самые разные страны, от Норвегии до Австралии. Троих знаю по их докладам на конференциях, которые организуем мы в JUG Ru Group, а другие трое — авторы популярных хабрапостов из хаба «IT-эмиграция».

Разработка хранилища — дело долгое и серьезное.

Многое в жизни проекта зависит от того, насколько хорошо продумана объектная модель и структура базы на старте.

Общепринятым подходом были и остаются различные варианты сочетания схемы “звезда” с третьей нормальной формой. Как правило, по принципу: исходные данные — 3NF, витрины — звезда. Этот подход, проверенный временем и подкрепленный большим количеством исследований — первое (а иногда и единственное), что приходит в голову опытному DWH-шнику при мысли о том, как должно выглядеть аналитическое хранилище.

С другой стороны — бизнесу в целом и требованиям заказчика в частности свойственно быстро меняться, а данным — расти как “вглубь”, так и “вширь”. И вот тут проявляется основной недостаток звезды — ограниченная гибкость.

И если в вашей тихой и уютной жизни DWH-разработчика внезапно:

• возникла задача “сделать быстро хоть что-то, а потом посмотрим”;
• появился бурно развивающийся проект, с подключением новых источников и переделкой бизнес-модели минимум раз в неделю;
• появился заказчик, который не представляет как система должна выглядеть и какие функции выполнять в конечном итоге, но готов к экспериментам и последовательному уточнению желаемого результата с последовательным же приближением к нему;
• заглянул менеджер проектов с радостной вестью: “А теперь у нас аджайл!”.

Или если вам просто интересно узнать как еще можно строить хранилища — вэлкам под кат!

Вот среднегодовые вложения в IT нескольких крупнейших европейских банков:

BNP Paribas — $7,1 млрд
HSBC — $6,0 млрд
Societe Generale — $4,7 млрд
Deutsche Bank — $4,5 млрд
UBS — $3,5 млрд
Barclays — $3,5 млрд
RBS — $2,9 млрд
Credit Suisse — $2,9 млрд
Commerzbank — $1,4 млрд

Это затраты как на собственные IT-отделы, так и на приобретение сторонних продуктов. Первая четвёрка в совокупности обгоняет Google (Alphabet Inc.) с его $21,4 млрд.

Тренд на цифровизацию постоянно звенит в новостях. Например, о внутренней реструктуризации Deutsche Bank, в результате которой 975 человек лишилось привычных мест трейдеров и банкиров. При этом половина сотрудников банка заняты в IT. Или о партнёрстве британского TSB Bank с IBM Services для внедрения облачных технологий и превращения первого в по-настоящему цифровой бизнес. Бюджет на реализацию проекта оценивается в £120 млн.

Не знаю, как для вас, а для меня это не просто £120 млн, а «120 миллионов фунтов стерлингов, Карл!».

Эта статья о том, что европейские банки хотят в IT. Это хорошая новость для нас с вами (ИТ-шников). Делюсь информацией, что сейчас происходит в Европе. Точнее, что нам удалось накопать. Будет много ссылок на источники.

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

Доклад Дарьи Вилковой для Zabbix Meetup Online

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

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

Мы создали активный агент — Mamonsu, который обеспечивал более гибкий мониторинг, чем на тот момент позволяли стандартные средства, и обеспечивал сбор метрик и их отправку на Zabbix Server. В нашей компании Mamonsu используется при проведении аудита.

Это компактный дайджест с литературой о настройке сетевой инфраструктуры и политик безопасности. Мы выбрали книги, часто упоминаемые на Hacker News и других тематических площадках об управлении ресурсами сетей, настройке и защите облачной инфраструктуры.

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

Почему важно знать и уметь обращаться с языками запросов? По своей сути в Data Science есть несколько важнейших этапов работы и самый первый и важнейший (без него уж точно ничего работать не будет!) — это получение или извлечение данных. Чаще всего данные в каком-то виде где-то сидят и их нужно оттуда «достать». 

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

Всего будет три основных блока типов запросов к данным, которые мы разберем в данной статье:

• «Стандартные» языки запросов — то, что обычно понимают, когда говорят о языке запросов, как, например, реляционная алгебра или SQL.
• Скриптовые языки запросов: например, питоновские штучки pandas, numpy или shell scripting.
• Языки запросов к графам знаний и графовым базам данных.

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

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

Побудительным мотивом к написанию этюда послужила статья «В карантин нагрузка выросла в 5 раз, но мы были готовы». Как Lingualeo переехал на PostgreSQL с 23 млн юзеров. Так же показалось интересной статья опубликованная 4 года назад — Реализация бизнес-логики в MySQL.

Показалось интересным то, что одна и та же мысль-"реализовать бизнес-логику в БД".



пришла в голову не только мне одному.

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

Описанные методы не являются каким то открытием и исключительным know how, все по классике и было реализовано неоднократно (я например подобный подход применил 20 лет назад на Oracle).Просто решил собрал все в одном месте. Вдруг кому пригодится. Как показала практика — довольно часто одна и та же идея приходит независимо разным людям. Да и для себя оставить на память, полезно.

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

ELK SIEM Open Distro: ELK stack — установка и настройка.

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

TL;DR: я устанавливаю Wireguard на VPS, подключаюсь к нему с домашнего роутера на OpenWRT, и получаю доступ к домашней подсети с телефона.

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

Вместо этого я настроил VPN с доступом в домашнюю локалку. Плюсы такого решения:

• Прозрачность: чувствую себя как дома при любых обстоятельствах.
• Простота: настроил и забыл, не надо думать о пробросе каждого порта.
• Цена: у меня уже есть VPS, для таких задач современный VPN почти бесплатен по ресурсам.
• Безопасность: ничего не торчит наружу, можно оставить MongoDB без пароля и никто не утащит данные.

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