Почему мы перестали держать свои серверы и начали арендовать чужое «железо»

Многие считают, что держать свои серверы выгодней, дешевле и надежней. Но в каждом правиле есть исключения. И сегодня я расскажу вам о том, когда это правило не работает.

Меня зовут Алексей Тарасов, я директор компании ООО «Тендерлэнд», которая вот уже как 11 лет занимается разработками программного обеспечения для участников размещения государственных и коммерческих заказов. Проще говоря, тендерных агрегаторов и сервисов для компаний, которые участвуют в тендерах. Такая деятельность требует серьёзной IT-инфраструктуры. Мы работаем с большими базами данных, различными микросервисами, пользовательскими файлами, ведем бэкенд-разработки.

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

А затем проект стал расти. И довольно стремительно. Появились новые технологии, а с ними — и новые требования к проекту. От инфраструктуры, которую мы создали на первых порах, потребовалась гибкость, которой не было. И мы столкнулись с целым рядом проблем.

Новая конфигурация — и быстро!

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

Варианта всего два — либо надо внести изменения в существующую конфигурацию, что часто невозможно, либо отказываться от сервера и покупать новый…

Помню, собирали мы как-то сервер для работы с MySQL с максимальным объёмом оперативной памяти — 256 Гб. Под него, естественно, своя материнская плата, процессор соответствующий. А потом так вышло, что нужно было срочно переходить на поисковый движок Elasticsearch, который, к слову, сделан на Java. А Java больше 32 Гб «прожевать» не может. И это ещё не всё. Когда ты строишь отказоустойчивый кластер, то обязательно должен подумать о дублировании данных, их репликации. Это значит, что у тебя обязательно должен быть парк полностью одинаковых по конфигурации машин. И получается, что вместо одного сервера с оперативкой 256 Гб, тебе уже нужно, скажем, шесть серверов с памятью по 32 Гб. Плюс на каждом — мощный процессор и SSD-диски для быстродействия.

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

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

Объявление на vc.ru Отключить рекламу
Транспорт
Фуры и бензин: как российский бизнес учился контролировать водителей и расход топлива
Представьте: вы заказали диван, а вам его не доставили. Все потому, что водителя не узнали на заправке и отказались…

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

Админ — тоже человек

Вторая проблема, с которой мы столкнулись в это время, — выросшие затраты на содержание и обслуживание растущего парка серверов. Чем больше у тебя машин, тем чаще они требуют внимания. Сгорел блок питания? Надо заменить. Истёк срок эксплуатации диска? Надо докупить. Вместе с ростом машин выросло и количество системных администраторов. А хорошие специалисты стоят дорого. Кроме того, они иногда болеют, уходят в отпуск или женятся. Да и человеческий фактор никто не отменял. Админы тоже люди — если работать без перерывов много часов, любой начнет ошибаться. Так, например, однажды нам довольно долго пришлось восстанавливать критичные данные с поврежденного харда — специалист ошибся и неверно настроил рэйд.

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

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

Плюсы перехода на арендованные серверы

Так, помучившись какое-то время, мы пришли к тому, что арендовать чужие серверы в нашем случае будет гораздо выгоднее во всех смыслах. Хостинг-провайдера выбирали, в основном, по цене и отзывам. Из нескольких вариантов остановились на FirstDEDIC. Кроме основных параметров, на которые мы ориентировались, в их пользу говорили ещё два факта — дата-центр уровня надежности Tier III и наличие второго проекта FirstVDS, где мы могли арендовать и виртуальные серверы. Собственно, с них мы и начали.

Заказали несколько виртуальных серверов, нагружали, проверяли, тестировали. Разместили там несколько простеньких проектов. Постепенно стали переносить свои проекты и на выделенные серверы. И надо сказать, что такой переход со своего «железа» на арендованное здорово облегчил нам жизнь. Собственно, к чему мы пришли в итоге.

Во-первых, снизились расходы на строительство и обслуживание инфраструктуры. Конкретные цифры раскрывать по понятным причинам не могу, но примерно процентов на 15%. Арендовать у провайдера выходит ненамного дороже, чем если бы мы покупали и амортизировали сами. Это мы уже проходили, так что точно знаем, в какую копейку это «влетает». Кроме того, все задачи по обслуживанию парка — теперь не наша проблема. За исправностью оборудования следят специалисты хостинг-провайдера, которые работают посменно. И даже если кто-то уходит в отпуск и болеет, на нас это не отражается никак.

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

В-третьих, у нас появилась возможность относительно безболезненно экспериментировать с конфигурациями. Например, я уже упоминал про поисковый движок Elasticsearch. Когда мы переносили сюда все проекты, выбрали под его размещение конфигурацию попроще на SSD SATA, понаблюдали, замерили показатели, решили перенести на серверы с SSD NVMe и получили существенный прирост скорости работы.

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

И наконец, отдельно хотелось бы сказать про VDS. У нас очень много разнообразных микросервисов. Для них мы используем виртуальные машины второго проекта того же провайдера. На них много что крутится. И это получается намного дешевле, чем облачная инфраструктура. Мы сравнивали по цене с Яндексом или Амазоном. По цене выгоднее с виртуалками, а по удобству практически то же самое. Я могу создать виртуальную машину, настроить ресурсы, как мне нужно, протестировать, а потом заказать ещё одну или несколько с такими же параметрами. По надёжности тоже не уступает. У провайдера есть тариф Атлант, облачные VDS с дублированием оборудования. Мы их используем под проекты, критичные к даунтайму.

Что в итоге

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

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

{ "author_name": "FirstVDS / FirstDEDIC", "author_type": "self", "tags": ["\u043e\u043f\u044b\u0442\u043a\u043b\u0438\u0435\u043d\u0442\u0430","\u043a\u0435\u0439\u0441_firstvds_1dedic","\u043a\u0435\u0439\u0441","\u0431\u0438\u0437\u043d\u0435\u0441\u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b","technology","it_\u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430","it","1dedic"], "comments": 75, "likes": 13, "favorites": 44, "is_advertisement": false, "subsite_label": "services", "id": 180763, "is_wide": false, "is_ugc": true, "date": "Thu, 26 Nov 2020 11:57:59 +0300", "is_special": false }
Объявление на vc.ru Отключить рекламу
Маркетинг
Как создать ценностное предложение в b2b и привлечь покупателей. Принципы, методы, инструменты
Как продвигать сложные продукты с длинными циклами сделки, такие как, например, ИТ-платформы, консалтинговые услуги…
0
75 комментариев
Популярные
По порядку
Написать комментарий...
29

Если у хостера возникнут разногласия с партнерами или собственниками помещения, где расположено оборудование, то принадлежащее ему оборудование может быть изъято в качестве залога (обеспечения). Прецеденты в РФ были. В итоге, моментальная потеря всех данных и усилий потраченных на настройку ПО. Это серьезный риск для IT-компании арендующей чужое железо.

Ответить
10

В посте конечно про это не скажут, ведь не надо ругать слона.

Ответить
5

по такой логике надо и свой ДЦ, и своих поставщиков электроэнергии, интернета и т.д.
мало ли что там где не прописано и какие прецеденты в РФ могут случиться

Ответить
0

по такой логике надо

- у всех своя логика, я писал о том что есть риски использования чужого оборудования и их надо учитывать. Если для Вас малейший риск ведет к  отказу от услуг ... значит так. Кстати я далеко не все риски перечислил)

Ответить
0

я, если что, намекнул так на перегибы вашей логики)

Ответить
0

если что, намекнул так на перегибы вашей логики

- еще раз, я отметил один из рисков, а выводы Вы сделали сами на основе собственной логики. Если что)

Ответить
0

Вы отметили это как "серьезный риск", т.е. тут не нужно делать выводы, а прямая трактовка, если что)
Но это не серьезный риск, вы перегибаете, я об этом.

Ответить
0

это не серьезный риск, вы перегибаете

Ничего я не "перегибаю". Просто напомню:

Ответить
0

еще 10-15 случаев назовете, чтобы это воспринималось серьезным риском?
я только 2-3 нагуглил.

Ответить
0

еще 10-15 случаев назовете, чтобы это воспринималось серьезным риском?

- серьезность не в частоте, а в последствиях. Мне не надо 10-15 пострадавших от бутылок выброшенных с верхних этажей дома, чтобы не ходить под стенами многоквартирного дома - достаточно того что я о таких случаях слышал. Вероятность события мала, но последствия катастрофичны.

Ответить
0

точно такая же вероятность катастрофичных последствий, если у вас будет свое железо:) такой же "серьезный риск"

Ответить
0

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

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

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

P.S. если Вы хотите лично меня убедить в том что я не прав, то мне не совсем понятно к чему прилагать такие усилия? Может дело в том что Вы зарегались 26 ноября 2020 чтобы специально пообщаться со мной? Тогда я польщен)

Ответить
1

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

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

Ответить
0

вам, судя по количеству ваших сообщений повсюду - либо тоже скучно

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

либо принципиально))

- обычно когда кого то в чем то обвиняют, это и есть проблема самого обвинителя. Вижу с момента регистрации Вы уже написали 6 комментов и все адресованы лично мне. Как уже писал выше - польщен.

Ответить
1

ага, и остальные свыше тыщи комментов под другими статьями это тоже сугубо из-за того, что личный опыт настолько жег карман, что вы в него не стали лезть за словом))

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

Я в целом ни в чем никого не обвинял, просто зацепила активность ваших комментов, вы только в этом посте оставили их более 20. Лично у меня, как говорится, вопросов ни к кому нет, но имеется ряд доёбок) аккаунт специально новый)

Ответить
0

остальные свыше тыщи комментов под другими статьями это тоже сугубо из-за того, что личный опыт настолько жег карман, что вы в него не стали лезть за словом))

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

вы точно так же описали позицию однобоко

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

зацепила активность ваших комментов, вы только в этом посте оставили их более 20

- я написал нейтральный пост и не понимаю (на самом деле понимаю) откуда набежали свежезарегистрированные пользователи которые пожелали мне оппонировать

настолько ли они критичны?

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

Ответить
2

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

Ответить
4

оборудование полностью принадлежит нам

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

мы делаем все, чтобы таких проблем не возникло

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

Один из двух дата-центров тоже наш полностью

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

эта ситуация вполне может коснуться и тех, кто не арендует, а использует свое “железо”

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

например, арендует под него помещение

- это как во "втором" дата центре?

Ответить
0

- покажите где у вас "оказалось" что это группа лиц с неясно описанными отношениями?
-клиенты видят где размещаются их серверы
-по поводу "за язык не тянут" - какой вопрос такой и ответ. Конкретизируйте опасения. 

Ответить
7

1. Ты кто? Разве я Вас о чем то спрашивал? Вы зареганы 24 сен 2020 ради этого коммента? Специалист по рекламе, который не перелогинился?

2:
покажите где у вас "оказалось" что это группа лиц с неясно описанными отношениями?

- когда приобретаете колокейшн или виртуалки Вы реально точно знаете кто владельцы хостинга и какие у них обязательства друг перед другом и перед кредиторами?

клиенты видят где размещаются их серверы

- меня несколько раз ставили перед фактом что мои сервера переезжают в другой ДЦ. Но Ваша уверенность в том что мир устроен так как Вам представляется - поражает

по поводу "за язык не тянут" - какой вопрос такой и ответ.

- еще раз, я Вас ни о чем не спрашивал. Но если Вы хотите представиться и уточнить какое отношение Вы имеете к статье или к "FirstVDS", который тоже довольно неожиданно (хм-хм) стал отвечать в статье написанной от имени клиента, буду только рад. Сочту это за вежливость.

Конкретизируйте опасения

- все описал в первом посте, но если хотите могу еще накидать, благо объем знаний на тему хостеров и их отношений с клиентами у меня достаточный

Ответить
1

А какой ДЦ посоветуете больше? В Химках или на Алтушке?

Ответить
1

Бекапы спасут данные, распределенная балансированная система спасет от перебоев. Свое оборудование в чужом ДЦ это дорого, держать резервное железо еще дороже, обновлять железки больно, горячий ремонт никто не выполнит.  Придумывать опасения нет нужды.

Ответить
0

Придумывать опасения нет нужды

- SLA своего хостера перечитайте, там тоже ни одна проблема не описана

Ответить
1

Конечно никто не напишет про проблемы в отношениях собственника (собственников) в соглашении. А про что можно даже при таком сценарии внезапно не потерять все данные вы почему-то не пишите. Бекап это вроде не сложно. 

Ответить
0

Бекап это вроде не сложно.

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

в соглашении

- самый интересный пункт это компенсации при потере данных и простое, ознакомьтесь

Ответить
0

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

В соглашении внезапно описан порядок рассмотрения претензий, вот не поленился, нашел и прочитал. Что там не так? 

Ответить
1

бэкапить все немного дешевле

- куда бэкапить то собрались?

не поленился, нашел и прочитал. Что там не так?

- как "там" где Вы прочитали без понятия, Вы какого то конкретного хостера имели в виду? Вроде статья не про кого то определенного. Я этого не хотел, но если на примере FirstVDS который в теме отметился (анлогичные SLA у всех), то:

"невозможности использования сервера Абонентом более 2 минут в сутки, подтверждённой данными системы мониторинга Провайдера"  - это значит что внешние независимые системы мониторинга не прокатят (чтобы флуд не разводить сразу пример: провайдер с маршрутами косякнул, изнутри его ДЦ все норм, снаружи Ваши сервера не доступны)

"по заявлению Абонента" - это значит, что если простой не заметили, то его и не было

"Провайдер производит перерасчёт, согласно которому услуги в течение данных суток предоставляются Абоненту бесплатно"
- это значит что за сутки простоя компенсация в размере не более двух суток бесплатного хостинга

- ну и потери данных, плановые (значит с оповещением) работы, обстоятельства непреодолимой силы (типа враги кабель рубанули), жалобы через 3 дня после инцидента. Это все в /dev/null

Ответить
0

Бекапить на сервер(а) другого или других хостеров, чтобы минимизировать влияние всякого внезапного, вроде и так логично, если я правильно понял у вас богатый опыт, не думаю что нужны дополнительные объяснения.
Вы же сказали своего, вот пошел на сайт своего хостера и прочитал условия:) И ещё на пару зашел, особых отличий не увидел. В ваших цитатах ничего страшного не вижу, все стандартно. Если есть пример соглашения получше на колокейшен, то я бы с удовольствием почитал.
Хотите отказоустойчивую систему - стройте, для этого есть все возможности и не только на своем железе.

Ответить
0

Бекапить на сервер(а) другого или других хостеров,

- ну вот и нарисовались доп расходы

ничего страшного не вижу, все стандартно

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

Ответить
0

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

Ответить
0

Про доп расходы ну ведь не серьезно же

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

Может есть примеры, как сделать хорошо и правильно?

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

Ответить
1

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

Ответить
0

Бэкапиться надо от и до. Тогда не так критично будет

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

Ответить
0

а еще могут возникнуть разные разногласия преразные. типа такого 
https://www.kommersant.ru/doc/805282

Ответить
0

Интересно. Там кстати история похожая, разногласия между совладельцами: "было внеочередное собрание акционеров, после которого 50% компании отошли новому гендиректору"

Ответить
0

подчеркну только там было разногласие не у хостера а у арендаторов между собой. и одна половина конфликта пришла к хостеру и потребовала выдать им физический доступ к серверам чтобы сменить пароли и захватить их.

Ответить
0

там было разногласие не у хостера а у арендаторов между собой

- я понял, просто это основная причина многих фейлов: конфликт собственников

Ответить
1

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

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

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

Ответить
0

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

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

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

в случае любого конфликта все вот такое арендованное и не ваше начинает играть на стороне того у кого там завязки.

Ответить
0

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

- с остальным согласен, а вот с этим нет: как раз в IT сделать клон web-проекта не сложно. Но в данном случае еще и авторские права замешаны.

Ответить
0

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

Ответить
8

А если взять сервер в 256гб и порезать на 5-6 виртуалок по 32гб?

Ответить
4

Тоже самое хотел написать, не говоря о том, что тот же эластик можно запустить в докере, настроив ограничение ресурсов.
P.S. Если пробегут джависты мимо, то увидим комментарий на счет 32Гб, точно видел решения на Java, которые и больше потребляли.

Ответить
3

А есть которые и на 1 Гб отлично живут.  Могу показать обработку 10 млн записей за два часа, начиная со скачивания гиговых архивов с CSV и до записи в базу + обновление индекса elasticsearch, причем он еще и embedded.
Bach идет в районе 5000 записей в секунду.

Все включая интерфейс потребляет в районе 1Гб в пике, без свопинга и тд.

Ответить
1

32Гб

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

Ответить
4

"Вроде бы простая смена технологий, а влечет за собой катастрофическую смену оборудования."
Ясен пень! Когда меняешь базу данных на поисковый движок может  потребоваться не только оборудование поменять, можно и сферу деятельности сменить. 

Ответить
3

Ну что же, жму руку! Вы, таки, заставили меня написать свой первый комментарий тут. И вот, что я хотел бы сказать:
1) теперь я никогда не воспользуюсь услугами вашей "хостинг" компании.
2) не торгуйтесь за качество текста на фриланс биржах, лучше было не мелочиться и заплатить больше 500 рублей но более грамотному автору за сочинение.
3) это не Яндекс.Дзен. Тут не сработает этот "ход" использования глупости и противоречий в авторском посте, дабы комментаторы подняли пост в топы и алгоритм подумал бы, что это интересно и стал прокачивать.
4) к вымышленному "клиенту" и иже с ним: лучше заплатить за консультацию немного денюшек, а не ставить MySQL обрабатывать big data.
5) 256Gb оперы.. Я вот, сходу, даже придумать не смог, чем её забить можно..
6) почему не использовать виртуализацию для деления 256Gb, как это те же хостеры делают, которым вы в любом случае переплачиваете? Да потому что вымышленный клиент не разбирается в технологиях.
7) вы так удивляетесь скорости работы SSD и NVM express SSD, хотя можно сперва прочитать разницу между ними, посмотреть тесты, бенчмарки, провести анализ.. О каком бизнесе идёт речь? Если вы не делаете банальных вещей при старте проекта и не продумываете наперёд последствия. А почему вы так же не удивляетесь, к примеру, дирижаблю и истребителю??
Короче, какой-то "Пупкин" узнал что "лучшим" продвижением компании являются авторские отзывы с линковкой, вот только автора выбрали неудачно.
Удачи Вам, о "чудо" хостинг в вашем нелёгком СЕО пути.

Ответить
3

Забавно читать выводы без аргументов) Почему клиент вымышленный? Сайт по ссылке открывается, есть отзывы, вакансии, даже ООО в сбисе гуглится. То, что клиент делает не так, как вы считаете правильным, тоже хостер виноват? Аргументов то нет. Писать отзыв не основанный на опыте под статьей клиента, даже с линковкой, немного странно. Наверное все были в сговоре, зарегистрировали ООО 11 лет назад, чтобы вас заставить комментарий написать)) Ох уж эти теории заговоров на пустом месте)

Ответить
0

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

Ответить
3

ППКС
свои сервера сегодня - неумно, невыгодно и неперспективно

Ответить
0

- фантазии и реальность:

Ответить
0

а мне нравится. во первых свои - потому что чужие хороши до поры до времени, например вот такой
https://www.kommersant.ru/doc/805282

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

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

Ответить
0

Не совсем понимаю какие могут быть недостатки в Вашем конкретном случае перехода на виртуальные сервера полностью? Просто переход на них - уже закрытие 80% указанных Вами проблем.

Ответить
4

Уверен?
У провайдера работают такие же админы, которые также могут ошибиться с настройкой RAID. Блок питания может сгореть из-за чего сервер также выйдет из строя. Про 256 Гб вообще какая-то ерунда, ставишь VmWare (или аналог подешевле) и получаешь россыпь виртуальных машин на реальном железе. Дальше ставится Докер чтобы упростить миграцию. Собственно то же самое делает и провайдер: за счёт расшаривания одного физического сервера на нескольких клиентов достигается та самая экономия.

Никаких преимуществ я не увидел. Могу высосать из пальца что компания ещё не доросла до админа и серверов, а игру во взрослых сочли дорогими понтами.

Ответить
–2

Не такие же. Там профи, а не студенты с закидонами. Там особые требования по безопасности и резервному копированию. Там тщательно продуманная, своевременно развиваемая инфраструктура и т.д.

Ответить
4

Там профи, а не студенты с закидонами

- хостеры тоже режут косты(

Там тщательно продуманная, своевременно развиваемая инфраструктура

Ответить
0

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

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

общие принципы вахтера как и везде в россии.

когда это свое и железо свое - работаешь 24 на 7 чтобы восстановить.

Ответить
0

И где вы только таких хостеров находите... В Мухосранске, что ли, Мухосрансктелеком? )) Юзайте нормальных хостеров, и будет вам счастие.

Ответить
0

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

Ответить
0

Ну так надо выбирать себе не говнохостеров, а проверенных и надежных.

Ответить
0

выбирать себе не говнохостеров

- зарплату сотрудников никто в клиентской оферте не пишет, а валуйхост я как первый попавшийся пример привел (таких примеров много, в том числе и в крупных компаниях, где на ЗП никто не жалуется - см пример по ссылке)

Ответить
0

 GitLab создана в 2014 году украинским предпринимателем Дмитрием Запорожцем

 Ну так надо выбирать себе не говнохостеров, а проверенных и надежных

Ответить
0

создана в 2014 году украинским предпринимателем

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

Ответить
2

Яндекс еще можно вспомнить, порубивший много виртуалок...

Ответить
1

это типа в идеальном сферическом провайдере админы сферические и идеальные?))

Ответить
0

Ой, ну нинада. Среднестатистический админ в среднестатистическом провайдере среднестатистически на порядок надежнее среднестатистического админа в среднестатистической говноконторе.

Ответить
0

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

Ответить
0

у нормальных серверов минимум 2 БП в горячем резерве, а если их еще и нормальный инженер подключал(ну или проектировал серверную) то они питаются от разных PDU, которые в свою очередь от разных ИБП, так что просто так блок питания у сервера вылететь не может, есличо

Ответить
1

колокол - сколько воспоминаний! выбор и покупка комплектующих, конфигурация дебиан, шум вентиляторов... эх...  

Ответить
1

Пишу бэк 7 лет и ни разу не работал с физическим сервером. До этого поста описанная проблема была для меня чем-то из середины нулевых. Зачем свой сервер...

Ответить
0

Недавнее падение Amazon Azure показало как надежно хранить данные на чужих серверах. Уронили один сервис пострадали все :)

Ответить
0

А на внутренних так не происходит?)

Ответить
0

абсолютно частный случай в виду специфики вашей работы. для большинства эти причины не актуальны.

Ответить

Комментарии

null