Forwarded from WeLoveNoFraud
Пользователи из России начали сообщать об удалении рабочих пространств в Slack — это затронуло команды «Сбера». Официально компания, принадлежащая SalesForce, не сообщала об ограничении работы в России.
С 12 марта в App Store и Play Store появилось около 60 отзывов об удалении рабочих пространств в Slack. Пользователи пишут, что аккаунты удалили без предупреждения и возможности сохранить данные. Другие — что получили предупреждение уже после блокировки. Многие сообщают, что у них была оплачена платная версия на год вперёд. В некоторых отзывах указано, что в пространствах работали 1500-2000 человек. https://vc.ru/services/379922-polzovateli-iz-rossii-nachali-soobshchat-ob-udalenii-rabochih-prostranstv-v-slack-eto-zatronulo-komandy-sbera
@welovenofraud
С 12 марта в App Store и Play Store появилось около 60 отзывов об удалении рабочих пространств в Slack. Пользователи пишут, что аккаунты удалили без предупреждения и возможности сохранить данные. Другие — что получили предупреждение уже после блокировки. Многие сообщают, что у них была оплачена платная версия на год вперёд. В некоторых отзывах указано, что в пространствах работали 1500-2000 человек. https://vc.ru/services/379922-polzovateli-iz-rossii-nachali-soobshchat-ob-udalenii-rabochih-prostranstv-v-slack-eto-zatronulo-komandy-sbera
@welovenofraud
vc.ru
Пользователи из России начали сообщать об удалении рабочих пространств в Slack — это затронуло команды «Сбера» — Сервисы на vc.ru
Официально компания не сообщала об ограничении работы в России.
Комитеты и согласующие.
— ... Они не придут ни к какому решению. Мэри, комитет — это единственная известная форма жизни с сотней желудков и без малейшего намека на мозг. В конце концов кто-нибудь, у кого есть своя голова на плечах, заставит их принять его план. Правда, вот не могу сказать, каким он будет. (Хайнлайн)
Согласно принципу Питера, человек, работающий в любой иерархической системе, повышается в должности до тех пор, пока не займёт место, на котором он окажется не в состоянии справиться со своими обязанностями, то есть окажется некомпетентным.
В этом причина повсеместного засилья комитетов и рабочих групп по согласованию меморандумов о намерениях. Размазывание ответственности по коллективу с уходом от личной при профнепригодности и ннекомпетентности.
После увольнения Стива Джобса комитет из эффективных директоров привел компанию Apple к эпическому «успеху». Настолько, что в 1998 Джобс вытаскивал ее практически из пучин банкротства. И вытащил, руководствуясь рядом принципов, из которых особенно хотелось бы отметить два главных:
1. Никаких комитетов. У каждого проекта, у каждой функции личная персональная ответственность.
2. Инженер должен думать о том, как сделать лучший продукт, а не как сэкономить. Об экономии должны думать другие люди.
Посмотрите вокруг себя – оцените, сколько рядом размазанной коллективной ответственности, а точнее коллективной безответственности. Когда в последний раз кто-то лично отвечал за допущенную халатность и наплевательское отношение к работе?
Ключевой момент здесь не строгость наказания, а сам его факт. Наказание должно быть неизбежным. Это нам успешно доказывают камеры и эвакуаторы. Не нужно лишений прав, не нужно драконовских штрафов – сделайте это в умеренной степени неприятным, но неотвратимым.
Второй пункт на самом деле вообще следствие первого. Просто в силу неполноты взгляда на проект инженер (чисто технический специалист) не может осознать связи между экономией на спичках и провалом всего проекта. Как только инженер начинает это понимать, то сразу становится руководителем проекта или ведущим архитектором.
Почему провалены проекты по импортозамещению? Финансово заинтересованные непрофессионалы без ответственности руководят стратегическими техническими проектами.
Все это усиливается многочисленными комитетами с представительской целью – когда некомпетентными имитируется деятельность в стиле «работать не буду, но могу проконтролировать».
“А нынче? Новое начальство, стремясь, на всякий случай, размыть ответственность за то, что послали тебя, а не другого, начало гонять кандидатов в САЭ по всем мыслимым комиссиям и инстанциям. Во-первых, даже нас, командиров кораблей, допущенных к полетам по минимуму «один-один», заставили в течение дней семнадцати-двадцати проходить стационарное медицинское обследование. Потом меня ждали заседания парткома, райкома, совета Управления ГА Центральных районов (УГАЦ), где чаще всего малознакомые или вовсе незнакомые люди, на основании каких-то трех-пяти вопросов, решали, отправлять ли мои документы в МГА на оформление визы для выезда за границу и в Антарктиду или «зарубить» их. Большинство из них «не нюхали» не то что Антарктики, но и Арктики и, тем не менее, брались судить, кого можно, а кого нельзя выпускать за пределы СССР на работу, где требовалась высочайшая слетанность экипажа, где люди должны доверять товарищу, порой, не только судьбу дела, но и свою жизнь. Прибавьте к этому заполнение многочисленных анкет, написание автобиографии, причем, никаких помарок и ошибок не допускалось, иначе приходилось переписывать все заново — и перед вами возникнет блестяще отрежиссированная бюрократическая волокита, протяженностью в два-три месяца. Как жаль этого времени, потраченного не на подготовку к полетам в Антарктиде или на отдых, а на пустопорожнее путешествие по кабинетам”
Из книги «С Антарктидой только на Вы» - автобиографии руководителя летного отряда антарктической экспедиции.
Комитеты хороши для ухода от ответственности, а не для результата.
— ... Они не придут ни к какому решению. Мэри, комитет — это единственная известная форма жизни с сотней желудков и без малейшего намека на мозг. В конце концов кто-нибудь, у кого есть своя голова на плечах, заставит их принять его план. Правда, вот не могу сказать, каким он будет. (Хайнлайн)
Согласно принципу Питера, человек, работающий в любой иерархической системе, повышается в должности до тех пор, пока не займёт место, на котором он окажется не в состоянии справиться со своими обязанностями, то есть окажется некомпетентным.
В этом причина повсеместного засилья комитетов и рабочих групп по согласованию меморандумов о намерениях. Размазывание ответственности по коллективу с уходом от личной при профнепригодности и ннекомпетентности.
После увольнения Стива Джобса комитет из эффективных директоров привел компанию Apple к эпическому «успеху». Настолько, что в 1998 Джобс вытаскивал ее практически из пучин банкротства. И вытащил, руководствуясь рядом принципов, из которых особенно хотелось бы отметить два главных:
1. Никаких комитетов. У каждого проекта, у каждой функции личная персональная ответственность.
2. Инженер должен думать о том, как сделать лучший продукт, а не как сэкономить. Об экономии должны думать другие люди.
Посмотрите вокруг себя – оцените, сколько рядом размазанной коллективной ответственности, а точнее коллективной безответственности. Когда в последний раз кто-то лично отвечал за допущенную халатность и наплевательское отношение к работе?
Ключевой момент здесь не строгость наказания, а сам его факт. Наказание должно быть неизбежным. Это нам успешно доказывают камеры и эвакуаторы. Не нужно лишений прав, не нужно драконовских штрафов – сделайте это в умеренной степени неприятным, но неотвратимым.
Второй пункт на самом деле вообще следствие первого. Просто в силу неполноты взгляда на проект инженер (чисто технический специалист) не может осознать связи между экономией на спичках и провалом всего проекта. Как только инженер начинает это понимать, то сразу становится руководителем проекта или ведущим архитектором.
Почему провалены проекты по импортозамещению? Финансово заинтересованные непрофессионалы без ответственности руководят стратегическими техническими проектами.
Все это усиливается многочисленными комитетами с представительской целью – когда некомпетентными имитируется деятельность в стиле «работать не буду, но могу проконтролировать».
“А нынче? Новое начальство, стремясь, на всякий случай, размыть ответственность за то, что послали тебя, а не другого, начало гонять кандидатов в САЭ по всем мыслимым комиссиям и инстанциям. Во-первых, даже нас, командиров кораблей, допущенных к полетам по минимуму «один-один», заставили в течение дней семнадцати-двадцати проходить стационарное медицинское обследование. Потом меня ждали заседания парткома, райкома, совета Управления ГА Центральных районов (УГАЦ), где чаще всего малознакомые или вовсе незнакомые люди, на основании каких-то трех-пяти вопросов, решали, отправлять ли мои документы в МГА на оформление визы для выезда за границу и в Антарктиду или «зарубить» их. Большинство из них «не нюхали» не то что Антарктики, но и Арктики и, тем не менее, брались судить, кого можно, а кого нельзя выпускать за пределы СССР на работу, где требовалась высочайшая слетанность экипажа, где люди должны доверять товарищу, порой, не только судьбу дела, но и свою жизнь. Прибавьте к этому заполнение многочисленных анкет, написание автобиографии, причем, никаких помарок и ошибок не допускалось, иначе приходилось переписывать все заново — и перед вами возникнет блестяще отрежиссированная бюрократическая волокита, протяженностью в два-три месяца. Как жаль этого времени, потраченного не на подготовку к полетам в Антарктиде или на отдых, а на пустопорожнее путешествие по кабинетам”
Из книги «С Антарктидой только на Вы» - автобиографии руководителя летного отряда антарктической экспедиции.
Комитеты хороши для ухода от ответственности, а не для результата.
Решил возобновить старый проект "Ах ты ж Ёб...лако!"
История былинных отказов хмарных вычислений на русском.
Аналитика и размышления останутся на BeerPanda, а там просто будет хронология и ссылки на первоисточники. Подписывайтесь!
PS. ищутся соавторы - кому не лень следить за новостями и копаться в облаках.
https://news.1rj.ru/str/yoblako_ru
История былинных отказов хмарных вычислений на русском.
Аналитика и размышления останутся на BeerPanda, а там просто будет хронология и ссылки на первоисточники. Подписывайтесь!
PS. ищутся соавторы - кому не лень следить за новостями и копаться в облаках.
https://news.1rj.ru/str/yoblako_ru
Telegram
Ах ты ж Ёб...лако!
История былинных отказов хмарных вычислений.
Относительно недавно делал аналитику по рискам OpenSource (задолго до 24 февраля). Разумеется по классике столкнулся с апологетами, что OpenSource никто никогда, это чистые светлые лица без политики.
Два моих главных тезиса, что вызвали особенный резонанс при обсуждениях потенциальных рисков, с учетом нарастания санкций:
1. Риск перекрытия доступа к чистому opensource а-ля дебиан пренебрежительно мало, но есть высокий риск, что закроют возможность коммита от российских разработчиков.
2. Пойдут патчи со встраиванием деструктивного контента и бэкдоров.
И что вы таки думаете? В первые же недели сработали оба пункта.
- oVirt закрыли для российских разработчиков
- NSA уличили в бэкдоре
- Начались массовые встраивания деструктивного кода, нацеленного на Россию
Продолжаются массовые блокировки в облаках (я об этом говорил 10 лет) по политическому признаку.
Сосед, всерьез занимающийся поддержкой умных домов (когда начинка умного дома от 15k USD) рассказывает - умные дома с облачной головой начали массово отрубаться. Вырубают просто голову в облаке, а ты дальше со всеми датчиками и релюшками в доме живи как хочешь.
ИТ выросли из детского сада (вирусы ради вирусов, красоты кода) и вступили в младший школьный возраст (вирусы ради воровства денег), а теперь и подростковый - когда бурлит гормон и происходит деление на черных и белых.
Нас будут использовать в политических целях, ИТ станет очень ярко поделенным на политические лагеря. Очень хочется надеяться, что полноценных масштабных кибервойн все же сможем избежать - слишком много завязано в реальном мире на виртуальных. Надеяться на взросление ИТ и переход к вынужденному net neutrality при сохранении политического уклада невозможно, будем ждать единой Земной Федерации.
Облака? Облака будут схлопываться. Почувствовав вкус манипуляций над политическим противником уровня "великий враг и кровавый режим" власть имеющие с каждым разом станут понижать планку - и вот уже просто несогласные и коммерческие конкуренты попали.
Что я вижу в качестве технологического будущего - уход от интернета вещей назад, к механике и принципиальной невозможности удаленного контроля и манипуляций. Наступает эпоха эдакого стимпанка, только без пара - будет электромеханика в изолированных контурах.
Два моих главных тезиса, что вызвали особенный резонанс при обсуждениях потенциальных рисков, с учетом нарастания санкций:
1. Риск перекрытия доступа к чистому opensource а-ля дебиан пренебрежительно мало, но есть высокий риск, что закроют возможность коммита от российских разработчиков.
2. Пойдут патчи со встраиванием деструктивного контента и бэкдоров.
И что вы таки думаете? В первые же недели сработали оба пункта.
- oVirt закрыли для российских разработчиков
- NSA уличили в бэкдоре
- Начались массовые встраивания деструктивного кода, нацеленного на Россию
Продолжаются массовые блокировки в облаках (я об этом говорил 10 лет) по политическому признаку.
Сосед, всерьез занимающийся поддержкой умных домов (когда начинка умного дома от 15k USD) рассказывает - умные дома с облачной головой начали массово отрубаться. Вырубают просто голову в облаке, а ты дальше со всеми датчиками и релюшками в доме живи как хочешь.
ИТ выросли из детского сада (вирусы ради вирусов, красоты кода) и вступили в младший школьный возраст (вирусы ради воровства денег), а теперь и подростковый - когда бурлит гормон и происходит деление на черных и белых.
Нас будут использовать в политических целях, ИТ станет очень ярко поделенным на политические лагеря. Очень хочется надеяться, что полноценных масштабных кибервойн все же сможем избежать - слишком много завязано в реальном мире на виртуальных. Надеяться на взросление ИТ и переход к вынужденному net neutrality при сохранении политического уклада невозможно, будем ждать единой Земной Федерации.
Облака? Облака будут схлопываться. Почувствовав вкус манипуляций над политическим противником уровня "великий враг и кровавый режим" власть имеющие с каждым разом станут понижать планку - и вот уже просто несогласные и коммерческие конкуренты попали.
Что я вижу в качестве технологического будущего - уход от интернета вещей назад, к механике и принципиальной невозможности удаленного контроля и манипуляций. Наступает эпоха эдакого стимпанка, только без пара - будет электромеханика в изолированных контурах.
"Разработчик «node-ipc (https://news.1rj.ru/str/svtvnews/4472)» столкнулся с жёсткой реакцией в ответ на внедрение вредоносных функций в свой код. Его твиттер был взломан (https://web.archive.org/web/20220319002246/https://twitter.com/electricCowboyR), а к нему в дом ворвались люди и избили горе-хакера (https://www.itpro.co.uk/development/open-source/367129/open-source-dev-attacked-for-spreading-data-wiping-protestware). Уязвимые версии пакета были удалены 8 марта. По данным GitHub, под угрозой оказалось более 750 тысяч человек."
Почему же так удивлен разработчик реакцией? Так до этого ж можно было!
Вспомним "патч Бармина". Для тех, кто не в курсе - это деструктивный код, который под видом помощи от сообщества вбрасывается человеку, помощь запросившему. В оригинале зашифрованный код, содержащий тотальное удаление данных "rm -rf /", был вброшен как вопрос "почему у меня не работает?"
И достаточно небольшая часть ИТ-специалистов (за исключением пострадавших, разумеется) осуждала "шутников". Азаза, лалки, сами виноваты! Вот же лошара, попался, лол кек.
Сомневаетесь? Достаточно почитать комментарии к моей статье на хабре: https://habr.com/ru/post/506332/
А тут массово накрыло, и бездумное применение со сборкой кода прямо из облачных хранилищ с самыми актуальными версиями (bleeding edge tech) подпалило зады все тем же угоравшим.
Почему же так удивлен разработчик реакцией? Так до этого ж можно было!
Вспомним "патч Бармина". Для тех, кто не в курсе - это деструктивный код, который под видом помощи от сообщества вбрасывается человеку, помощь запросившему. В оригинале зашифрованный код, содержащий тотальное удаление данных "rm -rf /", был вброшен как вопрос "почему у меня не работает?"
И достаточно небольшая часть ИТ-специалистов (за исключением пострадавших, разумеется) осуждала "шутников". Азаза, лалки, сами виноваты! Вот же лошара, попался, лол кек.
Сомневаетесь? Достаточно почитать комментарии к моей статье на хабре: https://habr.com/ru/post/506332/
А тут массово накрыло, и бездумное применение со сборкой кода прямо из облачных хранилищ с самыми актуальными версиями (bleeding edge tech) подпалило зады все тем же угоравшим.
Cancel Culture
Основа человеческой природы – это природа животная. Инстинктивные побуждения, гормоны, химия – иными словами нейрофизиология. То, что зашито в ДНК. Сюда же относятся все игры с доминированием, альфа-бета-омега статусы.
Поверх этого у нас есть то, что называется культурой. Все то, что не зашито в ДНК, а преподается обществом как свод правил и привычек.
Вежливость и этикет – это способ избежать ненужных конфликтов с доминированием и плясок вокруг альфы-беты-омеги. Свод правил как строить фразу, какие использовать слова, кто кому в каком порядке подает руку. И обратная сторона этикета – это его целенаправленное нарушение для демонстрации силы / статуса. Именно сюда и относится понятие “оскорбления”. Оскорбление – это целенаправленное действие, подчеркивающее отношение как низшему по отношению к автору действия существу, по статусу / положению, или вовсе лишающее цель человеческих черт и низводящее до животного.
Однако поскольку в оскорбление, в отличие от чисто физического животного доминирования, можно играть вдвоем на равных, возникает интересный феномен. Человека нельзя оскорбить словами, если он сам не хочет оскорбиться.
Давайте разберем теорию. А демонстрирует Б свое пренебрежительное отношение и превосходящую позицию в живописных жестах и словах. Должен ли Б быть оскорбленным? Зависит от множества факторов, в том числе от взаимоотношений и статусов А и Б. Если статус и позиция А изначально выше и это признано обеими сторонами, то это не оскорбление, а просто констатация факта. Т.е. оскорбление имеет смысл только в ситуации А <= Б. Должен ли Б считать себя оскорбленным и принимать какие-либо ответные действия? Простейший пример – человека облаивает из-за забора облезлая шавка. Будет ли человек предпринимать какие-то действия и требовать с шавки сатисфакции? Бомж начал оскорблять меня, моих родителей и всех моих родственников до 7го колена потому что я не дал ему 10 руб на выпивку. Должен ли я сделать хоть что-то в ответ? Сомневаюсь. Иными словами, оскорбление мало выдать, его еще необходимо принять.
И здесь мы видим первый звоночек нового поколения. Люди находятся в состоянии постоянной готовности принять оскорбление и активно ищут, где бы сейчас оскорбиться.
Очень интересный феномен, связанный с оскорблениями, заключается в том, что самое эффективное и жестко бьющее оскорбление – это срыв масок. Б надевает маску и притворяется, что он не Б, а В. Ничто не достигнет цели эффективнее, чем прямо и красочно описать, что обман виден и на самом деле это всего лишь Б. На практическом примере: действительно верующие не очень-то обращают внимание на сомнение в их вере и исполнении канонов. Но человек претендующий на звание верующего – он другое дело, ищет оскорблений и готов оскорбиться моментально.
Индустриальное общество было построено на результат. Даешь результат – молодец. Но ты ценен не более, чем результат твоей деятельности. В связи с этим есть процедура оценки результата / обратная связь по результату и установление статуса. Процедура оценки результата называется критикой, и она делится на есть конструктивную / неконструктивную – помогает исправить результат / не помогает. Высшая форма неконструктивной критики сливается с процедурой установления статуса. Практический пример установления статуса по результату – специалист 3/4/5 разряда и соответствующая тарифной сетке зарплата.
Что же мы наблюдаем в новейшем постиндустриальном обществе поколения ВКонтакте? Культ “онжеребенок” воспитывает в стиле “ты БОГ”. И все что ты выдал – БОЖЕСТВЕННО. Это просто преподаватель зажимает и не понимает божественности моей диточки. Диточку старательно оберегают от любой критики. А затем происходит самостоятельное общение в соцсетях. Итог: мне не нравятся твои слова – БАН! Ты меня критикуешь – БАН! Таким образом оберегается мирок своей божественности путем удаления из него любого дискомфорта и критики, в том числе конструктивной. Любая критика или даже не поглаживание болезненного ЧСВ этой персоны воспринимается как персональное оскорбление. Смотрим выше о готовности оскорбиться.
Основа человеческой природы – это природа животная. Инстинктивные побуждения, гормоны, химия – иными словами нейрофизиология. То, что зашито в ДНК. Сюда же относятся все игры с доминированием, альфа-бета-омега статусы.
Поверх этого у нас есть то, что называется культурой. Все то, что не зашито в ДНК, а преподается обществом как свод правил и привычек.
Вежливость и этикет – это способ избежать ненужных конфликтов с доминированием и плясок вокруг альфы-беты-омеги. Свод правил как строить фразу, какие использовать слова, кто кому в каком порядке подает руку. И обратная сторона этикета – это его целенаправленное нарушение для демонстрации силы / статуса. Именно сюда и относится понятие “оскорбления”. Оскорбление – это целенаправленное действие, подчеркивающее отношение как низшему по отношению к автору действия существу, по статусу / положению, или вовсе лишающее цель человеческих черт и низводящее до животного.
Однако поскольку в оскорбление, в отличие от чисто физического животного доминирования, можно играть вдвоем на равных, возникает интересный феномен. Человека нельзя оскорбить словами, если он сам не хочет оскорбиться.
Давайте разберем теорию. А демонстрирует Б свое пренебрежительное отношение и превосходящую позицию в живописных жестах и словах. Должен ли Б быть оскорбленным? Зависит от множества факторов, в том числе от взаимоотношений и статусов А и Б. Если статус и позиция А изначально выше и это признано обеими сторонами, то это не оскорбление, а просто констатация факта. Т.е. оскорбление имеет смысл только в ситуации А <= Б. Должен ли Б считать себя оскорбленным и принимать какие-либо ответные действия? Простейший пример – человека облаивает из-за забора облезлая шавка. Будет ли человек предпринимать какие-то действия и требовать с шавки сатисфакции? Бомж начал оскорблять меня, моих родителей и всех моих родственников до 7го колена потому что я не дал ему 10 руб на выпивку. Должен ли я сделать хоть что-то в ответ? Сомневаюсь. Иными словами, оскорбление мало выдать, его еще необходимо принять.
И здесь мы видим первый звоночек нового поколения. Люди находятся в состоянии постоянной готовности принять оскорбление и активно ищут, где бы сейчас оскорбиться.
Очень интересный феномен, связанный с оскорблениями, заключается в том, что самое эффективное и жестко бьющее оскорбление – это срыв масок. Б надевает маску и притворяется, что он не Б, а В. Ничто не достигнет цели эффективнее, чем прямо и красочно описать, что обман виден и на самом деле это всего лишь Б. На практическом примере: действительно верующие не очень-то обращают внимание на сомнение в их вере и исполнении канонов. Но человек претендующий на звание верующего – он другое дело, ищет оскорблений и готов оскорбиться моментально.
Индустриальное общество было построено на результат. Даешь результат – молодец. Но ты ценен не более, чем результат твоей деятельности. В связи с этим есть процедура оценки результата / обратная связь по результату и установление статуса. Процедура оценки результата называется критикой, и она делится на есть конструктивную / неконструктивную – помогает исправить результат / не помогает. Высшая форма неконструктивной критики сливается с процедурой установления статуса. Практический пример установления статуса по результату – специалист 3/4/5 разряда и соответствующая тарифной сетке зарплата.
Что же мы наблюдаем в новейшем постиндустриальном обществе поколения ВКонтакте? Культ “онжеребенок” воспитывает в стиле “ты БОГ”. И все что ты выдал – БОЖЕСТВЕННО. Это просто преподаватель зажимает и не понимает божественности моей диточки. Диточку старательно оберегают от любой критики. А затем происходит самостоятельное общение в соцсетях. Итог: мне не нравятся твои слова – БАН! Ты меня критикуешь – БАН! Таким образом оберегается мирок своей божественности путем удаления из него любого дискомфорта и критики, в том числе конструктивной. Любая критика или даже не поглаживание болезненного ЧСВ этой персоны воспринимается как персональное оскорбление. Смотрим выше о готовности оскорбиться.
Audio
Как никогда верно. Хоть и нецензурно
Тестирование сервера.
Стоит заговорить о тестировании сервера и абсолютному большинству далеких от инфраструктуры людей представляются гигафлопсы, иногда транзакции в секунду или даже кадры в секунду. А вот нет, это вообще не про сервер в общем случае.
Итак, что такое сервер. Сервер - вычислительный комплекс, предназначенный для автономной работы без прямого взаимодействия с пользователем (и в этом отличие от десктопа).
В более узком смысле и 95-97% случаев это подразумевает стоечное (rack) исполнение для установки в 19" шкафах.
Давайте разберемся, а что же может быть важно именно для сервера:
1. Качество исполнения корпуса и физические габариты - поместится ли сервер в стойку определенного размера (да-да, мои маленькие айтишники, стойки бывают разной глубины, например).
2. Наличие комплекта быстрого монтажа (быстросъемные рельсы на защелках). Если в компании не 2-3 сервера, а 2-3 или тем более 20-30 тысяч серверов, то этот казалось бы смешной пункт становится довольно таки важным.
3. Поддержка двух блоков питания с горячей заменой и резервировением 1+1. В отличие от десктопов это важно - на стойку в правильных ЦОДах подаются две независимые линии питания и БП подключаются к ним. В итоге страхуются и риск сгоревшего БП (а с горячей заменой даже сервер выключать не надо) и проблема отсутствия питания по одной линии при работах по электрике в ЦОДе.
4. Поддержка полного удаленного управления (iLO, iDRAC, BMC etc). Вспоминаем про тысячи серверов - у вас просто нет физической возможности нанять достаточное количество админов для хотя бы раскатки ОС в нужных количествах. Не говоря уже об обслуживании и мониторинге "а что это у нас там сгорело", если ОС не загружается.
5. Полная световая индикация компонентов. Начиная от сетевых карт и заканчивая компонентами с горячей заменой. Очень важен специальный включаемый режим подсветки (синим) для самого сервера и его компонентов с горячей заменой.
Приходит монтажник с диском на замену - а вокруг ряды стоек с одинаковыми серверами. Заранее включенная подсветка упрощает работу и сильно снижает вероятность ошибки при замене.
Смотрите, вот уже 5 важных пунктов, а мы сервер то еще даже не включали. На самом деле есть еще куча параметров, которым сервер должен соответствовать, в зависимости от важности / специфики конкретного окружения и организации.
И только в самом конце, после прохождения всех функциональных требований, кажущихся смешными человеку, никогда не работавшему с чем-то кроме макбука и "облака", мы наконец перейдем к нагрузочному тестированию, гигафлопсам и всяким SPEC CPU.
Но и это еще не все.
41. Доступность ЗИПа и апгрейдов. Для вендоров класса А характерны запреты на использование сторонних запчастей - и здесь ключевой вопрос состоит наличии и ценах на оригинальные запчасти. Причем в некоторых случаях разница на компоненты, например модуль памяти, в составе первоначальной поставки сервера и в виде "апгрейда" может составлять разы.
42. Применяемые классы и стандарты компонент. Некоторые стандарты на компоненты устарели не в прошлом году, а лет 5 назад. И хотя сейчас все еще можно найти эти компоненты, но ведь сервер в среднем служит от 5 до 10 лет, и можно ли будет найти эти компоненты года через 4?
Не говоря уже о том, что компоненты по прошлым стандартам обычно менее быстрые, но и менее емкие.
43. Доступность к покупке / сроки поставки. Маленьким любителям макбука и облака невдомек, что нельзя просто пойти и купить тысячу серверов и два десятка СХД. А если вдруг что и оказалось на складах - так это ширпотреб в конфигурации, что нам обычно вообще не нужна.
Маленькие любители макбуков полюбили серверные процессоры AMD, но если сервер на Intel можно было весь прошлый год купить со стандартными 6-8 недель, то на AMD срок поставки уже приближался, или даже превышал, год. Из-за отсутствия процессоров AMD в достаточном количестве.
Список можно продолжать, и мы все еще не пришли к сравнению процессорных архитектур и мегагерцев. Потому что сервер - это не процессор.
Стоит заговорить о тестировании сервера и абсолютному большинству далеких от инфраструктуры людей представляются гигафлопсы, иногда транзакции в секунду или даже кадры в секунду. А вот нет, это вообще не про сервер в общем случае.
Итак, что такое сервер. Сервер - вычислительный комплекс, предназначенный для автономной работы без прямого взаимодействия с пользователем (и в этом отличие от десктопа).
В более узком смысле и 95-97% случаев это подразумевает стоечное (rack) исполнение для установки в 19" шкафах.
Давайте разберемся, а что же может быть важно именно для сервера:
1. Качество исполнения корпуса и физические габариты - поместится ли сервер в стойку определенного размера (да-да, мои маленькие айтишники, стойки бывают разной глубины, например).
2. Наличие комплекта быстрого монтажа (быстросъемные рельсы на защелках). Если в компании не 2-3 сервера, а 2-3 или тем более 20-30 тысяч серверов, то этот казалось бы смешной пункт становится довольно таки важным.
3. Поддержка двух блоков питания с горячей заменой и резервировением 1+1. В отличие от десктопов это важно - на стойку в правильных ЦОДах подаются две независимые линии питания и БП подключаются к ним. В итоге страхуются и риск сгоревшего БП (а с горячей заменой даже сервер выключать не надо) и проблема отсутствия питания по одной линии при работах по электрике в ЦОДе.
4. Поддержка полного удаленного управления (iLO, iDRAC, BMC etc). Вспоминаем про тысячи серверов - у вас просто нет физической возможности нанять достаточное количество админов для хотя бы раскатки ОС в нужных количествах. Не говоря уже об обслуживании и мониторинге "а что это у нас там сгорело", если ОС не загружается.
5. Полная световая индикация компонентов. Начиная от сетевых карт и заканчивая компонентами с горячей заменой. Очень важен специальный включаемый режим подсветки (синим) для самого сервера и его компонентов с горячей заменой.
Приходит монтажник с диском на замену - а вокруг ряды стоек с одинаковыми серверами. Заранее включенная подсветка упрощает работу и сильно снижает вероятность ошибки при замене.
Смотрите, вот уже 5 важных пунктов, а мы сервер то еще даже не включали. На самом деле есть еще куча параметров, которым сервер должен соответствовать, в зависимости от важности / специфики конкретного окружения и организации.
И только в самом конце, после прохождения всех функциональных требований, кажущихся смешными человеку, никогда не работавшему с чем-то кроме макбука и "облака", мы наконец перейдем к нагрузочному тестированию, гигафлопсам и всяким SPEC CPU.
Но и это еще не все.
41. Доступность ЗИПа и апгрейдов. Для вендоров класса А характерны запреты на использование сторонних запчастей - и здесь ключевой вопрос состоит наличии и ценах на оригинальные запчасти. Причем в некоторых случаях разница на компоненты, например модуль памяти, в составе первоначальной поставки сервера и в виде "апгрейда" может составлять разы.
42. Применяемые классы и стандарты компонент. Некоторые стандарты на компоненты устарели не в прошлом году, а лет 5 назад. И хотя сейчас все еще можно найти эти компоненты, но ведь сервер в среднем служит от 5 до 10 лет, и можно ли будет найти эти компоненты года через 4?
Не говоря уже о том, что компоненты по прошлым стандартам обычно менее быстрые, но и менее емкие.
43. Доступность к покупке / сроки поставки. Маленьким любителям макбука и облака невдомек, что нельзя просто пойти и купить тысячу серверов и два десятка СХД. А если вдруг что и оказалось на складах - так это ширпотреб в конфигурации, что нам обычно вообще не нужна.
Маленькие любители макбуков полюбили серверные процессоры AMD, но если сервер на Intel можно было весь прошлый год купить со стандартными 6-8 недель, то на AMD срок поставки уже приближался, или даже превышал, год. Из-за отсутствия процессоров AMD в достаточном количестве.
Список можно продолжать, и мы все еще не пришли к сравнению процессорных архитектур и мегагерцев. Потому что сервер - это не процессор.
👍1
Тесты оборудования.
Почему кот себе яйца лижет? Потому что может.
Вот и мы… тестируем оборудование. Потому что скучно.
Так как же сделать все по уму и чтобы все случилось?
Цели теста (пилота)
С чего начинается пилот? Не с подключения оборудования в стойку, совсем нет. До начала любых работ с оборудованием идет работа с документами. И мы начинаем с определения целей пилота.
Цель пилота — устранение возражений Нет возражений — не нужен пилот. Да-да, именно так.
* Сомнения в надежности
* Сомнения в производительности
* Сомнения в масштабируемости
* Сомнения в совместимости и способности работать с нашими системами
* Мы не верим в ваши слайды и хотим убедиться на практике, что ваша система все это действительно умеет
* Это все будет очень сложно, наши инженеры и так загружены и им будет тяжело
Итого, в конечном итоге мы получаем три основных вида пилотного тестирования и как частный случай пилота, доказательство концепта (PoC – proof of concept):
* Нагрузочное тестирование (+ масштабируемость)
* Функциональное тестирование
* Тестирование надежности
В конкретном случае, в зависимости от сомнений конкретного заказчика, в пилоте могут совмещаться разные цели, или напротив, присутствовать только одна из них.
Пилот начинается с документа, описывающего русским языком по белому – зачем проводится данное тестирование. Туда же включается в обязательном порядке набор измеримых критериев, позволяющих однозначно сказать – прошел пилот успешно или что конкретно было не пройдено. Измеримые критерии бывают числовыми (как например задержи в мс, IOPS) или бинарными (да/нет). Если в вашем пилоте присутствует неизмеряемая величина в качестве критерия – в пилоте нет смысла, это исключительно инструмент манипуляций.
Оборудование
Пилот может проводиться на демо-оборудовании вендора / дистрибьютора / партнера или на оборудовании заказчика. Строго говоря, разница небольшая, общий подход один и тот же.
Правильная последовательность действий после определения целей тестирования – полная подготовка оборудования к тестированию ДО тестирования. Т.е. полный комплект должен быть собран на площадке партнера, все проверено и собрано. В обязательном порядке система должна быть запущена и проверена на ошибки. Казалось бы, ничего сложного, но 3 из 4 пилотов начинаются с поиска кабелей или трансиверов SFP.
Отдельно нужно подчеркнуть, что в рамках проверки демо-системы поставщик должны убедиться в ее чистоте. Все данные предыдущего тестирования должны быть удалены с системы в обязательном порядке перед передачей. Не исключено, что проходило тестирование на реальных данных, а там может быть все что угодно, и коммерческая тайна и персональные данные.
Программа тестирования
До передачи оборудования заказчику в обязательном порядке должна быть подготовлена программа тестирования, отвечающая целям тестирования. Каждый тест должен иметь измеримый результат и четкие критерии успеха.
Люди
В рамках подготовки к пилоту необходимо согласовать даты проведения пилота и присутствие всех необходимых лиц и их готовность к тестированию, как со стороны вендора / партнера, так и со стороны заказчика. О, сколько пилотов начиналось с ухода главного человека в пилоте у заказчика в отпуск на следующий день после монтажа оборудования!
Сферы ответственности / доступа
В программе должны быть четко понятны и в идеале описаны сферы ответственности всех участвующих лиц, требуемый доступ и визы от безопасности, включая NDA.
Пилот
Если мы выполнили все предыдущие пункты, то самая скучная часть – это сам пилот. Но он должен идти как по рельсам. Если нет, то значит была запорота часть подготовки.
Завершение пилота
При завершении пилота готовится документ по проведенному тестированию. В идеале со всеми тестами в программе с зеленой галочкой ПРОЙДЕНО.
Если у вас на руках в конце пилота нет документа со списком выполненных тестов и отметками пройдено – пилот провален и его не надо было начинать вообще.
Почему кот себе яйца лижет? Потому что может.
Вот и мы… тестируем оборудование. Потому что скучно.
Так как же сделать все по уму и чтобы все случилось?
Цели теста (пилота)
С чего начинается пилот? Не с подключения оборудования в стойку, совсем нет. До начала любых работ с оборудованием идет работа с документами. И мы начинаем с определения целей пилота.
Цель пилота — устранение возражений Нет возражений — не нужен пилот. Да-да, именно так.
* Сомнения в надежности
* Сомнения в производительности
* Сомнения в масштабируемости
* Сомнения в совместимости и способности работать с нашими системами
* Мы не верим в ваши слайды и хотим убедиться на практике, что ваша система все это действительно умеет
* Это все будет очень сложно, наши инженеры и так загружены и им будет тяжело
Итого, в конечном итоге мы получаем три основных вида пилотного тестирования и как частный случай пилота, доказательство концепта (PoC – proof of concept):
* Нагрузочное тестирование (+ масштабируемость)
* Функциональное тестирование
* Тестирование надежности
В конкретном случае, в зависимости от сомнений конкретного заказчика, в пилоте могут совмещаться разные цели, или напротив, присутствовать только одна из них.
Пилот начинается с документа, описывающего русским языком по белому – зачем проводится данное тестирование. Туда же включается в обязательном порядке набор измеримых критериев, позволяющих однозначно сказать – прошел пилот успешно или что конкретно было не пройдено. Измеримые критерии бывают числовыми (как например задержи в мс, IOPS) или бинарными (да/нет). Если в вашем пилоте присутствует неизмеряемая величина в качестве критерия – в пилоте нет смысла, это исключительно инструмент манипуляций.
Оборудование
Пилот может проводиться на демо-оборудовании вендора / дистрибьютора / партнера или на оборудовании заказчика. Строго говоря, разница небольшая, общий подход один и тот же.
Правильная последовательность действий после определения целей тестирования – полная подготовка оборудования к тестированию ДО тестирования. Т.е. полный комплект должен быть собран на площадке партнера, все проверено и собрано. В обязательном порядке система должна быть запущена и проверена на ошибки. Казалось бы, ничего сложного, но 3 из 4 пилотов начинаются с поиска кабелей или трансиверов SFP.
Отдельно нужно подчеркнуть, что в рамках проверки демо-системы поставщик должны убедиться в ее чистоте. Все данные предыдущего тестирования должны быть удалены с системы в обязательном порядке перед передачей. Не исключено, что проходило тестирование на реальных данных, а там может быть все что угодно, и коммерческая тайна и персональные данные.
Программа тестирования
До передачи оборудования заказчику в обязательном порядке должна быть подготовлена программа тестирования, отвечающая целям тестирования. Каждый тест должен иметь измеримый результат и четкие критерии успеха.
Люди
В рамках подготовки к пилоту необходимо согласовать даты проведения пилота и присутствие всех необходимых лиц и их готовность к тестированию, как со стороны вендора / партнера, так и со стороны заказчика. О, сколько пилотов начиналось с ухода главного человека в пилоте у заказчика в отпуск на следующий день после монтажа оборудования!
Сферы ответственности / доступа
В программе должны быть четко понятны и в идеале описаны сферы ответственности всех участвующих лиц, требуемый доступ и визы от безопасности, включая NDA.
Пилот
Если мы выполнили все предыдущие пункты, то самая скучная часть – это сам пилот. Но он должен идти как по рельсам. Если нет, то значит была запорота часть подготовки.
Завершение пилота
При завершении пилота готовится документ по проведенному тестированию. В идеале со всеми тестами в программе с зеленой галочкой ПРОЙДЕНО.
Если у вас на руках в конце пилота нет документа со списком выполненных тестов и отметками пройдено – пилот провален и его не надо было начинать вообще.
👍2
Тут волна перекрёстного опыления пошла, снова.
Собственно вот такие нашлись у нас дружественные каналы и чатики.
Подписываемся!
@RussianBackupUserGroup - здесь умеют делать бэкапы!
@beerpanda - общие технологически заметки и размышления
@vmugru - VMware User Group по-русски
@ctorecordschat - Обсуждения техдирские
@ctorecords - Техдирские заметки
@yoblako_ru - хронология былинных отказов в облаках
@yoblako_chat - обсуждения былинных отказов
@protelecom - чат про телеком
@pro_enterprise - чат про энтерпрайз
@linkmeup_podcast - канал для сетевиков и сетельвиц
@linkmeup_chat - чат про сети
@linkmeup_sysadm_chat - чат наших сисадминов
@linkmeup_256TTL - чат для тех кто любит погорячее))
@apksh - чат про страдания и Континенты
@eltex - чат об Элтексах
@MikTrain - лучший чат про Микротики
@asterisker -Asterisker-ы и точка
Список будет дополняться, пиши ответное сообщение сюда или мне в ЛС
Собственно вот такие нашлись у нас дружественные каналы и чатики.
Подписываемся!
@RussianBackupUserGroup - здесь умеют делать бэкапы!
@beerpanda - общие технологически заметки и размышления
@vmugru - VMware User Group по-русски
@ctorecordschat - Обсуждения техдирские
@ctorecords - Техдирские заметки
@yoblako_ru - хронология былинных отказов в облаках
@yoblako_chat - обсуждения былинных отказов
@protelecom - чат про телеком
@pro_enterprise - чат про энтерпрайз
@linkmeup_podcast - канал для сетевиков и сетельвиц
@linkmeup_chat - чат про сети
@linkmeup_sysadm_chat - чат наших сисадминов
@linkmeup_256TTL - чат для тех кто любит погорячее))
@apksh - чат про страдания и Континенты
@eltex - чат об Элтексах
@MikTrain - лучший чат про Микротики
@asterisker -Asterisker-ы и точка
Список будет дополняться, пиши ответное сообщение сюда или мне в ЛС
👍1
Тесты оборудования. Часть вторая.
Общая подготовка и обоснование тестирования – в предыдущем посте.
Теперь обсудим общую теорию как мы тестируем оборудование и, в частности, серверы.
1. Paper based review
На основании открытых данных и даташитов проводится общий анализ применимости данного конкретного оборудования, стоит ли связываться с компанией-производителем, конкретными моделями. Вполне может быть уже готовое сравнительное тестирование в открытых источниках.
2. Функциональные тесты – формальная часть
На основании подготовленного плана проводится формальное отмечание галочками выполнение соответствия требованиям. В данном случае по бумагам, спецификациям – по публично доступным и возможно по предоставленным после NDA. Принципиальное отличие – здесь мы говорим уже о конкретном продукте и по нашему плану.
В частности хорошие функциональные требования к серверам можно взять из открытых источников с Госзакупок (https://zakupki.gov.ru/223/purchase/public/purchase/info/common-info.html?regNumber=32110471366) «техническое задание к серверному оборудованию» (во вложенных документах).
3. Функциональные тесты – техническая часть
Здесь проводятся тесты уже с оборудованием – как отрабатывает резервирование БП, горячая замена компонентов и так далее.
4. Синтетическое тестирование
Тестирование мы проводим в большинстве случаев с блокирующими этапами. Т.е. при заваленном функциональном не переходим далее к синтетике, а потом к прикладному.
На данном этапе мы нагружаем железку при помощи открытых тестовых пакетов – SPEC CPU, pgbench, fio и так далее. Наверное, для многих будет удивлением, что у нас одна из крупнейших ИТ служб в России и при этом очень грамотная, и, разумеется, мы не руководствуемся результатами синтетики как истиной в последней инстанции.
Задачи синтетического тестирования:
- ранжирование линейки оборудования;
- качественное сравнение различных конкурирующих решений – когда разница в разы, а не на 5-10%;
- выяснение теоретических пределов производительности в вырожденном случае;
- обоснование дальнейших затрат времени и ресурсов на прикладное тестирование.
Последний пункт особенно важен – зачем нам отвлекать от 5 до 20 дорогостоящих сотрудников из разных подразделений, если производительность на синтетике оказалась в 20-30 раз хуже, чем у аналогов, или половина синтетических тестов попросту отказалась запускаться?
5. Прикладные тесты
Только после прохождения всего вышеперечисленного мы переходим к прикладным тестам. Т.е. измеряем производительность в прикладных, реально работающих системах, либо приближенных к ним.
Работаем мы обычно в очень тесном контакте с производителями оборудования и с внутренними ИТ специалистами, разрабатывающими ИС. Например в одном из нашумевших тестов было 20 инженеров со стороны производителя и только 5 с нашей стороны. Поэтому обвинения в предвзятости, целенаправленной деятельности против или некомпетентности команды попросту смехотворны. А внутренняя приемка у нас такая, что 95% критиков «а чо вы не публикуете подробности» никогда бы ее не сдали. Не публикуем, потому что ДСП и коммерческая тайна – раз, вы с такими ИС больше нигде и никогда не встретитесь – два.
6. Технические выводы
Под техническими выводами понимается анализ результатов и сводные показатели, выраженные в цифрах без учета стоимости. Т.е. прямое сравнение IOPS, FPS и удельные FPS/Вт, например. Весь тот китайско-птичий язык инженеров.
7. Бизнес-выводы
В этом разделе приводится аналитика по тем показателям, что инженерам обычно либо недоступны, либо попросту неинтересны. В первую очередь деньги, стоимость и удельная стоимость FPS/руб. Не мене важны и логистические показатели – например сроки поставки, доступность на рынке, политические риски и тому подобное.
8. Рекомендации
В отдельных случаях по запросу от производителя мы можем выдать со своей стороны рекомендации – а что, собственно, надо поправить, что доработать или в какую сторону двигаться в развитии продукта, чтобы в следующий раз пройти тестирование успешнее и получить рекомендацию к рассмотрению на включение в корп стандарт.
Общая подготовка и обоснование тестирования – в предыдущем посте.
Теперь обсудим общую теорию как мы тестируем оборудование и, в частности, серверы.
1. Paper based review
На основании открытых данных и даташитов проводится общий анализ применимости данного конкретного оборудования, стоит ли связываться с компанией-производителем, конкретными моделями. Вполне может быть уже готовое сравнительное тестирование в открытых источниках.
2. Функциональные тесты – формальная часть
На основании подготовленного плана проводится формальное отмечание галочками выполнение соответствия требованиям. В данном случае по бумагам, спецификациям – по публично доступным и возможно по предоставленным после NDA. Принципиальное отличие – здесь мы говорим уже о конкретном продукте и по нашему плану.
В частности хорошие функциональные требования к серверам можно взять из открытых источников с Госзакупок (https://zakupki.gov.ru/223/purchase/public/purchase/info/common-info.html?regNumber=32110471366) «техническое задание к серверному оборудованию» (во вложенных документах).
3. Функциональные тесты – техническая часть
Здесь проводятся тесты уже с оборудованием – как отрабатывает резервирование БП, горячая замена компонентов и так далее.
4. Синтетическое тестирование
Тестирование мы проводим в большинстве случаев с блокирующими этапами. Т.е. при заваленном функциональном не переходим далее к синтетике, а потом к прикладному.
На данном этапе мы нагружаем железку при помощи открытых тестовых пакетов – SPEC CPU, pgbench, fio и так далее. Наверное, для многих будет удивлением, что у нас одна из крупнейших ИТ служб в России и при этом очень грамотная, и, разумеется, мы не руководствуемся результатами синтетики как истиной в последней инстанции.
Задачи синтетического тестирования:
- ранжирование линейки оборудования;
- качественное сравнение различных конкурирующих решений – когда разница в разы, а не на 5-10%;
- выяснение теоретических пределов производительности в вырожденном случае;
- обоснование дальнейших затрат времени и ресурсов на прикладное тестирование.
Последний пункт особенно важен – зачем нам отвлекать от 5 до 20 дорогостоящих сотрудников из разных подразделений, если производительность на синтетике оказалась в 20-30 раз хуже, чем у аналогов, или половина синтетических тестов попросту отказалась запускаться?
5. Прикладные тесты
Только после прохождения всего вышеперечисленного мы переходим к прикладным тестам. Т.е. измеряем производительность в прикладных, реально работающих системах, либо приближенных к ним.
Работаем мы обычно в очень тесном контакте с производителями оборудования и с внутренними ИТ специалистами, разрабатывающими ИС. Например в одном из нашумевших тестов было 20 инженеров со стороны производителя и только 5 с нашей стороны. Поэтому обвинения в предвзятости, целенаправленной деятельности против или некомпетентности команды попросту смехотворны. А внутренняя приемка у нас такая, что 95% критиков «а чо вы не публикуете подробности» никогда бы ее не сдали. Не публикуем, потому что ДСП и коммерческая тайна – раз, вы с такими ИС больше нигде и никогда не встретитесь – два.
6. Технические выводы
Под техническими выводами понимается анализ результатов и сводные показатели, выраженные в цифрах без учета стоимости. Т.е. прямое сравнение IOPS, FPS и удельные FPS/Вт, например. Весь тот китайско-птичий язык инженеров.
7. Бизнес-выводы
В этом разделе приводится аналитика по тем показателям, что инженерам обычно либо недоступны, либо попросту неинтересны. В первую очередь деньги, стоимость и удельная стоимость FPS/руб. Не мене важны и логистические показатели – например сроки поставки, доступность на рынке, политические риски и тому подобное.
8. Рекомендации
В отдельных случаях по запросу от производителя мы можем выдать со своей стороны рекомендации – а что, собственно, надо поправить, что доработать или в какую сторону двигаться в развитии продукта, чтобы в следующий раз пройти тестирование успешнее и получить рекомендацию к рассмотрению на включение в корп стандарт.
👍1
Правительство предложило установить центрам обработки данных правовой статус и обязанности. Такой законопроект кабмина принят в первом чтении на пленарном заседании Госдумы 6 апреля.
«Впервые вводится в правовое поле понятие центра обработки данных как специализированного сооружения связи — а именно, инфраструктурного объекта», — сказал замминистра цифрового развития, связи и массовых коммуникаций Дмитрий Ким. Также, по его словам, уточняется перечень видов информации, подлежащей передаче в федеральные органы исполнительной власти со стороны операторов связи.
https://www.pnp.ru/politics/zakonoproekt-o-statuse-centrov-obrabotki-dannykh-prinyat-v-pervom-chtenii.html
«Впервые вводится в правовое поле понятие центра обработки данных как специализированного сооружения связи — а именно, инфраструктурного объекта», — сказал замминистра цифрового развития, связи и массовых коммуникаций Дмитрий Ким. Также, по его словам, уточняется перечень видов информации, подлежащей передаче в федеральные органы исполнительной власти со стороны операторов связи.
https://www.pnp.ru/politics/zakonoproekt-o-statuse-centrov-obrabotki-dannykh-prinyat-v-pervom-chtenii.html
Парламентская Газета
Законопроект о статусе центров обработки данных принят в первом чтении
Принятие законопроектов даст дополнительный стимул к развитию таких центров, считают в Минцифры.
Экстремальные времена требуют экстремальных решений.
Компания под атакой просит помощи. Подрядчик готов помочь, для этого нужны доступы к их инфраструктуре. Чтобы их получить, нужен подписанный договор. По экспресс-процедуре договор подписывается три дня (без неё ушёл бы минимум месяц). Ко времени получения доступов можно только констатировать уничтожение инфраструктуры шифровальщиком и заняться восстановлением, время упущено и потери в сотни раз больше, чем могли бы быть. Тот случай, когда антикоррупционное законодательство, кое-как работающее в спокойное время (хотя любой успешный бизнесмен умеет его обходить), работает против экономики в экстремальные времена.
Представьте себе пожарных, которые приехав на пожар, сдают персданные, биометрию и ПЦР, а потом подписывают многостраничные договора и получают пропуска для доступа в горящее здание.
Рустэм Хайретдинов
https://vk.com/wall709261529_96
Компания под атакой просит помощи. Подрядчик готов помочь, для этого нужны доступы к их инфраструктуре. Чтобы их получить, нужен подписанный договор. По экспресс-процедуре договор подписывается три дня (без неё ушёл бы минимум месяц). Ко времени получения доступов можно только констатировать уничтожение инфраструктуры шифровальщиком и заняться восстановлением, время упущено и потери в сотни раз больше, чем могли бы быть. Тот случай, когда антикоррупционное законодательство, кое-как работающее в спокойное время (хотя любой успешный бизнесмен умеет его обходить), работает против экономики в экстремальные времена.
Представьте себе пожарных, которые приехав на пожар, сдают персданные, биометрию и ПЦР, а потом подписывают многостраничные договора и получают пропуска для доступа в горящее здание.
Рустэм Хайретдинов
https://vk.com/wall709261529_96
👍9
mapmagistr2020-2.pdf
2.9 MB
Интерактивная карта "Магистральные сети связи в России" по состоянию на конец 2020.
Очень полезна для планирования точек присутствия и размещения ЦОДов по территории России.
Очень полезна для планирования точек присутствия и размещения ЦОДов по территории России.
👍9
И снова про мошеничество. На примере одной моей коллеги.
Взламывается ВК / фейсбук / вотсапп. Далее туда закидывается картинка со слезливым текстом, реквизитами и подписью взломанного человека.
1. ЧТО ДЕЛАТЬ?
Звонить! Чтобы голосом подтвердить - и при малейшем сомнении, что это не тот человек, по манере говорить, по выражениям - НЕ переводить деньги. В идеале нужно лично встретиться, чтобы подтвердить. Никаких "от меня приедет", только ЛИЧНО!
2. Что здесь подозрительного и палевного:
- острая эмоциональность сообщения, ведь всем жалко больного ребенка
- острая эмоциональность пишущего
- срочность - ну не бывает такой срочности даже при раке, чтобы через 10 минут, а до завтра не ждет
- позднее время публикации (в данном случае было в 23-45, чтобы стало неудобно звонить
- несоответствие даты - срок 8.04, а публикация была 7.04 в 23-45
- Разный шрифт написания реквизитов и подписи. Под готовую картинку вставлялся новый текст.
Идут валом картинки с больными детьми, с животными в травме.
БУДЬ БДИТЕЛЕН!
Взламывается ВК / фейсбук / вотсапп. Далее туда закидывается картинка со слезливым текстом, реквизитами и подписью взломанного человека.
1. ЧТО ДЕЛАТЬ?
Звонить! Чтобы голосом подтвердить - и при малейшем сомнении, что это не тот человек, по манере говорить, по выражениям - НЕ переводить деньги. В идеале нужно лично встретиться, чтобы подтвердить. Никаких "от меня приедет", только ЛИЧНО!
2. Что здесь подозрительного и палевного:
- острая эмоциональность сообщения, ведь всем жалко больного ребенка
- острая эмоциональность пишущего
- срочность - ну не бывает такой срочности даже при раке, чтобы через 10 минут, а до завтра не ждет
- позднее время публикации (в данном случае было в 23-45, чтобы стало неудобно звонить
- несоответствие даты - срок 8.04, а публикация была 7.04 в 23-45
- Разный шрифт написания реквизитов и подписи. Под готовую картинку вставлялся новый текст.
Идут валом картинки с больными детьми, с животными в травме.
БУДЬ БДИТЕЛЕН!
👍6
Психолог, психиатр, психотерапевт. Юридический статус и ответственность.
Давайте начнем с определений – кто есть кто.
Психиатр – врач (!) с высшим медицинским образованием, имеющий право ставить диагноз (определять здоров / болен).
Психотерапевт – медицинский работник, проводящий терапию (лечение) согласно диагноза от психиатра и плана лечения.
Психиатр может совмещать деятельность с психотерапией, или же например направлять пациентов на терапию к другому специалисту.
Психолог – специалист, работающий исключительно со _здоровыми_ людьми, испытывающими временные жизненные трудности.
Пример: мальчику два года, не говорит. Мама и бабушка в ужасе – ааааа! Отвели ребенка к психологу, та за 10 минут, не особо глядя на ребенка – «да он же аутист»!
И здесь мы наблюдаем тройной непрофессионализм, после которого вообще вон из профессии надо бы.
1. Ставит диагноз, не имея на это права.
2. Не имеет образования, достаточного для постановки диагноза.
3. Пугает своим непрофессиональным поведением и так напуганного человека.
Мальчик заговорил в 2.1, да все никак замолчать не может.
Но ничего этой даме психологу сделать невозможно. Ибо психология в РФ, по сути, нерегулируемая область деятельности. Даже еще менее регулируемая, чем булочные. Там хоть худо-бедно санэпид надзор есть.
Есть псевдорегуляция через ассоциацию психологов и необязательные профстандарты. Но в отличие от врача, которого можно лишить лицензии на деятельность, максимум для психолога – это то, что его фамилию вывесят на никому не известном сайте в черном списке. Вот вы когда последний раз проверяли эти черные списки?
Профстандарт и несоответствие ему не является основанием к увольнению психолога. Максимум, что можно сделать – это инициировать независимую проверку на квалификацию, а дальше уволить за несоответствие квалификации занимаемой должности. Это если ты работодатель.
В теории вы можете пожаловаться на психолога руководству клиники. Это если он в клинике работает или гос учреждении. А если нет, и это психолог-фрилансер? Ну вот как Вероника Степанова, скажем (автор программистов-анальников). Пока данный конкретный психолог не нарушает УК, вы практически ничего не можете ему/ей сделать. Только постфактум за причинение вреда здоровью, который еще замучаетесь доказывать.
То, что представлено сейчас под названием психология – это жуткий салат из 20-30 противоречащих друг другу сект с харизматичными лидерами и сверхценными идеями, помноженными на слабое понимание нейрофизиологии.
В общем к психологам относиться надо как к осетрине. Она, как известно, бывает только одной свежести – первая, она же последняя. Если вас что-то смущает в данном психологе, есть малейшее сомнение – не стесняйтесь обратиться к кому-то еще за дополнительной консультацией. И в особенности это нужно сделать, если психолог вызывает восторг – уж не в секту ли вы зашли?
От нечистого на руку или попросту безграмотного психолога вас никто не защитит, кроме вас самих.
Давайте начнем с определений – кто есть кто.
Психиатр – врач (!) с высшим медицинским образованием, имеющий право ставить диагноз (определять здоров / болен).
Психотерапевт – медицинский работник, проводящий терапию (лечение) согласно диагноза от психиатра и плана лечения.
Психиатр может совмещать деятельность с психотерапией, или же например направлять пациентов на терапию к другому специалисту.
Психолог – специалист, работающий исключительно со _здоровыми_ людьми, испытывающими временные жизненные трудности.
Пример: мальчику два года, не говорит. Мама и бабушка в ужасе – ааааа! Отвели ребенка к психологу, та за 10 минут, не особо глядя на ребенка – «да он же аутист»!
И здесь мы наблюдаем тройной непрофессионализм, после которого вообще вон из профессии надо бы.
1. Ставит диагноз, не имея на это права.
2. Не имеет образования, достаточного для постановки диагноза.
3. Пугает своим непрофессиональным поведением и так напуганного человека.
Мальчик заговорил в 2.1, да все никак замолчать не может.
Но ничего этой даме психологу сделать невозможно. Ибо психология в РФ, по сути, нерегулируемая область деятельности. Даже еще менее регулируемая, чем булочные. Там хоть худо-бедно санэпид надзор есть.
Есть псевдорегуляция через ассоциацию психологов и необязательные профстандарты. Но в отличие от врача, которого можно лишить лицензии на деятельность, максимум для психолога – это то, что его фамилию вывесят на никому не известном сайте в черном списке. Вот вы когда последний раз проверяли эти черные списки?
Профстандарт и несоответствие ему не является основанием к увольнению психолога. Максимум, что можно сделать – это инициировать независимую проверку на квалификацию, а дальше уволить за несоответствие квалификации занимаемой должности. Это если ты работодатель.
В теории вы можете пожаловаться на психолога руководству клиники. Это если он в клинике работает или гос учреждении. А если нет, и это психолог-фрилансер? Ну вот как Вероника Степанова, скажем (автор программистов-анальников). Пока данный конкретный психолог не нарушает УК, вы практически ничего не можете ему/ей сделать. Только постфактум за причинение вреда здоровью, который еще замучаетесь доказывать.
То, что представлено сейчас под названием психология – это жуткий салат из 20-30 противоречащих друг другу сект с харизматичными лидерами и сверхценными идеями, помноженными на слабое понимание нейрофизиологии.
В общем к психологам относиться надо как к осетрине. Она, как известно, бывает только одной свежести – первая, она же последняя. Если вас что-то смущает в данном психологе, есть малейшее сомнение – не стесняйтесь обратиться к кому-то еще за дополнительной консультацией. И в особенности это нужно сделать, если психолог вызывает восторг – уж не в секту ли вы зашли?
От нечистого на руку или попросту безграмотного психолога вас никто не защитит, кроме вас самих.
👍14❤1
Красноглазые рейсы идут в пень.
Были ли у вас когда нибудь встречи в Екатеринбурге или даже Красноярске в 9 утра? У меня бывали - и я оценил все прелести красноглазых рейсов. Т.е. Вылетаешь в 12-2 часа ночи из Москвы, прилетаешь в 7 утра по местному времени уставший, злой и невыспавшийся.
И я перестал так летать - только строго на день раньше. Для меня, клинического сова, встать на встречу к 9 утра в Москве то почти подвиг, а уж по Красноярскому времени адское насилие. В части контор к этому нет никаких вопросов - ведь я же еду зарабатывать деньги, и если я не в форме, то какой смысл вообще ехать? Не приехать и не вскрывать заказчика зачастую полезнее, чем приехать с плохим результатом.
Но в части, которая жалась, работала по серой схеме, были нюансы.
1. В одной из контор разговор в бухгалтерии, что по КЗоТ положена оплата дороги вызвал восклицание бухгалтера “ТЫ тут без году неделя работаешь, а уже условия ставишь”
2. Пришлось мне как то писать целую служебную записку, чтобы мне оплатили гостиницу аж за 3 тыс руб в Кургане. А то в счете было написано, что номер был с двумя кроватями - а мало ли с кем я там спал! Вот и оправдывался, мол не было других номеров, но честное слово спал один.
3. Еще в одной конторе было на уровне настоятельной и убедительной рекомендации принято писать служебки, чтобы предыдущий выходной день не оплачивался как командировка - это по личным причинам я полетел на день раньше. “А вдруг ты полетел там погулять просто”. Ага, в Перми в 10 вечера гулять - моя главная мечта.
4. Как то мне неделю 5 директоров (!) согласовывали такси за 2500 из аэропорта, потому что я заранее не заказал и не согласовал его. В офисе из 100 человек, да.
А у вас какие были морозные истории?
Были ли у вас когда нибудь встречи в Екатеринбурге или даже Красноярске в 9 утра? У меня бывали - и я оценил все прелести красноглазых рейсов. Т.е. Вылетаешь в 12-2 часа ночи из Москвы, прилетаешь в 7 утра по местному времени уставший, злой и невыспавшийся.
И я перестал так летать - только строго на день раньше. Для меня, клинического сова, встать на встречу к 9 утра в Москве то почти подвиг, а уж по Красноярскому времени адское насилие. В части контор к этому нет никаких вопросов - ведь я же еду зарабатывать деньги, и если я не в форме, то какой смысл вообще ехать? Не приехать и не вскрывать заказчика зачастую полезнее, чем приехать с плохим результатом.
Но в части, которая жалась, работала по серой схеме, были нюансы.
1. В одной из контор разговор в бухгалтерии, что по КЗоТ положена оплата дороги вызвал восклицание бухгалтера “ТЫ тут без году неделя работаешь, а уже условия ставишь”
2. Пришлось мне как то писать целую служебную записку, чтобы мне оплатили гостиницу аж за 3 тыс руб в Кургане. А то в счете было написано, что номер был с двумя кроватями - а мало ли с кем я там спал! Вот и оправдывался, мол не было других номеров, но честное слово спал один.
3. Еще в одной конторе было на уровне настоятельной и убедительной рекомендации принято писать служебки, чтобы предыдущий выходной день не оплачивался как командировка - это по личным причинам я полетел на день раньше. “А вдруг ты полетел там погулять просто”. Ага, в Перми в 10 вечера гулять - моя главная мечта.
4. Как то мне неделю 5 директоров (!) согласовывали такси за 2500 из аэропорта, потому что я заранее не заказал и не согласовал его. В офисе из 100 человек, да.
А у вас какие были морозные истории?
👍10
Forwarded from BeerPanda. Органично недоразвитый DevOps
Дано: чат 130+ человек, средний уровень старший архитектор / зам ИТ директора.
Условия: обсуждаем ИТ, материмся, безобразия нарушаем. Но строго под реальным именем / местом работы. Чтобы знали если что, кого. За год работы ни разу не применялись модераторские санкции.
Ищем: приходите к нам, у нас интересно. На входе фейс контроль.
Условия: обсуждаем ИТ, материмся, безобразия нарушаем. Но строго под реальным именем / местом работы. Чтобы знали если что, кого. За год работы ни разу не применялись модераторские санкции.
Ищем: приходите к нам, у нас интересно. На входе фейс контроль.
👍2
Что такое SDS?
Я очень часто встречаю мнение, что SDS - это 1, 2, 3, 4 ... и еще 500 разных критериев, среди которых лидирует "неограниченная масштабируемость", "scale-out" и почему-то "мультитенантность".
Нет, на самом деле SDS или "программно-определяемые хранилища" - всего лишь системы хранения данных, в которых не используется заказной кремний. Т.е. 100% программные системы, построенные на железе общего применения без использования специализированных ускорителей.
Фактически EMC VNX 2011 года был SDS, поскольку процессоры, память и даже сеть там были общедоступные, а заказными были только по сути корпуса. Матплаты там хоть и были заказными, но фактически особо ничем не отличались от общедоступных - на стандартных компонентах.
Это классические СХД, а в противовес им есть новые модные гиперконвергентные НЕ SDS - HPE Simplivity, полностью построенная вокруг идеи использования специального ускорителя для дедупликации.
Почему даже классические СХД отошли в сторону SDS? Все очень просто - цикл разработки и стоимость поддержки заказного кремния в рамках развития ИТ перестали оправдываться производительностью. Время появления и стоимость инженерных образцов уже высоки, а с учетом неминуемых исправлений еще больше. Любая серьезная аппаратная ошибка приводит к проблеме - а как исправлять то, что уже стоит у клиентов?
При этом производительность стандартных Xeon начала сравниваться и превосходить производительность ASIC. Стоимость разработки и протипирования упала в десятки раз, а все ошибки в программном коде легко исправить патчами. Сама же СХД стала просто User-level процессом в Linux (иногда Windows).
ВСЕ. ТОЧКА. Нет в SDS никаких больше требований или функций. Scale-Out, Multitenancy и прочее можно реализовать и с заказным кремнием, и не в опенсорсе - это не является неотъемлемой частью или признаком SDS.
Ну и раз уж затронули тему гиперконвергентных систем, давайте наведем порядок в определениях.
Гиперконвергентные системы
Конвергентные системы, как подсказывает название — системы с совмещением функций. И в данном случае имеется в виду совмещение функции хранения и исполнения ВМ. Вроде просто, но внезапно врывается маркетинг.
Впервые с термином конвергентные системы на рынок врываются маркетологи. Под конвергентной системой продавались обычные классические серверы + СХД + коммутаторы. Просто под одним партномером. Или даже не продавались, а выпускалась бумага под названием “референсная архитектура”. Мы искренне порицаем этот подход и переходим к архитектурному рассмотрению.
Архитектура
Сохраняя конвергенцию как архитектурный принцип, получаем совмещение точки хранения и точки исполнения ВМ в единой системе.
Конвергентная архитектура, иными словами, подразумевает использование одних и тех же аппаратных сервисов как для исполнения ВМ, так и для их хранения на локальных дисках. Ну а поскольку должна быть отказоустойчивость — в конвергентной архитектуре есть слой распределенной SDS.
Получаем:
* Классическая система — софт, СХД, коммутация и серверы идут из разных мест, совмещаются руками заказчика/интегратора. Отдельные контракты на поддержку.
* Конвергентная система — все из одних рук, единая поддержка, единый партномер. Не путать с самосбором от одного вендора.
И, получается, что термин под нашу конвергентную архитектуру уже занят. Ровно та же ситуация, что с супервизором. (*)
Гиперконвергентная система — конвергентная система с конвергентной архитектурой.
Конечно же не обошлось и без второго пришествия маркетологов. Появились конвергентные системы в которых совмещения хранения не было, а есть выделенные узлы хранения под управлением распределенной SDS.
Появился в рамках маркетинговых войн даже специальный термин disaggregated HCI (дизагрегированная гипервергентная инфраструктура). В частности, например, NetApp с подобной системной сначала довольно интенсивно воевали за право называть свою систему гиперконвергентной, но в итоге сдались. NetApp HCI на сегодня (конец 2019) — hybrid cloud infrastructure.
(*) гипервизор так называется потому что термин супервизор был уже занят
Я очень часто встречаю мнение, что SDS - это 1, 2, 3, 4 ... и еще 500 разных критериев, среди которых лидирует "неограниченная масштабируемость", "scale-out" и почему-то "мультитенантность".
Нет, на самом деле SDS или "программно-определяемые хранилища" - всего лишь системы хранения данных, в которых не используется заказной кремний. Т.е. 100% программные системы, построенные на железе общего применения без использования специализированных ускорителей.
Фактически EMC VNX 2011 года был SDS, поскольку процессоры, память и даже сеть там были общедоступные, а заказными были только по сути корпуса. Матплаты там хоть и были заказными, но фактически особо ничем не отличались от общедоступных - на стандартных компонентах.
Это классические СХД, а в противовес им есть новые модные гиперконвергентные НЕ SDS - HPE Simplivity, полностью построенная вокруг идеи использования специального ускорителя для дедупликации.
Почему даже классические СХД отошли в сторону SDS? Все очень просто - цикл разработки и стоимость поддержки заказного кремния в рамках развития ИТ перестали оправдываться производительностью. Время появления и стоимость инженерных образцов уже высоки, а с учетом неминуемых исправлений еще больше. Любая серьезная аппаратная ошибка приводит к проблеме - а как исправлять то, что уже стоит у клиентов?
При этом производительность стандартных Xeon начала сравниваться и превосходить производительность ASIC. Стоимость разработки и протипирования упала в десятки раз, а все ошибки в программном коде легко исправить патчами. Сама же СХД стала просто User-level процессом в Linux (иногда Windows).
ВСЕ. ТОЧКА. Нет в SDS никаких больше требований или функций. Scale-Out, Multitenancy и прочее можно реализовать и с заказным кремнием, и не в опенсорсе - это не является неотъемлемой частью или признаком SDS.
Ну и раз уж затронули тему гиперконвергентных систем, давайте наведем порядок в определениях.
Гиперконвергентные системы
Конвергентные системы, как подсказывает название — системы с совмещением функций. И в данном случае имеется в виду совмещение функции хранения и исполнения ВМ. Вроде просто, но внезапно врывается маркетинг.
Впервые с термином конвергентные системы на рынок врываются маркетологи. Под конвергентной системой продавались обычные классические серверы + СХД + коммутаторы. Просто под одним партномером. Или даже не продавались, а выпускалась бумага под названием “референсная архитектура”. Мы искренне порицаем этот подход и переходим к архитектурному рассмотрению.
Архитектура
Сохраняя конвергенцию как архитектурный принцип, получаем совмещение точки хранения и точки исполнения ВМ в единой системе.
Конвергентная архитектура, иными словами, подразумевает использование одних и тех же аппаратных сервисов как для исполнения ВМ, так и для их хранения на локальных дисках. Ну а поскольку должна быть отказоустойчивость — в конвергентной архитектуре есть слой распределенной SDS.
Получаем:
* Классическая система — софт, СХД, коммутация и серверы идут из разных мест, совмещаются руками заказчика/интегратора. Отдельные контракты на поддержку.
* Конвергентная система — все из одних рук, единая поддержка, единый партномер. Не путать с самосбором от одного вендора.
И, получается, что термин под нашу конвергентную архитектуру уже занят. Ровно та же ситуация, что с супервизором. (*)
Гиперконвергентная система — конвергентная система с конвергентной архитектурой.
Конечно же не обошлось и без второго пришествия маркетологов. Появились конвергентные системы в которых совмещения хранения не было, а есть выделенные узлы хранения под управлением распределенной SDS.
Появился в рамках маркетинговых войн даже специальный термин disaggregated HCI (дизагрегированная гипервергентная инфраструктура). В частности, например, NetApp с подобной системной сначала довольно интенсивно воевали за право называть свою систему гиперконвергентной, но в итоге сдались. NetApp HCI на сегодня (конец 2019) — hybrid cloud infrastructure.
(*) гипервизор так называется потому что термин супервизор был уже занят
👍15
Начал было погружаться в музыкальную сцену, и даже от очень уважаемых людей, бесспорно гуру в вопросах собственно музыки, насчет цифрового звука зачастую слышны какие-то мифы.
Поэтому - вот вам основы цифрового звука.
https://telegra.ph/Osnovy-cifrovogo-zvuka-1-05-12
Поэтому - вот вам основы цифрового звука.
https://telegra.ph/Osnovy-cifrovogo-zvuka-1-05-12
Telegraph
Основы цифрового звука. 1
Рассмотрим цифровой звук для непрофессионалов цифровой индустрии. Начал было погружаться в музыкальную сцену, и даже от очень уважаемых людей, бесспорно гуру в вопросах собственно музыки, насчет цифрового звука зачастую слышны какие-то мифы. Итак, что такое…
👍11