Последний учебный год, апрель месяц. Студента все чаще и чаще начинают посещать мысли о том, что надо бы заняться дипломной работой. Заняться — в смысле придумать, как быстро состряпать нечто, что будет хотя бы созвучно той теме, которую, вроде как, утверждали с научным руководителем. А, да, надо хотя бы на 80 страниц, еще и соблюсти ГОСТы там всякие… Понятное дело, самому столько связного текста уже не успеть набрать (да еще и могут начать в суть работы вникать, ну его!). Очевидно — надо брать готовую работу, которую уже защитили, работу качественную, проверенную и одобренную. Знакомая всем нам ситуация. Открытым остается единственный вопрос — как сделать так, чтобы работа прошла проверку на заимствования… Поиск в интернете и общение с коллегами по несчастью приводят студента к следующим вариантам решения проблемы:

• Написать работу самому;
• Перефразировать текст (дорого и сложно);
• Обхитрить систему с помощью «технических обходов».

Давайте посмотрим, какими бывают технические обходы, как мы их отлавливаем и почему их применение — не самая хорошая идея…

«Flying Cart», Afu Chan

Я работаю в Mail.ru Cloud Solutons архитектором и разработчиком, в том числе занимаюсь нашим облаком. Известно, что распределенной облачной инфраструктуре нужно производительное блочное хранилище, от которого зависит работа PaaS-сервисов и решений, построенных с их помощью.

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

Расскажу, как это было — возможно, эта история, проблемы, с которыми мы столкнулись, и наши решения будут полезны тем, кто тоже использует Ceph. Кстати, вот видеоверсия этого доклада.

Публикуем второй отчет зарплатного сервиса «Моего круга». Отчёт построен на данных по 7900+ зарплатам, внесенных нашими пользователями за последние полгода. 70% зарплат внесено разработчиками, остальные — администраторами, тестировщиками, менеджерами, аналитиками, дизайнерами, эйчарами, маркетологами и специалистами поддержки.

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

Как я писал в предисловии предыдущей статьи, я нахожусь в поисках языка, в котором я мог бы писать поменьше, а безопасности иметь побольше. Моим основным языком программирования всегда был C#, поэтому я решил попробовать два языка, симметрично отличающиеся от него по шкале сложности, про которые до этого момента приходилось только слышать, а вот писать не довелось: Haskell и Go. Один язык стал известен высказыванием "Avoid success at all costs"*, другой же, по моему скромному мнению, является полной его противоположенностью. В итоге, хотелось понять, что же окажется лучше: умышленная простота или умышленная строгость?

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

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

_{Источник изображения:}

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

Всех приветствую. Это текст от первого лица. Пишет Дмитрий Козменко.

Прежде всего хочу подчеркнуть, что мы, сочинский провайдер «Бизнес-Связь», в течение пяти лет успешно используем технологию пассивной оптической сети в городе Сочи и прилегающих посёлках. На данный момент у нас работает более тридцати головных станций GPON, обслуживающих несколько тысяч абонентов. Мы знакомы с технологией не понаслышке, участвовали в закрытых тестированиях, дебажили прошивки вместе с разработчиками как самих устройств, так и чипсетов. То есть технологию GPON мы, разумеется, используем в работе. Однако там, где есть возможность, работаем с классической схемой по «витой паре». И нам почему-то никогда не приходило в голову брать месседж про GPON в каких бы то ни было маркетинговых завлекаловках абонентов или же в качестве какого-то нашего совершенно особенного конкурентного преимущества. Потому что, если разобраться внимательно и в деталях, абонентам технология GPON как шла, так и ехала. А тот факт, что многие провайдеры позиционируют использование GPON как сильное продуктовое преимущество для абонентов – это выглядит странно. Если не сказать, что выглядит очковтирательством немножк☺.

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



Мы поговорили с Алексеем Усовым, сертифицированным специалистом RHCA Level XIII – о том, как выбрать программу обучения, зачем нужна сертификация, как проходят экзамены, как к ним подготовиться и что все это дает на выходе.

Заголовок статьи звучит как epic fail, но на самом деле все не так однозначно. Да и в общем и целом эта история закончилась весьма позитивно, хоть и не в Google. Но это уже тема для другой статьи. В этой же статье я расскажу о трех вещах: каким образом проходил мой процесс подготовки, каким образом проходили интервью в Google и почему же на мой взгляд все не так однозначно, как может показаться.

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

Google ищет инженеров постоянно. Как SRE, могу точно сказать, что вы нужны в наших рядах. Печеньки на мини кухнях и кофе в кофемашинах ждут вас. Всего-то нужно пройти собеседование. Это сложно, но реально — когда-то я уже описывал свою историю как соискателя, а сейчас уже в числе прочего занимаюсь и проведением собеседований. Так что сейчас я расскажу, как мы проводим собеседования с инженерами.

Нет, я не стал рекрутером. Процесс собеседования предполагает сперва разговор с рекрутером. Это общая беседа “что-куда-зачем” (то есть описание процесса для вашего конкретного случая) и тот самый всеми любимый скрининг из опросника с несколькими вариантами ответов. Скрининг мне в своё время показался весьма базовым, подозреваю, что вы отвечали на такие вопросы уже сотню раз. Затем собеседования будут проводиться уже инженерами — вашими будущими коллегами (близкими или далёкими, это уже как получится, наша планета весьма небольшая).

Привет! Меня зовут Вадим Мадисон, я руковожу разработкой System Platform Авито. О том, как мы в компании переходим с монолитной архитектуры на микросервисную, было сказано не раз. Пора поделиться тем, как мы преобразовали свою инфраструктуру, чтобы извлечь из микросервисов максимум пользы и не дать себе в них потеряться. Как нам здесь помогает PaaS, как мы упростили деплой и свели создание микросервиса к одному клику — читайте дальше. Не всё, о чём я пишу ниже, в Авито реализовано в полной мере, часть — то, как мы развиваем нашу платформу.

(А ещё в конце этой статьи я расскажу о возможности попасть на трехдневный семинар от эксперта по микросервисной архитектуре Криса Ричардсона).

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

25 марта мы открыли регистрацию на Linux Quest, это Игра для любителей и знатоков операционной системы Linux. Немного статистики: зарегистрировалось на игру 1117 человек, из них 317 — нашли хотя бы один ключ, 241 успешно справились с заданием первого этапа, 123 — второго и 70 прошли третий этап. Сегодня наша игра подошла к концу, и мы поздравляем наших победителей!

«Флант» — это технологическая компания. Сейчас у нас порядка 60 человек и 7 команд. Что примечательно, практически все в той или иной мере инженеры — включая менеджеров, которые нет-нет, да и напишут строчку-другую кода.

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

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

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

У этих классических отношений есть вариации — опционы, проценты, бонусы, которые немного напоминают, что владельцы и сотрудники в одной лодке. Но бывают и менее типичные ситуации.

Компания Флант состоит из нескольких команд девопосов, которые обслуживают чужие продакшены под ключ. Они выросли из банды студентов-энтузиастов и фанатов Linux, а сейчас построили структуру «бизнесов внутри бизнеса», просто потому что так комфортнее и честнее. Дима Столяров и Саша Баталов рассказали нам, как это устроено.

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

_{Источник изображения:www.nikonsmallworld.com}

Антиплагиат – это специализированный поисковик, о чем уже писали ранее. А любому поисковику, как ни крути, чтобы работать быстро, нужен свой индекс, который учитывает все особенности области поиска. В своей первой статье на Хабре я расскажу о текущей реализации нашего поискового индекса, истории его развития и причинах выбора того или иного решения. Эффективные алгоритмы на .NET — это не миф, а жесткая и продуктивная реальность. Мы погрузимся в мир хеширования, побитового сжатия и многоуровневых кешей с приоритетами. Что делать, если нужен поиск быстрее, чем за O(1)?

Если кто-то еще не знает, где на этой картинке шинглы, добро пожаловать…

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

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

Облака, белогривые лошадки...

^{(откуда-то из интернета, впервые увидел тут.)}

Нагрузка на нашу систему сильно неравномерна: во-первых, в течение суток нагрузка меняется в 5 раз. Во-вторых, есть и ярко выраженная сезонность. Суточный максимум проверок после окончания летней сессии уменьшается в 10 раз! Зимняя сессия не столь яркая, но тоже не подарок. Плюс каждая последующая летняя сессия тяжелее (по числу проверок) и сложнее (новые технологии поиска и функциональность) предыдущей. Поэтому, с одной стороны, хочется иметь хороший запас по ресурсам, с другой – не платить лишнего во время спада активности. В сессию можно развернуть побольше серверов, а летом сократить объем потребляемых ресурсов. Очевидно, что это как раз случай облачных провайдеров. В этой статье я расскажу о различных аспектах взаимодействия с несколькими облачными провайдерами (AWS, ИТ-Град, MCS, YC). Если кому-то покажется, что это крик души, он не сильно ошибется. Итак, поехали!

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

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

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

English version is also available.

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

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


Далее вы найдете видео и текстовую версию одного из лучших докладов DevOpsConf Russia 2018.

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

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

«Успешными преподавателями становятся те, кто выбирает это занятие для удовольствия»

Если вас посещала мысль, а не податься ли в преподаватели, то наверняка вы задумывались и над тем, есть ли у вас для этого необходимые умения, навыки и склонность. И как вообще предложить миру свои услуги преподавателя, если ты хорошо разбираешься в своей IT-профессии, но не имеешь педагогического образования? Руководитель отдела подбора преподавателей и методистов GeekBrains Людмила Карамышева срывает покровы и рассказывает, как мы ищем преподавателей на наши IT-курсы, как стать популярным преподавателем и почему это получается не у всех разработчиков.