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

Вот я и решил спустя два с половиной года после переезда в Германию написать что-то демотивирующее про этот период моей жизни.

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

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

Поэтому этот пост я хотел бы адресовать тем специалистам, которые собираются переезжать в Германию со своей семьёй. Я расспросил свою жену о том, как она пережила эти 2,5 года моего профессионального счастья, искала смысл жизни и дошла до того, что открыла в Германии ИП по 3Д-визуализации.

Всем привет.

Я наконец-то изыскал время и написал вторую часть своей истории об IT-эмиграции. Первую часть можно прочитать тут — История переезда системного администратора в Германию. Часть первая: поиск работы и виза. В этой части я опишу подробно, как мы с сестрой обустраивались на новом месте, какие ошибки при этом допускали и сколько нам эти ошибки стоили.

Итак, поехали.

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

Всем привет.

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

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

На Хабре часто пишут про эмиграцию в разные страны, а про Австрию ещё не было. Пора восполнить пробел.

Хальштатт

Я попробую описать мой опыт переезда в Австрию (в Вену), а также немного расскажу про особенности страны, которые я узнал за 6 лет проживания тут. Старался кратко, заранее извиняюсь, что не получилось :)

Перед вами, с разрешения автора, мой довольно вольный пересказ статьи DevOps-инженера Paul Hammant, в которой он очень просто описывает не очень очевидные преимущества Serverless с точки зрения DevOps, а также безопасности работы с бекендом приложения.

Эта статья является первой в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.

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

Итак, начальные условия.

Вы на новом месте работы или у вас повышение или вы решили по-новому взглянуть на свои обязанности. Сеть компании – это ваша зона ответственности. Для вас во многом это челендж и новое, что несколько оправдывает наставнический тон данной статьи :). Но, надеюсь, что статья также может быть полезна и любому сетевому инженеру.

Ваша первая стратегическая цель – научиться противостоять энтропии и удержать уровень предоставляемого сервиса.

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

Утверждён новый список профессий, подходящих для программы профессиональной иммиграции в Канаду.

Вкратце: программисты вошли!

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

1. Почему Чили?

Чили — не самое популярное направление для иммиграции, поэтому мало кто знает, что здесь:

• Открытая миграционная политика. Гражданам РФ на границе ставится туристическая виза на 90 дней. Если вы за это время нашли работу, то можно получить временный внж на один год (visa temporaria). После временного дают бессрочный внж (permanecia definitiva) и через пять лет гражданство. Чилийский паспорт — вездеход, дает право безвизового въезда во множество стран включая всю Европу и США.
• Самая развитая в Южной Америке экономика.
• Средиземноморский климат, по сравнению с которым ночь-улица-фонарь-аптека с ноября по март ощутимо проигрывают.

Так и вышло, что в октябре 2015 года мы, frontend developer и QA engineer купили билеты в один конец и отправились покорять новый континент.

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

Можно бесконечно спорить о понятии «DevOps» — вроде и вакансии есть, и должности, и инструкции, и KPI… Вот только я по-прежнему постоянно вижу совершенно разное восприятие этого понятия между бизнесом, админами и разработчиками. Первые воспринимают DevOps как методологию, вторые — как набор инструментов для автоматизации рутины, а третьи — как набор инструментов для деплоя. В чем-то правы все.

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

Привет, хабр! В этой статье расскажу, как мы в Positive Technologies создавали и развивали отдел автоматизации разработки, внедряли идеи DevOps в практику разработки и какие инструменты и технологии для этого использовали, а также как организовали процессы CI/CD. В том числе поделюсь успехами и планами на будущее.

Про DevOps говорят много и разного. Нам же интересно мнение только тех, кто действительно внедряет и следует DevOps принципам. Так удачно сложилось, что в Программный комитет DevOpsConf Russia входят именно такие люди. Воспользовавшись служебным положением, я задал им восемь одинаковых вопросов:

• Каково главное преимущество DevOps подхода, на твой взгляд?
• Что больше всего может помешать компании в DevOps трансформации?
  
• Как интегрировать специалистов по безопасности в процесс поставки ПО?
  
• Как относишься к поднимающемуся хайпу вокруг SRE?
• Какие инструменты сегодня непременно есть там, где говорят о DevOps?
• Что отличает хорошего инженера от плохого с точки зрения DevOps?
  
• Как логичнее всего попасть в профессию?
  
• Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?

Ответы получились очень любопытными и заодно позволяют составить некоторое впечатление о тех, кто вложил много усилий и немножко души в расписание нашей конференции. Например, ответ на первый вопрос шире, чем сокращение time-to-market. Мнения по поводу SRE разошлись, зато все практически единодушно советуют читать «The DevOps Handbook», но и еще надавали кучу рекомендаций — за ними под кат.

DevOps — это маркетинговое словечко, за которым ничего нет! Или все-таки есть? Может быть, DevOps — это набор «правильных» инструментов, или это такая специальная культура. И кто вообще должен этим заниматься, что из себя представляет DevOps-инженер? Одним словом, есть некоторые разночтения в понятиях, и очень много мифов. Некоторые совсем тривиальные, и мало кто в них поверит, а некоторые пускают корни в умах уважаемых специалистов. Разбираться будем вместе с опытными DevOps’ерами Александром Титовым и Иваном Евтуховичем (evtuhovich). Хотя они и считают, что DevOps — это решение проблемы производства цифровых продуктов и называть так отдельного человека это в стиле российского бизнеса.


О спикерах: Александр Титов и Иван Евтухович представляют компанию Экспресс 42, которая занимается консалтингом в области DevOps. Среди её клиентов много известных компаний, например, МТС, Райффайзенбанк банк, Альфа-Банк и другие.

За 5 лет работы собралась куча мифов про DevOps, которые существуют в обществе. В своем докладе на РИТ++ 2017 Александр и Иван рассуждали на эту тему. Иван в безапелляционном тоне объявлял расхожее мнение, а Александр пытался убедить слушателей в том, что это лишь миф.

В начале октября Wi-Fi Alliance анонсировали новую версию стандарта Wi-Fi – Wi-Fi 6. Её выход намечен на конец 2019 года. Разработчики поменяли подход к именованию — заменили привычные конструкции типа 802.11ax на одиночные цифры. Разбираемся, что еще есть нового.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Сегодня давайте поговорим о преимуществах Postgres перед другими системами с открытым кодом. Эту тему мы обязательно раскроем более подробно на PG Day'16 Russia, до которой осталось всего два месяца.

Возможно, вы спрашиваете себя: «Почему PostgreSQL?» Ведь есть и другие варианты реляционных баз данных с открытым исходным кодом (в рамках этой статьи мы рассматривали MySQL, MariaDB и Firebird), так что же Постгрес может предложить такого, чего нет у них? В слогане PostgreSQL заявляется, что это «Самая продвинутая база данных с открытым исходным кодом в мире». Мы приведем несколько причин, почему Постгрес делает такие заявления.

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

_{Grimoire ensorcele by naiiade}

Любую достаточно развитую технологию можно сравнить с оружием: когда у врага есть ружье, а у тебя нет, поневоле хочется изменить баланс сил в свою пользу. В области IT-безопасности знания, передаваемые различными способами, и есть то самое оружие, использование которого ограничивается не столько нормами УК, сколько этическим выбором.

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

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

Мы рады представить NGINX 1.10 и 1.11. Эти номера версий обозначают стабильную (stable) и основную (mainline) ветки бесплатных открытых выпусков, над которыми мы сфокусируем наши усилия на протяжении следующих 12 месяцев.

NGINX версии 1.10.0 уже вышел, а будущий выпуск основной ветки будет под номером 1.11.0.

Abstract: описание видов ребута, рассказ про sysrq, ipt_SYSRQ, ipmi, psu.

Как перезагрузить сервер? — Это вопрос, который обычно задают ну очень начинающим пользователям, которые путаются между halt, shutdown -r, reboot, init 6 и т.д.

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

В этой статье: что мешает серверу перезагрузиться и как ему помочь.

Начнём с теории ребута.

При выключении или перезагрузке сервера менеджер инициализации (в большинстве современных дистрибутивов — systemd, в эксцентричной Ubuntu 14.04 до сих пор upstart, в архаичном хламе — sysv-init) в определённом порядке посылает всем демонам команду «выключись». И большинство демонов (например, СУБД, вроде mysql) знают, как выключаться правильно. Например, закончить все транзакции, сохранить все несохранённые данные на диск и т.д. Для in-memory СУБД, наподобие redis, это и вовсе может быть критичным: не сохранил — потерял.

Старые системы иницализации ждали неограниченно долго каждый из инит-скриптов. Например, если «шутник» добавил вам в «stop» веточку «sleep 3600», то ваш сервер будет перезагружаться час с хвостиком. А если там цифра поболе, или просто программа, которая не хочет завершаться, то и ребут никогда не закончится.

Ядро — это та часть операционной системы, работа которой полностью скрыта от пользователя, т. к. пользователь с ним не работает напрямую: пользователь работает с программами. Но, тем не менее, без ядра невозможна работа ни одной программы, т.е. они без ядра бесполезны. Этот механизм чем-то напоминает отношения официанта и клиента: работа хорошего официанта должна быть практически незаметна для клиента, но без официанта клиент не сможет передать заказ повару, и этот заказ не будет доставлен.
В Linux ядро монолитное, т.е. все его драйвера и подсистемы работают в своем адресном пространстве, отделенном от пользовательского. Сам термин «монолит» говорит о том, что в ядре сконцентрировано всё, и, по логике, ничего не может в него добавляться или удаляться. В случае с ядром Linux — это правда лишь отчасти: ядро Linux может работать в таком режиме, однако, в подавляющем большинстве сборок возможна модификация части кода ядра без его перекомпиляции, и даже без его выгрузки. Это достигается путем загрузки и выгрузки некоторых частей ядра, которые называются модулями. Чаще всего в процессе работы необходимо подключать модули драйверов устройств, поддержки криптографических алгоритмов, сетевых средств, и, чтобы уметь это правильно делать, нужно разбираться в строении ядра и уметь правильно работать с его модулями. Об этом и пойдет речь в этой статье.