Сделать процесс наливки, переключение вланов, поддержка актуальных темплейтов вот это всё у же будет занимать человеко-месяц
Дмитрий Харитонов
кря
Это так, кроме того что железо все же всегда дешевле виртуалок
прямых затрат - да меньше, но время простоя, человеко лет на поддержку
Andrey
И плюс ответсвенность - сильно сломался амазон - все страдают и с пониманием относятся
кря
Дмитрий Харитонов
С экономической точки зрения девопса все равно берут на фул тайм, почему бы не потратить месяц на то, чтобы эконмить годы?
кря
Дмитрий Харитонов
прямых затрат - да меньше, но время простоя, человеко лет на поддержку
Так суть то этих вакансий в том что человека и так берут в штат.
Andrey
А вот история про железо у меня в хецнере было 60 стораджей так вот и дня не проходило чтоб не надо былр менять пару дисков
Andrey
Так суть то этих вакансий в том что человека и так берут в штат.
Думаете нет других вещей ? Которые нужнее ?
Andrey
А вот история про железо у меня в хецнере было 60 стораджей так вот и дня не проходило чтоб не надо былр менять пару дисков
А это несколько писем, они ещё там ошибаются иногда, с переездом в гугл сторадж о проблеме забыли
кря
Думаете нет других вещей ? Которые нужнее ?
а даже если нет, то можно просто уделить больше времени на саморазвитие
Andrey
Если нет - то уволят и всё, капитолизом
Дмитрий Харитонов
А вот история про железо у меня в хецнере было 60 стораджей так вот и дня не проходило чтоб не надо былр менять пару дисков
Ты же не сам их менял.
Я об эконмии, например тех же железок с хетзнера и виртуалок do или aws
Andrey
Ты же не сам их менял.
Я об эконмии, например тех же железок с хетзнера и виртуалок do или aws
Рукалицо. Мой сотрудник или я писал письмо, ждал ответа писал ещё письмо, проверял что рейд ребилдится и т.д.
Дмитрий Харитонов
Ясно что железо на колокейшине или в своём дц не особенно экономно.
кря
Если нет - то уволят и всё, капитолизом
не уволят, сегодня нет проблем или потребностей в расширений, уволили, завтра появились траблы, или необходимость проапдейтиться, или еще что, а человека нет
Дмитрий Харитонов
Рукалицо. Мой сотрудник или я писал письмо, ждал ответа писал ещё письмо, проверял что рейд ребилдится и т.д.
Ии? Что, это много времени отнимает?
Кстати, мне никогда не приходилось писать дважды.
Andrey
Наймут нового, это норм
Andrey
Ии? Что, это много времени отнимает?
Кстати, мне никогда не приходилось писать дважды.
Это то чем можно не заниматься
Andrey
Если каждый день нужно менеджить поломанные диски - это дичь
кря
Ии? Что, это много времени отнимает?
Кстати, мне никогда не приходилось писать дважды.
3 мая я обратился в саппорт aws, сегодня 8 мая, вопрос еще не решен, они вчера только подтвердили баг
Дмитрий Харитонов
Это то чем можно не заниматься
Лениво чтоли?) или не хочется заниматься мониторингом железа?
Andrey
Andrey
Я лучше в амазон
Дмитрий Харитонов
Просто я не вижу тут проблемы, а плюсы в том что можно оперативно самому пофиксить проблему.
Лично мне так удобнее чем перекладывать ответственность на кого-то далекого.
Andrey
Pavel
Если каждый день нужно менеджить поломанные диски - это дичь
А что значит менеджить диски? Менять каждый день?
Andrey
А что значит менеджить диски? Менять каждый день?
Да каждый день вылетает диск ( не один и тот же) просто их 1200
Дмитрий Харитонов
А что значит менеджить диски? Менять каждый день?
Когда много серваков и большим количеством дисков так бывает.
Pavel
Да каждый день вылетает диск ( не один и тот же) просто их 1200
Представьте, что у вас огромный BigData кластер который не переставая дерёт диски.
Например в неделю не менее трёх дисков из кластера "горят". В этом случае в цоде появляется чуть ли не выделенный человек =)
Andrey
Просто я не вижу тут проблемы, а плюсы в том что можно оперативно самому пофиксить проблему.
Лично мне так удобнее чем перекладывать ответственность на кого-то далекого.
Когда самому надо уметь пофиксит и mysql и оракл и ceph и bgp и одновременно выясняется что авс таки надёжней
кря
Когда много серваков и большим количеством дисков так бывает.
а еще может быть трабла когда свич в стойке перегревается и начинает глючить, это нужно писать на саппорт, ждать, проще ж у себя поставить все железо и самому разбираться с свичами.
Andrey
Представьте, что у вас огромный BigData кластер который не переставая дерёт диски.
Например в неделю не менее трёх дисков из кластера "горят". В этом случае в цоде появляется чуть ли не выделенный человек =)
Так и есть, но можно взять емр или гугловую технологию и с обжект стораджа всё монтировать
Дмитрий Харитонов
Ну у меня на хетзнере около сотни серваков. Не все они sx291 с 15 дисками в каждом. Но вылететь может раз в 3 месяца один диск. Хотя нагрузка там будь здоров на дисковую.
Pavel
Фантазировал на тему специального робота, который по зажиганию триггера в мониторинге меняет диск. Ну типа робота как в ленточной библиотеке
Andrey
Когда серверов более 10
Andrey
SeniorAnykey
Фантазировал на тему специального робота, который по зажиганию триггера в мониторинге меняет диск. Ну типа робота как в ленточной библиотеке
А чего фантазировать? Берем ардуину и БУ ленточку...
Дмитрий Харитонов
Когда самому надо уметь пофиксит и mysql и оракл и ceph и bgp и одновременно выясняется что авс таки надёжней
Но и дороже. Сперва кажется что затраты копейки. А когда инфраструктура разртстается и усложняется становится понятно что дешевле было бы делать самому и посадить пару человек на поддержку всего этого.
Andrey
Дмитрий Харитонов
Я же не говорю что aws это плохо. Я говорю что это дорого и не очень гибко.
кря
Но и дороже. Сперва кажется что затраты копейки. А когда инфраструктура разртстается и усложняется становится понятно что дешевле было бы делать самому и посадить пару человек на поддержку всего этого.
сколько будет стоять время простоя этого всего если где то что сломается?
Andrey
Построить микроклауд на своём делезе задача ой какая не простая
Дмитрий Харитонов
сколько будет стоять время простоя этого всего если где то что сломается?
Если делать отказоустойчиво, то ломаться будет не чаще чем амазон.
Дмитрий Харитонов
Построить микроклауд на своём делезе задача ой какая не простая
Не на своём, на арендованом
Andrey
Если делать отказоустойчиво, то ломаться будет не чаще чем амазон.
Да не сделать силами 3х-4х человек как амазон
кря
Если делать отказоустойчиво, то ломаться будет не чаще чем амазон.
и стоять сравнимо с амазоном, потому что любая отказоустойчивость это избыточность
кря
очень часто суть AWS и подобных, если что то сломалось мы просто возьмем и переподнимим, а потом будем разбираться
Andrey
Причем если правильно сделано по переподнять в эйжуре можно
Andrey
Или гугле
Дмитрий Харитонов
Ладно, я добрался до работы, всем спасибо да интересный флуд)
Oleg
если DevOps инженер сам не понимает в чём преимущества облаков, то вероятно он просто заблудившийся сисадмин
Dmitry
#job
Коллеги, привет! Есть потенциальная проектная (~1 год) вакансия docker/kubernetes специалиста. Оплата почасовая 1000р/час.
Работа удаленная, занятость частичная (+-80 часов в месяц)
Стучите в личку, спасибо за внимание!
Анатолий
если DevOps инженер сам не понимает в чём преимущества облаков, то вероятно он просто заблудившийся сисадмин
а в чем преимущества облаков?
Daniel
в отказоустойчивости
Анатолий
поверхностный ответ как по мне. всё должно зависить от обстоятельств проекта. где-то может быть более правильным решением отдельные сервера настраивать, а не облако городить.
Something
а в чем преимущества облаков?
как и везде, масштаб порождает сокращение издержек. В части облаков - это готовые сети (-сетевик), готовые оси (- админ), готовые acl (-безопасник). Понятно, что это утрированное суждение, но в общем смотрим на нетфликс и т.п.
Daniel
вы спросили - мы ответили.
Something
движение в облако тесно связано с контейнерами и далее. В общем все бы хотели, чтобы на момент подготовки отчетов для бизнеса, прод база резко набрала мощность, отжав ту от тестовой, а потом откатила ресурсы обратно. Вот контейнер + облако - это стремление к тому, чтобы все 100% ресурсов были утилизированы 24 на 7
Oleg
есть такой ресурс для истинных профессионалов - Wikipedia
Oleg
там много полезного можно найти, в отличие от уютных чятиков
Oleg
https://en.wikipedia.org/wiki/Cloud_computing#Characteristics
Grigorii
поверхностный ответ как по мне. всё должно зависить от обстоятельств проекта. где-то может быть более правильным решением отдельные сервера настраивать, а не облако городить.
+1. Особенно учитывая, что облако может быть частным
кря
поверхностный ответ как по мне. всё должно зависить от обстоятельств проекта. где-то может быть более правильным решением отдельные сервера настраивать, а не облако городить.
Самообслуживание по требованию (англ. self service on demand) — потребитель самостоятельно определяет и изменяет вычислительные потребности, такие как серверное время, скорости доступа и обработки данных, объём хранимых данных без взаимодействия с представителем поставщика услуг;
Универсальный доступ по сети — услуги доступны потребителям по сети передачи данных вне зависимости от используемого терминального устройства;
Объединение ресурсов (англ. resource pooling) — поставщик услуг объединяет ресурсы для обслуживания большого числа потребителей в единый пул для динамического перераспределения мощностей между потребителями в условиях постоянного изменения спроса на мощности; при этом потребители контролируют только основные параметры услуги (например, объём данных, скорость доступа), но фактическое распределение ресурсов, предоставляемых потребителю, осуществляет поставщик (в некоторых случаях потребители всё-таки могут управлять некоторыми физическими параметрами перераспределения, например, указывать желаемый центр обработки данных из соображений географической близости);
Эластичность — услуги могут быть предоставлены, расширены, сужены в любой момент времени, без дополнительных издержек на взаимодействие с поставщиком, как правило, в автоматическом режиме;
Учёт потребления — поставщик услуг автоматически исчисляет потреблённые ресурсы на определённом уровне абстракции (например, объём хранимых данных, пропускная способность, количество пользователей, количество транзакций), и на основе этих данных оценивает объём предоставленных потребителям услуг.
https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D0%BB%D0%B0%D1%87%D0%BD%D1%8B%D0%B5_%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F (с)
Анатолий
и что везде прям нужно встраивать облака, класть сервисы в контейнеры? есть же понятие избыточности
Logan
если DevOps инженер сам не понимает в чём преимущества облаков, то вероятно он просто заблудившийся сисадмин
если devops-инженер считает, что любая задача решается облаками всегда – он религиозный фанатик и говорить с ним не о чем
кря
и что везде прям нужно встраивать облака, класть сервисы в контейнеры? есть же понятие избыточности
есть проекты где и shared хостинга хватит
Something
я специально вставил коммент, что суждение утрировано..((
Something
кря
не надо прям совсем планку опускать =)))
хорошо назовите пример проекта для которого shared хостинга мало, а облако будет избыточным