Как стать автором
Обновить

Комментарии 805

Спасибо, итересно было почитать, сейчас уже на новом месте? Как оно там?
Я работал над Брингли, который закрыли


Что-то знакомое, думаю.
Как я проработала 3 месяца в Я.Маркете и уволилась
Но не все так радужно. Не успела я проработать и месяц, как Сбер объявил о прекращении финансирования Bringly, проект оказался убыточным


Про Брингли мало деталей к сожалению.

Да, уже на новой работе. Пока очень динамично — огромное количество новой информации.
Про Брингли, если честно, не хочется говорить. Я помню свой первый день в Яндексе, 05 марта 2019, как сидел в Мулен Руж (конференц-зал) и слушал про трансграничное направление Маркета. Уже тогда было понятно, что оно не полетит. Идея строилась вокруг брендированной одежды и обуви из Турции… Ну такое… Стоимость логистики + турецкий подход к бизнесу всё убили. А конкурировать с АлиЭкспресс на товарах из Китая нереально.

Крупные компании прощупывают ниши, это нормально. Но сваливать на разрабов проблемы маркетинга это низко, подобное можно ждать от шаражки с взбаломошным директором, но никак от крупной компании.
но никак от крупной компании
Самая главная и очевидная ошибка — а с чего вы взяли что это крупная компания? По меркам бизнеса — это типичный средний бизнес со всеми вытекающими проблемами среднего бизнеса по определению.
И второе — «кто-то там» сказал, что ожидания болельщиков — это проблемы болельщиков. Это я про то, что если кто-то там шибко обольщался, ну так это проблемы того кто обольщался. Не более того.
Есть конкретные критерии крупного бизнеса — доход более 2 млрд руб, количество работников — более 251 человек. Яндекс под эти критерии подходит. Так что это не я взял, это общие критерии для РФ, могли бы и погуглить, а не задавать глупых вопросов.

И про болельщиков я не понял — что вы этим хотели сказать? Если для вас норма сваливать на разрабов менеджерские просчеты, то идите в… Яндекс, там такое цветет и пахнет.

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

Извините, не так прочитал.
8854 больше, чем 251.
745 млн долларов больше, чем 2 млрд рублей.
Разве не так?

А что было в оригинальном коммаентарии, если кто помнит? Сейчас там +1.

Привёл доказательства правоты автора.
А комментарий следовало писать под предыдущим постом.
Комментатор неправильно прочитал коммент на который отвечал, решил что в нем озвучены не критерии большой фирмы а количество людей и доход Яндекса. И весьма прямолинейно обвинил автора во лжи.
Хм… Сколько злобы. :))) А зачем?

Итак, что вам даёт число? Скорее всего чуть менее чем ничего. Число никак не раскрывает экономическую модель бизнеса. Для маразматичного налоговика число может быть что-то там да и даёт, но вменяемым — вряд ли…

Бизнес как водится трёх видов бывает. Мелкий, средний и крупный. Критерии сего определяются вовсе не какими то там числами, а экономическими моделями. Про мелкий смысла нет говорить, с ним всё понятно. Средний — это когда дело доросло до вменяемого размножения самого себя. Крупный — это средний + производство базовых «орудий труда» для дела. Само собой это всё слишком грубые критерии, если нужны более чёткие — учебник экономики откройте, а не налоговый кодекс, или что там вы открыли от рашенских маразматиков — тут уж я понятия не имею…
И про болельщиков я не понял — что вы этим хотели сказать?
Ниже строка.
Это я про то, что если кто-то там шибко обольщался, ну так это проблемы того кто обольщался. Не более того.

И да, яндыкс — это средний бизнес, торгующий гавённой третьесортной рикламкой вразнос. Не более.
Причём заметьте, яндыкс является средним бизнесом даже с небольшой натяжкой вообще-то…
Крупный — это средний + производство базовых «орудий труда» для дела.
получается, что крупный бизнес — это средний делающий велосипеды для себя :)
И Яндекс по ваше определение точно подходит :)
Не знаю зачем яндыксу «велосипеды». Это у яндыкса спрашивать нужно.

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

Ой простите. Это не про яндыкс. Ахаха! :)

А у яндыкса похоже что да, только калешные монструозные виласипеды… Тут вы возможно правы.

пс: Сбоку Хабра подкинула «совершенно случайно»: «Google делает свой процессор, а AMD готовится уничтожить Qualcomm». Конечно же это просто совпадение, не более.
Хахаха, вот ты не в курсе что гугл делает ARM процессор для консьюмерского рынка. Делать на нем серьезную работу никто не собирается, он для телефончиков. По твоим некомпетентным маразматическим критериям даже гугл — средний бизнес, так что ты так обсратушки, что просто смешно.
Сам себе что-то выдумал, сам доказал обратное. Может тебе хоть немного изучить тему, мальчик, прежде чем лезть в разговоры взрослых людей?
В путаете причину и следствие. То что вы назвали — это следствие укрупнения бизнеса. И яндекс по вашему же определению — крупный.

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

И если вас не устраивают рашенские маразматики, то в ЕС критерии крупного бизнеса — более 250 человек, а также более 50 млн евро или общим балансом 43 млн евро.

Может если кругом маразматики, то маразматик — это вы? Особенно мне понравилось «торгующий гавённой третьесортной рикламкой вразнос». Смешно. Сам этот маразм выдумал?
Joom?
НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

Два человека написали статью на одну и ту же тему. Обе в плюсе. Но вы говорит, что


  • у Юли статья в плюсе, потому что она женщина
  • у Ивана статья в плюс, потому что он дело правильные вещи

Я правильно понимаю вашу мысль? о_О

Те, кому нравилось работать в Яндекс.Маркете, не пишут такие статьи=)
Кто плюсует мне тоже интересно. Это достаточно забавно и интересно читать, но всё же ценность таких статей околонулевая (ИМХО) по сравнению с техническими статьями.
Ну вот прочитает человек такую статью, решит что Яндекс говно и не пойдет туда. Кому от этого лучше? Человеку, который не получит полезный опыт создания scalable систем? Яндексу, который не получит (возможно) ценного сотрудника?
Очевидно, человеку, который не пойдёт и не разочаруется в компании сам (если он прочтёт статью и поймёт, что разочаровался бы).
А полезный опыт создания масштабируемых систем можно далеко не только в Яндексе получить.

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

Прежде всего самому Яндексу. Чем больше нашумит статья, тем больше вероятность, что высшее руководство с ней ознакомится и предпримет какие-либо меры.

Я работал в каком-то другом маркете и ничего подобного описанному в статье у нас не было. Либо всё за 2 года ТАК испортилось, либо автор слегка (совсем чуть-чуть) преувеличивает проблемы.
Представим теоретическую ситуацию что в статье — ложь. Что должно делать руководство в этом случае? Ну проведут они расследование, выяснят, что переработок нет или почти нет, статический анализ есть и на венде люди прекрасно работают, а человек просто обиделся на что-то, вот и пишет всякое. А потом другой человек прочитал это и не пошел работать в Яндекс, основываясь на недостоверных/неполных данных. Кто в этой теоретической ситуации выиграл?

В Яндексе, собственно, политика такая вместо того, чтобы строить внутренние процессы так, чтобы не было стыдно, если вдруг что-то станет достоянием общественности, — там бьют по башке всех, кто хотя бы минимально проявит свою нелояльность.

Вы это говорите на основании собственного опыта?

Ну, представлять-то можно много чего. Например, что всё именно так как автор и написал, или даже всё на самом деле ещё хуже, но руководство не в курсе.


Агась.

Да даже бывшие/нынешние сотрудники Маркета (вроде меня) не в курсе происходящих ужасов, что уж о там о руководстве говорить=)
Мой изначальный поинт в том что не надо принимать на веру всё что пишут в интернетах и автор может быть (скажем мягко) не совсем объективен.
Да, во всякую дичь легче поверить — я когда читал всё это поймал себя на мысли «ну нихрена себе там у джавистов», но, поразмыслив, всё же решил, что слова автора надо делить примерно на 10. Например его поинт про то что на маке/венде не собирается разбивается о то, что это и не нужно делать ибо неудобно — яндексовая система сборки позволяет собирать удаленно на (линуксовых) серверах. Зачем собирать 2 часа утилиту если можно собрать ее за 10 минут на сервере? Опять же, когда я устраивался я всё это выяснил заранее и не стал брать Мак (вероятно, зря).
Если бы я до сих пор работал в Маркете и был в курсе что там в команде джавистов я бы мог подтвердить или опровергнуть описанное в статье. Из того, что я видел и где я работал — ничего подобного и близко не было.

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


Нытьё про работоспособность java-приложения под виндой я тоже не разделяю, но у всех свои тараканы. И в любом тексте можно найти какой-нибудь изъян, что не делает этот текст ложным.

Ну а меня в своё время уволили

Ого, ничего себе. А можно подробности (в личку)?

И в любом тексте можно найти какой-нибудь изъян, что не делает этот текст ложным.

Ну так там не один такой изъян — про монорепу фигня написана, про качество кода, про велосипеды, про легаси. То есть оно конечно в какой-то мере есть (покажите мне проект без легаси), но не это ужас-ужас достойный целой статьи.
С чем я могу согласиться — это переработки, но это как-то о-малое от всего описанного.

Я мало уже помню подробностей.


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

Смысл в монорепе в том что у вас есть легкий доступ к тем самым велосипедам. И да, «не связанные» проекты в том числе хотят иметь этот доступ. Нужна библиотечка из Утилей — подключили одной строкой в ya.make. Захотела ваша тулза из 10 строк ходить в YT — фигня вопрос, ну подумаешь вместо 10 секунд компилируется теперь 40 минут. Зато экономится время разработчика — не надо пилить свой локальный велосипед когда есть алгортим/функция/библиотека/велосипед в Аркадии. Например, поиск Маркета юзает плюс-минус тот же код, что и основной поиск.
Не, я не спорю, что при должном тулинге можно сделать это и на мультирепах, но проблема в том что и в случае монорепы и в случае мультирепы этот тулинг нужен (ни то ни другое не является серебрянной пулей и не работает из коробки) — в силу тех или иных причин Яндекс выбрал монорепу и связанный с ней тулинг. Утверждать, что монорепа — говно, «забыв» о необходимости (другого) тулинга для мультирепы — это писать фигню, потому что складывается впечатление что в Яндексе дурачки, а вот мультирепа все проблемы решит из коробки.

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

Да, гитхаб это клево и удобно, а как быть с переменованием функций, например? В Аркадии я могу взять и заменить Stroka на TString одним коммитом.
А вот взять товарищей из Qt, у них мультирепа. Вот я хочу переименовать функцию из QtCore которая используется в другом сабмодуле. Это надо добавить функцию-обертку, закоммитить, пойти в другой модуль, заюзать враппер там, закоммитить, пойти в QtCore и наконец переименовать функцию, избавившись от обертки, закоммитить. Не слишком ли много действий для такой простой задачи?
В Аркадии я могу взять и заменить Stroka на TString одним коммитом.

По отдельному коммиту в каждую фичеветку каждого проекта тогда уж.


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


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

Похоже они перестарались и зачем-то разрезали один проект на несколько реп, что ничего кроме проблем не даёт. На репы имеет смысл нарезать по зоне ответственности.

То есть по ссылке вы не ходили? Там как раз описывается система которая автоматически выкачивает зависимости по мере их использования. Как из npm так и из отдельных репозиториев. Был бы я Яндексом, то отмасштабировал бы её и на яву и цпп. Но я не яндекс.


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


Тулинг там довольно тривиальный: обнаружил зависимость от директории — выкачал в неё репозиторий.

Я пролистал ссылку, понял что ничего не понимаю в Джаваскрипте и закрыл — я сходу не увидел высокоуровнего описания, а вникать в портянки кода на ЖС у меня нет желания, извините, веб разработка — не моё.
Нет, я прекрасно знаю, что все эти проблемы решаемы в мультирепе, скажем, в 2 Гисе был свой набор скриптов для этого. Можно и деб-пакеты собирать из различных репозиториев и рулить зависимостями на этом уровне, тоже подход. По всякому можно, я и не утверждаю что монорепа лучше чем мультирепа, я утверждаю что безапелляционно заявлять что «Х — говно» это профанационный уровень, которым проникнута вся статья.

Тулинг там довольно тривиальный

Именно так и работает селективный чекаут в ya make=)

Но это реально говно. Такой подход не масштабируется. Полирепу же легко масштабировать.

Это очень спорное утверждение. Сразу хочу сказать, что я не фанат монорепы.

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

Я довольно долго использовал парадигму дебиановских пакетов и бинарную зависимость. Что я могу сказать: бинарная зависимость в C++ — это боль. Отдельно доставляют циклические зависимости, если у программ есть плагины. Ещё раз отдельно, но уже по-другому, доставляют переезды на новые версии ОС, когда тебе надо пересобрать ВСЁ, даже какие-то старые коммон-библиотеки, которые уже года 3 как заморожены.

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

Стоит отметить, что везде это был C/C++ код, со всеми его проблемами динамической или статической линковки. Но общие моменты, что надо уметь делать минорные релизы, которые не ломают API+ABI, думаю, будут применимы ко всем языкам. Это тяжело, и это форсит накапливать подобные несовместимые изменения в большие пачки и делать большие мажорные релизы, которые требуют много работы для внедрения, переписывания кода у использующих данный код проектов и т.д. А пока все медленно переползают — надо поддерживать 2, а то и 3 мажорных релиза. И да, сложность поиска кода действительно есть, найти, из чего именно был собран какой либо бинарник/пакет далеко не так тривиально, как может показаться. Есть ещё «вирусные» изменения, типа включения поддержки нового стандарта C++ — это тянет за собой включение сборки с этим же стандартом и у всех зависимых компонентов. На сколько я понимаю, у Java есть примерно такая же фигня с целевой версией JVM, и примерно такая же проблема у JS кода, подобным «вирусным» изменением может быть использование более новой версии питона при разработке какой либо библиотеки.

В противоположность этому монорепа требует вносить изменения плавно и итеративно, можно даже вносить изменения, ломающие API, но своим же коммитов исправлять все использования из чужого кода, главное — сохранять совместимость на уровне сетевого протокола и формата данных. Да, это требует наличия тестов у проектов. Да, это несколько усложняет разработку в бранчах (поэтому обычно монорепа соседствует с trunk-based разработкой), но позволяет делать такие изменения у популярных, с точки зрения количества использующих их проектов, библиотек. Важно отметить, что монорепа — это не столько большой SVN/Mercurial/git/whatever, сколько система сборки, система контроля зависимостей, тестирование, система CI/CD и т.д.
вся фигня заключалась в том, что твою библиотеку юзали разные проекты, но каждый — какую-то версию

То есть проблема в фиксации версий, а не полирепе.


Я довольно долго использовал парадигму дебиановских пакетов и бинарную зависимость.

А тут соответственно проблема в попытке полагаться на бинарную совместимость, а не полирепе.


А пока все медленно переползают — надо поддерживать 2, а то и 3 мажорных релиза.

Не надо поддерживать устаревший код. Тогда переползать будут гораздо быстрее.

То есть проблема в фиксации версий, а не полирепе.

А какие предложения есть? Как вообще искать все проекты, которые используют твою библиотеку, особенно если разработка идёт в фиче-бранчах?

А тут соответственно проблема в попытке полагаться на бинарную совместимость, а не полирепе.

А на какую зависимость надо полагаться? Если по исходникам, то как фиксировать?

Не надо поддерживать устаревший код. Тогда переползать будут гораздо быстрее.

Как синхронизировать разработку, если твою библиотеку использует 50 проектов?

Вы абстрактно хорошие вещи говорите, но как их воплотить в реальную жизнь? Можете рассказать, как вы это видите для компилируемых языков?
Можете рассказать, как вы это видите для компилируемых языков?

Какая разница — компилируемый ли язык или интерпретируемый? Та или иная форма "dll hell" и необходимости менеджить зависимости никуда не девается. Самое простое, конечно, статическая линковка и затаскивать внешние модули целиком (и собирать вместе с ними). Сильно сложнее, когда зависимости через артефакты. Но ничего нового Вы не сказали — так или иначе эта проблема характерна для любой разработки. Как со стороны потребителей готовых блоков (библиотек), так и со стороны разработчиков (которым приходится поддерживать несколько версий в параллель и давать определенные гарантии на интерфейс библиотеки).
Теоретически можно построить фашизм и заставить всех использовать только последние версии в рамках отдельно взятой организации, но это просто космическое количество человеко-часов, чтобы поддерживать весь код в актуальном состоянии (а то! Думали, что айти это дешево и просто на кнопочки клацать!)


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

Как вообще искать все проекты, которые используют твою библиотеку, особенно если разработка идёт в фиче-бранчах?

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


А на какую зависимость надо полагаться? Если по исходникам, то как фиксировать?

Не фиксировать. Вы бы всё же прочитали ту статью. Хотя бы раздел про версионирование. Там JS специфики не много, а проблемы рассматриваются довольно типичные.

Собственно, в комментарии habr.com/ru/post/456288/#comment_20290512 поднимались проблемы, на которые не было получено ответа.

По сути вы предлагаете trunk-based разработку, но, в отличие от монорепы, автор библиотеки не обязан проверять, что тот самый виртуальный общий транк (то есть все текущие последние ревизии/версии всего, что есть в репозитории) собирается и проходит тесты.

Простите, но ваши фразы типа
Заботиться об обновлениях — задача потребителя вашего кода.
мне говорят о том, что вы коммон библиотеки или клиенты для своего сервиса, которыми пользуются потребители, не делали. Им, потребителям, надо, чтобы работало, а не тестировать ваши изменения по 10 раз на дню.

А фраза
Вы можете ему помочь, если не будете ломать апи, а слом апи сопровождать codemod-ом,
говорит о том, что вы совершенно не поняли мои слова про ABI.

Если бы мне предложили работать с какой либо библиотекой в концепции «автор может делать много изменений, поддерживает только транк/мастер, но на ваш (то есть мой) сервис ему, в целом, наплевать» — то я бы поостерёгся ею пользоваться и пошёл искать альтернативы.

Почему же в реальной жизни все JS-еры фиксируют версии? Почему не собирают всё на самой последней версии? Почему существуют LTS версии библиотек и даже операционных систем? Ваша концепция (vintage — это же вы?) не выглядит какой-то уникальной, почему никто не живёт так, если она столь хороша?
По сути вы предлагаете trunk-based разработку

Вовсе нет. В фичеветках, как обычно.


автор библиотеки не обязан проверять, что тот самый виртуальный общий транк (то есть все текущие последние ревизии/версии всего, что есть в репозитории) собирается и проходит тесты.

Конечно, для этого существует CI


Им, потребителям, надо, чтобы работало, а не тестировать ваши изменения по 10 раз на дню.

Вы зачем 10 раз в день ломаете мастер? Не надо так. Настройте CI чтобы не давал вам пушить в мастер непротестированный код.


на ваш (то есть мой) сервис ему, в целом, наплевать

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


Ваша концепция не выглядит какой-то уникальной, почему никто не живёт так, если она столь хороша?

Мы тут не в "пусть говорят", чтобы использовать апелляцию к толпе в качестве аргумента.

Конечно, для этого существует CI

Ваш, или для вот тех проектов? Если у вас полирепа, то откуда вы вообще про их CI узнаете? Они там, с другой стороны компании, и вообще у них Teamcity, а не Jenkins.

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

Непротестированный моими тестами, или тестами пользователей моей библиотеки?

Мы тут не в «пусть говорят», чтобы использовать апелляцию к толпе в качестве аргумента.

Это называется «проверка жизнью». Удачные концепции распространяются между компаниями и коллективами разработчиков, неудачные — забываются. И почему вы пропустили ту часть абзаца, где было про LTS и про жизнь на самой новой версии из NPM вот прям сейчас?
Конечно, для этого существует CI

Если CI единое для всех проектов, то это уже, по сути, монорепа и есть. То, что у каждого проекта свой репозиторий, а не папочка в монорепе — сути не меняет.

Если CI единое для всех проектов, то это уже, по сути, монорепа и есть.

очень спорный аргумент.


То, что у каждого проекта свой репозиторий, а не папочка в монорепе — сути не меняет.

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

в монорепе Вы в принципе не можете версионировать отдельные "папочки"

А как это раздельное версионирование работает с единым CI?

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

Плюс у монорепы есть пара «вкусных» бонусов. Например, вы можете поправить библиотеку вместе с клиентским кодом.
Плюс у монорепы есть пара «вкусных» бонусов. Например, вы можете поправить библиотеку вместе с клиентским кодом.

А вне монорепы, конечно, я не могу это сделать? Или все-таки могу, но Вы имеете в виду, что не за одну итерацию? Так одна итерация — это такая же фикция, потому что пока я там в trunk based монорепы буду все места править и делать тесты зелеными… ну, вы поняли

Так одна итерация — это такая же фикция, потому что пока я там в trunk based монорепы буду все места править и делать тесты зелеными…
для этого есть прекоммитные проверки — вы пытаетесь закоммитить, тесты фейлятся, вы меняете код, тесты зеленеют, коммитите… В итоге всё изменение (и либы, и клиентов) приходит в одной ревизии и нет промежуточных поломанных

Это не "прекоммитные" проверки, которые должны на машине разраба отрабатывать быстро (иначе зачем они ещё нужны). А предмержевые (не могу придумать более удачного слова) проверки — на фичеветке поверх мастера. И тогда, да, они могут быть "долгими". Что более важно — может быть конвенция, что все коммиты из фичеветки при мерже в мастер должны быть схлопнуты (squash) и снабжены цельным, адекватным описанием.

Это не «прекоммитные» проверки, которые должны на машине разраба отрабатывать быстро (иначе зачем они ещё нужны)
никто не отменяет возможность запускать тесты на машинке разработчика*, но когда у вас помимо тестов библиотеки есть тесты её зависимостей и зависимостей зависимостей, и часть из этих тестов выполняются 10+ минут… А еще учтите баснословное время сборки всего этого зоопарка, и даже если мы не верим клиентским юнит тестам, мы должны как минимум не ломать им сборку. Поэтому реально перед тем как пытаться коммитить вы скорее всего захотите вручную запустить лишь пару самых релевантных тестов, но даже они могут тянуть столько зависимостей, что их сборка даже на мощном пк будет занимать десятки минут. Итого внимание вопрос: а зачем вообще локально что-то делать если разрабатывать на сервере продуктивнее?

* предполагая что они вообще могут на этой машинке запуститься и отработать.

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


Итого внимание вопрос: а зачем вообще локально что-то делать если разрабатывать на сервере продуктивнее?

Ну, и почему тогда Вы именно про предкоммитные проверки говорите? Прекоммит означает, что если что-то не так, то сразу все фейлится и в истории (гита, например) ничего не остается. Например, на прекомит правильно вешать проверку на наличие паролей в репо.
А в остальном — разработчик — какая разница — пускай коммитит мусор в удаленное репо (главное, что не в мастер) — мы все равно перед мержем заставим его убрать его :-/


Окей — у нас разный подход именно из-за того, что в нормальных компаниях нету Аркадии (и не будет).

Прекоммит означает, что если что-то не так, то сразу все фейлится и в истории (гита, например) ничего не остается.
но ведь… именно так в аркадии и происходит. И можно делать атомарные изменения одновременно либ и их зависимостей, что в мультирепе невозможно by design. В итоге я вашу критику монорепы тем более не понимаю.

Извините, ни один из Ваших аргументов за монорепу… Не серьезен.


Полностью согласен с nin-jin ниже.


большой SVN/Mercurial/git/whatever, сколько система сборки, система контроля зависимостей, тестирование, система CI/CD и т.д.

Где противоречие? Повторюсь, что для любого проекта, будь он хоть в "полирепе", все указанные сущности будут нужны

НЛО прилетело и опубликовало эту надпись здесь

Не то чтобы мурыжили. Просто обмен опытом никому оказался на самом деле не нужен. А на публику-то надо показывать хорошее лицо.

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

"Обращаете внимание на пол автора? Да вы сексист!"
"Не обращаете внимание пол автора? Вы ужасно невнимательны!"


Нда. Без шансов :))

НЛО прилетело и опубликовало эту надпись здесь

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


В этом конкретном тексте после начал данного треда мне буквально пришлось полезть в пост, чтобы уточнить пол автора. Потому что вне зависимости от пола автора монорепозиторий или Java чем-то принципиально иным не станут :)

Первое же предложение в тексте:
Я уволился из Яндекс.Маркета, отработав там почти 15 месяцев

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

К тому же она дискредитировала Хабр в глазах IT-сообщества

Почему я должен думать, что того автора 'разоблачили' и она 'плохая'?
Вы так публично заявлете об этом, но ни приложив ни единого доказательства.
Я вам поставил минус заслужили.

Я сейчас открыл того автора sashavoloh и у нее есть статьи и высокая карма и лайков за подобную статью (про маркет) не меньше чем в этой, мне кажется, что вы что-то нездоровое 'просите'
НЛО прилетело и опубликовало эту надпись здесь

Да да. Вам бы тут сообществу про токсичность втирать, обвинив изначально в отключении мозга. Мира и процветания.

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

эээ, что, простите? Вы уж определитесь, кто вокруг вас "плохой".

В Компании работает очень много действительно крутых разработчиков, которые могут практически всё, что угодно. Но вот стоит ли тратить их усилия, чтобы написать свою версию Кафки или пародию на Docker и Kubernetes?

Да, стоит, Docker и Kubernetes работают не настолько хорошо, чтобы их можно было использовать в масштабах Яндекса. Я работал в Яндексе 5 лет, последние 2 года работаю в Авито и смотрю на зоопарк современных Open Source технологий изнутри — их стабильность и качество очень сильно преувеличены.

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

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

Здесь считается нормальным посадить senior разработчика «грепать» логи с нескольких хостов, потому что ELK-стек not invented here.

Насколько я помню, в Яндексе принято возделывать свою делянку, если что-то неудобно, это надо улучшать.

Разработчики каждого сервиса сами отвечают за его функционирование в production’е

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

А ещё очень много проектов, которые собираются и запускаются только на Linux.

Это нормально если у вас production на Linux.

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

Я за время работы в Яндексе отучился в ШАД вольнослушателем, это дало безумный буст карьере, из-за чего я собственно и уволился, но это совсем другая история :)

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

Угу, Амазону с его EKS/ECS подходят, Адидасу для его корпоративного управления медиями подходит — а Яндексу не подходят. Какой такой у Яндекса особый масштаб?

При том, что вряд ли у Яндекса получится сделать лучше: контейнеризация — это уровень ядра системы. Каков размер команды Яндекса, которая занимается кернелхакингом и системными демонами?

АФАИК, в Яндекс.Деньгах docker и k8s себя нормально чувствуют без велосипедов. И ELK там есть. Ну то есть на три велосипеда меньше, и как-то ни клиенты этого не ощущают, ни разработчики не расстроены.

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

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

Насколько я помню, в Яндексе принято возделывать свою делянку, если что-то неудобно, это надо улучшать

Улучшать трассировку логов на продакшне — это ответственность devops/эксплуатации, а не разработчиков.

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

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

Это нормально если у вас production на Linux.

Это ненормально, если вы пишете на Java. Если вы пишете на Java — будьте добры писать кроссплатформенно.

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

Ну, во-первых — не везде. Во-вторых — как выбирать, не имея данных на руках?

А руководство в Яндексе, линейное которое — очень токсичное.
Угу, Амазону с его EKS/ECS подходят, Адидасу для его корпоративного управления медиями подходит — а Яндексу не подходят. Какой такой у Яндекса особый масштаб?

У Яндекса сотни тысяч серверов. У Амазона ещё может быть что-то похожее (к сожалению слабо себе представляю их внутреннюю кухню, они используют своё публичное облако?), про Адидас вообще странно слышать в этом контексте.

При том, что вряд ли у Яндекса получится сделать лучше: контейнеризация — это уровень ядра системы. Каков размер команды Яндекса, которая занимается кернелхакингом и системными демонами?

Не помню, к сожалению, кажется человек 10 там было. Справедливости ради, сам Docker — это не уровень ядра, это набор обёрток вокруг интерфейсов ядра, насколько я помню.

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

По моим наблюдениям скорее ценится богатая эрудиция и умение на месте построить из имеющихся middleware-блоков нужную функциональность.

Улучшать трассировку логов на продакшне — это ответственность devops/эксплуатации, а не разработчиков.

К сожалению мне не попадалось компаний где это было бы на 100% так.

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

В победившем мире DevOps это абсолютно не так.

Это ненормально, если вы пишете на Java. Если вы пишете на Java — будьте добры писать кроссплатформенно.

Я, к сожалению, не пишу на Java (только на Python, Go и C++), но обычно от backend-разработчика требуется реализовать функциональность, которая будет работать в проде, а не на произвольной архитектуре и ОС.

Ну, во-первых — не везде. Во-вторых — как выбирать, не имея данных на руках?

Искать информацию, просить встречи с командой, пытаться понять комфортно ли будет работать с этим тимлидом. В конце концов всегда можно сротироваться в другую команду.
Подозреваю, все-таки 100 000 виртуальных серверов, в среднем 1 юнит-сервер 500 Вт, тогда суммарная мощность около 500 МВт. Вся Германия потребляет в среднем 40 000 МВт.
Скорее всего вы неверно неверно посчитали энергопотребление серверов, это в основном блейды, у них потребление сильно меньше.

На 2013 год только в поисковом облаке было около 40000 железных серверов, это было уже 7 лет назад, с тех пор было построено несколько новых датацентров, каждый следующий запаковывался всё плотнее и плотнее.

Вот неплохой обзор.
Сервера 500 давно уже не потребляют. Сотню-две (3 — в упор) в зависимости от нагрузки, если нет GPU и jbod.
И нет, контейнеров не 100 тысяч, намного больше. Я не помню, сколько я могу сказать, чтобы не нарушить NDA =)
два процессора с турбобустом легко потребляют > 400 =)
Вопрос в том, каких. Не обязательно покупать десять тысяч процессоров, которые жрут 200+ в прыжке, если они будут менее производительны, чем 15 тысяч других процессоров, которые жрут меньше и стоят дешевле в 2 раза.

Современные процессоры (особенно не под пиковой нагрузкой) очень экономят электричество. Как-то я поймал thinkpad x1 gen6 с i7-чтототамU за потреблением трёх ватт по acpi. С включенным экраном и wifi. Трёх. А так 8-10. И это нифига не медленный процессор.
Вы сравниваете процессор для ультрабука, который троттлится при открытии браузера с серверным процессором? =)

Посмотрите TDP для современных процессоров Intel. Он там указан без турбобуста ark.intel.com/content/www/us/en/ark/products/series/192283/2nd-generation-intel-xeon-scalable-processors.html
> Вы сравниваете процессор для ультрабука, который троттлится при открытии браузера с серверным процессором? =)
Я сравниваю процессор, который на ~20% медленнее ходовых на рынке бюджетных серверов i7 6700/e3-1230 при в три раза меньшем потреблении, а в простое — раз в 20 меньшем.
Ничерта он не троттлился, год в powersave простоял. Вот 5xxx — да, тротлится. Так, что музыка с браузера заикаться начинает.

> Посмотрите TDP для современных процессоров Intel.
Посмотрел, 2660v4 — 105W. Отличный процессор и продаётся на развес.
Только зачем смотреть на TDP, если можно посмотреть на реальное потребление серверами?
> Посмотрел, 2660v4 — 105W. Отличный процессор

Если базовая частота 2ггц устраивает =)

Сейчас проверил 2699v4 на турбобусте — 195 ватт при TDP 145W
Ну вот cpuboss пишет про 2660/2699 typical power consumption:
85.31W vs 117.81W

Что отлично укладывается в мои слова. И даже если на 2 камня дунуть турбобустом — будет 300 в прыжке.

> Если базовая частота 2ггц устраивает =)
Частота-то может и не устраивает, но вот ценник в 75 тысяч против 270 заманчив ;)
А три с половиной камня 2660 будут в любом случае производительнее, чем один 2699

Я уже писал чуть ниже, что рассуждения «2699 лучше» и все подобные хороши только когда серверов несколько штук. Ну может десятков. И место для их установки ограничено, а не достраивается по необходимости.
И да, что один сервер будет потреблять полкиловата — да, такое случается, я с этим не спорил. Бывают сервера и с большим количеством сокетов, но это же не показатель что «все сервера потребляют 3 киловатта».
> Ну вот cpuboss пишет про 2660/2699 typical power consumption:
85.31W vs 117.81W

не знаю что они пишут, но я смотрю сенсоры на реальной машине под нагрузкой с LA 60-70 =)

> Частота-то может и не устраивает, но вот ценник в 75 тысяч против 270 заманчив ;)

2699v4 нет смысла брать (у него цена неадекватная), т.к. уже два поколения процессоров вышло и за 160-180 тысяч сейчас можно получить больше потоков (48) с большей базовой частотой (2.4). А за 250 тысяч можно получить базовую частоту 3.2 и 32 потока. Но TDP там 205 ватт =(

> И да, что один сервер будет потреблять полкиловата — да, такое случается, я с этим не спорил.

Я просто ответил на утверждение:

> Сервера 500 давно уже не потребляют. Сотню-две (3 — в упор)

Серверы разные нужны, серверы разные важны =)
Сколько тепла в вашем ДЦ можно со стойки снять? Какой резон ставить мощные камни, если 40 (ну ок, пусть даже 30) тушек в стойке будут в 2 раза превышать бюджет по питанию и охлаждению, если нормально их прогрузить?
> Серверы разные нужны, серверы разные важны =)
Это-то понятно, но ветка изначально про вполне конкретные серверы была )
Да, Интеле сейчас отнял у АМД титул главного по горячим камням.
У меня на даче стоит Lenovo 3550 M4 с 2CPU и 8 HDD SAS 15k под виртуализацией, в среднем кушает 250-300Вт
сотню-две (3 — в упор) в зависимости от нагрузки, если нет GPU и jbod.
современные xeon'ы потребляют 240 ватт, а в серверной машинке их два. Плюс мелочевка типа материнки и оперативы
Не ссорьтесь :) На самом деле, это знают только в конкретном, подчеркиваю, конкретном датацентре. Берут общее энергопотребление за период, делят на количество серверов и т.д. и т.п. Не забываем охлаждение, не забываем про инфраструктуру доставки питания (потери на проводах). Днем загрузка серверов и процессоров в частности больше, ночью меньше, поэтому датацентры дают серьезные скидки тем, кто работает ночами, и потому у Амазона спотовые, т.е. оставшиеся на конкретный момент свободные вычислительные ресурсы стоят в несколько раз дешевле обычных — но, как следствие, у вас нет никакой гарантии, что они будут доступны, скажем, и на следующий день по этой же дешевой цене.
А вы сейчас спорите про термопакет сервера, т.е.максимальное количество потребляемой энергии, на которое рассчитываются системы охлаждения и питания сервера. Это совершенно другое, посмотрите на загрузку процессора на вашей собственной машине сейчас, например.
Очевидно, что когда речь идет о масштабных закупках, процессоры выбираются не по принципу «взять самый мощный и жрущий электричество» же =)
Нужно соблюдать баланс между ценой, потреблением, производительностью и много чем ещё. Есть достаточно производительные Xeon-ы с в два раза меньшим потреблением электричества.
Смотрят на количество ядер, так как от этого зависит стоимость лицензий. Иногда в сумме дешевле взять быстрые камни с малым количеством ядер
Если речь стоит про лицензии — это уже вряд ли масштабные закупки.

вы все правы. потребление зависит от нагрузки.

> У Яндекса сотни тысяч серверов. У Амазона ещё может быть что-то похожее

Если сложить всех клиентов амазона на EKS/ECS и сам амазон, то там под одну-две сотни яндексов наберется. Сравнивать, конечно, так не очень правильно, но для амазона это как бы единая система.

Амазон, кстати, это отличный пример компании, у которой внутри все максимально просто и при этом сильно стабильней чем у облачных конкурентов.

А у вас есть свежие данные про число серверов у Amazon? Я нашёл только несколько устаревшие, там упоминалось про 900к серверов суммарно.

Было бы интересно ознакомиться с реальным положением дел :)
Не знаю на счет количества реальных серверов, облака и kubernetes это не про физические машины. То, что у них очень много клиентов, которым постоянно нужно поднимать по 10000+ воркеров для временных батч-вычислений и все это работает стабильно, является для меня показателем.

Не забывайте, что у них в клиентах есть такие гиганты как Netflix, Twich, Twitter, ESPN, Adobe.
Kubernetes в последних версиях поддерживает до 200 подов на одну ноду, в более старых до 100.

10000 инстансов — это не очень много на самом деле, всего около сотни серверов, это зависит от их размера конечно.

А вы уверены, что у них эти воркеры работают в Kubernetes? У меня, к сожалению, нет под рукой подробной информации об их инфраструктуре. Если вы в курсе — было бы интересно послушать.

AWS EKS это как раз k8s в облаке.
Но справедливости ради, для AWS Lambda они использовали Firecracker, т.к. изоляция докера их не устроила, а традиционные виртуалки слишком тяжёлые.

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


Косвенно могу подтвердить свою точку зрения тем, что крупные компании не требуют знания конкретных технологий у кандидатов, только знания языка и концепций: Amazon, Google, Facebook.
Потому что у них внутри свои велосипеды…
Только их велосипеды — часто стандарт в отрасли. У яндекса с выкаткой велосипедов в стандарт отрасли пока все сложнее.
Это ненормально, если вы пишете на Java. Если вы пишете на Java — будьте добры писать кроссплатформенно.

Зачем это делать и тратить на это ресурсы? Какую проблему это решит?

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

Я не уверен в этом. Допустим, есть некоторая библиотека, которая вызывает какой-нить sendfile или inotify через JNI. Очевидно эта библиотека не кросплатформенная, и все что от нее зависит тоже. Чтоб сделать это кроссплатформенным нужно будет городить странный никому не нужный код, который никогда не будет запускаться и еще поддерживать его.
Я когда давно работал в Яндекса, там была противоположная хрень. Был малекний кусок какого то С++, который собирался под винду, толи Яндекс бар, то ли что-то такое. И из-за него весь репозиторий тоже должен быть быть таким. Хотя там был библиотечный код для бэкэнда, 99.9% которого никто и никогда не будет запускать под виндой, кроме этого мелкого куска. В итоге все разработчики делали все, чтоб их код только не попадал в этот репозиторий и можно было нормально использовать очень полезные gcc расширения и всякие linux-специфичные API без глупых заморочек.
качество кода поднимает

Лишние уровни абстракций или условная компиляция сомнительное улучшение кода.

найм людей упрощает

Реально кто-то может не принять офер или уволиться узнав, что какой-то кусок кода нельзя запустить по его любимой windows rt?

Я бы реально отказался от оффера если бы узнал что не смогу полноценно разрабатывать под линуксом (и не один раз это делал).

Аналогично. Разработка под windows — это боль, превращающая программирование в страдания.
Допустим, есть некоторая библиотека, которая вызывает какой-нить… или inotify через JNI. Очевидно эта библиотека не кросплатформенная, и все что от нее зависит тоже


Кому очевидно?
Очевидно что эта библиотека кросплатформенная и называется JDK. Ибо функции inotify в Java выполняет WatchService.

Откройте какой-нибудь условную обёртку над нативыми библиотеками, например Xerial и удивитесь на скольких платформах она работает

Mac\x86_64\libsqlitejdbc.jnilib
FreeBSD\x86_64\libsqlitejdbc.so
Linux\aarch64\libsqlitejdbc.so
Linux\android-arm\libsqlitejdbc.so
Linux\arm\libsqlitejdbc.so
Linux\armv6\libsqlitejdbc.so
Linux\armv7\libsqlitejdbc.so
Linux\ppc64\libsqlitejdbc.so
Linux\x86\libsqlitejdbc.so
Linux\x86_64\libsqlitejdbc.so
Windows\x86\sqlitejdbc.dll
Windows\x86_64\sqlitejdbc.dll
Очевидно что эта библиотека кросплатформенная и называется JDK. Ибо функции inotify в Java выполняет WatchService.

Вообще-то, с WatchService всё не так хорошо. Например, иногда в Windows она норовит на файлы повесить share mode при котором другие процессы ничего с этими файлами сделать не могут. Потом в том, как приходят события в WatchService, в Windows есть свои интересные нюансы (не помню точно, какие, сталкивался с этими особенностями пару лет назад).


Откройте какой-нибудь условную обёртку над нативыми библиотеками, например Xerial и удивитесь на скольких платформах она работает

А если нет такой условной обёртки? Или условная обёртка не подходит под нужды? Ну например, разместить text input поверх GL окна, при этом имея полный доступ к конфигурации GL-контекста этого окна? К сожалению, ни SDL, ни GTK этого делать не позволяют, так что то, что в Windows решается штатным Windows API, в Linux делается за счёт продирания через особенности интеграции GTK с wayland или X.org.

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

Ну так написание, отладка, тестирование и поддержка этих if...else — это человекочасы, которых в конкретном случае может и не быть. Видимо, люди сопоставили тот факт, что у большинства и так linux или macos, а поддержка windows выйдет дороже, чем перевод на linux/macos тех, кто предпочитает windows.

Может это и так в каких-то других языках программирования, но это явно не про джаву.
Странно что вы osx и линукс в корзину кладёте. Это вообще-то разные системы. И большинства таки либо Windows либо OsX

Может это и так в каких-то других языках программирования, но это явно не про джаву.

Ну скажем так, дьявол в деталях. В Java действительно всё с этим очень хорошо, но порой можно попасть в какие-то те самые 0.01% случаев, где начнётся ад.


Странно что вы osx и линукс в корзину кладёте. Это вообще-то разные системы. И большинства таки либо Windows либо OsX

Я ссылаюсь на статью автора, где указано, что проект заводится под Linux, с трудом — под Mac и вообще без надежд — в Windows. Что там у большинства в Яндексе, я могу только гадать, и вообще, не зная их реалий не могу сказать, почему так. Я лишь называю одну из возможных причин.

OK, про OsX понял, а вот про 0.01% случаев, когда ад начинается, интересно узнать примеры кейсов.

Ведь, в большинстве случаев, нам просто требуется включить несколько нативных библиотек и вызывать нужную, проверяя ОС.
Как в общем-то все эти Java -wrapper-ы и делают
а вот про 0.01% случаев, когда ад начинается, интересно узнать примеры кейсов.

Ну вот простой пример — использовали Apache Spark (написан на Scala) из Java приложения.

Обнаруживаем, что при запуске под Windows после выхода он не удаляет временные файлы, вообще. Так как у нас Big data после десятка перезагрузок легко было полностью исчерпать все место на сервере.

Разбираемся, выясняется — баг в Spark'е — он пытается удалять временные файлы, забыв их закрыть в другом треде. Linux'у — пофиг где что открыто, ему сказали удалить — он удалил (точнее файл-то для того процесса остался, но в системе его уже не видно). Windows — просто не удаляет такие файлы.

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

К счастью, у нас не было ни одного клиента с сервером на Win в тот момент, поэтому мы просто отправили PR в Spark и забили.

А представьте ситуацию, когда мы вообще бы не тестировали на Win, а потом резко решили собрать приложение под Win — там каждый неправильный файловый дескриптор или неверная кодировка — превратиться в проблему.
И это я еще не говорю о статическом подключении С++ библиотек со всякими распознавания изображений и т.п. вещами, у которых просто нет версий для Win, к примеру.
Я ссылаюсь на статью автора, где указано, что проект заводится под Linux, с трудом — под Mac и вообще без надежд — в Windows
вообще как показывает моя личная практика нет смысл заводить под mac/windows вообще ничего (ну, кроме приложух типа ябраузера, но автор очевидно не из той команды). Локально я собираю только протобуфы, чтобы подсказки IDE работали. А код запускаю на дев-сервере

Ну а как же скорость сборки? Дев сервер на CI собирается? Сколько времени на это уходит? А как насчёт того, что IDE пересобирает только изменившиеся файлы (например, 1 из 100К файлов в проекте)? А как насчёт того, что некоторые известные нашлёпки на IDE умеют ещё и редеплой делать очень быстро?

Сколько времени на это уходит? А как насчёт того, что IDE пересобирает только изменившиеся файлы (например, 1 из 100К файлов в проекте)?
изменившиеся файлы отслеживает не IDE, а система сборки, и пересобираются точно так же только изменения. А сервер с парочкой xeon'ов собирает явно быстрее чем ноутбук с i5.

Если вы про Яндекс, то вся эта радость, на сколько я знаю, для Java не подходит. И чтобы только сгенерировать проект для Idea приходится минутами ждать (локальную) компиляцию протобуфов вместе с protoc и другим туллингом. Да и с C++ вы, как мне кажется, приукрашиваете и не говорите о проблемах. Например, распространённая среди коллег плюсовиков практика рефакторинга седом для меня является признаком наличия таких проблем.

Почему — странно? Обе — POSIX, обе под капотом имеют разные вариации на тему Berkeley System V.
И большинства таки либо Windows либо OsX
в яндексе линукс популярнее винды. Вообще (моё личное мнение) винда для разработки удобна тогда и только тогда, когда вы разрабатываете исключительно под винду.
С настолками, действительно, возня, но условный вебчик на джаве пишется так, что можно гонять отдельные сервисы локально без каких-то проблем. Понятно, что на серваках может быть докер, мониторинг и всякие прокладки, но локально дернуть main-класс ничего не мешает.

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

testcontainers под винду нормально работает? небось только с WSL и какими-нибудь костылями. Но под WSL сейчас, наверное, можно почти что угодно завести, только чем это от разработки под линукс отличается? Не говоря уж о том, что во многих не тривиальных мейвеновских-гредловских проектах будет кроме java куча скриптов на каком-нибудь баше, поддерживать которые под виндой больно и не нужно.

Нормально работает, без всяких проблем. Только докер поставить надо :)

А докер под виндой сейчас разве не через wsl работает?

нет

Недавно выпустили WSL 2, в докере тоже появилась его поддержка.
только памяти он жрет капец, как собственно и wsl1, это всеравно гдето внутри виртуалка у него
wsl1, это всеравно гдето внутри виртуалка у него

У первой версии нет виртуалки, а драйвер занимает пару сотен килобайт.
да, я чёто попутал походу (с докером виндовым)

Скорее всего, работает так же как под макос: на уровне ядра системы запускается легковесная VM, которая автоматом транслирует часть системных вызовов Linux в системные вызовы windows

Попробую еще WSL2. Но моя попытка работать с WSL убилась об отсутствие поддержки tun интерфейсов. А VPN заказчика подразумевает их использование для подключения к инфраструктуре. Так что далеко не всё там идеально.

Ну как бы лучше (продуктивнее и с меньшей болью) запускать и отлаживать код на своём PC, а не где-то на сервере.
Конечно, можно обложиться настройкой удалённого доступа в ide, подключаться по ssh и использовать что-то для синхронизации, но это всё требует внимания и служит дополнительными точками отказа. Из проблем — ide для индексирования проекта нужен нормальнный быстрый доступ к файлам и хаки типа "клонировать код и на PC и на сервере и потом как-то синхронизировать" не очень удобны.

Я когда работал в Яндексе лет 10 назад, при всем желании локально ничего внятного запустить просто не выйдет никак из-за отсутствия гигабайт нужных данных и доступа к нужным серверам. То есть от силы что-то простейшее вроде hello world. Более того локально оно компилироваться будет ну очень неторопливо.

А всякие тестовые базы с гигабайтами нужных данных? И завязываться на них при локальном запуске

Когда я работал объемы, софт и железо были такое, что чтоб что-то читать вменяемое из этой БД к ней нужно только локально конектиться. Иначе это занимало ну очень долго все. Наверное можно было как-то держать особо маленкие, специально подготовленные базы для быстрого тестирования. Но ни у кого на это не было времени, тк мы тогда росли примерно по 70-100% в год и постоянно нужно было что-то делать, чтоб текущую архитектуру на перле и MySQL приспособить под новые реальности. MySQL в основном использовался как тупой хранилищи из-за объемов. Все join и всякие агрегации делали в коде, тк это работало на порядок быстрее.
У нас были специальные разработчиские сервера с сотнями гигов памяти и десятками ядер, настроенной репликаций данных. Чтоб подобную полную разработку сделать локально потребовалось бы немало ресурсов людских, который тогда не было.
Что-то я не совсем понял. А в чем проблема просто разрабатывать в linux софт, который будет потом работать под linux? И не надо никаких удаленных доступов и синхронизаций. Еще и контейнеры нативно.
Потому что с точки зрения только устроившегося в Яндекс топикстартера успешный столичный программист должен быть с Mac'ом ;-)
Если бы. Успешный столичный программист, судя по всему, разрабатывает на винде :)
Ну под винду есть удобные IDE (VS) и другой удобный софт.
Винда — популярное ентерпрайз решение как тонкий клиент.

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

Удаленные доступы и синхронизации конечно надо, особенно сейчас.

Я поэтому и выбрал мак (вместо линукса) — на маке есть вменяемый офис и аутлук. Что для Корп мира, ну, прям очень как важно. Но либо у Яндекса есть свои велосипеды вместо офисного пакета и органайзера, либо на роли обычного разработчика они не нужны вовсе

Запускать и отлаживать локально программу, которая в продакшене работает на серверах с 56\80 ядрами и 256\512 Гб памяти конечно можно (в каком-нибудь усечённом варианте), но очень не удобно.
Запускать и отлаживать локально программу, которая в продакшене работает на серверах с 56\80 ядрами и 256\512 Гб памяти конечно можно (в каком-нибудь усечённом варианте), но очень не удобно.

Извините, но это чушь. Вы слабо представляете себе современную разработку.

Ну как слабо представляю. Я как раз такой сервис разрабатываю. Слепок одного шарда продакшен данных занимает почти целиком сервер с 256 Гб. Конечно мы умеем делать миниатюрную копию такого шарда с искуственными данными, но достаточно часто требуется именно полноценная версия. На ноутбуке это провернуть невозможно.

Я некоторое время участвовал в разработке одного сервиса-сателлита MS SQL и там вся разработка велась на рабочей станции, естественно под Windows. Мне не понравилось. MSFT не экономит на оборудовании, но если у клиентов характерные размеры баз по 50-1000Гб, а у тебя десктоп с 32Гб RAM, то это создаёт неудобства. Всё равно приходилось пользоваться виртуалками, только ещё и с RDP вместо консоли. Ну и скорость компиляции (если нужно локально собрать) оставляла желать лучшего.
Слепок одного шарда продакшен данных занимает почти целиком сервер с 256 Гб.

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

Эээээ, писать на языке, который спроектирован кроссплатформенным — кроссплатформенно? Ну я даже не знаю, что ответить. Следовать идеологии и практикам языка, не?

Переформулирую — зачем тащить в Java-решение нативный код, который делает его (Java-решение) некроссплатформенным?
А разворачивать вы это ручками будете? Есть много вещей под который нужно свои обёртки для установки/разворачивания делать. И трудоёмкость там улетает в небеса, если кросплатформенность делать.
Аналогично со сложной сборкой. Если вам нужно на выходе exe-файл получить, то очень интересно становится.
Аналогично со всякими нестандартными технологиями. Допустим, вам нужно с видео работать. Ну, блин, напишите это на Java без нативного кода, да ещё и кросплатформенно.
exe получить как раз не проблема. Для этого есть launch4j. unix-бинарник — ещё проще.
Есть-то он есть, но сделать сложную автоматическую там тот ещё квест. Особенно если нужно разные программы из одного дерева исходников делать.
А иметь разные linux и windows билд-сервера с разными система сборки — незабываемое удовольствие. И сборку можно бы сделать под под wine, но это квест.
Собирать исполняемые файлы под linux проще, но тоже интересно — особенно же хотим, чтобы там всякая автоматизация была, ошибки внятные выводились, версия доступна была и т.п. А если мы этого не хотим, то мы криворукие уродцы.
А ещё кроме exe нужно если некий исталлятор делать и что-то для разворачивания под Linux (а если у нас несколько дистрибутивов...)
И вот это всё сделать и поддерживать ради смелого утвреждения, что раз язык кроссплатформенной, то нужно всё писать кроссплатформенно?
Нет никакого квеста. Всё прекрасно собирается как мавеном так и граделом за один проход и одной командой. Никаких разных систем сборки не надо. Для launch4j формально требуется windows, но можно обойти это ограничение, если приспичит.

Нам по сути надо либо shell -скрипт приконкатенатить к fat-jar-у либо exe-шник который запускает сам себя как java -jar . Все эти trap-ы и проверку версий пишете внутри shell скипта.

Кроме того, вроде как в последней джаве сделали какой-то упаковщик.

Если нужен rpm — используете redline rpm, если msi — wix плагин для мавена (ну здесь уже без Windows билдера походу не обойтись)

А разворачивать вы это ручками будете?

А при чем тут «разворачивать»? Если вы пишете на Java вещь, которая так себе разворачивается что под Windows, что под Linux — вы выбрали не тот язык, не тот фреймворк, и не то средство решения задачи.

И трудоёмкость там улетает в небеса, если кросплатформенность делать.

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

Если вам нужно на выходе exe-файл получить, то очень интересно становится.

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

Допустим, вам нужно с видео работать. Ну, блин, напишите это на Java без нативного кода, да ещё и кросплатформенно.

Вы не поверите — буквально полгода назад ушел из стартапа, который активно переваривал видюшечки, и все там было на джаве (точнее на Котлине, но не суть).
А при чем тут «разворачивать»? Если вы пишете на Java вещь, которая так себе разворачивается что под Windows, что под Linux — вы выбрали не тот язык, не тот фреймворк, и не то средство решения задачи.

Угу. А какие у нас есть кроссплатформенные средства, которыми нужно решать таки езадачи? Java — говорите, что нет. Python? аналогично и те же проблемы, что и у Java. C++/Qt — ОФИГЕННО ДОРОГО, долго и сложно и на выходе, мы вместо одних проблем получаем вагон других. Так себе размен. .NET — те же проблемы, что у Java, но больше, хуже и в обратную сторону. И получаем… Что такие задачи решать не нужно? Интересно.

Вы не поверите — буквально полгода назад ушел из стартапа, который активно переваривал видюшечки, и все там было на джаве (точнее на Котлине, но не суть).

Тогда вы должны понимать проблемы кроссплатформенной разработки.
Тогда вы должны понимать проблемы кроссплатформенной разработки.
Может они только на андроид их разворачивали :)

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

чтобы их можно было использовать в масштабах Яндекса.

А какие масштабы в Яндексах?
Их продуктовые направления проигрывают многим американским стартапам, как по объёму, так и по качеству. Странно слышать, что локальный продукт требует более масштабных масштабов, чем глобальный… мы же всё таки не в Китае или Индии.

Я ответил выше, у Яндекса сотни тысяч серверов.
На таких масштабах различие в 10% производительности — огромные деньги.

Мой вопрос был не про количество серверов :)

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

Kubernetes — это продукт на основе внутреннего продукта Google, Zookeeper родился в Yahoo, Cassandra в Facebook, MongoDB в 10gen и так далее, очень многие из активно используемых сегодня технологий так или иначе зародились как внутренние продукты в разных компаниях.

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

Видимо потому что я там работал и знаю, что он большой? Меня напротив удивляет ваше стремление считать Яндекс априори маленьким :)

А что для вас большая инфраструктура?
Меня напротив удивляет ваше стремление считать Яндекс априори маленьким :)

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


Например, в Netflix на Q1 2020 — 182 миллиона активный пользователей, и если я правильно помню, за время пандемии они таки пробили 200кк юзеров. А вот у Яндекса с их кинопоиском нет даже гипотетических шансов приблизиться к этим цифрам.


И по всем остальным продуктам — тоже самое.

Похоже только для Вашего уровня он большой.

Так он в абсолютных величинах большой. Или для вас большой — это когда серверов не меньше миллиона?

Мне кажется с точки зрения разработчика капитальной разницы между условными 100к и 1кк нет.

Размеры — они относительны вообще. Земля большая или маленькая? Ну вот смотря с чем сравнивать.

Очевидно, romangoward имел ввиду «большой» на столько, что надо обязательно не использовать решения, которые устраивают другие компании с большим числом пользователей.

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

У вас 2 варианта:
1) Если вы берёте внешний продукт (условный Kubernetes), то тут же натыкаетесь на то, что он не работает как ожидалось и для приведения его в пригодное к использованию состояние нужно вложить кучу сил, затем сделать все интеграции и тому подобное, в дальнейшем вы вероятно получите некоторое (небольшое на самом деле) снижение порога вхождения для новых программистов, которые возможно будут знакомы с устройством вашей платформы.

Теперь у вас 2 конкурирующих платформы, перевести старые сервисы на новую — отнюдь не бесплатное мероприятие, это годы работы.

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

У обоих вариантов есть и плюсы и минусы, первый вариант приятнее для программистов, которые получают опыт работы с модной технологией, которая скорее всего устареет через 5 лет, второй вариант приятнее для компании — внутренний продукт проще развивать под свои потребности.

Почему не опенсорсить: во-первых это не бесплатно, чтобы сделать хороший опенсорс проект из того, что уже работает в проде, нужно вложить действительно много усилий, во-вторых не все продукты имеют смысл в отрыве от экосистемы (по аналогии с Google TrueTime), в-третьих часть продуктов таки опенсорсится, если есть достаточная мотивация у их разработчиков, чтобы этим заниматься (Clickhouse, Catboost, etc).
Только это инфраструктура была создана в Яндексе в более-менее юзабильном виде лишь через несолько попыток. И каждый раз приходилось переносить сервисы из одной системы в другую. Иногда это было просто. Иногда — не очень.

Локальный рынок бывает разный. В Китае есть немало местных игроков, по сравнению с которыми FAANG — маленькие.
Ну и у Яндекса есть экспортируемые зарубеж продукты, в том числе за границы бывшего СССР.

В начале ветки:
мы же всё таки не в Китае или Индии.
НЛО прилетело и опубликовало эту надпись здесь
Может быть все-таки «сотни тысяч» вируалок? Был на экскурсии в датацентре Яндекса под Хельсинки. Красиво, конечно, но не прям rocket science. И сотен тысяч серверов там далеко не показали.
У Яндекса не один датацентр. Из них несколько своих — в Сасово, Мянтсяле. И постоянно проводятся учения «в нескольких датацентрах пожар».
Уже давно не проводятся.
Уже ведь опять проводятся.
Но отдельные сервисы в специальном списке исключений? :)
Проводились, сейчас подход поменяли, но при управлении рисками и планировании нагрузок варианты учитываются.

Ничего странного нет в том, что крупный игрок проигрывает в чём-то стартапу. Тот же Яндекс был когда-то стартапом и выстрелил на фоне других крупных (на тот момент) игроков на рынке.


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

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

Это можно было бы хоть как то принять если бы не текст статьи:
>>За это никто не платит
Это просто входит в основные обязанности, мой руководитель говорил «если мы не можем написать сервис так, чтобы из-за него нас не будили по ночам — нас всех надо уволить всвязи с профнепригодностью» — звучит конечно категорично, но тут есть разумное зерно.
НЛО прилетело и опубликовало эту надпись здесь
должна оплачиваться
В Яндексе так не принято (с)

Если ваш сервис регулярно падает ночью — ваша работа вообще не должна оплачиваться.


А если речь про оплату пару раза в год, то это не так уж важно.

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

А рядовых кодеров будят ночью поднимать рейд?

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

При чем тут вина? Чинит часто не тот, кто "виноват", а кто может.


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


Если вас попросили сделать криво, то у вас есть все моральные причины отказаться от ночной работы. Потому что в этом случае вы сделали именно то, что просили. Можно предложить сделать надёжнее, если заказчик согласен.


А если вас попросили сделать, что б работало, то вы либо делаете, что об оно доживало до утра, либо не жалуетесь, что приходится ночью поднимать. Я думаю, это справедливо. Свою работу нужно делать хорошо (кроме пункта 1 и то не всегда).


Рейд падает очень редко, если определить причину можете только вы, то ничего страшного диагностировать проблему ночью 1-2 раза в год (если железо падает чаще — бегите оттуда).

Это было не про «кто чинит» а к «ваша работа вообще не должна оплачиваться.»
Я для себя сделал простой вывод, судя по всему, в яндексе не поставлен нормально процесс on-call/triage. Обычно, разработчик, который дежурит на on-call не чинит проблемы сам, у него тупо нет возможности это сделать. Его задача заключается в другом. А для того, чтобы собрать сломанный raid массив есть SRE.
Вобще нормальный код должен быть устойчив к отказу рейда на одном конкретном сервере.
Если ваш сервис регулярно падает ночью — ваша работа вообще не должна оплачиваться.

Почему?


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


  • фича Икс должна быть готова через неделю
  • не успеваете в рабочее время, работайте в нерабочее
  • не успели, -100%
  • успели, выкатили, сервис упал: -100%
  • недовольны? может вы просто стремные профессионалы которые не могут оценивать и делать нормально?

А если речь про оплату пару раза в год, то это не так уж важно.

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


Я не к тому что разработчик должен вставать в позицию "я работаю по таскам с 9 до 17, все остальное меня не волнует". Вовлеченость в продукт это здорово, просто я считаю что не очень справедливо когда компания у которой есть деньги предпочитает эксплуатировать вовлеченность и экономить.

Я не к тому что разработчик должен вставать в позицию «я работаю по таскам с 9 до 17, все остальное меня не волнует».
А почему нет, кстати? Работник и не обязан делать что-то ещё, если это прямо не прописано в договоре. Почему-то работодатель, когда речь заходит о выполнении его обязанностей, считает каждую копейку, но от работника вдруг требуется какая-то «вовлечённость» и «лояльность».
Крутые парни, уходя с работы, не оборачиваются на недоделанные задачи.
Если это не что-то прямо резко срочное, что уже прямо на проде горит, то оно вполне потерпит до утра.
пусть он будет падать раз в неделю

Если ваше требование такое — не жалко, пусть падает, то просить чинить ночью нет никаких причин.


таких бесплатных разработчиков

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


Даже пара раз в год показывает отношение компании к людям

Согласен. Речь о том, что это не важно с финансовой точки зрения. Компания легко может оплатить две ночных смены, это слабо влияет на ФОТ, никакой особой экономии тут нет.

Как знакомо. Нормально сделать займет 2 месяца? Херня, делайте за 2 недели.


Так, почему сервис упал? Времени мало было? Просто вы хреново работали, исправляйте как хотите.

фича Икс должна быть готова через неделю
не успеваете в рабочее время, работайте в нерабочее
не успели, -100%
успели, выкатили, сервис упал: -100%
недовольны? может вы просто стремные профессионалы которые не могут оценивать и делать нормально?

О, вы случайно в Озоне менеджером не работали?
не успели, -100%
успели, выкатили, сервис упал: -100%


Хм, вот не просто так там очень большие премии
мой руководитель говорил
Языком чесать много мозгов не надо… А он сам то мог писать так, чтобы код был без багов и чтобы сервисы не падали? Что-то слабо верится, это позиция на уровне утопии
Да, мог, он руководил разработкой поиска по документам. Конечно факапы всегда случаются, но я даже на своём опыте могу сказать, что почти любой сервис можно довести до такого состояния, когда он практически не требует временных затрат на эксплуатацию в нерабочее время.
Но на доведения нужно то самое время, которое должно быть оплачено, дают ли его на это?
Этим обычно в рабочее время занимаешься, вполне понятная адекватному руководителю задача.
Странно почему автор пишет про неоплачиваемые переработки, если руководители адекватны, и время на доведение есть.
В Яндексе работают тысячи людей, и команд, соответственно, сотни. В каждой из них свой небольшой мир.
В Яндексе работают тысячи людей, и команд, соответственно, тысячи.
Команд, соответственно, должны быть сотни.

Но ведь какое-то влияние взаимное должно же присутствовать? Ведь эти команды не работают в изоляции, а когда в некоторых считается "нормальным" и "необходимым" перерабатывать (работать за бесплатно), то менеджеры могут на них указывать и говорить:"а вот они сидели ночами, фиксили баги, а вы отказываетесь..."

Работать бесплатно — неправильно. Если кто-то считает, что это правильно и делает так — ССЗБ.
… а когда в некоторых считается «нормальным» и «необходимым» перерабатывать (работать за бесплатно), то менеджеры могут на них указывать и говорить:«а вот они сидели ночами, фиксили баги, а вы отказываетесь...»

а вам доводилось иметь дело с такими странными менеджерами?

"обычно"
А разве не должно быть "всегда"? Мне, к счастью, ещё не пришлось работать в месте, где переработки бы не оплачивались.

Мне тоже не доводилось, но вот автору довелось.
У нас если и были переработки (я работал в 3 разных командах), то они были добровольными.

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

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

Это похоже на манипуляцию со стороны руководителя. Переработки и доступность во вне рабочее время должны согласовываться и удовлетворять обе стороны. Если руководитель продавливает ответственность 24/7 на разработчиков без какой-то дополнительной компенсации, то руководитель наверное в глазах своего руководства молодец раз смог организовать поддержку 24/7 задешево. Для меня немного удивительно что это на уровне Яндекса так устраивают, но с другой стороны вся прибыль Яндекса зависит от того как сильно они сэкономят на з/п недешевых кадров.


Для меня нормальная мотивация такая, мы платим тебе +20% и ты доступен неделю в месяц в любое время на решение проблем своего сервиса (цифры произвольные). И у тебя есть выбор, хочешь ли ты +20% или хочешь чтобы тебя не беспокоили. Ты можешь сделать так что ты получаешь +20% и твой сервис настолько хорош, что он не падает. Это я немного с потолка придумал, может быть приняты другие варианты. (У нас в этом плане примерно как в яндексе :)

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

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

Да, тут, скорее это была форма речи с преувеличением, больно уж позиция сомнительная для тимлида — наказание своих работников неоплачиваемым ночевками перед компьютером за какие-то ошибки в работе. Хотя может сходил на какие-то курсы начинающих менеджеров :) Плохо, что в куче контор есть та же поддерка N-ой линии на программистах, и дежурства, но при этом это можно как-то компенсировать, а тут — нет.
Вполне обычная позиция. Я имел несчастье работать с подобными «деливери менеджерами\лидами». Они боятся что-то сказать руководству\заказчику. Боятся просить больше времени. Пускают пыль в глаза за счет разработки, экономят резервный фонд-бонусы.
Занижают оценки по срокам чтобы показать «какой я молодец». Потом песочат разрабочиков «мы должны уложиться» это «у нас жесткий дедлайн» и т.д. Всегда находятся те, кто работают. Отказывающихся всегда можно потом на ревью завалить.
Это при том, что в этой же компании на соседнем проекте на того же заказчика может быть все прямо очень ОК.
Во-первых, обычно, человеки с первого раза идеально не делают (т.е. это не только IT, касается, раз уж увольнять то всех и отовсюду, будем сидеть и плевать друг в друга, какие мы все непрофпригодные). Надо учитывать, что создание — процесс итеративный, с ошибками и падениями.
А во-вторых, не надо жлобиться на ресурсы для разработки, сколько потратили — столько и получили.
Иначе, такие вот статьи.
Когда толкаются такие пафосные и категоричные лозунги, напрашивается моментальное предложение: «Начните в первую очередь с себя.»
Потому что «Нет плохих солдатов, есть плохие генералы.»
Да, стоит, Docker и Kubernetes работают не настолько хорошо, чтобы их можно было использовать в масштабах Яндекса.

Смешно. Масштабы Яндекса несравнимы например с масштабами Walmart, а там активно пользуются стандартными кубами, кафками и докерами.


Может просто кто-то не умеет их готовить?


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

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

А каковы масштабы Walmart? Могу ошибаться, но он же только недавно начал переход в онлайн и всегда старался держаться традиционной модели продаж.
Опять же, Google и Facebook не используют Kubernetes — у них свои непубличные велосипеды. Используют ли его в Amazon я не знаю, но имея такую команду разработки облака, они тоже вполне могут себе позволит своё решение (а решения на базе k8s продавать кастомерам).

Гугл не использует кубернетис просто потому что их инфраструктура строилась задолго до кубернетиса и по большому счету кубернетес ей и был вдохновлен.

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

У вас откуда такая информация?
Вы же в курсе что Кубернетис — это разработка самого Гугла?
Да, конечно. Я имел в виду core infra самого гугла.
Что такое core infra самого гугла? какой из сотен сервисов вы считаете его core?
Kuber это не первая контейнерная оркестрация, которую разработал гугл. Переводить все сервисы, которые работают уже десятилетия на кубер — это долго и дорого.
Возможно это есть в глобальных планах, но насколько я знаю, гугл уже поднимает на кубернетесе новые сервисы и кучу внутренних тулзов.
Это — https://en.wikipedia.org/wiki/Borg_(cluster_manager). В интернете есть немного иформации если поискать.

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

Просто подумайте — первый релиз кубера всего 5 лет назад.
А в гугле — подавляющее количество основных сервисов гораздо старше.

За пять лет кубер значительно изменился и вырос, скажем сейчас он выглядит гораздо надежнее, появились популярные инструменты, из-за массового использования были найдено и устранено множество проблем.

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

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

Кубер — это, безусловно, хорошо, если у тебя кластер на 10, 10 или даже 1000 машин. Но запустится ли он на 100к машинах? Как будет работать оркестрация меж-локационнных выкладок? Как шардировать всё это хозяйство, и иметь при этом один логический кластер?

Собственно, даже в доке кубера пишут:
At v1.18, Kubernetes supports clusters with up to 5000 nodes. More specifically, we support configurations that meet all of the following criteria:

No more than 5000 nodes
No more than 150000 total pods
No more than 300000 total containers
No more than 100 pods per node

5к нод — это совсем несерьёзно даже для Яндекса/Мейла, не говоря уж про Гугл.

Я не совсем понимаю — зачем все 500к условных машин загонять в один кластер? Чтобы отгребать проблемы от единого, но распределенного контролплейна? Почему не делать кучу маленьких, логически отделенных кубернетесиков, поверх которых уже будет оркестрацию кластеров?


More specifically, we support configurations that meet all of the following criteria:

И ещё. Это скорее не "хард" лимит, а некоторый отказ от ответственности, что же "мы не гарантируем работу на 5000+ вычислительных узлов" (что на самом деле уже дофига), "но если хотите — пробуйте сами"

Например, потому что вам надо задеплоить map-reduce на 15к машин? Или потому что вам надо задеплоить какую-нибудь систему машинного обучения на тысячу машин, и «надувать» её по ночам, когда пользовательская нагрузка спадает?

Чем больше машин под управлением одного шедулера, тем более эффективно он может распределить ресурсы. Даже если делать несколько кластеров, то каждый из них должен быть на порядок больше, чем самые жирные системы, которые в нём живут, иначе будут либо пятнашки по перекидыванию машин между кластерами, либо пятнашки по перекидыванию проектов между кластерами. Чтобы вот всего этого избежать и делают кластера размером в availability zone. Почитать про это можете в статье про tupperware: engineering.fb.com/data-center-engineering/tupperware.

Я бы ещё сказал, что если у вас под кубернетесом есть IaaS, который вы можете легко сдувать-надувать, то строить один большой кластер действительно нет смысла. Но в случае с Google/FB borg/tupperware крутятся на голом железе.

Если взять публичные данные
https://www.similarweb.com/top-websites/category/e-commerce-and-shopping


Е-коммерция Волмарта на 7ом месте и туда ходит 450М уникальных человек в месяц. Я.Маркет на 47ом с 80М посетителей в месяц.


При этом Волмарт как бы крупнейший ритейл в мире с ~5000 реальных магазинов и это только в США (есть ещё кучи выкупленных брендов в других странах).


АйТи тут огромное даже если брать только е-коммерцию. С учётом физ-ритейла масштабы уже совсем страшные. Товарооборот, ценообразование, логистика, складское ПО, да даже ПО для управления персоналом (2 миллиона человек) — любая задача сразу превращается в HighLoad Cup.


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


При этом все густо обмазано вполне стандартными решениями — кафки, кубы и пр.


Есть и прикольные нестандартные. Кэш на коболе с интересными свойствами


https://github.com/walmartlabs/zECS

Возможно вы правы, буду благодарен за ссылку на статью об устройстве внутренней инфраструктуры Walmart.

Они действительно строят на них собственную инфраструктуру или как Amazon, предоставляют их клиентам облака?
Они действительно строят на них собственную инфраструктуру или как Amazon, предоставляют их клиентам облака?

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

НЛО прилетело и опубликовало эту надпись здесь
Если бы все крупные компании не писали собственные велосипеды, а брали только готовые решения, то собственно, вы никогда бы не увидели ни Kubernetes, ни React, ни Clickhouse(яндекс)
Если бы все крупные компании не писали собственные велосипеды, а брали только готовые решения, то собственно, вы никогда бы не увидели ни Kubernetes, ни React, ни Clickhouse(яндекс)

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

Вполне возможно что автор не до конца понимает или перефразирует причины, по которым Яндексу не подходят эти решения.

Не маркету — Яндексу в целом, маркет же живёт на общей инфраструктуре.
Смешно. Масштабы Яндекса несравнимы например с масштабами Walmart, а там активно пользуются стандартными кубами, кафками и докерами.

Walmart может себе такое позволить. Закупки серверов это заметная часть CapEx'а Яндекса. Очень много человеко-лет закопаны в то, чтобы оптимально утилизировать оборудование. Плюс Яндекс технологическая компания, её ценность — в технологиях. Многие «велосипеды» либо в целом лучше, чем открытые аналоги и создают конкурентное преимущество, либо появились раньше, либо решают слишком специфические задачи. Там где можно переходить на стандартные технологии — переходят.
НЛО прилетело и опубликовало эту надпись здесь
Ни на одном из крупных рынков, где Яндекс зарабатывает деньги, у него нет монопольного положения, везде сильные конкуренты. За каждым из сервисов стоят сложные технологии, даже если вам кажется, что это очередная доска объявлений или просто клиент такси. В конце концов тогда в IT вообще нет ничего крутого, если сложный ML на сотнях тысяч RPS это не круто.

Я некоторое время работал в Microsoft, у меня есть знакомые и бывшие коллеги в FAANG'ах и, я бы сказал, что технологически Яндекс выглядит очень даже на уровне и во многом вынужден быть эффективней именно засчёт технологий там, где условный Google может посадить 100 разработчиков и залить проблемы железом.

То что Яндекс оказался на огороженном локальном рынке — это, на мой взгляд, большая проблема для компании, которая мешает ей «захватить мир», а не преимущество.
НЛО прилетело и опубликовало эту надпись здесь
Это не административный ресурс, Яндекс интернетом не управляет. И то, и другое — это попытка продать свою остальную экосистему тем, кто уже пользуется продуктами компании. Не знаю деталей и кто там более не прав, но мне кажется не это делает Яндекс и Гугл успешными, а всё-таки именно технологии.

Гугл в 10 раз больше по персоналу, в 50 раз больше по income'у, при этом Яндексу приходится решать схожие с ним задачи и лезть в области, где Гугла нет. Начиная с определённого масштаба уже не важно 10 тысяч серверов или 100 тысяч. Вам нужен, например, map-reduce и у вас нет в 10 раз больше разработчиков чтобы их нагнать в этот проект, приходится быть эффективными.

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

Я понимаю, что сложно доказать не нарушая NDA, что за фасадом в Яндексе не тысячи голодных студентов, админресурс и прорва серверов, но кажется даже только по внешним признакам можно оценить, что технологически Яндекс как минимум интересен на фоне FAANG'ов. Периодически проводятся всякие конференции и т.д., можно зайти, послушать и поспрашивать как делаются очередные доски объявлений :)
НЛО прилетело и опубликовало эту надпись здесь
Еще раз — Гугл в 100 раз крупнее вас по трафику и сервисам, имеет в 50 раз больше прибыли и при этом имеет всего в 10 раз больше людей, где ваша эффективность? Пока что я вижу что Гугл 5х кратно эффективнее вас.

Вообще-то, это не так работает. Нельзя просто брать большую фирму, а потом делить в 10/100 раз, так как ряд вещей будет стоит одинаково и вообще себистоимость любого продукта (особенно ПО) падает с тиражом.

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

В моя сторона третья — я ни к Яндексу, ни к Гуглу отношения не имею. Просто мерять эффективность таким образом — не правильно в корне.

При этом Гугл не плодит конкурентов доставке еды, такси и прочим доскам объявлений

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

Гугл не плодит конкурентов доставке еды, такси и прочим доскам объявлений не потому что не хочет, а потому что Амазон, Алиэкспрер, Убер и т.п. слишком сильны на глобальном рынке.
Еще раз — Гугл в 100 раз крупнее вас по трафику и сервисам, имеет в 50 раз больше прибыли и при этом имеет всего в 10 раз больше людей, где ваша эффективность? Пока что я вижу что Гугл 5х кратно эффективнее вас.

Это пять.
Интеллектуальный уровень:
Одна женщина вынашивает ребёнка 9 месяцев, возьмём 9 женщин и ребёнок будет через месяц!
НЛО прилетело и опубликовало эту надпись здесь
Да, стоит, Docker и Kubernetes работают не настолько хорошо, чтобы их можно было использовать в масштабах Яндекса.

Потому что решать какие конкретно сервисы должны ехать в докер/кубер, а какие жить на виртуалках а какие на bare iron, должны архитекторы, а не менеджеры сверху.
Docker/Kuber/Openshift прекрасные инструменты. И я видел плохую реализацию, неплохую и отличную. Изучив историю — везде совпадало с тем, от кого исходило решение — от инженеров или от менеджеров.

>> Здесь считается нормальным посадить senior разработчика «грепать» логи с нескольких хостов, потому что ELK-стек not invented here.
> Насколько я помню, в Яндексе принято возделывать свою делянку, если что-то неудобно, это надо улучшать.

Ну тут же конкретный пример. Поднять ELK, либо любой другой лог аггрегатор несложно. На крайняк собственно погрепать логи может mid или вообще L3 support.

>> Разработчики каждого сервиса сами отвечают за его функционирование в production’е
>> Это нормально, представьте на своём месте несчастного админа, который должен чинить ваш велосипед даже не представляя как он работает.

Это не нормально. Для начала, вы отрезали значимую часть фразы, а именно «Для этого вводятся так называемые недельные факап-дежурства».
На подобные дежурства должны выделяться отдельные люди из L3 поддержки. Разработчики могут быть on-call, если вдруг что-то пойдет не так, а не дежурить лично, в виде переработки. А в правильно построенном SDLC, разработчики могут быть on-call во время релиза, а в остальное время продукт не должен падать, за чем следит production suppor team, и разработчики обрабатывают тикеты в рабочее время.
Я не исключаю, что может быть критичная ситуация, когда поднимут фиксить багу в 3 часа ночи. Но это не должно быть регулярно назначаемым недельным дежурством, это должно быть исключительным событием, происходящим не чаще раза в год.

> А ещё очень много проектов, которые собираются и запускаются только на Linux.
> Это нормально если у вас production на Linux.
Возможно. Но для java/nodejs современные сборщики типа npm/gradne/maven могут собрать продукт и под виндой, то есть например на машине разработчика, чтобы он мог локально и быстро что-то дебажить. Плохо не то, что проект собирается только в Линукс, плохо то, что на это жалуется человек, проработавший более года, и мне понравился стиль изложения. Поэтому априори я доверяю мнению автора, а именно то, что многие проекты незаслуженно собираются исключительно под Линукс.
В Яндексе же культура инженеров, они и принимают почти все решения, просто это могут быть не разработчики конкретного сервиса, а комитет из «заслуженных инженеров», принимающих решение на уровне всей компании.

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

Это не сложная иерархия.

Это обычная ситуация — должна быть команда, которая оказывает production support.
И это не разработчики, которые нанимаются разрабатывать.
Это те, которых нанимают именно на условия L3 support, работа посменам, 24/7.
В обязанности — постоянно читать нотификации с различных систем мониторинга, оперативно реагировать, коммуницировать с соответствующими командами. Если слетел диск — это не разработчик должен выяснять и открывать тикеты на админов. Это делает L3 саппорт.
А если разработчика припахать на дежурство, он В ПРИНЦИПЕ не будет способен погрузиться в решение сложной задачи, потому что постоянное переключение на чтение писем, слежением за системами мониторинга просто не дают это делать.
В том сервисе, за который я отвечал (in-memory key-value storage на 300 машин), всё было устроено так:
Система сопровождалась двумя людьми — мной и старшим коллегой, который её написал. За железом следила автоматика, вылет единичных машин не страшен, мы смотрим только за метриками, которые влияют на работу клиентов.

За пару месяцев работы мы довели эту систему до состояния «за полгода ни одного коммита, всё работает само», ещё где-то года полтора с неё клиенты на новую-кленовую переезжали, тратить время на её эксплуатацию было не нужно.

Если бы она сломалась в ту неделю, когда я был дежурным — мне бы позвонили из колцентра и попросили её починить.
Сравним два абзаца?
За пару месяцев работы мы довели эту систему до состояния «за полгода ни одного коммита, всё работает само», ещё где-то года полтора с неё клиенты на новую-кленовую переезжали, тратить время на её эксплуатацию было не нужно.

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


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

Мы, к сожалению, не знаем чем именно занимался топикстартер в маркете и почему у них там всё ломалось.


Мне довелось работать в инфраструктуре поиска — там картина другая, я считаю небесполезным её показать.


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

> колцентр, который осуществляет дежурство и в случае чего вам звонит
Это не тот коллцентр, где инженеры сидят) Это тот, где просто названия лампочек зачитывали. А лампочки ещё и настроить правильно нужно.
Да, стоит, Docker и Kubernetes работают не настолько хорошо, чтобы их можно было использовать в масштабах Яндекса.
А как так получилось, что Яндекс.Облако предоставляет Kubernetes как сервис для клиентов, но для себя его использовать по какой-то причине не может.
Ну и отдельная проблема, что написание своих велосипедов для фундамента системы скорее всего означает ещё и переписывания с нуля всего стека CI/CD, потому что все имеющиеся решения заточены под Docker и Kubernetes или что-то похожее. Можно конечно сделать хитрее и избежать затрат на переписывание CI/CD с помощью отказа от CI/CD, и всё билдить, тестировать и раскатывать ручками, и видимо, Яндекс частично по этому пути и пошёл.

Ну и в конечном счёте, если Кубер не очень, так может попробовать контрибьютить в сам кубер, а не изобретать «не имеющее аналогов» решение?
А как так получилось, что Яндекс.Облако предоставляет Kubernetes как сервис для клиентов, но для себя его использовать по какой-то причине не может.

Для Kubernetes Initial release 7 June 2014

Я так мыслю, что к этому моменту у Яндекса все уже давно работало на чем-то другом.
> потому что все имеющиеся решения заточены под Docker
На это ответить можно легко — github.com/yandex/porto с докером совместим и мало кто догадывается, что там не docker, когда катает релизы. Правда не уверен, что на гитхабе весь код (точнее — точно не весь, но насколько).

> для себя его использовать по какой-то причине не может.
В основном из-за того, что kuber мало приспособлен к реальной жизни. Цена поддержки в больших инсталляциях с огромным количеством сервисов выше (заметьте — не микросервисов, тут сервисы-то не пересчитаешь), чем писать что-то своё узкоспециализированное.
И как выше заметили — яндекс создан раньше, чем k8s и всё необходимое к нему, жили же до этого как-то.
Да, стоит, Docker и Kubernetes работают не настолько хорошо, чтобы их можно было использовать в масштабах Яндекса.

Что мешает вкладываться в разработку open source проектов, вместо создания своих велосипедов? Это был риторический вопрос.


Это нормально если у вас production на Linux.

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


Я за время работы в Яндексе отучился в ШАД вольнослушателем

Ага, и это по вечерам после работы. У меня так не получилось, потому что ещё есть семья


очень много зависит от команды и руководителя

И это печально, потому что кандидат со стороны про это знать не может. И выбрать что-то после 1-1,5 часов общения с руководителем тоже нереально

И это печально, потому что кандидат со стороны про это знать не может. И выбрать что-то после 1-1,5 часов общения с руководителем тоже нереально.

Собеседование — обоюдный процесс. Если человек не может понять устраивает ли его руководитель после интервью — возможно не стоит идти в такую компанию?

Собеседование — это презентация с обоих сторон. Детали конкретной «реализации» вылазят уже после испытательного срока.

— Смогу я ездить на профильные конференции?
— Конечно!
— А за границу?
— Конечно!

А по факту, может случиться, как автора: то фонды исчерпали, то конфа не сильно профильная, то коронавирус, то еще чего. И бог бы с ней, с конференцией, но оно так чего не коснись. ))
Что мешает вкладываться в разработку open source проектов, вместо создания своих велосипедов? Это был риторический вопрос.


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

Велосипед точно так же может помереть за 5 лет.

Скорее, Яндекс просто не умеет эти технологии готовить в своих масштабах. К примеру, Ericsson/Nokia предлагают контейниризованные продукты Mobile core, которые прокачивают сотню гигабит в односерверном исполнении и терабиты трафика в мультисерверных решениях, успевая по пути его развернуть до L7 и еще и классифицировать попакетно для систем тарификации.


Никакие "свои" докеры/кафки никто в здравом уме себе не пишет — если надо что-то подтюнить в существующем opensource, контрибутят прямо в сам проект, например, Ericsson/Nokia контрибутят в опенстек (конечно, контрибутят не всё, что доработали, но свой опенстек они не пишут).

> концепции одни и те же, а умение пользоваться конкретной технологией не стоит почти ничего.

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

Это из реального интервью?

Это нормально если у вас production на Linux.

Да, допустимо, но это как коммитить в репу проектные файлы иде — потому что без нее не собрать — неаккуратно и не лучшим образом говорит о разработчиках, тем более в JVM (в C++ еще можно понять).
Зачем ты это сделал? :)
Известно же, чем заканчивается: не спишь, расстраиваешься, еще и минусов в карму, небось, напихали.
Разработчики каждого сервиса сами отвечают за его функционирование в production’е


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


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

Читал не так давно статью от разработчика из Одноклассников, у него Cassandra плохо работала, пилили свой велосипед. Похожее мышление. Данных, конечно же, не было. И тут похожее.


За 17 лет в индустрии научился замечать подобные вещи, обычно это такой период, лет за 5 проходит.


Плохо то, что подобное поощряется и даже пролазит на конференции, и оттуда распространяется дальше. И на хабр тоже.

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