Вот не уловил, где вы тут увидели потерю 40 минут?
Я кстати примерно так же обычно поступаю. Потому что это правильно - прежде чем "созвониться на пару минут", извольте изложить свой вопрос текстом. И найдите в моем календаре свободное время. Чтобы я подготовился, и понимал, что мы вообще собрались обсуждать.
Во-первых, то что вы собираетесь создать, называется СУБД. СУБД, а не база данных. И это две разные вещи. Если бы вы собирались создать базу данных, вы бы взяли готовую СУБД, и написали бы описание своей базы и ее таблиц на языке SQL (если быть чуть точнее, DDL). И выполнили бы.
Во-вторых, чтобы научиться понимать, как это работает, полезно научиться абстрагироваться от мелких неважных деталей. Потому что начиная описывать с чтения команд с консоли, вы дойдете до конца к 50 статье. Если вообще дойдете.
Кроме всего прочего, чтение SQL откуда-то - это обычно так называемый клиент, или клиентская часть, а типичная СУБД этим вообще не занимается. Поэтому для понимания принципов это не особо-то и нужно. Было бы намного логичнее начать с чего-то типа слоя хранения, т.е. Б-деревьев, ну или парсера SQL (причем напрашивается просто взять готовый), ну или с той части, которая строит план запроса.
Ваша формулировка "забить на успех спринта" в моем исполнении звучала бы скорее так: "Назвать имеющийся результат спринта успехом". Ведь что главное в успехе? То что вы с заказчиком согласны считать результат таковым. Результат полезен для заказчика, и получен в разумные сроки (возможно чуть позже, чем хотелось).
Вот честно, никогда не видел чтобы синьоры разработчики уходили в аналитику. Хороший разработчик и так обычно знает свою систему и бизнес компании на уровне аналитика, и вполне может работать без наличия оного, выполняя его роль. Пусть не каждый, и не всем это нравится, но это вполне типично. А вот чтобы наоборот - такие мне попадались буквально единицы.
А уж чтобы уйти в маркетинг? А вы хоть одного такого видели живьем? Я могу поверить в такое, но считать это вариантом развития карьеры всерьез - ну очень странно.
Ну, dynamic allocation это строго про число executors. Если ресурсы это память - то динамической аллокацией это не решается.
Задачи на уровне оркестратора - это всегда сложности интеграции по сравнению с кусками кода одной программы. Они конечно решаются, но это лишний геморрой. Ну т.е. обычно при таком способе у вас вместо взаимодействия по API получается обмен файлами, который далеко не всегда удобен (не говоря уже про такие простые вещи, что эти файлы нужно за собой подчищать и т.п.).
Ну вот скажем, простой пример - если оркестратор Oozie, то задача может записать key-value результат, именуемый data, при помощи которого можно передавать что-то между задачами. Это API, пусть и примитивный.
Но вот проблема - если задача завершается ошибкой, то Oozie считает, что data не будет.
Но ведь задача же может завершиться ошибкой, проделав часы работы, и какие-то результаты у нее все равно будут (я уже не говорю, что в случае Yarn нам бы не мешало как-то сохранить applicationId для последующего анализа, почему оно вообще упало, или скажем код возврата Spark, чтобы понять, что ему скажем памяти не хватило).
Не вижу причин, почему не использовать, если все что вы описываете, к нам неприменимо? Вас смущает отсутствие перезагрузки месяцами - а как по мне, это признак стабильности. Что в этом плохого-то, особенно в ситуации, когда бандлы можно перезагрузить на лету?
Я вполне понимаю, что ваши проекты хорошо ложатся не k8s, ну так и замечательно. Это ничего практически не говорит о карафе, кроме того, что для ваших проектов k8s лучше. Я могу даже сказать, что караф довольно туго масштабируется - мы вот пробовали cellar, я бы не стал его рекомендовать. Т.е. если вам нужно динамически расширяться - да, караф не ваш выбор, но у нас расширение предсказуемо скажем за месяц, я даже статически могу еще узел развернуть, и руками его подключить, даже без всякой автоматизации успею. А так-то у меня все через дженкинс сделано.
Упоминание же микросервисов меня вообще смутило. Для меня бандл это и есть микросервис. Понятно что не любой, я не могу написать бандл на Go. Но мне это и не нужно.
Возможно все ваши боли, или значительная их часть - от того, что вы не сами технологию выбрали, а вам она досталась, и была непривычной?
Ну как вам сказать... например высокое начальство мне говорит - вы теперь обязаны проводить еще и нагрузочное тестирование. И еще добавляет - закажите себе стенд для этого тестирования, не экономьте, берите как 100% пром стенда. Мы смотрим на свои пром стенды, выбираем из них самый маленький, и заказываем примерно конфигурацию в 20% от него. И уже от конкретных людей, которые занимаются планированием ресурсов типа процессоров или там дисков получаем замечание: "А вы в курсе, что это будет стоить XX миллионов в год?". Так что процессы на верхних уровнях очень часто слабо стыкуются с реальностью,
Не проверяете?
Если у вас есть код, который точно не работает в определенных условиях (скажем в одном случае из 100). Вы над ним подумали, и поняли, что если изменить одну строчку - то он будет работать правильно и в этом случае, а остальные не заденет (по сути, вы выполнили тест этого куска в голове). И вы можете выдать исправленную версию только тому пользователю, которого затронул этот баг. И процесс, где работает ваш код, не управляет АС, и даже автомобилем. И что вы выберете? Я лично в такой ситуации выберу отдать версию в пром, озвучив риски всем кому надо, и проверить там.
Опять же, если будет утечка корневого сертификата да еще из абстрактного УЦ с СКЗИ класса защиты КС3, то это будет новость интереснее свежей новости про xz.
Да не то слово.
Я знаю про vault, мы как раз в процессе внедрения. Поэтому и решил позадавать вопросы в том числе.
Вы слегка упрощаете. Я очень часто говорю своим QA, что не знаю, как проверить. И они меня прекрасно понимают - потому что у нас интеграционный проект, и проблемы чаще всего возникают на стыке с другими проектами, причем иногда в результате эксплуатации скажем в течение пары недель.
То есть, чтобы проверить, мне иногда всего-то нужен работающий процесс как в проме, смежный проект с его процессами, люди, которые всем этим пользуются, и все это должно поработать с определенными настройками дней 20. А времени у меня на это не заложено, потому что про влияние времени мы только что в процессе починки бага выяснили. Вот так реально выглядит вариант "не знаю как проверить" - не знаю, как проверить, за разумное время, и не угрохав на это кучу нужных для других задач ресурсов. И при этом само исправление может выглядеть как однострочник.
но и повышаем уровень защищенности (подделка сертификата немножко сложнее угадывания любимого пароля, который у меня - "qwerty").
Ну если честно, то это далеко не очевидно. У вас же много пользователей, правда? Представим что в какой-то момент вы их всех решили тоже аутентифицировать по сертификатам. Бац - и у вас в компании появился свой Удостоверяющий Центр (это перевод CA, если что). И у вас вместо записанных там и сям на бумажке паролей - валяющиеся там и сям на дисках пользовательские сертификаты. Много. В непонятном состоянии. Непонятно когда протухнут.
А уж тихая и незаметная утечка корневого сертификата, которым можно подписать пользовательский, точно такой же, под которым у вас ходит в базу DBA... это вообще.
Ну я надеюсь вы поняли. Перевод на сертификаты - это куча дополнительного высокоуровневого гемора на голову админов. В каком-то смысле уровень защищенности может и растет, но схема усложняется, в ней появляются новые неочевидные дыры в безопасности. Станет ли в итоге лучше - совсем не факт. А вот сложнее для всех - станет точно.
Вы ведь не забыли себе в календарь записать, что нужно перевыпустить сертификат через годик, да? :)
Причем не просто за знаниями, а за теми знаниями, которые учащийся сам выберет. И он сам будет нести ответственность за их полезность. И получать зарплату по результатам принятых самим решений.
И именно, что как минимум техническую. Люди которые научатся принимать ответственность за себя, они и в обычную политику потом пойдут.
А я вас и не опровергаю, я наоборот, пытался другими словами развить эту же мысль. Да, согласен. Есть некая база, которой может быть стоит учить всех, и есть куча направлений, которые довольно разные.
Я не знаю, почему у вас так, при этом у нас в области больших данных, картина плюс-минус такая же - вы нигде не найдете готового специалиста скажем по Spark, или там Cassandra, их конечно есть сколько-то - но они все как правило пристроены (переманить - можно). Поэтому вариант взять человека со знанием языка программирования, и научить остальному - не просто рабочий, но наверное и основной. И возраст тут перестает играть какую-либо роль.
Ну, а вы попробуйте его заставить? Вот я как 3 линия (и разработчик) что могу сделать такому пользователю? При этом я в целом понимаю, что у него есть куда других задач, как и у меня. Внутри компании деньги не работают. Учить, улучшать документацию, строить пользователей ровными рядами, улучшать процессы... это все можно, но особых пряников, как и кнутов, у меня для них нет. Его начальник просто скажет - у нас есть задачи поважнее. Впрочем, иногда и я им такое же скажу (что часто есть чистая правда - что важнее, делать новые фичи, или поддерживать/писать документацию? на это нет одного верного ответа).
Иногда это очень сложно сказать. Ну представьте что у вас пользователь и поддержка - это одна компания. Т.е. это внутренний потребитель. Даже если он платит деньги за поддержку и за продукт - эти деньги все равно в каком-то смысле перекладываются из одного кармана в другой.
Я в том смысле, что если это покупатель продукта - то ваш первый комментарий совершенно правильный. Просто бывают и другие варианты.
Я совершенно не против того, чтобы написать парсер SQL самому. Просто как по мне, это многовато для одного проекта, вместе с остальным.
Хотя конечно каждый сам оценивает свои способности и возможности.
Вот не уловил, где вы тут увидели потерю 40 минут?
Я кстати примерно так же обычно поступаю. Потому что это правильно - прежде чем "созвониться на пару минут", извольте изложить свой вопрос текстом. И найдите в моем календаре свободное время. Чтобы я подготовился, и понимал, что мы вообще собрались обсуждать.
Вполне возможно что месяц. Потому что отпуск, или праздники. Или просто релиз запланирован.
Во-первых, то что вы собираетесь создать, называется СУБД. СУБД, а не база данных. И это две разные вещи. Если бы вы собирались создать базу данных, вы бы взяли готовую СУБД, и написали бы описание своей базы и ее таблиц на языке SQL (если быть чуть точнее, DDL). И выполнили бы.
Во-вторых, чтобы научиться понимать, как это работает, полезно научиться абстрагироваться от мелких неважных деталей. Потому что начиная описывать с чтения команд с консоли, вы дойдете до конца к 50 статье. Если вообще дойдете.
Кроме всего прочего, чтение SQL откуда-то - это обычно так называемый клиент, или клиентская часть, а типичная СУБД этим вообще не занимается. Поэтому для понимания принципов это не особо-то и нужно. Было бы намного логичнее начать с чего-то типа слоя хранения, т.е. Б-деревьев, ну или парсера SQL (причем напрашивается просто взять готовый), ну или с той части, которая строит план запроса.
Ваша формулировка "забить на успех спринта" в моем исполнении звучала бы скорее так: "Назвать имеющийся результат спринта успехом". Ведь что главное в успехе? То что вы с заказчиком согласны считать результат таковым. Результат полезен для заказчика, и получен в разумные сроки (возможно чуть позже, чем хотелось).
В остальном же согласен почти по всем пунктам.
Вот честно, никогда не видел чтобы синьоры разработчики уходили в аналитику. Хороший разработчик и так обычно знает свою систему и бизнес компании на уровне аналитика, и вполне может работать без наличия оного, выполняя его роль. Пусть не каждый, и не всем это нравится, но это вполне типично. А вот чтобы наоборот - такие мне попадались буквально единицы.
А уж чтобы уйти в маркетинг? А вы хоть одного такого видели живьем? Я могу поверить в такое, но считать это вариантом развития карьеры всерьез - ну очень странно.
Ну, dynamic allocation это строго про число executors. Если ресурсы это память - то динамической аллокацией это не решается.
Задачи на уровне оркестратора - это всегда сложности интеграции по сравнению с кусками кода одной программы. Они конечно решаются, но это лишний геморрой. Ну т.е. обычно при таком способе у вас вместо взаимодействия по API получается обмен файлами, который далеко не всегда удобен (не говоря уже про такие простые вещи, что эти файлы нужно за собой подчищать и т.п.).
Ну вот скажем, простой пример - если оркестратор Oozie, то задача может записать key-value результат, именуемый data, при помощи которого можно передавать что-то между задачами. Это API, пусть и примитивный.
Но вот проблема - если задача завершается ошибкой, то Oozie считает, что data не будет.
Но ведь задача же может завершиться ошибкой, проделав часы работы, и какие-то результаты у нее все равно будут (я уже не говорю, что в случае Yarn нам бы не мешало как-то сохранить applicationId для последующего анализа, почему оно вообще упало, или скажем код возврата Spark, чтобы понять, что ему скажем памяти не хватило).
У нас точно такая же нога, и не болит (с).
Не вижу причин, почему не использовать, если все что вы описываете, к нам неприменимо? Вас смущает отсутствие перезагрузки месяцами - а как по мне, это признак стабильности. Что в этом плохого-то, особенно в ситуации, когда бандлы можно перезагрузить на лету?
Я вполне понимаю, что ваши проекты хорошо ложатся не k8s, ну так и замечательно. Это ничего практически не говорит о карафе, кроме того, что для ваших проектов k8s лучше. Я могу даже сказать, что караф довольно туго масштабируется - мы вот пробовали cellar, я бы не стал его рекомендовать. Т.е. если вам нужно динамически расширяться - да, караф не ваш выбор, но у нас расширение предсказуемо скажем за месяц, я даже статически могу еще узел развернуть, и руками его подключить, даже без всякой автоматизации успею. А так-то у меня все через дженкинс сделано.
Упоминание же микросервисов меня вообще смутило. Для меня бандл это и есть микросервис. Понятно что не любой, я не могу написать бандл на Go. Но мне это и не нужно.
Возможно все ваши боли, или значительная их часть - от того, что вы не сами технологию выбрали, а вам она досталась, и была непривычной?
Хорошо, спасибо
Да уж. Сразу вспоминается анекдот "Чего только не сделают, чтобы не ходить на овощную базу"...
Ну как вам сказать... например высокое начальство мне говорит - вы теперь обязаны проводить еще и нагрузочное тестирование. И еще добавляет - закажите себе стенд для этого тестирования, не экономьте, берите как 100% пром стенда. Мы смотрим на свои пром стенды, выбираем из них самый маленький, и заказываем примерно конфигурацию в 20% от него. И уже от конкретных людей, которые занимаются планированием ресурсов типа процессоров или там дисков получаем замечание: "А вы в курсе, что это будет стоить XX миллионов в год?". Так что процессы на верхних уровнях очень часто слабо стыкуются с реальностью,
Если у вас есть код, который точно не работает в определенных условиях (скажем в одном случае из 100). Вы над ним подумали, и поняли, что если изменить одну строчку - то он будет работать правильно и в этом случае, а остальные не заденет (по сути, вы выполнили тест этого куска в голове). И вы можете выдать исправленную версию только тому пользователю, которого затронул этот баг. И процесс, где работает ваш код, не управляет АС, и даже автомобилем. И что вы выберете? Я лично в такой ситуации выберу отдать версию в пром, озвучив риски всем кому надо, и проверить там.
А универсального ответа очевидно тут нет.
Да не то слово.
Я знаю про vault, мы как раз в процессе внедрения. Поэтому и решил позадавать вопросы в том числе.
Вы слегка упрощаете. Я очень часто говорю своим QA, что не знаю, как проверить. И они меня прекрасно понимают - потому что у нас интеграционный проект, и проблемы чаще всего возникают на стыке с другими проектами, причем иногда в результате эксплуатации скажем в течение пары недель.
То есть, чтобы проверить, мне иногда всего-то нужен работающий процесс как в проме, смежный проект с его процессами, люди, которые всем этим пользуются, и все это должно поработать с определенными настройками дней 20. А времени у меня на это не заложено, потому что про влияние времени мы только что в процессе починки бага выяснили. Вот так реально выглядит вариант "не знаю как проверить" - не знаю, как проверить, за разумное время, и не угрохав на это кучу нужных для других задач ресурсов. И при этом само исправление может выглядеть как однострочник.
Ну если честно, то это далеко не очевидно. У вас же много пользователей, правда? Представим что в какой-то момент вы их всех решили тоже аутентифицировать по сертификатам. Бац - и у вас в компании появился свой Удостоверяющий Центр (это перевод CA, если что). И у вас вместо записанных там и сям на бумажке паролей - валяющиеся там и сям на дисках пользовательские сертификаты. Много. В непонятном состоянии. Непонятно когда протухнут.
А уж тихая и незаметная утечка корневого сертификата, которым можно подписать пользовательский, точно такой же, под которым у вас ходит в базу DBA... это вообще.
Ну я надеюсь вы поняли. Перевод на сертификаты - это куча дополнительного высокоуровневого гемора на голову админов. В каком-то смысле уровень защищенности может и растет, но схема усложняется, в ней появляются новые неочевидные дыры в безопасности. Станет ли в итоге лучше - совсем не факт. А вот сложнее для всех - станет точно.
Вы ведь не забыли себе в календарь записать, что нужно перевыпустить сертификат через годик, да? :)
Причем не просто за знаниями, а за теми знаниями, которые учащийся сам выберет. И он сам будет нести ответственность за их полезность. И получать зарплату по результатам принятых самим решений.
И именно, что как минимум техническую. Люди которые научатся принимать ответственность за себя, они и в обычную политику потом пойдут.
А я вас и не опровергаю, я наоборот, пытался другими словами развить эту же мысль. Да, согласен. Есть некая база, которой может быть стоит учить всех, и есть куча направлений, которые довольно разные.
Я не знаю, почему у вас так, при этом у нас в области больших данных, картина плюс-минус такая же - вы нигде не найдете готового специалиста скажем по Spark, или там Cassandra, их конечно есть сколько-то - но они все как правило пристроены (переманить - можно). Поэтому вариант взять человека со знанием языка программирования, и научить остальному - не просто рабочий, но наверное и основной. И возраст тут перестает играть какую-либо роль.
Я как раз работаю в этих "прочих".
Ну, а вы попробуйте его заставить? Вот я как 3 линия (и разработчик) что могу сделать такому пользователю? При этом я в целом понимаю, что у него есть куда других задач, как и у меня. Внутри компании деньги не работают. Учить, улучшать документацию, строить пользователей ровными рядами, улучшать процессы... это все можно, но особых пряников, как и кнутов, у меня для них нет. Его начальник просто скажет - у нас есть задачи поважнее. Впрочем, иногда и я им такое же скажу (что часто есть чистая правда - что важнее, делать новые фичи, или поддерживать/писать документацию? на это нет одного верного ответа).
Иногда это очень сложно сказать. Ну представьте что у вас пользователь и поддержка - это одна компания. Т.е. это внутренний потребитель. Даже если он платит деньги за поддержку и за продукт - эти деньги все равно в каком-то смысле перекладываются из одного кармана в другой.
Я в том смысле, что если это покупатель продукта - то ваш первый комментарий совершенно правильный. Просто бывают и другие варианты.
Он ее читает - но как правило после того, как уже налажал. И да, далеко не все пользователи оплачивают стоимость техподдержки и даже покупают продукт.