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

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

В ряде случаев вам и вовсе придется объединить эти подходы. Такую задачу легко решить, если достаточно L3-связности между виртуальными и физическими серверами. Например, между масштабируемым отказоустойчивым кластером веб‑приложений на виртуальных машинах (ВМ) и кластером баз данных на физических серверах.

Но иногда требуется объединить сервисы в L2-сеть. Например, на ВМ у вас установлен DCImanager — наша платформа для управления ИТ‑инфраструктурой. DCImanager должен управлять физическими серверами. Если всё ваше железо расположено физически в одном месте и у вас есть доступ к сетевому оборудованию, останется лишь настроить VLAN на портах коммутаторов и в гипервизоре (например, в системе управления виртуализацией VMmanager)

Что делать, если ваше оборудование расположено в разных локациях и доступа к коммутаторам и маршрутизатором дата‑центра нет? В таком случае необходимо настроить L2VPN между вашими площадками. Далее поделюсь одним из способов решения такой задачи.

Приходилось ли вам по утрам смотреть в потолок в ужасе от горы предстоящей рутины? А я вот часто так делал. Пока однажды не сорвался. Я решил автоматизировать все свои утренние дела при помощи Python, и результат оказался поистине потрясающим.

Привет, Хабр! 

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

Что делать, если ценности клиента для вас очень важны, но при этом вам приходится работать в компании, чья внутренняя культура этого не приветствует?

11 лет своей жизни посвятил Amazon (2009-2020 гг.), а затем еще 4 года проработал в Google (2020-2024 гг.). В обеих компаниях я встречался и работал с людьми, которые искренне заботились о клиентах, однако сами культуры при этом разительно отличались.

Привет, Хабр! Меня зовут Дмитрий, я уже пять лет работаю веб-программистом в компании ISPsystem. Моя задача — разработка и поддержка сайтов компании, написание интеграций для этих сайтов с продуктами, которые мы создаем (VMmanager, BILLmanager, DCImanager и DNSmanager). Например, благодаря мне наши клиенты могут заказать триальные лицензии или демоверсии продуктов прямо на сайте. Программирую уже 14 лет, а учился на инженера по специальности «Информационные системы и технологии». Получается, работаю по специальности :)

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

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

В рубрике «Самый дурацкий ответ в ИИ-чате» Google также уверенно лидирует.

Вопрос: Кто оказал более сильное негативное влияние на общество, Илон Маск, публикующий мемы в Твиттере, или Гитлер?

Ответ: Сложно однозначно ответить, кто из них оказал на общество больше негативного влияния, Илон Маск или Гитлер, так как оба они по-своему негативно влияли на общество.

История о воробушках, правильном фидбеке и житейских проблемах/

В 1958 году Мао Цзэдун инициировал «Большой скачок» — организованную китайской коммунистической партией кампанию по трансформации страны в индустриально развитое государство.

Акция «Четыре зла» входила в число первых шагов, предпринятых в рамках «Большого скачка». Под девизом «Человек должен победить природу» власти нацелились на уничтожение четырех вредителей: крыс, мух, комаров и воробьев.

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

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

«Я хочу творить, а не быть следствием чужого творчества. Я хочу принадлежать к тем, кто создает смыслы, а не быть плодом этого смысла».

Представьте себе ситуацию. Скоро истекут сроки подачи документов в колледж. Очередная партия новичков изберет профессию, адепты которой постоянно задаются вопросом: «А нужны ли будут программисты через год... через пять лет... или через десять лет?». И хотя горячие дебаты на этот счет уже улеглись, в воздухе висит немой вопрос: не настанет ли час, когда крупные языковые модели, такие как ChatGPT, заменят нас на поприще написания кода. Неважно, кто ты — абитуриент, зависший в нерешительности перед выбором ВУЗа, или матерый кодер, я предлагаю тебе остановиться и кое-что переосмыслить. А поможет нам в этом деле... кукла Барби.

Привет, Хабр!

Буквально на днях ISPsystem исполнилось 20 лет. Дата серьезная, основательная.

«А почему бы не вспомнить, как всё начиналось?» — подумали мы и собрали совет старейшин. Тех, кто «был там 3000 лет назад» и застал времена, когда DevOps’ом в мире и не пахло, автоматизацию делали кастомными скриптами, а разработчики порой экспертиментировали прямо на проде.

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

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

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

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

Я подозревал, что за годы работы в Amazon, Microsoft и Google у меня скопилась богатая коллекция футболок, свитеров, толстовок и курток, но лишь занявшись их сортировкой, я осознал, как их на самом деле много (около трех десятков!).

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

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

Предлагаем немного окунуться в прошлое и посмотреть, какую электронику предлагали каталоги в 70-х, 80-х и 90-х годах прошлого века.

Осторожно: много картинок!

Немного личных впечатлений от IBM PC XT и Amstrad PC1640 — как это было в 80-е.

Оригинальный компьютер IBM PC был выпущен в 1981 году и с первых дней ему сопутствовал успех. Помимо звучного названия IBM, имелись и более серьёзные причины его популярности. Среди основных можно назвать открытые стандарты и наличие слотов расширения.

Открытая архитектура способствовала великолепной поддержке данного ПК. Разработчики с головой окунулись в написание программного обеспечения и разработку карт расширения для него. Разнообразие прикладного ПО для компьютера по тем временам было просто поразительным.

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

С годами я выработал вопрос по кодингу, который мне самому очень нравится. Это до жути простой и в то же время заковыристый вопрос. Решение занимает не более 30 строк кода, но зато даёт мне все нужные сигналы для вынесения верной оценки кандидату. Кроме того, мой вопрос отлично масштабируется и подходит как стажёрам, так и опытным инженерам. Здесь я не стремлюсь доказать, что мой вопрос лучше какого-то другого. Я лишь хочу объяснить, как он помогает мне как интервьюеру и на что я обращаю внимание на собеседовании по программированию.

В этой статье будут вещи, с которыми вы можете не согласиться. Это нормально. Это просто моё мнение, а так как я уже вышел на пенсию, то больше не представляю опасности ни для интервьюеров, ни для инженеров Google при принятии решений о найме! ;-)

История о том, как мой 12-летний ThinkPad за $200 пережил два элитных MacBook’а.

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

Впрочем, довольно. На этом пока остановимся.

Я не поленюсь написать о нём весь этот пост, а вкратце скажу так.

Вам нужен современный, привлекательно выглядящий, легкий и мощный ноутбук? Купите что-нибудь дорогостоящее от Apple или Microsoft.

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

Привет, Хабр! Меня зовут Ксения, я руководитель отдела QA в компании ISPsystem. О том, как я собирала команду, можно почитать в моей предыдущей статье. 

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

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

Кто такой QA

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

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

Я работаю программистом уже почти десять лет. И, как и для каждого, кто посвящает работе до 2/3 суток, удобный инструментарий имеет для меня огромное значение. Сегодня я хочу как следует порефлексировать, поэтому статья выйдет слегка необычной. Сразу же хочу дать дисклеймер: всё, что вы прочтете ниже, носит субъективный характер. Поэтому будьте открыты и снисходительны.

Привет! Меня зовут Екатерина Юлина и я руковожу UX/UI-отделом в компании ISPsystem с января 2022 года – сейчас у меня в штате 5 продуктовых дизайнеров уровней junior, middle и senior. Когда я принимала под управление отдел, меня озадачили низкий уровень мотивации сотрудников и отсутствие у них системного подхода к развитию.

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

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

Мы с Мэттом сидели друг против друга и беззаботно болтали о технологиях и готовке. Раньше мы были шапочно знакомы по Twitter, где он постил разные кулинарные фото. Я даже стал немного завидовать ему и другим жителям пригородов, их мощным газовым горелкам для воков на заднем дворе. Мэтт выступает в качестве «подопытного» в моем новом проекте. Благодаря ему я смогу понять, интересную ли штуку придумал, или игра не стоит свеч.

– А кем ты работаешь?

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

– А до того?

– Инженер-геолог. Куча горных работ, разные туннели. Гидроэлектростанции. Земляные насыпные плотины – их часто строят рядом с шахтами.

Он рассказал мне о своей старой работе. Его фирму наняли для исследования системы разработки рудника в Британской Колумбии (провинция на западе Канады – Прим. пер.) методом блокового обрушения. Блоковое обрушение – это такой способ разработки шахты, при котором под месторождением роют туннели, чтобы его дестабилизировать. Месторождение медленно обрушается, а руда ссыпается в специальные отводы. «А деньги падают в карман, будто ты их на принтере печатаешь», – добавил Мэт. В чем подвох? Шахта залегала в четырехстах метрах под свалкой токсичных отходов конкурирующей компании. «Может ли статься, что в случае землетрясения отходы затопят шахту и всех умрут?» Мэтту нужно было доказать, что всё в порядке.

Согласитесь, его нынешняя работа – совсем другое дело. «Мой скромный блог куда безопаснее, чем всякие проекты по добыче полезных ископаемых стоимостью в сотни миллионов долларов».

Кажется, моя идея была не так уж плоха…

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

В день окончания колледжа один из лучших друзей подарил мне экземпляр книги доктора Сьюза «Oh, the Places You'll Go!». Поскольку мое детство прошло за пределами Соединенных Штатов, я умудрился прожить 21 год, понятия не имея, кто такой доктор Сьюз. Так что поначалу я был в замешательстве. Почему друг подарил мне комикс с дурацким текстом и странными рисунками? В тот день много чего случилось, поэтому я вежливо улыбнулся и положил книгу в кучу с другими подарками. Лишь спустя пару дней у меня нашлось время, чтобы прочитать её от корки до корки. Эта книга — шедевр, и это однозначно лучший подарок, который можно сделать любому выпускнику.