Спасибо за столь подробный ответ. По поводу инцидента в Яндекс - к сожалению, я очень хорошо знаю что там произошло. Проблема там была не физическая а логическая. И кстати, сбой в был внутри зоны, в связности именно между компонентами, снаружи всё (то что было живо 8-) отзывалось без проблем. И именно в такой ситуации можно было всё быстро поднять на другом физическом сервере/ах в том же ЦОД. Ну да это не принципиально. Отвечая на ваш вопрос - помешало поднять в другом месте то, что по ряду причин всё заточено именно под яндекс и именно под эту упавшую зону. А решение наше пока еще не географически распределённое потому, что облака это дорого, чертовски дорого... Мы хорошо это знаем, каждый месяц переводя в Яндекс шестизначную сумму, уже очень близко приблизившуюся к семизначной, и пока не можем позволить себе её увеличить. Выгодность/невыгодность надо хорошо считать. Я знаю компании, которые ушли в облака потому что это модно. Знаю те, которым неважно сколько это стоит, а важно что бы было кого засудить за сбой системы. Но знаю и тех, кто считал арифметику. Мы вот думали что всё посчитали и пошли как раз в облако. Но сейчас понимаем, что арендовав четыре года назад два шкафа в двух ЦОД сейчас были бы в плюсе.. Для индивидуального разработчика, который хочет поднять условный пет проект, не очень задумываясь что такое сегментация системы, разграничение доступа к данным, требования регулятора, которому нужно пару-тройку ядер, и который не знает и не хочет знать, что такое RDMA, маска подсети и Layer 7, но умеет писать yaml файлы - ваше решение однозначно может оказаться удобным и выгодным. Ни в коем случае не хочу никого задеть или обидеть, прошу не понять меня неправильно. Но для каждой конкретной задачи скорей всего понадобится свой определённый инструмент. И, повторюсь, облака это удобно и дёшево для малонагруженного простого проекта и очень-очень недёшево для большой системы.
Принципиальная ошибка автора заключается в том, что он исходит из предположения что системы в облаках работают сами, без собственных девопс инженеров и других специалистов по инфраструктуре у пользователя. Я бы даже сказал классическая ошибка. В небольших проектах возможно так и есть. И полтора программиста, которые пишут код в таких проектах, заодно в оставшееся время могут и поднимать контейнеры и рулить базами данных/кубернетесом/кафкой. Но в реальных больших системах собственные сисадмины/девопс инженеры всё равно нужны. Сотрудники облачного провайдера отвечают только за общую инфраструктуру облака. И никак не отвечают и не могут отвечать за ваш проект. И поэтому вся арифметика меняется. На входе действительно проще, быстрей и дешевле поднять систему в облаке. Особенно если система не должна работать 24/7 и ВМ/контейнеры можно поднимать для тестов и отладки на пару часов в день. Но при реальной эксплуатации надо хорошо считать. То что дешевле и проще в первый месяц, далеко не всегда дешевле и проще в перспективе 5-и лет. И в этом я полностью согласен с @ky0 выше. Плюс отсутствие доступа к инфраструктуре может сыграть и очень плохую шутку при неудачном стечении обстоятельств. Реальный пример случился с нами буквально на днях, когда рухнула часть облачной инфраструктуры Яндекса. И это по закону подлости был как раз день, когда мы показывали проект большому госзаказчику. Если бы это были наши собственные сервера, мы бы уже метнулись кабанчиком в ЦОД/серверную и подняли дополнительный сервер с копией системы. А так ждали у моря погоду, что-то придумывали/изобретали и пытались сделать хорошую мину при плохой игре... Уже написал свой пост, а потом обратил внимание что это рекламная статья товарища из компании, которая предлагает облачные услуги. Не знаю, может у них хорошее облако, не проверял. Но не верю в сказки что большие сложные проекты будут хорошо работать сами по себе, без специалистов по инфраструктуре, которые ими непосредственно занимаются. И, кстати @kirillkosolapov - а как у вас в облаке с 152-ФЗ?
Невозможно на 100% надеяться на чужие гарантии, аудиты, сертификаты и т.д.. Никакой независимый аудит не в состоянии обеспечить 100% защиту. Ни от багов, ни от бэкдоров.
Может в курсе - какие свичи поддерживаются ОС NVIDIA Onyx ? Я что-то не нашёл в описании. Является ли эта ОС частью ON (Open Network) проекта? Спасибо.
Коллеги - вот этот вот всё серьёзно? Да ещё под тегом "информационная безопасность"? Что тогда дальше? Статья "как мы поменяли полиси и разрешили заходить под эккаунтом администратора без пароля и это очень быстро и удобно и не надо запоминать пароли"? Или это просто попытка скрытой рекламы некоего устройства собственного производства?
Согласен. Спасибо за идею. Будем считать что корованы - это стада стеллеровых/морских коров. Осталось придумать как их можно грабить. (всё таки охотиться и грабить не совсем одно и то же)
А - ну тогда другое дело. Если кОрОваны из коров (а другой смысл слова "кОрОваны" мне в голову не приходит; подумать же о безграмотности пишущего слово "кОрОваны" мне не позволяет врождённая вежливость), и при условии что коровы не пострадают - то тогда, наверное, дело богоугодное.. Но вот одна проблема - игра вроде морская. Я пока не могу придумать, где парусник может повстречаться с коровами в корованах..
Заранее прошу прощения у более опытных хабровчан — но я не понял цель и выводы из данной статьи. Написано много, оценить правильность употребления слов и перечисления диагнозов я не могу, не имею достаточного образования. И не готов приравнять классическое получение медицинского образования к чтению кем-то статей и книжек в интернете…
Соответственно — два вопроса.
1) Если среди читателей есть профессиональные медики — то не могли бы они критически отреагировать на вышенаписанное? Имеют ли какой-то смысл все упомянутые выше слова в конкретном используемом сочетании?
2) Уважаемый автор — а что вы хотели сказать и рассказать? Что злые и жадные врачи неправильно лечили вас от хламидиоза, который вы получили воздушно капельным путём? И что сидячая работа усугубила это неправильное лечение?
Спасибо и прошу заранее прощения, если кого-то задел…
Не противоречит точно. Из за того что израильский парламент разделён примерно поровну на «правых» и «левых», есть некая не очень большая религиозная партия, не являющаяся правящей, но являющаяся тем камешком на весах, который обычно склоняет весы голосования в нужную сторону. Поэтому большие партии постоянно вынуждены принимать её во внимание.
Спасибо за столь подробный ответ.
По поводу инцидента в Яндекс - к сожалению, я очень хорошо знаю что там произошло. Проблема там была не физическая а логическая. И кстати, сбой в был внутри зоны, в связности именно между компонентами, снаружи всё (то что было живо 8-) отзывалось без проблем. И именно в такой ситуации можно было всё быстро поднять на другом физическом сервере/ах в том же ЦОД. Ну да это не принципиально. Отвечая на ваш вопрос - помешало поднять в другом месте то, что по ряду причин всё заточено именно под яндекс и именно под эту упавшую зону. А решение наше пока еще не географически распределённое потому, что облака это дорого, чертовски дорого...
Мы хорошо это знаем, каждый месяц переводя в Яндекс шестизначную сумму, уже очень близко приблизившуюся к семизначной, и пока не можем позволить себе её увеличить.
Выгодность/невыгодность надо хорошо считать. Я знаю компании, которые ушли в облака потому что это модно. Знаю те, которым неважно сколько это стоит, а важно что бы было кого засудить за сбой системы. Но знаю и тех, кто считал арифметику. Мы вот думали что всё посчитали и пошли как раз в облако. Но сейчас понимаем, что арендовав четыре года назад два шкафа в двух ЦОД сейчас были бы в плюсе..
Для индивидуального разработчика, который хочет поднять условный пет проект, не очень задумываясь что такое сегментация системы, разграничение доступа к данным, требования регулятора, которому нужно пару-тройку ядер, и который не знает и не хочет знать, что такое RDMA, маска подсети и Layer 7, но умеет писать yaml файлы - ваше решение однозначно может оказаться удобным и выгодным. Ни в коем случае не хочу никого задеть или обидеть, прошу не понять меня неправильно. Но для каждой конкретной задачи скорей всего понадобится свой определённый инструмент.
И, повторюсь, облака это удобно и дёшево для малонагруженного простого проекта и очень-очень недёшево для большой системы.
Принципиальная ошибка автора заключается в том, что он исходит из предположения что системы в облаках работают сами, без собственных девопс инженеров и других специалистов по инфраструктуре у пользователя. Я бы даже сказал классическая ошибка. В небольших проектах возможно так и есть. И полтора программиста, которые пишут код в таких проектах, заодно в оставшееся время могут и поднимать контейнеры и рулить базами данных/кубернетесом/кафкой. Но в реальных больших системах собственные сисадмины/девопс инженеры всё равно нужны. Сотрудники облачного провайдера отвечают только за общую инфраструктуру облака. И никак не отвечают и не могут отвечать за ваш проект. И поэтому вся арифметика меняется. На входе действительно проще, быстрей и дешевле поднять систему в облаке. Особенно если система не должна работать 24/7 и ВМ/контейнеры можно поднимать для тестов и отладки на пару часов в день. Но при реальной эксплуатации надо хорошо считать. То что дешевле и проще в первый месяц, далеко не всегда дешевле и проще в перспективе 5-и лет. И в этом я полностью согласен с @ky0 выше.
Плюс отсутствие доступа к инфраструктуре может сыграть и очень плохую шутку при неудачном стечении обстоятельств. Реальный пример случился с нами буквально на днях, когда рухнула часть облачной инфраструктуры Яндекса. И это по закону подлости был как раз день, когда мы показывали проект большому госзаказчику. Если бы это были наши собственные сервера, мы бы уже метнулись кабанчиком в ЦОД/серверную и подняли дополнительный сервер с копией системы. А так ждали у моря погоду, что-то придумывали/изобретали и пытались сделать хорошую мину при плохой игре...
Уже написал свой пост, а потом обратил внимание что это рекламная статья товарища из компании, которая предлагает облачные услуги. Не знаю, может у них хорошее облако, не проверял. Но не верю в сказки что большие сложные проекты будут хорошо работать сами по себе, без специалистов по инфраструктуре, которые ими непосредственно занимаются.
И, кстати @kirillkosolapov - а как у вас в облаке с 152-ФЗ?
Невозможно на 100% надеяться на чужие гарантии, аудиты, сертификаты и т.д.. Никакой независимый аудит не в состоянии обеспечить 100% защиту. Ни от багов, ни от бэкдоров.
Почему ни о чём? Человек сказал что хотел сказать, поделился болью, во многом прав. Пообещал в следующей статье подробности как он эту боль решил...
Кстати - интересно как.
Может в курсе - какие свичи поддерживаются ОС NVIDIA Onyx ? Я что-то не нашёл в описании. Является ли эта ОС частью ON (Open Network) проекта?
Спасибо.
Скажите пожалуйста - всю эту конфигурацию вы получили от вендора? Или нашли сами? Если сами - то как и на базе чего искали?
Спасибо
Очень интересно. Ждём.
Не уверен что понял вопрос, сорри..
Коллеги - вот этот вот всё серьёзно? Да ещё под тегом "информационная безопасность"? Что тогда дальше? Статья "как мы поменяли полиси и разрешили заходить под эккаунтом администратора без пароля и это очень быстро и удобно и не надо запоминать пароли"? Или это просто попытка скрытой рекламы некоего устройства собственного производства?
Спасибо за науку. 8-)
А-а, вон оно как, Петрович..
Тогда совсем другое дело...
Согласен. Спасибо за идею. Будем считать что корованы - это стада стеллеровых/морских коров. Осталось придумать как их можно грабить. (всё таки охотиться и грабить не совсем одно и то же)
А - ну тогда другое дело. Если кОрОваны из коров (а другой смысл слова "кОрОваны" мне в голову не приходит; подумать же о безграмотности пишущего слово "кОрОваны" мне не позволяет врождённая вежливость), и при условии что коровы не пострадают - то тогда, наверное, дело богоугодное.. Но вот одна проблема - игра вроде морская. Я пока не могу придумать, где парусник может повстречаться с коровами в корованах..
корованы нельзя. коров нельзя обижать
Откуда столько злости? Чем вам лично насолили люди, долго работающие на одном месте и получаюшие там высокую зарплату?
Соответственно — два вопроса.
1) Если среди читателей есть профессиональные медики — то не могли бы они критически отреагировать на вышенаписанное? Имеют ли какой-то смысл все упомянутые выше слова в конкретном используемом сочетании?
2) Уважаемый автор — а что вы хотели сказать и рассказать? Что злые и жадные врачи неправильно лечили вас от хламидиоза, который вы получили воздушно капельным путём? И что сидячая работа усугубила это неправильное лечение?
Спасибо и прошу заранее прощения, если кого-то задел…