LINUX.ORG.RU
ФорумTalks

Мода на облака, бигдату, и распределенные БД [теория тупости]

 , , , ,


1

2

Давайте немножко побеседуем про новомодные low consistency poor availability системы, снискавшие популярность в последнее время.

Попытка заблокировать сервисы Google обернулась сбоем в работе систем Центробанка РФ (комментарий)
«интернет вояками планировался как отказоустойчивая сеть, но вебмакаки умудрились сделать из нее сильно связанный фарш, поздравляю, вы сломали чугунный шар»

Как мы все знаем, интернет разрабатывался, как отказоустойчивая система, которая функционирует до последнего узла. Как мы знаем, коммерсанту частенько есть что скрывать и не хочется зависеть от благого расположения Васи Пупкина, даже если Васю Пупкина зовут SAP, Oracle, IBM, или Microsoft. Так почему же люди покупают Office 365 и Dynamics 365 при том, что есть полностью оффлайн альтернативы? Если вы размещаетесь в России или Китае, покупаете продукт 365, а потом Роскомнадзоры или сам MS блокирует вам облако — вы остаетесь полностью в дерьме. Кто это покупает и что ими движет? Кто завязывает свой бизнес на Dynamics 365? Или на облачный Битрикс? Я не понимаю, предлагайте ваши вариант.

«Облака», в плане «привязан цепью к интернет-серверу», не новы, Самая отстойная копирастическая контора, Ubisoft, в свое время отличилась тем, что их uPlay при кратковременной потере интернет-соединения вываливал вас из ОФФЛАЙН игры. По сути, многие софтоделы ориентируются на облако просто для того, чтобы иметь больше возможностей струсить денег с потребителя. И даже несмотря на то, что теоретически возможность миграции предоставляет много кто — фактически эта миграция выйдет вам в копеечку и вы семь раз подумаете, прежде чем мигрировать.

Ладно, допустим, просто допустим, что таким образом некий Ерохин экономит время и деньги на установке и настройке оффлайнового софта, на организации своего сервера, к которому можно было бы получить доступ даже с мабилы (не спрашивайте меня, зачем с мобилы — я не понимаю). Давайте даже на минуту пофантазируем, что мы — технически грамотный разработчик, который желает приобщиться к потоку денег. Естественно, при этом мы желаем клиенту только добра. Железо дешевое, хостинг дешевый — давайте же сделаем бэк нашего продукта на большом-прибольшом числе серверов, да еще и в разных геолокациях, чтобы у нашего любимого клиента было меньше проблем со связью.

Но раскидать серваки по планете — это одно, а заставить их работать после этого вместе — это совершенно другого уровня задача. Как она обычно решается? Через базы данных, в число которых входят брокеры сообщений, вроде RabbitMQ. И здесь мы вступаем на тропу лютого треша, потому что проектировать и реализовывать распределенные системы и БД в частности на планете умеет человек двадцать, и скорее всего они работают не у вас, но спрос на них сильно больше, потому что другие «умники» уже давно витают в облаках и своих спецов не отдадут.

«Готовые решения всё порешают» — скажете вы? А знаете ли вы, что ZooKeeper — единственная распределенная СУБД, гарантирующая строгую согласованность данных при отказах? А знаете ли вы, что, даже несмотря на выдающиеся достижения, в ZooKeeper операция синхронизированного чтения нелинеаризуема, а потому часть вашего кластера может сидеть с тухлыми данными, не зная об этом? А знаете ли вы, что полностью исправный кластер Riak при интенсивных конфликтах обновлений теряет более половины этих обновлений на полностью исправном кластере? Даже при самых строгих настройках согласованности данных. Причем, таким ужасным Riak делать было не обязательно — на самом деле это спонсоры Riak и попросили сделать умолчательную конфигурацию такой ужасной.

Но как же так, мы же все давно знаем про Paxos, который еще триста лет назад позволял достигнуть консенсуса в распределенной системе с отказами узлов — почему же до сих пор в школе не преподают основы построения распределенных систем? Если мы возьмем тот же ZooKeeper, то мы увидим, что в случае отказа лидера кластеру требуется НЕСКОЛЬКО СЕКУНД на возобновление работы — это настоящая стоимость честного распределенного консенсуса, который у ZooKeeper при выборах лидера похож на Paxos. Для решения проблем дичайше медленного консенсуса и возникла идея выбора «эталонного сервера», лидера, мнение которого безоговорочно принимает весь кластер без затрат на спор между узлами.

Правда, этот подход все равно не сработает при достаточно частых сбоях с частыми потерями лидера. Более того, система на консенсусе полностью выйдет из строя при потере более половины узлов. Вы можете заметить, что согласно теореме говна-или-мочи достижима либо согласованность данных, либо доступность системы, либо в системе недопустимы отказы. Давайте пожертвует согласованностью ради доступности! Но беда мамкиных бигдатовцев заключается в том, что средняя система по больнице не обладает высокой доступностью и не обладает хорошими гарантиями согласованности. То есть, высокодоступная система готова работать 24/7 до первого отказа сервера или потери соединения с интернетом. Почему пришлось так делать? Потому что иначе будет высокая задержка ответа и/или большая нагрузка на каналы.

Возьмем среднюю бигдату в вакууме — GitLab:
https://about.gitlab.com/blog/2017/02/01/gitlab-dot-com-database-incident/
Пока бигдатовцы боролись со спамером, они умудрились ушатать данные пользователей за целый день, и потом еще день восстанавливали ее из бэкапа. Тест на доступность успешно провален. Это еще ладно — а я слышал истории о том, что у сервиса бэкапы-то есть, но восстанавливать их придется несколько недель. Так что отказ на день — это еще вполне себе High Availability по нынешним меркам.

Да, какой-нибудь яндекс регулярно устраивает тесты отказоустойчивости, вырубая датацентр. Однако, мне страшно подумать, что случится, если у яндекса внезапно вырубится более половины датацентров и отвалятся службы, опирающиеся на консенсус. Ихний кластер ClickHouse опирается в своей работе на (сюрприз) ZooKeeper. Отказ обезьянника (а он полностью отрубается при отказе половины узлов) приводит к переходу кластера в read-only. Сколько там еще служб отправится в read-only — мне было бы интересно узнать (давайте попросим роскомнадзор для проверки поблокировать датацентры яндекса).

Заметьте, что на серверах обычно SSD/HDD стоят в зеркале — чтобы, боже упаси, 24/7 сервис не умер из-за отказа одного из жестких дисков. И этому процессу впаривания говна нет конца, даже если завтра сделают устройства для передачи информации со сверхсветовой скоростью на спутанных квантовых состояниях и карманные петабайтные носители со средним периодом отказа в 2000 лет, то желающих хранить данные на локалхосте станет еще меньше и облачные сервисы будут выходить из строя по таймаутам при недопустимо больших задержках канала связи в 1 мс.

Потому, как ни странно, самое надежное «облако» — это то, которое стоит у вас в локальной сетке. Мало того, что облака могут в любой момент отвалиться — они еще и более несводобны, чем проприетарная софтина на локалхосте, как и предупреждал нас Штолман:
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html

Я вот что не пойму: я один это вижу? Ваши данные, которые не ваши, ваши приложения, которая не ваши, ваши высоконадежные высокодоступные SaaS, которые остаются таковыми до первого отказа (и тоже, в общем-то, не ваши). Или вы тут все зарабатываете на SaaS (как Шома), потому особо не вскрываете эту тему? А со мной не поделились — у-у-у, подлецы.

PS: сам участвовал в разработке SaaS, но поставляли также и коробку для внутреннего сервера.

★★★★

Последнее исправление: byko3y (всего исправлений: 1)

самое надежное «облако» — это то, которое стоит у вас в локальной сетке

хорошо что весь текст не стал читать (шутка), а последняя фраза обнадеживает, не хочу на галеру.

вот у нашего начальства пара раз приходила светлая мысль от своих серваков отказаться, но экономика там совсем другая, и за 10 серверов платить придется уже совсем по другому

Shulman
()

почему же до сих пор в школе не преподают основы построения распределенных систем

А преподавать-то кто будет? То-то и оно.

Nervous ★★★★★
()

почему же до сих пор в школе не преподают основы построения распределенных систем

Потому что один ЛОРовский графоман не понимает, что система образования в школе безвозвратно устарела.

fernandos ★★★
()

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

Никаких суверенных интернетов нет и не предвидится, даже в Китае он так себе суверенный. У регионалов конечно будет какая-то власть, но минимальная. И всё дело в экономии. Глобальные инвесторы посчитали, что проще и удобнее вложиться в десяток крупнейших разработчиков облаков и всё будет хранится и обрабатываться у них, причём более-менее надёжно, чем ждать, когда каждый узел сам как-то там обеспечит надёжность.

ixrws ★★★
()

«Дьявол начинается с пены у рта ангела»

В целом - я бы тоже за «облако под кроватью», чаще всего. Но вот тут мои подопечные/подэникеистые люди переезжают в другой офис и решили свою железную, подкроватную цифровую АТС поменять на виртуально-облачную АТС - так мне кажется, что это вполне логично. Удобно. Быстро. Не завязано на провайдера IP-телефонии.

Toxo2 ★★★★
()

Облако под кроватью с точки зрения пользователя - такое же удаленое облако с доступом по инету. Только ещё и железо самому чинить…

WindowsXP ★★
()

Живёшь, вроде всё норм

@

У роскомпозора бешенство, начинает бросаться на всех

@

«АХАХАХАХАХПХХХАХАХВХХАВХА ЗАЧЕМ КУПИЛ ЕСЛИ ЗАБЛОКИРУЮТ?»

LikeABoss
()
Последнее исправление: LikeABoss (всего исправлений: 1)
Ответ на: комментарий от fernandos

почему же до сих пор в школе не преподают основы построения распределенных систем

Потому что один ЛОРовский графоман не понимает, что система образования в школе безвозвратно устарела

На самом деле это была ирония: чем ответственнее задача, тем выше шанс, что выполнять ее будет полный дебил. То есть, либо эффективный манагер, который просто разводит работодателя на даллары, либо вахтер, которому очень хочется значить. Примерно то же, на самом деле, относится и к системе образования. Как говорил нам когда-то преподаватель по математике в институте «учитесь хорошо, а то будете работать преподавателем».

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

На самом деле это была ирония: чем ответственнее задача, тем выше шанс, что выполнять ее будет полный дебил

Задача не такая ответственная, как вы можете подумать. Школьники в большинстве своём не особо сознательны. Вот если студентов учить построению распределенных систем, то задача уже ответственная. Хотя, опять же, система образования устарела.

fernandos ★★★
()
Ответ на: комментарий от Shulman

потому что не у каждого школьника остаются деньги на эту книгу

Скачал Martin Kleppmann «Designing Data-Intensive Applications. The Big Ideas Behind Reliable, Scalable and Maintainable Systems» O’Reilly (2017)

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от ixrws

Никаких суверенных интернетов нет и не предвидится, даже в Китае он так себе суверенный. У регионалов конечно будет какая-то власть, но минимальная. И всё дело в экономии. Глобальные инвесторы посчитали, что проще и удобнее вложиться в десяток крупнейших разработчиков облаков и всё будет хранится и обрабатываться у них, причём более-менее надёжно, чем ждать, когда каждый узел сам как-то там обеспечит надёжность

Пока что я вижу, что нынче уже каждый васян становится облачным провайдером, а «экономия» от этого подхода такая, что облачные провайдеры купаются в золоте (наверное, потому что так ловко помогают бизнесу цвести).

Я соглашусь только с одним — глобальные элиты вложились в разработку опенсорсного софта для датацентров. Теперь этого опенсорса для облаков развелось, как собак нерезанных, только и успевай лепить вместе да продавать. Системы уже давно не проектируются и не пишутся — он именно лепятся. Ну типа вот у нас есть новый проект, как мы будем его реализовать? Возьмем редис, кролика, монгу, постгрес, memcached — это уже no-brainer, архитектура ясна раньше, чем допит утренний кофе. Как говорится «если в руках только молоток — то вокруг видятся одни гвозди».

byko3y ★★★★
() автор топика
Ответ на: комментарий от Toxo2

Но вот тут мои подопечные/подэникеистые люди переезжают в другой офис и решили свою железную, подкроватную цифровую АТС поменять на виртуально-облачную АТС - так мне кажется, что это вполне логично

Проблема связи заключается в том, что ее фокус находится за пределами офиса, там, где много-премного абонентов. Ты даже при желании не можешь звонить по телефону так, чтобы твои переговоры не прослушивали.

byko3y ★★★★
() автор топика

Всё так, люди которые не разбираются в технологиях думают что они смогут сэкономить не учитывая неочевидные риски.

BLOBster ★★★
()
Ответ на: комментарий от fernandos

Задача не такая ответственная, как вы можете подумать. Школьники в большинстве своём не особо сознательны. Вот если студентов учить построению распределенных систем, то задача уже ответственная. Хотя, опять же, система образования устарела

Ладно, мне кажется, что ты не осознаешь, насколько всё плохо, потому поясню. Многопоточная, многозадачная, и распределенная системы — НЕДЕТЕРМИНИРОВАНЫ. То есть, у них есть очень большое отличие от машины Тьюринга, которую ты запустишь сто раз и сто раз получишь тот же результат. Теоретически невозможно построить детерминированную систему консенсуса на асинхронных ненадежных каналах связи:
https://en.wikipedia.org/wiki/Consensus_(computer_science)#The_FLP_impossibil...

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

Потому недетерминированность не значит невозможность, но это значит, что понимать алгоритм работы системы крайне сложно. Какой-нибудь десяток шагов, будучи перемешанными в произвольной последовательности благодаря асинхронности, дают порядка 10! (факториал десяти) комбинаций последовательностей выполнения. То есть, сложность понимания улетает туземун очень и очень быстро.

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

Теперь ты понимаешь, почему я написал «реализовывать распределенные системы и БД в частности на планете умеет человек двадцать, и скорее всего они работают не у вас»?

byko3y ★★★★
() автор топика
Ответ на: комментарий от BLOBster

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

Сэкономить? Поднимите руку, кто сэкономил на облаках?

byko3y ★★★★
() автор топика
Ответ на: комментарий от Morin

А что я должен понять, что человек хочет поговорить, а не работать? Ну возможно и так. Но я о людях хорошего мнения, плохое они сами о себе скажут.

ixrws ★★★
()
Ответ на: комментарий от ixrws

А что я должен понять, что человек хочет поговорить, а не работать? Ну возможно и так. Но я о людях хорошего мнения, плохое они сами о себе скажут

Вы про меня, что ли? Я ищу работу, если чо. Говно ковырять вилкой мне не интересно, кредит отдавать мне не нужно. Как раз закончил прототип многозадачности для питона на разделяемой памяти, на днях думаю релизнуть сорцы.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

В целом да, но насчёт васянов не соглашусь. Во всех средних и крупных проектах, в которых приходится участвовать - используется либо amazon, либо google, либо ms, либо для снижения рисков смесь этих провайдеров. Там конечно могут быть и ораклы с ibm, но их среди масс куда меньше. Васянские облака не в почёте, найти для них devopsов(которых теперь в комманде чуть меньше, чем программистов) сложнее и дороже, а результат непредсказуем. Плюс часто для стартапов, для средних проектов и для крупных инвесторских проектов амазоны, гуглы и ms дают либо скидки либо льготный период либо ещё какие-то варианты. Типо как первая доза героина бесплатна. Ну и васянские облака не умеют в региональные отделения и всякие там договорённости с операторами.

ixrws ★★★
()
Ответ на: комментарий от byko3y

Ну типо того:) Просто темы очень простынные, вроде бы и так должно быть всё понятно учитывая опыт работы. Ну и обычно когда пашут, нет времени так длинно писать, пишут короче:) Да и почему сразу кредит? Дети например могут быть, а они мотиватор по круче кредита. Да и вообще, жить на что-то надо всегда. Даже при скромных запросах, если жить нормально, накопления быстро заканчиваюся, мы же не из рода скруджмакдаков.

В целом это норм, если бы лор состоял из одних только работяг, то топиков вообще бы не было:)

ixrws ★★★
()
Последнее исправление: ixrws (всего исправлений: 1)
Ответ на: комментарий от ixrws

Во всех средних и крупных проектах, в которых приходится участвовать - используется либо amazon, либо google, либо ms, либо для снижения рисков смесь этих провайдеров. Там конечно могут быть и ораклы с ibm, но их среди масс куда меньше

Ты, судя по всему, в чем-то таком облачном участвовал — поясни мне, нахера оно надо, какие преимущества дает, что вы с ними можете сделать и не можете без них? Организовать файлопомойку, БД, запустить логику на node.js на нескольких серверах? Меня удивила фраза «Васянские облака не в почёте, найти для них devopsов» — то есть, облака типа еще и нужно уметь админить? Это что за прикол? Как по мне — это что-то уровня «админ калькулятора», учитывая то, что за тебя вся инфраструктура уже развернута и администрируется.

byko3y ★★★★
() автор топика
Ответ на: комментарий от ixrws

В целом это норм, если бы лор состоял из одних только работяг, то топиков вообще бы не было:)

Господь тебе дал свободное от охоты на мамонтов время, чтобы ты творил, чтобы царапал рисунки на стенах пещеры, и просто осмыслял мир. Труд не сделал из обезьяны человека — труд сделал из человека корову.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от byko3y

А кто сказал преимущества? Ну первое реальное преимущество(а может и последнее), что я знаю и с чем сталкивались - проект получил сильно льготные условия для размещения в aws. Его выбили инвесторы по какой-то программе, так глубоко в шоубизнес я не проникал, у меня отчество не Борисович, а фамилия не Шаломов, поэтому не знаю как получают такие льготы. Но по сути, где-то год проект не достигая определённой нагрузки, пользовался aws почти бесплатно.

Ну а дальше не то чтобы преимущества, а целый ад и израиль:) Система состоит из сервисов(которые почему-то зовут микросервисами, но настоящие(то есть микро, потому что пишут то микро, то жирнющие сервисы с мегатоннами логики и простынями) микросервисы писать никто не умеет, поэтому пишут сервисы по стилю всё это напоминает старую добрую CORBA, но на nodejs и kafka. Каждый сервис в своём контейнере, сервисов штук 200-300. Каждый деплоится отдельно, для поддержания работоспособности всего этого нужно хотя бы 3х девопсов фултайм, потому что кто-то может заболеть и вообще работы ручной там вагон. И там не то что админить, devops он всё это дело программирует, то есть он полноценный член комманды, занимающийся написанием кода для инфраструктуры. Тут работает простое правило - чем больше сущностей, тем больше работы. Помимо того, что из-за количества сущностей это бешеный ад с точки зрения развёртывания, так это ещё ад с точки зрения разработки, потому что поднять весь этот рой сервисов локально для разработки - та ещё задачка и отнимает слишком много времени. Поэтому добро пожаловать в https://www.telepresence.io/ .

Стоит ли оно того? Ну теоретически, если комманда и правда из хороших кадров, разбитие среднего проекта на скажем не 300, а 10-20 сервисов, которые могут иметь множество инстансев и согласованно работать с базами - даст возможность держать очень высокую нагрузку. Но так работают издревле все высоконагруженные проекты задолго до моды микросервисов. А вот если сервисов у среднего проекта 300 и более, то факапов будет дохрена, а выхлопа мало. Потому что слишком много сущностей, наверняка один, два или десять сервисов вообще не будут уметь работать согласованно с базой в количестве 10 или 20 экземпляров. Вплоть до забивания базы говнов или просто отказа в обслуживании из-за гонок.

На практике, если комманда и правда из хороших кадров, то грамотное профилирование среднего или крупного проекта, затем выделение узких мест и переписывание их в зависимости от условий нужным образом(где-то может просто надо код php переписать на С, а базу поменять скажем на oracle, а где-то код выделить в сервисы и заставить работать нужное количество экземпляров сервисов в зависимости от нагрузки) - решит все проблемы. При этом и разработка будет удобной, и аренда обычных серверов будет дешевле обходится и обслуживать удастся больше клиентов в минуту. Иными словами ничего нового не придумали за последние лет 30.

ixrws ★★★
()
Последнее исправление: ixrws (всего исправлений: 1)
Ответ на: комментарий от ixrws

Ещё забыл добавить, что разные сервисы будут написаны разными людьми и даже несмотря на code review, на практике они будут иметь совершенно разные стили кодирования и разные подходы к реализации одних и тех же вещей. Надо ли говорить насколько сложно погружаться новичкам в это болото? Linux, ядро я имею ввиду, куда проще оказывается, как бы это не казалось смешно:)

ixrws ★★★
()

Я вот что не пойму: я один это вижу?

да

olelookoe ★★★
()
Ответ на: комментарий от ixrws

Ну первое реальное преимущество(а может и последнее), что я знаю и с чем сталкивались - проект получил сильно льготные условия для размещения в aws

Ну это вообще не преимущество, как ты правильно заметил.

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от ixrws

Ещё забыл добавить, что разные сервисы будут написаны разными людьми и даже несмотря на code review, на практике они будут иметь совершенно разные стили кодирования и разные подходы к реализации одних и тех же вещей. Надо ли говорить насколько сложно погружаться новичкам в это болото? Linux, ядро я имею ввиду, куда проще оказывается, как бы это не казалось смешно

Мой опыт ныряния в болота говорит, что код на сотню тысяч строк может вынести мозги повеселее, чем ядро линя. Потому что средний индус в вакууме вообще не парится качеством своего кода, а в ядро хреновый код не примут.

byko3y ★★★★
() автор топика

Так почему же люди покупают Office 365 и Dynamics 365 при том, что есть полностью оффлайн альтернативы?

Ну-ну. Давай, расскажи мне про альтернативы.

Если серьезно, то своя инсталляция чего-то подобного это деньги.

Для маленьких и средних компаний не выгодно, а зачастую невозможно, вложиться заранее в свой парк оборудования, чтоб потом на этом жить несколько лет. Банально нет свободных денег для этого. Кроме того велики финансовые риски в случае ошибки, поэтому хорошие техдиры стоят дорого. С большими компаниями сложнее: они могут себе позволить вложится в долгую, да и подушка по деньгам у них обычно больше.

Поэтому весь мир переходит на что-то, за что можно платить ежемесячно и за человека, а не за хост. Так бухгалтерия сходится, риски падают, хотя стоимость, конечно, растет (хотя и не так значительно).

Беда в том, что в РФ компании тоже хотят быть современными, учитывая нашу законодательную специфику, то даже ещё больше хотят, чем на западе. Но у нас специфическая страна, поэтому все очень плохо.

zloelamo ★★★★
()
Последнее исправление: zloelamo (всего исправлений: 1)

самое надежное «облако» — это то, которое стоит у вас в локальной сетке.

Да, но... менеджер понимает что такое решение должен поддерживать эникейщик, которому постоянно придется платить $3000 в месяц иначе этот эникейщик уйдет к другому продавцу картриджей для принтеров. И, чтобы сэкономить на эникейщике, тем самым доставить себе менеджеру больше блекджеков, и переводят на облачную бигдату. Головная боль по ее поддержанию стоит дешевле «выделенного» эникея

Karapuz ★★★★★
()
Ответ на: комментарий от byko3y

Все проблемы возникли только из-за архитектуры и плохого подбора кадров.

Мне нравится это твоё «только». Типа давайте обсудим преимущества только отбросим те преимущества, которые не интересны.

Архитектура и подбор кадров - это по твоему ничего не стоит?

Тот же найм админа для поддержки почтового сервера в непрофильную организацию - это очень большая головная боль для любого малого-среднего бизнеса. У нанимающих нет понимания по каким критериям оценивать работу сотрудника, а у нанявшегося нет никаких возможностей к развитию и росту, полная деградация и риск нарваться на erzent-а с его «закладками».

И твои разглагольствования по поводу отказоустойчивости на случай ядерной войны вообще не применимы к ситуациям когда надо сначала обеспечить отказоустойчивость на случай гораздо более вероятного запоя сотрудника.

alpha ★★★★★
()

Я вот что не пойму: я один это вижу?

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

zemidius
()
Ответ на: удаленный комментарий

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

Однако же, школа в Новосибирске не развалится от того, что в Нью Джерси упал датацентр. А вот современные «надежные» компьютерные системы — вполне.

byko3y ★★★★
() автор топика

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

theurs ★★
()
Ответ на: комментарий от zloelamo

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

Какой еще «парк»? Нельзя проложить локалку и кинуть в кладовку сервак? Или купить сервак у локального провайдера? Тоже помесячно. Зачем облако?

byko3y ★★★★
() автор топика
Ответ на: комментарий от zgen

Так развалится же, её ровно так же разбомбят и физически и технически без всяких нью-джерси

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

купить сервак у локального провайдера

Это уже движение в сторону облаков. Только подкровать, только хардкор.

Nervous ★★★★★
()
Ответ на: комментарий от byko3y

А, ну ок если под бомбёжками и в раскуроченной школе не так страшно, то уж тем более какой-то там облачный офис тебе не нужен. Не понимаю тогда о чём переживания. Перо, свеча, пергамент - вперед.

zgen ★★★★★
()
Последнее исправление: zgen (всего исправлений: 1)
Ответ на: комментарий от Nervous

Только подкровать, только хардкор.

только localhost только хардкор

zgen ★★★★★
()
Ответ на: комментарий от Karapuz

Да, но... менеджер понимает что такое решение должен поддерживать эникейщик, которому постоянно придется платить $3000 в месяц иначе этот эникейщик уйдет к другому продавцу картриджей для принтеров. И, чтобы сэкономить на эникейщике, тем самым доставить себе менеджеру больше блекджеков, и переводят на облачную бигдату. Головная боль по ее поддержанию стоит дешевле «выделенного» эникея

У нас нормальная практика — это совмещать админство с другими обязанностями. Конечно, если требования совсем несерьезные, то можно и через gmail с телеграмом всю работу в компании вести. Помню, пришел по одному вопросу в страховую, а мне посоветовали обратиться в их чат Viber — какого хера, спрашивается, я должен идти не на их сайт, и даже не писать на корпоративную почту, а писать в какую-то вайберовую помойку? Не хватало еще, как в shareware, регулярных сообщений плана «вы используете пробную версию Viber, для продолжения работы нажмите кнопку „2“ Это совсем несерьезно, но это работает. Но как только серьезность отрывается от уровня плинтуса — это всё уже не прокатывает.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Это совсем несерьезно, но это работает

Суть. Тред можно закрывать как решенный %)

Nervous ★★★★★
()
Ответ на: комментарий от byko3y

и даже не писать на корпоративную почту

Вот кстати, давно любопытно: если «корпоративная почта» это тупо домен на Яндексе, то для определения уровня плинтуса кому-нибудь приходит в голову посмотреть MX запись крутая-страховая.рф? И от результата определять крутость?

Toxo2 ★★★★
()
Ответ на: комментарий от alpha

Архитектура и подбор кадров - это по твоему ничего не стоит?

Это 50% успеха, конечно же. Остальная половина — это продать кому-то эту хрень.

Тот же найм админа для поддержки почтового сервера в непрофильную организацию - это очень большая головная боль для любого малого-среднего бизнеса

Я сейчас попытался вспомнить, какая «непрофильная» организация поблизости нанимает админа почтового сервера. Ну типа разных провайдеров почтовых серваков — пруд-пруди, ставить сервак еще и локально в организации сомнительная затея. Особенно если учесть, что почта — это таки инструмент связи, а не внутрикорпоративный инструмент.

риск нарваться на erzent-а с его «закладками»

Пардон, я не в курсе, что за erzent и какие у него закладки.

И твои разглагольствования по поводу отказоустойчивости на случай ядерной войны вообще не применимы к ситуациям когда надо сначала обеспечить отказоустойчивость на случай гораздо более вероятного запоя сотрудника

И твои разглагольствования по поводу отказоустойчивости на случай ядерной войны вообще не применимы к ситуациям когда надо сначала обеспечить отказоустойчивость на случай гораздо более вероятного запоя сотрудника

Так я не спорю, что в большинстве случаев это всё несерьезно, и бизнес с таким же успехом будет работать на shareware или крякнутой софтине с руткитом.

byko3y ★★★★
() автор топика
Ответ на: комментарий от theurs

Тот же аналог битрикса наваять самостоятельно, поди найди таких специалистов

Я боюсь, что битрикс — это весьма низкая планка. Да, универсальную софтину написать довольно тяжело, но склепать под конкретную задачу на XAF «какую-то» поделку может и студень за бутылку водки.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Пардон, я не в курсе, что за erzent и какие у него закладки.

Был тут. Вечно обиженный на hr недоадмин с низкой квалификацией (типа @Shulman) из Питера, но большими запросами, все его обижали и увольняли и он оставлял таймбомбы и активировал закладки в серверах, о чем тут и писал под несколькими аккаунтами.

zemidius
()
Последнее исправление: zemidius (всего исправлений: 1)
Ответ на: комментарий от Toxo2

Вот кстати, давно любопытно: если «корпоративная почта» это тупо домен на Яндексе, то для определения уровня плинтуса кому-нибудь приходит в голову посмотреть MX запись крутая-страховая.рф? И от результата определять крутость?

Вы все-таки продолжаете апеллировать к почте, хотя это средство связи и на нем компьютерные системы не заканчиваются. Для средства связи положительное свойство — это общепринятость. Телефон > электропочта > Viber > нонейм месенжер.

byko3y ★★★★
() автор топика
Ответ на: комментарий от ixrws

дядь, я вот пришел на работу с утра, сантехник я, говно прочищаю, а щас вот обед сижу читаю таких умных людей как ты и не понимаю. Завтра позвонят и скажут отрубить провайдерам всем инет. Это что сейчас не суверенный интернет?Облаки впны ваши, куда? как? это будет работать?

Neresar ★★
()
Ответ на: комментарий от byko3y

Вы все-таки продолжаете апеллировать

Мне правда интересно. Просто думу думаю.

Когда-то давно я ужас-как-расстроился, когда выяснилось, что форумы в инетрнетах - это не программисты пишут, а тупо готовые CMS люди пользуют.

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

Отчего так программисты на МетаПрог нервничают? Это же следующее звено в той же цепи. Вполне логично, что и программы люди сами будут писать рано или поздно.

Toxo2 ★★★★
()
Ответ на: комментарий от Neresar

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

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

NAY_GIGGER
()
Последнее исправление: NAY_GIGGER (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.