За такую зарплату найдётся куча студентов, они и за 10 тысяч готовы работать, а ты тут выпендриваешься
Боль. Нормальные инженеры уходят (в DevOps'ы, например). А приходящие студенты пока ещё научатся... Как очередная партия придёт, так сразу хочется попреподавать немного в ВУЗе, чтобы они почувствовали практику. Потом вспоминаю, какой я плохой преподаватель и отпускает.
А какая-то сумма чаевых там стоит по умолчанию? И, наверное, отключение чаевых приложение не запоминает? Почему-то я думаю, что на оба вопроса ответ "да" (вспомним про капиталиста и 300%, хотя тут процент гораздо меньше). Если я неправ, то готов признать, что думал про Яндекс хуже, чем они есть. Просто ставить их приложение, чтобы это всё выяснить совершенно неохота...
К тому же докер легко скалировать - достаточно запустить несколько контейнеров
Скалировать? Хотел сперва придраться к термину, но он уж очень хорошо подходит для "запустить несколько контейнеров". Потому, что для масштабирования запуска нескольких контейнеров будет явно недостаточно. Тут надо или подпереть этот запуск каким-нибудь сторонним решением (внешним балансировщиком или балансировщиком в контейнере) или как-то сказать самому докеру, чтобы он нагрузку между контейнерами распределял, если он такое умеет.
Тут, кажется, формула N-мерного "синуса" в N-мерном пространстве. Где N сильно больше трёх. На бумаге вроде и ничего себе так. Но про визуализацию собственном воображении полной картины лучше забыть, а то вдруг получится...
Вот про инфраструктурщиков бы поподробнее. Железо, оно хоть в очень многом одинаковое (если рассматривать его работу как обработку пакетов/потоков команд) но и разница между СХД, коммутатором и гепервизором тоже преизрядная. Тут или Вы ищете пачку профильных специалистов или Вам нужен кто-то навроде меня, имеющий опыт работы понемногу со многими инфраструктурными компонентами. Что с одной стороны облегчает взаимодейтсвие с разработчиками и админами сервисов, а с другой - не даёт столь глубокого погружения, как у узкопрофильных специалистов.
2 - это ошибка перевода, похоже. Если удалили файл [на блочном устройстве], а [оперативная] память не освобождена, то я буду недоумевать. Должна была, что-ли?
Там просто ОЧЕНЬ много команд внутри, похоже. У двух похожих коммутаторов могут слегка отличаться CLI, например. Видно, что со временем они потихоньку сходятся к более или менее единому стандарту, но процесс идёт небыстро. По СХД разброс меньше. По крайней мере, веб-интерфейс и RESTful API на OceanStor/Dorado, которые мне встречались, везде одинаковый.
Так что то, что в одном из депертаментов у китайцев что-то плохо, не говорит о том, что плохо везде. Как, впрочем, и не гарантирует от обратного.
Я правильно понял, что у каждого коммутатора свой номер AS и на аплинках он использует eBGP? Это типовая практика в ЦОДах вообще или в ЦОДах Вашей организации?
В пределе - монтёр вообще перестанет действовать без подсказки. Ему ответственность зачем, когда можно её избежать? А когда монтёров много - это быстро задолбает энергетика.
По универсальности - да. По составу - сильно нет. Если посмотреть на разрешение от FDA, то основной компонент wd - дезодорированный уайт-спирит. А у баллистола - вазелиновое масло. Поэтому подсохший баллистол гораздо лучшая смазка, чем подсохшая WD-40.
Надо как-нибудь попробовать. Особенно с word-овскими файлами, которые, с некоторых пор zip-архив.
Я очень хорошо вижу, как блочная дедупликация может работать с загрузочными LUN'ами, например. Или образами виртуальных машин для VDI. Но вот с пользовательскими файлами. Наверное, мне пользователи подходящие не попадаются...
Я говорил о том, что дедупликация на блочном уровне на каждом конкретном узле поможет слабо. Просто прикиньте вероятность того, что одинаковые файлы двух клиентов случайно попадут на одну ноду. А синхронизировать хэши между десятком тысяч нод, ну не знаю. На самой ноде, скорее, полезно потоковое сжатие, но не слишком агрессивное.
А вот дедупликация на уровне распределённой ФС уже может работать очень хорошо. Но тут нетривиальности добавляет отказоустойчивость. И она уже не на блочном уровне получается.
P.S. перечитал источник. Возможно, я не прав и файлы одного пользователя/группы стремятся быть на одной ноде. Тогда именно блочная дедупликация становится чуть более уместной.
Думаю, что отсутствие у облака хранения непосредственно на блочном устройстве с дедупликацией. Ведь на блочном уровне хранит каждый из десятков тысяч узлов и попытка дедуплицировать на этом уровне должна породить ужасающий оверхэд при записи.
Ок. Про железо для разработчиков сказали. А на мой любимый вопрос - как быть при Scrum/Agile с железом для выполнения того, что накодили? Своё (долго закупается; если закупать с запасом - дорого), облака - за них кто-то в корпорации готов платить (и иметь шанс навсегда "прилипнуть" к сервисам условного Амазона)? Если будет вторая статья о том, что происходит на границах Scrum'а, то будет очень круто.
Ох уж эти Рид с Соломоном. Сделать заради кодов целую собственную целочисленную алгебру - это-ж надо было такое придумать.
P.S. когда-то давно замучился искать эти коды Ридеса-Ламона. Поисковики тогда искали ровно то, что спрашиваешь, не пытаясь понять, что именно надо найти.
Интересно, кто-нибудь фиксировал, насколько выросло энергопотребление лабораторий в результате? (Понятно, что предполагается 4 раза, но интересно, сколько вышло на самом деле)
Будучи школьниками получили с братом водород таким способом, пытаясь сделать батарейку. Понимание того, что нужны электроды из разных металлов и раствор было. Доступа к кислоте - нет. Зато к сельскохозяйственным удобрениям - был. Ну и идея "толкнуть" слабую батарейку коротким замыканием тоже была.
До сих пор помню тот восторг, который был, когда при изучении химии в школе, я смог воспроизвести формулу реакции (и уже точно узнать, что за газ мы получили), а учитель химии подтвердила, что ошибок в формуле нет.
Zabbix бесплатный и жутко расширяемый (в плане мониторинга всяческих нестандартных штук). Ну и масштабируемый.
Конечно, бесплатность во многом кажущаяся, так как нормальный администратор Zabbix, который может запустить и поддерживать мониторинг с миллионами элементов данных и десятками тысяч хостов (+вменяемые админы в подразделениях, которые не мониторят вообще всё, что хост может отдать) стоит вполне себе приличных денег.
И Zabbix-ом можно мониторить адскую помесь ужа и ежа, приправленную жабой, были бы люди, понимающие, какие данные важны, а какие - нет. А красивыми и умными решениями с искусственным интеллектом эффективно можно мониторить, ИМХО, достаточно типовые решения (а в случае давно живущей инфраструктуры надо либо приводить её к каноническому виду, либо мониторить только недавно сделанный по фэн-шую кусок; то и другое плохо, каждое по-своему). Или платить вендору за доработку. И будет ли этот вендор через 10 лет, когда парк железа и софта обновится и перестанет поддерживаться?
Боль. Нормальные инженеры уходят (в DevOps'ы, например). А приходящие студенты пока ещё научатся... Как очередная партия придёт, так сразу хочется попреподавать немного в ВУЗе, чтобы они почувствовали практику. Потом вспоминаю, какой я плохой преподаватель и отпускает.
А какая-то сумма чаевых там стоит по умолчанию? И, наверное, отключение чаевых приложение не запоминает?
Почему-то я думаю, что на оба вопроса ответ "да" (вспомним про капиталиста и 300%, хотя тут процент гораздо меньше). Если я неправ, то готов признать, что думал про Яндекс хуже, чем они есть. Просто ставить их приложение, чтобы это всё выяснить совершенно неохота...
Скалировать? Хотел сперва придраться к термину, но он уж очень хорошо подходит для "запустить несколько контейнеров".
Потому, что для масштабирования запуска нескольких контейнеров будет явно недостаточно. Тут надо или подпереть этот запуск каким-нибудь сторонним решением (внешним балансировщиком или балансировщиком в контейнере) или как-то сказать самому докеру, чтобы он нагрузку между контейнерами распределял, если он такое умеет.
Тут, кажется, формула N-мерного "синуса" в N-мерном пространстве. Где N сильно больше трёх. На бумаге вроде и ничего себе так. Но про визуализацию собственном воображении полной картины лучше забыть, а то вдруг получится...
Вот про инфраструктурщиков бы поподробнее. Железо, оно хоть в очень многом одинаковое (если рассматривать его работу как обработку пакетов/потоков команд) но и разница между СХД, коммутатором и гепервизором тоже преизрядная.
Тут или Вы ищете пачку профильных специалистов или Вам нужен кто-то навроде меня, имеющий опыт работы понемногу со многими инфраструктурными компонентами. Что с одной стороны облегчает взаимодейтсвие с разработчиками и админами сервисов, а с другой - не даёт столь глубокого погружения, как у узкопрофильных специалистов.
2 - это ошибка перевода, похоже. Если удалили файл [на блочном устройстве], а [оперативная] память не освобождена, то я буду недоумевать. Должна была, что-ли?
Там просто ОЧЕНЬ много команд внутри, похоже. У двух похожих коммутаторов могут слегка отличаться CLI, например. Видно, что со временем они потихоньку сходятся к более или менее единому стандарту, но процесс идёт небыстро.
По СХД разброс меньше. По крайней мере, веб-интерфейс и RESTful API на OceanStor/Dorado, которые мне встречались, везде одинаковый.
Так что то, что в одном из депертаментов у китайцев что-то плохо, не говорит о том, что плохо везде. Как, впрочем, и не гарантирует от обратного.
А может пусть становятся? А то найти позицию сисадмина уровня крепкого мидла с оплатой, как у мидла-программиста, весьма непросто.
Я правильно понял, что у каждого коммутатора свой номер AS и на аплинках он использует eBGP? Это типовая практика в ЦОДах вообще или в ЦОДах Вашей организации?
В пределе - монтёр вообще перестанет действовать без подсказки. Ему ответственность зачем, когда можно её избежать? А когда монтёров много - это быстро задолбает энергетика.
По универсальности - да. По составу - сильно нет. Если посмотреть на разрешение от FDA, то основной компонент wd - дезодорированный уайт-спирит. А у баллистола - вазелиновое масло. Поэтому подсохший баллистол гораздо лучшая смазка, чем подсохшая WD-40.
Неправильно понимал. Это факт. Что-то смешались у меня в голове блоки и блоки.
Надо как-нибудь попробовать. Особенно с word-овскими файлами, которые, с некоторых пор zip-архив.
Я очень хорошо вижу, как блочная дедупликация может работать с загрузочными LUN'ами, например. Или образами виртуальных машин для VDI. Но вот с пользовательскими файлами. Наверное, мне пользователи подходящие не попадаются...
Я говорил о том, что дедупликация на блочном уровне на каждом конкретном узле поможет слабо. Просто прикиньте вероятность того, что одинаковые файлы двух клиентов случайно попадут на одну ноду. А синхронизировать хэши между десятком тысяч нод, ну не знаю. На самой ноде, скорее, полезно потоковое сжатие, но не слишком агрессивное.
А вот дедупликация на уровне распределённой ФС уже может работать очень хорошо. Но тут нетривиальности добавляет отказоустойчивость. И она уже не на блочном уровне получается.
P.S. перечитал источник. Возможно, я не прав и файлы одного пользователя/группы стремятся быть на одной ноде. Тогда именно блочная дедупликация становится чуть более уместной.
Думаю, что отсутствие у облака хранения непосредственно на блочном устройстве с дедупликацией. Ведь на блочном уровне хранит каждый из десятков тысяч узлов и попытка дедуплицировать на этом уровне должна породить ужасающий оверхэд при записи.
Ок. Про железо для разработчиков сказали. А на мой любимый вопрос - как быть при Scrum/Agile с железом для выполнения того, что накодили? Своё (долго закупается; если закупать с запасом - дорого), облака - за них кто-то в корпорации готов платить (и иметь шанс навсегда "прилипнуть" к сервисам условного Амазона)?
Если будет вторая статья о том, что происходит на границах Scrum'а, то будет очень круто.
Ох уж эти Рид с Соломоном. Сделать заради кодов целую собственную целочисленную алгебру - это-ж надо было такое придумать.
P.S. когда-то давно замучился искать эти коды Ридеса-Ламона. Поисковики тогда искали ровно то, что спрашиваешь, не пытаясь понять, что именно надо найти.
Интересно, кто-нибудь фиксировал, насколько выросло энергопотребление лабораторий в результате? (Понятно, что предполагается 4 раза, но интересно, сколько вышло на самом деле)
Будучи школьниками получили с братом водород таким способом, пытаясь сделать батарейку. Понимание того, что нужны электроды из разных металлов и раствор было. Доступа к кислоте - нет. Зато к сельскохозяйственным удобрениям - был. Ну и идея "толкнуть" слабую батарейку коротким замыканием тоже была.
До сих пор помню тот восторг, который был, когда при изучении химии в школе, я смог воспроизвести формулу реакции (и уже точно узнать, что за газ мы получили), а учитель химии подтвердила, что ошибок в формуле нет.
Zabbix бесплатный и жутко расширяемый (в плане мониторинга всяческих нестандартных штук). Ну и масштабируемый.
Конечно, бесплатность во многом кажущаяся, так как нормальный администратор Zabbix, который может запустить и поддерживать мониторинг с миллионами элементов данных и десятками тысяч хостов (+вменяемые админы в подразделениях, которые не мониторят вообще всё, что хост может отдать) стоит вполне себе приличных денег.
И Zabbix-ом можно мониторить адскую помесь ужа и ежа, приправленную жабой, были бы люди, понимающие, какие данные важны, а какие - нет. А красивыми и умными решениями с искусственным интеллектом эффективно можно мониторить, ИМХО, достаточно типовые решения (а в случае давно живущей инфраструктуры надо либо приводить её к каноническому виду, либо мониторить только недавно сделанный по фэн-шую кусок; то и другое плохо, каждое по-своему). Или платить вендору за доработку. И будет ли этот вендор через 10 лет, когда парк железа и софта обновится и перестанет поддерживаться?