Pull to refresh
31
0
Сергей Краснов @realscorp

Operations team techlead

Send message

Рад слышать, что хотя бы подтверждён. Буду надеяться на исправление. Спасибо!

Это всё круто, и мне действительно очень нравится Vivaldi. Удобные вертикальные вкладки - киллерфича, я браузер рекомендую всем подряд.
Но когда ж вы почините баг с CTRL+TAB на MacOS? Багу около года. Пользователи, я в том числе, неоднократно создавали баг-репорт. Нашли способы воспроизвести, а разработчики будто нас не замечают.
Баг наверняка несложный в исправлении, а пользователям он ломает юзабилити.
Прям лучший бы подарок от вас на НГ многим пользователям был.

Очень круто. Приятно видеть всё новые применения eBPF.

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

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

Кора головного мозга возникла 500 млн. лет назад, а до этого 3.5 млрд. лет без неё как-то обходились.
Однако же теперь для как минимум одного заносчивого биологического вида она стала ключевой структурой.

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

Спрошу у VKCS, что они по этому поводу скажут, спасибо.

Невозможно потушить пожар, если ты работаешь в кратере действующего вулкана

Могу только ещё раз поздравить тебя с тем, что своё кольцо Саурона ты в этот кратер наконец выкинул :)

Согласен, средств объективного контроля нет. Можно замерять производительность и выкатывать претензии, если она не совпадает с SLA, но это сложно, и в продакшне - тем более.

Ну, мы сравнивали с учётом переподписки. Это было отдельной строкой в рабочей таблице и предполагаемые к закупке on-prem кластера считали именно с переподпиской, сравнивая с чистыми vCPU в облаке. Плюс VKCS обещает 100% времени HT-ядра. Не знаю, насколько это правда, но по тестам производительности всё было достаточно стабильно и нас в итоге устроило.

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

Один админ совершенно точно не справляется с сотней виртуалок при потребности в относительно частых изменениях. И уж тем более, если это on-prem на солянке из оборудования без полноценных vSphere, кластеров, СХД и пр.

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

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

Даже в наших масштабах мы постоянно, ежедневно, непрерывно спотыкались на необходимость понять, чем и как думал человек, который до тебя настраивал эту ВМ и какого чёрта он напихал скрипты подключения одной NFS-шары в 5 (пять, Карл) разных мест Windows-инстанса. Я не могу здесь приводить другие реальные примеры, касающиеся, например, прода, но это действительно была ежедневная огромная боль.

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

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

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

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

Потому что "single provider". У них проблема - у вас проблема, и быстро её не ререшить.

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

Можно фигакнуть ансиблом/терраформом сетап или нет?

Конечно, почти все публичные облака имеют api и с ними можно работать яерез Терраформ. Но у всех своя специфика - сеть, работа с образами, ключами, свой Терраформ-провайдер со своими конструкциями. Можно писать под два облака, но у нас слишком маленькая для этого команда. Риски и неудобства работы только с одним облаком, конечно, есть, я согласен, но на данном этапе нашего развития и размера они не перевешивают выгоды того же решения.

Если нет, то это ни чем не лучше, чем on-prem, кроме того, что теперь ещё меньше ручек для контроля происходящего.

Меньше ручек - плохо тем, что меньше возможности их крутить. Но меньше ручек - это ещё и хорошо тем, что меньше необходимости их крутить. Решение зависит от условий задачи.

Скол ко человеко-часов потратили? Судя по описанию - я так понял, что стартанули в конце 2021, а уже март 2022, то есть, в общем-то, не так много времени прошло? И о каких масштабах инфры идёт речь? Сотни, тысячи виртуалок?

Проект стартовал в декабре 2020, примерно до февраля шла работа по выбору между on-prem и IaaS, затем до августа - выбор конкретного облачного провайдера, это всё в одного техлида параллельно с другими проектами, плюс ~неделя со стороны пары QA и разработчика для тестирования копии продов. С сентября началась подготовка миграции и сама миграция. Подготовка - проработка концепций, сетевая часть, написание модулей и common-ролей, пайплайны и т.п. - примерно 3 месяца работы одного техлида суммарно. Сама миграция - порядка 5-6 месяцев командой из 3-4 человек (параллельно с другими задачами). Масштаб - чуть менее сотни виртуалок.

Переезд уже закончился или все ещё в процессе?

Почти закончился, осталось примерно 7%.

Ещё такой вопрос - почему ансибл? Как я понял, Вы доконфигурируете сервера после создания их терраформом? Почему не пошли от обратного - создание своих шаблонов под каждый тип приложений и уже развёртывание готовых к эксплуатации ВМ?

Я согласен, что это стратегически более правильный подход и это будет следующим этапом развития нашей инфры. Но, во-первых, для этого нужно освоить Packer, обучить команду и вписать его в общий воркфлоу и пайплайны, а у нас был жёсткий дедлайн. Во-вторых, многие наши виртуалки в любом случае, после создания даже из шаблона, нужно доводить до ума - хотя бы вводить в домен Windows-инстансы. А в-третьих, Ansible очень удобен для сложного конфигурирования и даже в Packer мы бы именно его использовали, как провижионер, и текущие плейбуки и роли очень пригодятся.

В остальном статья очень подробная и полезная. Большая спасибо. Есть что почерпнуть для своей работы.

Спасибо на добром слове! Рад, что статья понравилась.

Искренне рад, что статья принесла пользу!

Спасибо, это всё объясняет про Лурк последнего времени, вообще всё.

Для 63.3% редакторов Хабра громкие заголовки - единственный источник дохода.

Information

Rating
Does not participate
Location
Кемерово, Кемеровская обл., Россия
Date of birth
Registered
Activity