Pull to refresh
81
0
Vladimir Chernyshev @VolCh

Software Engineer, Technical Lead

Send message

Собственная инфраструктура — это собственный дата-центр? а лучше несколько, если один сгорит (


Ну и полный cloud native и собственные ДЦ — это крайности и всегда есть промежуточные варианты типа аренды (V)DS и построения инфраструктуры на них

Тесты всякие сначала, потом разговоры и упражнения на расслабление

Я не говорил что у меня :) Но вообще было тогда что-то непонятное:
один чарт на всю систему в папке charts которого лежат чарты по сервисам. Не архивы, а полностью, отдельно как зависимости не устанавливались, собственно dependencies вроде и не было в Chart.yaml. Всё это в одном репозитории, использовался как таковой только корневой

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

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


Клиенты платят нам за использование штуки, которую мы сделали. Вы вот пользуетесь Хабром, но не указываете им как его делать? Голосуете своим присутствием и активностью за те или иные фичи. Примерно так и у нас, только голосуют деньгами.

Вам же привели примеры, когда количество дней в месяце официально не было 28-31.


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

практика показывает — что пока петух не клюнет, не особо то и находятся

Не согласуется с


и в облаках все для этого есть, и даже больше

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


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

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


какие часы, вы о чем вообще?! На terraform + ansible это все поднимается и настраивается за 15-20 минут

Я не один раз говорил, что процессы сначала надо выставить, а потом об облаках думать. Особенно в расчёте на задачи типа "надо сотни серверов на пару часов", а не "перевести 10 серверов в облако за минимальное время"

Как отделить шарлатанов от специалистов? Мне вот так "помогали" с выгоранием бороться, пока не решил к неврологу сходить по другому вопросу, а он на МРТ направил…

Если всё равно, то это уже выгорание, наверное, а от jquery и ES5 вполне может тошнить

Там же "после отпуска", а не "не вернулся из отпуска"

А причём тут количество дней в месяце? )


Но программист может не знать, что на системе не реальное время. Более того, основное заблуждение программиста, имхо, при работе со временем это то, что он (его программа) может его получить

Вы то ли не читаете мои ответы или читаете по диогонали, то ли не понимаете смысла написанного ))

У вас мысли скачут, так что логической связи не видно )


тут же находятся методы и способы оптимизации ;)

Да они почти всегда на виду. Что там искать особо?


откуда данные? есть статистика?

Слово "субъективно" заметили или по диагонали читаете? )


инфраструктура это всегда про расходы

Некоторые перед тем как нести эти расходы прикидывают сроки их окупаемости.


За счет использование тех же снепшотов/autoscaling group/availability zones/load balancer и т.д. и т.п.

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


У нас был например кейс — для POC нужна была сотня виртуалок

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

Главное в борьбе с выгоранием не упустить что-то более серьезное с близкими симптомами

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

Узнать за это время человека, как он себя будет вести в той или иной ситуации… невозможно

Имхо, лучше так чем никак


Но, то что вы развели клиента на подобную хрень конечно здорово )

Я стараюсь не работать в местах, где заказчики разрабатываемого софта — это клиенты, а не коллеги.

В итоге они вложились (переписали код с 5ку на 7ку) и получили профит.

Я переписывал несколько проектов, но к экономии это не приводило явной. Отложило покупку новых серверов наверное, но это не точно. И причём тут облака?


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


а у нас 100ни. А в тестах — тысячи. И что теперь

Не думаю, что у вас обычный проект. Только и всего. Молчу уж про Баду. Субъективно у подавляющего большинства компаний затраты на сервера меньше 1000 долларов. Даже если переезд в облака позволит снизить их раза в два, издержки на переезд окупятся ой как нескоро, если вообще окупятся.


либо вы что то делаете не так, либо облака не эффективны для вашей инфраструктуры. Все просто

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

Не первое? Только когда счета и/или скорость работы неприятно удивят? )

А при должной оптимизации вы могли бы взять 8ми ядерный, и получить экономию

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


Если у вас 1-10 серверов, то скорее всего особого смысла не будет.

Вот это вот гораздо ближе к реальной жизни чем всё, что вы писали ранее


но при этом у вас простой в год условно уменьшился на 100 часов.

А если на 2? С 3 до 1

Поправка: не днём рождения, а датой наступления полного количества скольких-то лет в юридических целях типа возможности избирать или быть избранным

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

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity