Интересно, как именно автор предлагает отказаться от документации? Ну будет API клиент знать, что есть POST /document/create, а откуда он возьмёт формат данных?
Или типа идея в том, что SPA это плохо, и браузер должен вызвать GET /document/create, и там вернётся форма? Это уже устарело давно.
Из своего опыта, основная причина багов - некомпетентность программиста. Есть люди, которые делают задачи хорошо и во вменяемые сроки, а есть в той же команде, при тех же процессах и тулзах, такие, что простейшие задачи занимают месяцы и все равно там баги.
Согласен. Сам был на месте автора. Точно так же ругал начальство (CEO) и программистов, которых сам же и нанимал.
Но я не ушел, поэтому теперь понимаю свои ошибки. Нет смысла ругать CEO, нужно либо отстаивать свое мнение, либо делать так, чтобы работало годами, не ломаясь. Нет смысла ругать программистов, не умеющих разобраться в гениальном коде - лучше самому этот код не писать, а учить команду, как решить проблему. Ну и самое главное, заставлять доделывать задачи, не допускать костылей в новом коде, даже если чуть больше времени занимает. Моя частая ошибка была, я разрешал закрывать задачи в виде "ну тут сделано криво, но у нас горят сроки, потом доделаем". Практика показала, потом наступает года через 3, и все это время приходилось бороться с костылями.
По статье, автор описывает, что такие ситуации бывают, и что люди склонны хвалить себя и ругать других, когда такое происходит. Но, возможно, у автора не произошел рост как управленца, т.к. он уволился, вместо разгребания всего, что он наделал. К сожалению, очень сложно научиться правильно поступать в таких ситуациях.
Ага, необходима, только не своими силами. У нас сейчас GCP/GKE и AWS/EKS, плюс Azure/AKS кое-где. Мы решили силы тратить на наш продукт, а не на поддержку Kubernetes. В итоге вот нам так лучше.
Очень капризный в плане зависимостей: ядро, операционка, компоненты, драйвера должны быть совместимы. Когда перешли на EKS и GCP, забыли про это.
Сталкивались с багами в файловом драйвере и в сетевом слое. Сталкивались с багами в ядре. Если у нас в приложении что-то не работало, то приходилось еще и проверять k8s помимо приложения. То есть не было уверенности, что наши кластеры стабильны. У вендоров есть свои проблемы, например, у EKS поды иногда застревают в Terminated, но это не так страшно, как когда на своем кластере просто ломалась сеть или отваливался драйвер overlayfs.
Файловая система: мы так и не смогли нормально сделать persistence volumes. Пробовали Ceph, пробовали glusterfs, пробовали local volumes. Везде свои минусы. У GCP/EKS проблем нет - gp2/gp3 EBS, или аналог у гугла. "просто работает".
Практически нигде мы не запускали HA control plane - сложно, да и жалко было серверов.
Обновления это боль. С частыми релизами k8s, версии становятся EOL через 9 месяцев. Если кластеров много, это очень геморно. Плюс, пункты 1 и 2 - при обновлении обычно что-то отваливалось. У вендоров обновление происходит одной кнопкой.
Ха, мы совершили все эти ошибки. С выводами согласен полностью. Особая боль это собственный k8s. Брр.. Но вот самое интересное, даже если бы я эту статью прочитал лет 5 назад, уверен, что проигнорировал бы. Подумал бы - со мной такого не случится, это просто другие люди глупые, а я молодец, у меня такого не будет. К сожалению, опыт подобных ошибок не всегда можно передать кому-то, кто сам не попробовал.
Такая же мысль. Хотя, я работал с людьми, которые больше 10 лет программисты, но застряли конкретно. И да, согласен про опыт, я 18 лет работаю, но самомнение лет 15 назад было гораздо выше. Чем больше знаю, тем больше понимаю, что есть куда расти.
Это сложный вопрос. Компания хочет платить поменьше, сотрудники получать побольше. При этом есть долгосрочные последствия — меньше заплатил в этом году, в следующем году у команды мотивация так себе и страдает продукт. Заплатил в этом году побольше, но продукт ещё не на рынке, прибыли нет, грянул кризис и весь проект закрыли. Заранее угадать нельзя. Люди, которые со своего опыта говорят, как надо, совершают ошибку выжившего.
Поэтому и споры — надо прозрачные грейды! Нет, надо торговаться за зарплату! Оба правы — их компании выжили, и они, скорее всего, видели примеры не-выживания с обратной стратегией.
В мире капитализма ценят результат. Заработал денег сегодня — молодец, через год все отказались от продукта, потому что бажное говно в дырах — не молодец.
Или наоборот, пилил продукт 5 лет, с хорошей зарплатой, процессами, без переработок, а потом оказалось, что 3 года назад вышло бажное говно, и т.к. альтернатив не было, на него подсели, а переезжать на новый продукт дорого.
Читал не так давно статью от разработчика из Одноклассников, у него Cassandra плохо работала, пилили свой велосипед. Похожее мышление. Данных, конечно же, не было. И тут похожее.
За 17 лет в индустрии научился замечать подобные вещи, обычно это такой период, лет за 5 проходит.
Плохо то, что подобное поощряется и даже пролазит на конференции, и оттуда распространяется дальше. И на хабр тоже.
Так я про то и говорю, ваших данных в статье нет, есть чьи-то другие. Поэтому и сравнил с LinkedList, т.к. похожую аргументацию видел уже.
Переход на личности не нужен, когда можно говорить о данных и предпосылках. Предположения о моем опыте роли не играют, достаточно данные показать — свои, не чужие.
Спрашивать мои данные, когда не предоставили свои — ну странно как-то. Как вам помогут мои данные, когда вы сами не померяли и не запустили профайлер? А если запустили, тогда в чем проблема данные показать?
Например, первая же причина — "затрата ресурсов CPU на маршалинг и демаршалинг" — сколько у вас конкретно терялось на этом? Информации нет. Из моего опыта, это проценты (1-2) от общей картины, никак не 20-30.
Избыточность — ну допустим. Однако поменять структуры данных проще, чем пилить свой DataStax Enterprise.
Издержки на сеть — надо мерять, опять же. Из опыта, это тоже проценты, особенно если решить избыточность.
То есть эти 3 проблемы решаемы, и меньшими усилиями, чем велосипед из поста. Но, конечно, не так интересно.
Работаю я не DBA, нет, ближе к development manager / architect.
Натянули сову на глобус. Данных нет. Напоминает рассуждения — а давайте LinkedList вместо ArrayList.
Поддержка этого решения на порядки сложнее.
Cassandra постоянно меняется и меняет свои API, мы ее перестаем использовать именно из-за этого. Цена ошибки теперь не только потеря бизнес-логики, но и потеря данных.
Рад за бизнес, что достаточно здоров, чтобы оплачивать сомнительные эксперименты.
Кто-то ещё вводит пароли сам? Уже лет 10 пользуюсь KeePassXC, пароль набирается автоматически либо вставляется из буфера.
О чем это? О ком это? Зачем это тут?
Интересно, как именно автор предлагает отказаться от документации? Ну будет API клиент знать, что есть POST /document/create, а откуда он возьмёт формат данных?
Или типа идея в том, что SPA это плохо, и браузер должен вызвать GET /document/create, и там вернётся форма? Это уже устарело давно.
Хочу выпить, а магазин не продает после 10, и вообще закрыт уже. Ну что же, взломаю окно и возьму бутылку сам, раз не хотят моих денег.
Из своего опыта, основная причина багов - некомпетентность программиста. Есть люди, которые делают задачи хорошо и во вменяемые сроки, а есть в той же команде, при тех же процессах и тулзах, такие, что простейшие задачи занимают месяцы и все равно там баги.
Согласен. Сам был на месте автора. Точно так же ругал начальство (CEO) и программистов, которых сам же и нанимал.
Но я не ушел, поэтому теперь понимаю свои ошибки. Нет смысла ругать CEO, нужно либо отстаивать свое мнение, либо делать так, чтобы работало годами, не ломаясь. Нет смысла ругать программистов, не умеющих разобраться в гениальном коде - лучше самому этот код не писать, а учить команду, как решить проблему. Ну и самое главное, заставлять доделывать задачи, не допускать костылей в новом коде, даже если чуть больше времени занимает. Моя частая ошибка была, я разрешал закрывать задачи в виде "ну тут сделано криво, но у нас горят сроки, потом доделаем". Практика показала, потом наступает года через 3, и все это время приходилось бороться с костылями.
По статье, автор описывает, что такие ситуации бывают, и что люди склонны хвалить себя и ругать других, когда такое происходит. Но, возможно, у автора не произошел рост как управленца, т.к. он уволился, вместо разгребания всего, что он наделал. К сожалению, очень сложно научиться правильно поступать в таких ситуациях.
Ага, необходима, только не своими силами. У нас сейчас GCP/GKE и AWS/EKS, плюс Azure/AKS кое-где. Мы решили силы тратить на наш продукт, а не на поддержку Kubernetes. В итоге вот нам так лучше.
Грабли, которые были у нас:
Очень капризный в плане зависимостей: ядро, операционка, компоненты, драйвера должны быть совместимы. Когда перешли на EKS и GCP, забыли про это.
Сталкивались с багами в файловом драйвере и в сетевом слое. Сталкивались с багами в ядре. Если у нас в приложении что-то не работало, то приходилось еще и проверять k8s помимо приложения. То есть не было уверенности, что наши кластеры стабильны. У вендоров есть свои проблемы, например, у EKS поды иногда застревают в Terminated, но это не так страшно, как когда на своем кластере просто ломалась сеть или отваливался драйвер overlayfs.
Файловая система: мы так и не смогли нормально сделать persistence volumes. Пробовали Ceph, пробовали glusterfs, пробовали local volumes. Везде свои минусы. У GCP/EKS проблем нет - gp2/gp3 EBS, или аналог у гугла. "просто работает".
Практически нигде мы не запускали HA control plane - сложно, да и жалко было серверов.
Обновления это боль. С частыми релизами k8s, версии становятся EOL через 9 месяцев. Если кластеров много, это очень геморно. Плюс, пункты 1 и 2 - при обновлении обычно что-то отваливалось. У вендоров обновление происходит одной кнопкой.
Плоскости управления - это control planes что ли? Странный перевод.
Ха, мы совершили все эти ошибки. С выводами согласен полностью. Особая боль это собственный k8s. Брр.. Но вот самое интересное, даже если бы я эту статью прочитал лет 5 назад, уверен, что проигнорировал бы. Подумал бы - со мной такого не случится, это просто другие люди глупые, а я молодец, у меня такого не будет. К сожалению, опыт подобных ошибок не всегда можно передать кому-то, кто сам не попробовал.
Такая же мысль. Хотя, я работал с людьми, которые больше 10 лет программисты, но застряли конкретно. И да, согласен про опыт, я 18 лет работаю, но самомнение лет 15 назад было гораздо выше. Чем больше знаю, тем больше понимаю, что есть куда расти.
Так у вас на картинке разные RGB значения справа и слева, поэтому и цвета разные?
Может, я туплю, но в чем именно проблема, какие цвета неправильные? У вас на картинке разные значения RGB слева и справа, поэтому цвета разные.
Это сложный вопрос. Компания хочет платить поменьше, сотрудники получать побольше. При этом есть долгосрочные последствия — меньше заплатил в этом году, в следующем году у команды мотивация так себе и страдает продукт. Заплатил в этом году побольше, но продукт ещё не на рынке, прибыли нет, грянул кризис и весь проект закрыли. Заранее угадать нельзя. Люди, которые со своего опыта говорят, как надо, совершают ошибку выжившего.
Поэтому и споры — надо прозрачные грейды! Нет, надо торговаться за зарплату! Оба правы — их компании выжили, и они, скорее всего, видели примеры не-выживания с обратной стратегией.
В мире капитализма ценят результат. Заработал денег сегодня — молодец, через год все отказались от продукта, потому что бажное говно в дырах — не молодец.
Или наоборот, пилил продукт 5 лет, с хорошей зарплатой, процессами, без переработок, а потом оказалось, что 3 года назад вышло бажное говно, и т.к. альтернатив не было, на него подсели, а переезжать на новый продукт дорого.
Как знакомо. Нормально сделать займет 2 месяца? Херня, делайте за 2 недели.
Так, почему сервис упал? Времени мало было? Просто вы хреново работали, исправляйте как хотите.
Читал не так давно статью от разработчика из Одноклассников, у него Cassandra плохо работала, пилили свой велосипед. Похожее мышление. Данных, конечно же, не было. И тут похожее.
За 17 лет в индустрии научился замечать подобные вещи, обычно это такой период, лет за 5 проходит.
Плохо то, что подобное поощряется и даже пролазит на конференции, и оттуда распространяется дальше. И на хабр тоже.
Переход на личности не нужен, когда можно говорить о данных и предпосылках. Предположения о моем опыте роли не играют, достаточно данные показать — свои, не чужие.
Спрашивать мои данные, когда не предоставили свои — ну странно как-то. Как вам помогут мои данные, когда вы сами не померяли и не запустили профайлер? А если запустили, тогда в чем проблема данные показать?
Например, первая же причина — "затрата ресурсов CPU на маршалинг и демаршалинг" — сколько у вас конкретно терялось на этом? Информации нет. Из моего опыта, это проценты (1-2) от общей картины, никак не 20-30.
Избыточность — ну допустим. Однако поменять структуры данных проще, чем пилить свой DataStax Enterprise.
Издержки на сеть — надо мерять, опять же. Из опыта, это тоже проценты, особенно если решить избыточность.
То есть эти 3 проблемы решаемы, и меньшими усилиями, чем велосипед из поста. Но, конечно, не так интересно.
Работаю я не DBA, нет, ближе к development manager / architect.
Натянули сову на глобус. Данных нет. Напоминает рассуждения — а давайте LinkedList вместо ArrayList.
Поддержка этого решения на порядки сложнее.
Cassandra постоянно меняется и меняет свои API, мы ее перестаем использовать именно из-за этого. Цена ошибки теперь не только потеря бизнес-логики, но и потеря данных.
Рад за бизнес, что достаточно здоров, чтобы оплачивать сомнительные эксперименты.
Отлично. Надеюсь, качество статей улучшится. После разделения потеряли кучу толковых авторов.