«Альтернатива есть всему»: как уход производителей софта отражается на российской разработке? Рассказываем на примере АЭРОДИСКа в нашей рубрике #внутренняякухня. Спойлер: реальная картина далека от шумихи в СМИ, большинство разработчиков быстро и успешно адаптировались к новой действительности.
Итак, единственный общий инструмент, на котором у нас были завязаны многие рабочие процессы – это система для управления проектами Jira. От него будем отказываться. Свою роль сыграло и то, что Jira решила убрать те привычные решения, которыми мы пользовались – вместо них будут облачные продукты. На замену мы уже выбрали отечественную платформу – Битрикс24, провели тест-драйв и скоро будем мигрировать. Пока непривычно, конечно. Можем позже рассказать о том, как работается с этой системой, если интересно: пишите в комментах.
Некоторые ребята пользовались продуктами JetBrains. Вот с ними были проблемы – отказывались принимать оплату. Мы решили вернуться на бесплатную open source версию, ее возможностей вполне хватает. В остальном у нас нет жесткой привязки к инструментарию: каждый разработчик пользуется своим. Вот так выглядит типичный набор: Linux, опенсорсный редактор VS Code, локальные репозитории кода. Вместо виртуализации VMWare мы используем свои продукты vAIR/АИСТ, а резервное копирование от Veeam заменили на RuBackup. Больше ничего и не нужно.
Чтобы обезопасить себя от блокировок открытого софта, уже забрали себе копии с GitHub. Так что, в общем-то, кардинальных изменений от санкций не почувствовали. Мы уже привыкли, что мир быстро меняется. И готовы к тому, что альтернативный вариант всегда можно найти.
С кадровым вопросом у нас тоже все спокойно. На некоторое время мы взяли паузу на найм – сейчас снова возобновляем. В остальном у нас все как работали, так и работают. Никто чемоданов не собирал. Ребята трезво оценивают ситуацию и понимают, что в России сейчас для них возможностей больше. На наши продукты колоссальный спрос, объем работы увеличивается. А значит, можно нехило прокачать и экспертизу, и уровень дохода, а еще быстро продвинуться по карьерной лестнице.
@aerodisk_official — трезво про импортозамещение в ИТ
#разработка #внутренняя_кухня #санкции
Итак, единственный общий инструмент, на котором у нас были завязаны многие рабочие процессы – это система для управления проектами Jira. От него будем отказываться. Свою роль сыграло и то, что Jira решила убрать те привычные решения, которыми мы пользовались – вместо них будут облачные продукты. На замену мы уже выбрали отечественную платформу – Битрикс24, провели тест-драйв и скоро будем мигрировать. Пока непривычно, конечно. Можем позже рассказать о том, как работается с этой системой, если интересно: пишите в комментах.
Некоторые ребята пользовались продуктами JetBrains. Вот с ними были проблемы – отказывались принимать оплату. Мы решили вернуться на бесплатную open source версию, ее возможностей вполне хватает. В остальном у нас нет жесткой привязки к инструментарию: каждый разработчик пользуется своим. Вот так выглядит типичный набор: Linux, опенсорсный редактор VS Code, локальные репозитории кода. Вместо виртуализации VMWare мы используем свои продукты vAIR/АИСТ, а резервное копирование от Veeam заменили на RuBackup. Больше ничего и не нужно.
Чтобы обезопасить себя от блокировок открытого софта, уже забрали себе копии с GitHub. Так что, в общем-то, кардинальных изменений от санкций не почувствовали. Мы уже привыкли, что мир быстро меняется. И готовы к тому, что альтернативный вариант всегда можно найти.
С кадровым вопросом у нас тоже все спокойно. На некоторое время мы взяли паузу на найм – сейчас снова возобновляем. В остальном у нас все как работали, так и работают. Никто чемоданов не собирал. Ребята трезво оценивают ситуацию и понимают, что в России сейчас для них возможностей больше. На наши продукты колоссальный спрос, объем работы увеличивается. А значит, можно нехило прокачать и экспертизу, и уровень дохода, а еще быстро продвинуться по карьерной лестнице.
@aerodisk_official — трезво про импортозамещение в ИТ
#разработка #внутренняя_кухня #санкции
Джуны никому не нужны? Что? С любопытством наблюдаем за обсуждениями, которые то и дело возникают в ИТ-среде. Дескать, молодых спецов никуда не берут, платить им не хотят, одни закрытые двери сплошь и рядом. Всем нужны сеньоры или мидлы. Такой вот плач Ярославны, который не имеет никакого отношения к реальности.
Давайте проведем простые аналогии. Возьмем автосервис, например. Сколько вам нужно нанять крутых автомехаников с опытом работы в 15-20 лет? А сколько нужно простых ребят, которые будут делать рутину – то есть, большую часть работы? Вот и делаем выводы.
Если вы нанимаете одних сеньоров, тут можно только посочувствовать. Работать такой механизм не будет. Очевидно, что высокооплачиваемые, матерые специалисты не должны заниматься «операционкой». У них сложные задачи – выстроить процессы, научить других. А на простые задачи как раз и набирают джунов, которых потом выращивают до мидлов и далее. У нас все распределено примерно так: на команду из 10 разработчиков всего 1 сеньор и 3-4 мидла, остальные – джуны.
Не забываем и про психологический фактор. Соберите «звездных» специалистов – сформированных профессионально, каждого со своим опытом, точкой зрения – и попробуйте заставить их работать вместе. Да они передерутся. Не в прямом смысле, конечно, но вангуем скандалы и соперничество. Мы уже как-то писали про подобный свой опыт вот в этом посте – и почему делаем ставку на молодых.
Если же вы столкнулись с реальной ситуацией («не берут никак, хоть ты тресни»), тут надо четко понимать: джуны джунам рознь. Типичная ситуация: человек пошел на курсы в надежде на золотые горы. А чего бы нет? ИТ в тренде, платят хорошо. Только вовлеченности ноль, никакого интереса к инженерным изысканиям нет. Конечно, в таких специалистах мало кто заинтересован.
Другое дело – если человек с первых этапов обучения начинает вовлекаться в команду, проявляет соображалку, инициативу, энтузиазм, пытается развиваться и погружается в тематику в целом. Таких спецов берут без проблем. Поэтому диагноз следующий. Джуны в российском ИТ сейчас крайне востребованы, при условии их желания развиваться и играть в команде.
#ИТ #мнение #разработка
@aerodisk_official — трезво про импортозамещение в ИТ
Давайте проведем простые аналогии. Возьмем автосервис, например. Сколько вам нужно нанять крутых автомехаников с опытом работы в 15-20 лет? А сколько нужно простых ребят, которые будут делать рутину – то есть, большую часть работы? Вот и делаем выводы.
Если вы нанимаете одних сеньоров, тут можно только посочувствовать. Работать такой механизм не будет. Очевидно, что высокооплачиваемые, матерые специалисты не должны заниматься «операционкой». У них сложные задачи – выстроить процессы, научить других. А на простые задачи как раз и набирают джунов, которых потом выращивают до мидлов и далее. У нас все распределено примерно так: на команду из 10 разработчиков всего 1 сеньор и 3-4 мидла, остальные – джуны.
Не забываем и про психологический фактор. Соберите «звездных» специалистов – сформированных профессионально, каждого со своим опытом, точкой зрения – и попробуйте заставить их работать вместе. Да они передерутся. Не в прямом смысле, конечно, но вангуем скандалы и соперничество. Мы уже как-то писали про подобный свой опыт вот в этом посте – и почему делаем ставку на молодых.
Если же вы столкнулись с реальной ситуацией («не берут никак, хоть ты тресни»), тут надо четко понимать: джуны джунам рознь. Типичная ситуация: человек пошел на курсы в надежде на золотые горы. А чего бы нет? ИТ в тренде, платят хорошо. Только вовлеченности ноль, никакого интереса к инженерным изысканиям нет. Конечно, в таких специалистах мало кто заинтересован.
Другое дело – если человек с первых этапов обучения начинает вовлекаться в команду, проявляет соображалку, инициативу, энтузиазм, пытается развиваться и погружается в тематику в целом. Таких спецов берут без проблем. Поэтому диагноз следующий. Джуны в российском ИТ сейчас крайне востребованы, при условии их желания развиваться и играть в команде.
#ИТ #мнение #разработка
@aerodisk_official — трезво про импортозамещение в ИТ
Часть 2: одних амбиций мало
Вторая история про нашего джуна. Человек очень талантливый, с некоторым базовым образованием, высокими софт-скилами и весьма серьезными амбициями. Пришел к нам работать, начал потихоньку развиваться. И здесь, в отличие от первого случая, интеграция с коллективом прошла, что называется, бесшовно.
Однако был с этим джуном нюанс – качество кода. Вот грязно писал и все тут. Хотя за счет командной работы результат получался в принципе нормальным: где-то его подстраховывали, где-то – он. При этом у человека, как мы уже отмечали ранее, были большие амбиции – уверенно метил выше.
Так оно в итоге и получилось. Джун дорос до полноценного мидла, знаний, навыков и ответственности стало гораздо больше. А вот код лучше не стал, почему-то. И это вылилось в самую настоящую проблему. Одно дело, когда он, как джуниор, отвечал за два пазла, а в картине продукта их 100, например. Тут коллеги могут поправить. Но совсем другое дело, когда он, как мидл, ответственен уже за 10 таких пазлов. Т.е. мы получаем достаточно большой кусок некачественного кода. Представьте, сколько времени понадобится, чтобы его почистить?
А самое обидное, что человек принципиально ничего не хотел менять. Мы рассчитывали, что став мидлом, в нем проснется некоторая внимательность, желание работать над собой и улучшать свои характеристики – способности были, и мы были готовы помочь их раскрыть и вырастить специалиста, потратить на это время и ресурсы. Но в результате амбиции не совпали с уровнем трудоголизма. Получилось, что на словах он хотел, а на деле не очень. Уровнем дошел до мидла, а сознание осталось джуновское.
Напрашивается вывод из всего вышесказанного. Что реально может помешать карьере в ИТ?
— Лень. Главный секрет успеха в том, что надо работать и желательно любить свое дело. Разработка – это постоянный и напряженный труд. Сидеть, ничего не делать и зарабатывать деньги здесь не получится, друзья.
— Нежелание работать в команде. Смогут ли 10 человек по отдельности построить большой дом? Нет, только 10 шалашей. А вот коллективными усилиями, с взаимопомощью очень даже смогут. Вот и в ИТ также. Нежелание работать вместе чревато отсутствием результата.
— Негибкость. Какая разница, насколько крутой специалист, если он не может перестроиться под компанию и решать конкретно ее задачи?
С другой стороны, надо понимать, что не всем нужен карьерный рост и звание сеньора, тимлида и т.п. Бывает, что человек приходит к 9, нормально выполняет свои обязанности и уходит в 6 домой. Получает за это достойные деньги и больше ему ничего и не нужно. И это тоже нормально.
#HR_истории #ИТ #мнение #разработка
@aerodisk_official — трезво про импортозамещение в ИТ
Вторая история про нашего джуна. Человек очень талантливый, с некоторым базовым образованием, высокими софт-скилами и весьма серьезными амбициями. Пришел к нам работать, начал потихоньку развиваться. И здесь, в отличие от первого случая, интеграция с коллективом прошла, что называется, бесшовно.
Однако был с этим джуном нюанс – качество кода. Вот грязно писал и все тут. Хотя за счет командной работы результат получался в принципе нормальным: где-то его подстраховывали, где-то – он. При этом у человека, как мы уже отмечали ранее, были большие амбиции – уверенно метил выше.
Так оно в итоге и получилось. Джун дорос до полноценного мидла, знаний, навыков и ответственности стало гораздо больше. А вот код лучше не стал, почему-то. И это вылилось в самую настоящую проблему. Одно дело, когда он, как джуниор, отвечал за два пазла, а в картине продукта их 100, например. Тут коллеги могут поправить. Но совсем другое дело, когда он, как мидл, ответственен уже за 10 таких пазлов. Т.е. мы получаем достаточно большой кусок некачественного кода. Представьте, сколько времени понадобится, чтобы его почистить?
А самое обидное, что человек принципиально ничего не хотел менять. Мы рассчитывали, что став мидлом, в нем проснется некоторая внимательность, желание работать над собой и улучшать свои характеристики – способности были, и мы были готовы помочь их раскрыть и вырастить специалиста, потратить на это время и ресурсы. Но в результате амбиции не совпали с уровнем трудоголизма. Получилось, что на словах он хотел, а на деле не очень. Уровнем дошел до мидла, а сознание осталось джуновское.
Напрашивается вывод из всего вышесказанного. Что реально может помешать карьере в ИТ?
— Лень. Главный секрет успеха в том, что надо работать и желательно любить свое дело. Разработка – это постоянный и напряженный труд. Сидеть, ничего не делать и зарабатывать деньги здесь не получится, друзья.
— Нежелание работать в команде. Смогут ли 10 человек по отдельности построить большой дом? Нет, только 10 шалашей. А вот коллективными усилиями, с взаимопомощью очень даже смогут. Вот и в ИТ также. Нежелание работать вместе чревато отсутствием результата.
— Негибкость. Какая разница, насколько крутой специалист, если он не может перестроиться под компанию и решать конкретно ее задачи?
С другой стороны, надо понимать, что не всем нужен карьерный рост и звание сеньора, тимлида и т.п. Бывает, что человек приходит к 9, нормально выполняет свои обязанности и уходит в 6 домой. Получает за это достойные деньги и больше ему ничего и не нужно. И это тоже нормально.
#HR_истории #ИТ #мнение #разработка
@aerodisk_official — трезво про импортозамещение в ИТ
❗️ Чего тебе надобно, старче? Составляем дорожную карту развития СХД.
Друзья, нам очень нужна ваша помощь. Сейчас мы строим планы на следующий год и составляем дорожную карту развития наших продуктов. Чтобы понять, какой функционал добавить или улучшить в СХД, нужно определить реальные потребности компаний, которые используют системы хранения (речь не только об оборудовании “Аэродиска”, а вообще любых вендоров).
Поэтому просим вас выделить 6 минут времени и ответить на несколько вопросов, чтобы мы могли узнать:
— Чего не хватает вашим компаниям в функционале СХД сейчас.
— Что бы вы хотели видеть в системах хранения в ближайшем будущем, а что через несколько лет.
Результаты исследования мы обязательно опубликуем на нашем канале. Давайте вместе сделаем СХД ближе к пользователю.
Заранее всем спасибо.
#опросы #СХД #разработка
@aerodisk_official — трезво про импортозамещение в ИТ
Друзья, нам очень нужна ваша помощь. Сейчас мы строим планы на следующий год и составляем дорожную карту развития наших продуктов. Чтобы понять, какой функционал добавить или улучшить в СХД, нужно определить реальные потребности компаний, которые используют системы хранения (речь не только об оборудовании “Аэродиска”, а вообще любых вендоров).
Поэтому просим вас выделить 6 минут времени и ответить на несколько вопросов, чтобы мы могли узнать:
— Чего не хватает вашим компаниям в функционале СХД сейчас.
— Что бы вы хотели видеть в системах хранения в ближайшем будущем, а что через несколько лет.
Результаты исследования мы обязательно опубликуем на нашем канале. Давайте вместе сделаем СХД ближе к пользователю.
Заранее всем спасибо.
#опросы #СХД #разработка
@aerodisk_official — трезво про импортозамещение в ИТ
Под капотом СХД. Если мы в своем гараже решили сделать и выпустить на рынок систему хранения данных или любой другой сложный программно-аппаратный комплекс, что нам понадобится кроме мата? Каков путь разработчика?
🔧 Программное обеспечение. И это самый главный квест, без которого нет смысла даже вставать с дивана. Сначала – исследования, потом сбор и анализ хотелок, которые превращаются в требования, их проверка, после чего оказывается, что все неправильно – переделать. Затем разработка минимальной живой версии. Далее проводим тестирование в рамках разработки и после нее. И только потом уже выпускаем первую версию и оказывается, что опять все неправильно и надо переделать. 🙂
🔧 «Железо». Некоторые думают: «А что там мудрить: сервер воткнул в обычную полку, диски поставил – вот и "железо"». Однако все чуть-чуть сложнее. Часть компонентов действительно покупается. Только что-то производится в России – с поставками в этом случае больших проблем нет. А что-то разрабатывается не у нас, а «у них». И купить, привезти это что-то сейчас – особая уличная магия. А потом когда оказалось, что «железо» несовместимо с софтом, возвращаемся в пункт выше.
🔧 Поддержка. Правы те, кто говорят, что продукт на 50% состоит из саппорта. А поддержка СХД – особенно сложный и хитрый процесс. Почему?Требуется очень высокая степень доступности к ПО и «железу».
🔧 Сертификация. Это обязательная часть при производстве СХД. Они должны соответствовать требованиям рынка. А чем больше рынок, тем толще сертификаты. Не получишь одобрения тех или иных регуляторов – продукт не продашь. Не продашь продукт – а зачем его тогда вообще разрабатывали? Дома немецкое кино коллекционировать? Слишком дорогое удовольствие.
Для кого-то пункты выше – «сизифов труд», а для тех, кто занимается разработкой сложных систем – скучные будни. И это кратко, а если длинно – по каждому пункту мы пройдемся подробно в специальной серии постов с тегом #это_СХД. Уже скоро!
А пока пишите в комментариях, какие еще темы подсветить в этом цикле. 🙂
#это_СХД #СХД #разработка #железо #софт
@aerodisk_official — трезво про импортозамещение в ИТ
🔧 Программное обеспечение. И это самый главный квест, без которого нет смысла даже вставать с дивана. Сначала – исследования, потом сбор и анализ хотелок, которые превращаются в требования, их проверка, после чего оказывается, что все неправильно – переделать. Затем разработка минимальной живой версии. Далее проводим тестирование в рамках разработки и после нее. И только потом уже выпускаем первую версию и оказывается, что опять все неправильно и надо переделать. 🙂
🔧 «Железо». Некоторые думают: «А что там мудрить: сервер воткнул в обычную полку, диски поставил – вот и "железо"». Однако все чуть-чуть сложнее. Часть компонентов действительно покупается. Только что-то производится в России – с поставками в этом случае больших проблем нет. А что-то разрабатывается не у нас, а «у них». И купить, привезти это что-то сейчас – особая уличная магия. А потом когда оказалось, что «железо» несовместимо с софтом, возвращаемся в пункт выше.
🔧 Поддержка. Правы те, кто говорят, что продукт на 50% состоит из саппорта. А поддержка СХД – особенно сложный и хитрый процесс. Почему?
Для кого-то пункты выше – «сизифов труд», а для тех, кто занимается разработкой сложных систем – скучные будни. И это кратко, а если длинно – по каждому пункту мы пройдемся подробно в специальной серии постов с тегом #это_СХД. Уже скоро!
А пока пишите в комментариях, какие еще темы подсветить в этом цикле. 🙂
#это_СХД #СХД #разработка #железо #софт
@aerodisk_official — трезво про импортозамещение в ИТ
❗️ Виртуализация мечты. Продолжаем работать над дорожной картой развития наших продуктов. Исследование по СХД уже провели, теперь пришло время поговорить о системах виртуализации.
Мы подготовили небольшой опрос, который займет у вас не более 5 минут, а нам даст бесценную информацию о реальных потребностях заказчиков:
⚙️ какие задачи решаются с помощью виртуализации;
⚙️ чего не хватает в функциональности систем сейчас;
⚙️ какие фичи вы бы хотели видеть в ПО в будущем и др.
Ну что, сделаем отечественный рынок виртуализации чуток взрослее, а систему виртуализации АЭРОДИСК еще лучше? 😉 Результаты исследования опубликуем на канале.
Заранее всем спасибо!
#опросы #виртуализация #разработка
@aerodisk_official — трезво про импортозамещение в ИТ
Мы подготовили небольшой опрос, который займет у вас не более 5 минут, а нам даст бесценную информацию о реальных потребностях заказчиков:
⚙️ какие задачи решаются с помощью виртуализации;
⚙️ чего не хватает в функциональности систем сейчас;
⚙️ какие фичи вы бы хотели видеть в ПО в будущем и др.
Ну что, сделаем отечественный рынок виртуализации чуток взрослее, а систему виртуализации АЭРОДИСК еще лучше? 😉 Результаты исследования опубликуем на канале.
Заранее всем спасибо!
#опросы #виртуализация #разработка
@aerodisk_official — трезво про импортозамещение в ИТ
Из чего же, из чего же, из чего же сделана СХД? Продолжаем сатирическую экскурсию в новом выпуске рубрики – #это_СХД.
❗️Важное замечание. Допускаем, что многим после прочтения заголовка покажется, что мы возьмем и распишем подкапотку со всеми костылями и синей изолентой. В какой-то момент нам действительно хотелось так сделать. Но все-таки поступили иначе. И если после этого предупреждения вам до сих пор интересно – милости просим. А если нет – все равно читайте, ведь советских газет для изучения за обедом не так уж и много. 😉
Теперь по существу. Пост является околохудожественным продолжением рубрики про внутренности СХД, которая хоть и широкими мазками, но отвечает на вопрос: «Почему нельзя просто взять и сделать нормальную СХД?». А также объясняет, как создание систем хранения данных влияет на сон разработчика.
‼️ И еще чуть-чуть важного. Если все-таки тянет подискутировать про синюю изоленту под капотом СХД, то для этого идеально подойдет ближайшая конференция – «Технократия», где мы специально будем делать акцент на технической составляющей наших продуктов. Сразу отметим: хочется сохранить камерность мероприятия, поэтому количество посетителей строго ограничено. Получить талончик можно попробовать тут.
А мы начинаем
Программная часть СХД, как и любой нормальный бутерброд, состоит из нескольких слоев и должна либо не падать совсем, либо падать управляемо и строго маслом вверх. Поэтому на низком уровне системы важна простота, и тут СХД мало чем отличается от обычного сервера. Стандартный набор: BIOS и какая-нибудь несложная система управления (BMC). Она нужна для того, чтобы на аппаратном уровне можно было удаленно подключиться к «железу» и выполнять с ним элементарные операции. BMC, как и BIOS, некоторые допиливают под себя. У нас, например, тоже используется своя переписанная система, но без фанатизма.
Дальше идет ОС. Ни для кого не секрет, что 99% всех СХД, как, впрочем, и любых более-менее серьезных систем, имеют в своей основе Linux. Иногда Unix. В целом суть не меняется, но есть нюансы.
Конечно, некоторые компании, причем с уважаемыми транснациональными лицами, предпочитали экзотику и использовали нечто подобное обрезанной Windows. Но все осталось в их темном прошлом. Сейчас в большинстве случаев фундамент – Linux. Как правило, разработчик СХД берет готовое ядро, которое подходит по ряду причин, и дорабатывает его до нужного состояния. Мы, например, выбрали Alt Linux, потому что они – крайне компетентные ребята.
Над операционной системой – функциональные Open Source блоки. И вот тут уже начинается уличная магия в двух актах. В первом – мы получаем некий набор стандартных компонентов Linux (файловые системы, менеджеры томов и др.), которые нужно дописать согласно правилам ее использования, не нарушив никаких обязательств. И здесь немного задержимся, ведь речь идет про наш любимый Open Source.
Всегда радостно наблюдать за разными «потомственными экспертами», когда речь заходит о применении OS в российском софте. «Фи. Т.е получается, отечественные разработчики воруют чужие наработки?». Ну да, японские, китайские и американские специалисты ничего не воруют, сидят себе спокойно, пишут продукты на базе открытого ПО. А вот российские разработчики – это другое, они непременно должны написать все с нуля и точка.
Тут есть один маленький нюанс: дело в том, что в основе СХД (как и в любых других сложных решениях) используются Open Source компоненты. Которые каждый производитель перерабатывает под себя, создавая абсолютно новый продукт, не забывая, конечно, соблюдать правила сообщества. Получается, вся мировая разработка стоит на воровстве? Или нужно просто внимательнее читать правила использования OS? Оставим это «на подумать» и двигаемся дальше.
Продолжение ⬇️⬇️
#это_СХД #СХД #разработка #софт
❗️Важное замечание. Допускаем, что многим после прочтения заголовка покажется, что мы возьмем и распишем подкапотку со всеми костылями и синей изолентой. В какой-то момент нам действительно хотелось так сделать. Но все-таки поступили иначе. И если после этого предупреждения вам до сих пор интересно – милости просим. А если нет – все равно читайте, ведь советских газет для изучения за обедом не так уж и много. 😉
Теперь по существу. Пост является околохудожественным продолжением рубрики про внутренности СХД, которая хоть и широкими мазками, но отвечает на вопрос: «Почему нельзя просто взять и сделать нормальную СХД?». А также объясняет, как создание систем хранения данных влияет на сон разработчика.
‼️ И еще чуть-чуть важного. Если все-таки тянет подискутировать про синюю изоленту под капотом СХД, то для этого идеально подойдет ближайшая конференция – «Технократия», где мы специально будем делать акцент на технической составляющей наших продуктов. Сразу отметим: хочется сохранить камерность мероприятия, поэтому количество посетителей строго ограничено. Получить талончик можно попробовать тут.
А мы начинаем
Программная часть СХД, как и любой нормальный бутерброд, состоит из нескольких слоев и должна либо не падать совсем, либо падать управляемо и строго маслом вверх. Поэтому на низком уровне системы важна простота, и тут СХД мало чем отличается от обычного сервера. Стандартный набор: BIOS и какая-нибудь несложная система управления (BMC). Она нужна для того, чтобы на аппаратном уровне можно было удаленно подключиться к «железу» и выполнять с ним элементарные операции. BMC, как и BIOS, некоторые допиливают под себя. У нас, например, тоже используется своя переписанная система, но без фанатизма.
Дальше идет ОС. Ни для кого не секрет, что 99% всех СХД, как, впрочем, и любых более-менее серьезных систем, имеют в своей основе Linux. Иногда Unix. В целом суть не меняется, но есть нюансы.
Конечно, некоторые компании, причем с уважаемыми транснациональными лицами, предпочитали экзотику и использовали нечто подобное обрезанной Windows. Но все осталось в их темном прошлом. Сейчас в большинстве случаев фундамент – Linux. Как правило, разработчик СХД берет готовое ядро, которое подходит по ряду причин, и дорабатывает его до нужного состояния. Мы, например, выбрали Alt Linux, потому что они – крайне компетентные ребята.
Над операционной системой – функциональные Open Source блоки. И вот тут уже начинается уличная магия в двух актах. В первом – мы получаем некий набор стандартных компонентов Linux (файловые системы, менеджеры томов и др.), которые нужно дописать согласно правилам ее использования, не нарушив никаких обязательств. И здесь немного задержимся, ведь речь идет про наш любимый Open Source.
Всегда радостно наблюдать за разными «потомственными экспертами», когда речь заходит о применении OS в российском софте. «Фи. Т.е получается, отечественные разработчики воруют чужие наработки?». Ну да, японские, китайские и американские специалисты ничего не воруют, сидят себе спокойно, пишут продукты на базе открытого ПО. А вот российские разработчики – это другое, они непременно должны написать все с нуля и точка.
Тут есть один маленький нюанс: дело в том, что в основе СХД (как и в любых других сложных решениях) используются Open Source компоненты. Которые каждый производитель перерабатывает под себя, создавая абсолютно новый продукт, не забывая, конечно, соблюдать правила сообщества. Получается, вся мировая разработка стоит на воровстве? Или нужно просто внимательнее читать правила использования OS? Оставим это «на подумать» и двигаемся дальше.
Продолжение ⬇️⬇️
#это_СХД #СХД #разработка #софт
Начало в предыдущем посте⤴️
Во втором акте нам нужно создать с нуля все недостающее ПО. Например, нормальную графику, кластерный софт, свой API, инструменты мониторинга и сбора статистики и т.д.
Почему нельзя взять узкоспециализированные необходимые компоненты из открытых источников? Во-первых и в-единственных, потому, что их там нет. Никто в здравом уме не будет выкладывать такие вещи. Люди, которые уже делали нечто подобное, прекрасно помнят, сколько крови и пота ушло на разработку этих решений и очень ценят свой труд.
«Ой, да ладно. В чем проблема написать необходимое ПО? Взял, собрал команду и написал!» – спросит недоверчивый читатель и, возможно, будет в чем-то прав. Но есть проблема, даже две.
Недостаточно просто написать, нужно еще как-то обеспечить совместимость создаваемого софта с исходными программными компонентами и «железом». СХД – это сложная и чувствительная структура, где все элементы должны бесшовно взаимодействовать между собой. И очень много времени и сил уходит на то, чтобы довести не только свой, но и открытый код до ума. Более того, некоторые готовые решения практически полностью переписываются и используются вообще по-другому. Это как с пнем: можно на нем сидеть, можно его сжечь, а можно – использовать для строительства, например. Какой из вариантов будет полезнее? Также и с софтом.
Далее надо не прогореть на этапе проектирования. Для упрощения, допустим, что с архитектурой вроде все понятно – сразу бросаемся в омут с головой и беремся за самые хардкорные задачи. Например, если кластерный модуль, то непременно для high-end.
И как раз тут вылезает вторая проблема (это уже про нашу матушку – Россию). На деле оказывается, что реализовать задумку совсем не просто. Особенно, когда без опыта (а для России это норма, ведь за последние 30 лет у нас делалось не так много СХД, да и специалистов по их разработке нет). И начинается круговорот проблем в разработке – одну решили, продукт заработал, как бац – получите еще парочку.
Процесс стопорится, все расстроены. А ведь это закономерно, мы же не идем на Эльбрус без подготовки? Здесь такая же история. Нужно двигаться от простого к сложному, класть кирпичик за кирпичиком.
💬 Для иллюстрации: свой первый кластерный модуль для mid-range СХД мы создали еще семь лет назад. Он был простым, в том числе с точки зрения отказоустойчивости, но рабочим. Постепенно СХД усложнялась, требования к кластерному ПО увеличивались, навыки и знания команды – тоже. И вот за это время мы переделали компонент 4 или 5 раз, причем почти с нуля.
Ну и до кучи, любая серьезная разработка – это сразу несколько контуров, многочисленные тесты, работа множества отделов. Процесс требует не только значительных ресурсов, но и сильной команды. А кадров не хватает. Особенно в нашей узкоспециализированной области.
Продолжение ⬇️⬇️
#это_СХД #СХД #разработка #софт
Во втором акте нам нужно создать с нуля все недостающее ПО. Например, нормальную графику, кластерный софт, свой API, инструменты мониторинга и сбора статистики и т.д.
Почему нельзя взять узкоспециализированные необходимые компоненты из открытых источников? Во-первых и в-единственных, потому, что их там нет. Никто в здравом уме не будет выкладывать такие вещи. Люди, которые уже делали нечто подобное, прекрасно помнят, сколько крови и пота ушло на разработку этих решений и очень ценят свой труд.
«Ой, да ладно. В чем проблема написать необходимое ПО? Взял, собрал команду и написал!» – спросит недоверчивый читатель и, возможно, будет в чем-то прав. Но есть проблема, даже две.
Недостаточно просто написать, нужно еще как-то обеспечить совместимость создаваемого софта с исходными программными компонентами и «железом». СХД – это сложная и чувствительная структура, где все элементы должны бесшовно взаимодействовать между собой. И очень много времени и сил уходит на то, чтобы довести не только свой, но и открытый код до ума. Более того, некоторые готовые решения практически полностью переписываются и используются вообще по-другому. Это как с пнем: можно на нем сидеть, можно его сжечь, а можно – использовать для строительства, например. Какой из вариантов будет полезнее? Также и с софтом.
Далее надо не прогореть на этапе проектирования. Для упрощения, допустим, что с архитектурой вроде все понятно – сразу бросаемся в омут с головой и беремся за самые хардкорные задачи. Например, если кластерный модуль, то непременно для high-end.
И как раз тут вылезает вторая проблема (это уже про нашу матушку – Россию). На деле оказывается, что реализовать задумку совсем не просто. Особенно, когда без опыта (а для России это норма, ведь за последние 30 лет у нас делалось не так много СХД, да и специалистов по их разработке нет). И начинается круговорот проблем в разработке – одну решили, продукт заработал, как бац – получите еще парочку.
Процесс стопорится, все расстроены. А ведь это закономерно, мы же не идем на Эльбрус без подготовки? Здесь такая же история. Нужно двигаться от простого к сложному, класть кирпичик за кирпичиком.
💬 Для иллюстрации: свой первый кластерный модуль для mid-range СХД мы создали еще семь лет назад. Он был простым, в том числе с точки зрения отказоустойчивости, но рабочим. Постепенно СХД усложнялась, требования к кластерному ПО увеличивались, навыки и знания команды – тоже. И вот за это время мы переделали компонент 4 или 5 раз, причем почти с нуля.
Ну и до кучи, любая серьезная разработка – это сразу несколько контуров, многочисленные тесты, работа множества отделов. Процесс требует не только значительных ресурсов, но и сильной команды. А кадров не хватает. Особенно в нашей узкоспециализированной области.
Продолжение ⬇️⬇️
#это_СХД #СХД #разработка #софт
Начало в предыдущем посте⤴️
А теперь немного программных лозунгов. Каким должен быть софт для СХД?
🛠 Надежным. Даже кратковременный сбой может привести к потере или повреждению данных. Поэтому важно обеспечить высокий уровень доступности и самой системы, и данных, а также использовать всевозможные (изощренные) методы резервного копирование без применения систем резервного копирования.
🛠 Производительным. Задействовать все возможные технологии оптимизации ввода-вывода, исключая жертвы и разрушения. Чтобы в итоге уметь выдавать нужный уровень продуктивности для своих задач.
🛠 Масштабируемым. Система не должна «падать» при увеличении нагрузки, а вот уметь расширяться под более емкие задачи – обязана. И масштабы этого расширения должны быть заранее определены опытным путем и протестированы при разработке.
🛠 Безопасным. СХД содержат ценную информацию, поэтому число атак на них постоянно растет. Необходимо внедрять процессы безопасной разработки и желательно проходить сертификацию/аттестацию всех известных внутренних органов. Это дисциплинирует.
🛠 Совместимым с ИТ-инфраструктурой. СХД должна легко и бесшовно встраиваться в ИТ-ландшафт заказчика, независимо от платформы и технологии. Это требует не только тщательного тестирования на совместимость, но и поддержки в актуальном состоянии всех компонентов СХД.
Если проще, то все программные лозунги выше можно переформулировать: надо сделать так, чтобы не сильно переживать за то, что где-нибудь на АЭС система ляжет, будет взломана, потеряет данные или кто-то (а, возможно, и вы) останется без электричества или еще без чего-нибудь. Поэтому иногда лучше просто взять и донести кольцо до Ородруина. 🙂
#это_СХД #СХД #разработка #софт
@aerodisk_official — трезво про импортозамещение в ИТ
А теперь немного программных лозунгов. Каким должен быть софт для СХД?
🛠 Надежным. Даже кратковременный сбой может привести к потере или повреждению данных. Поэтому важно обеспечить высокий уровень доступности и самой системы, и данных, а также использовать всевозможные (изощренные) методы резервного копирование без применения систем резервного копирования.
🛠 Производительным. Задействовать все возможные технологии оптимизации ввода-вывода, исключая жертвы и разрушения. Чтобы в итоге уметь выдавать нужный уровень продуктивности для своих задач.
🛠 Масштабируемым. Система не должна «падать» при увеличении нагрузки, а вот уметь расширяться под более емкие задачи – обязана. И масштабы этого расширения должны быть заранее определены опытным путем и протестированы при разработке.
🛠 Безопасным. СХД содержат ценную информацию, поэтому число атак на них постоянно растет. Необходимо внедрять процессы безопасной разработки и желательно проходить сертификацию/аттестацию всех известных внутренних органов. Это дисциплинирует.
🛠 Совместимым с ИТ-инфраструктурой. СХД должна легко и бесшовно встраиваться в ИТ-ландшафт заказчика, независимо от платформы и технологии. Это требует не только тщательного тестирования на совместимость, но и поддержки в актуальном состоянии всех компонентов СХД.
Если проще, то все программные лозунги выше можно переформулировать: надо сделать так, чтобы не сильно переживать за то, что где-нибудь на АЭС система ляжет, будет взломана, потеряет данные или кто-то (а, возможно, и вы) останется без электричества или еще без чего-нибудь. Поэтому иногда лучше просто взять и донести кольцо до Ородруина. 🙂
#это_СХД #СХД #разработка #софт
@aerodisk_official — трезво про импортозамещение в ИТ
«Шуба, скроенная сообща, не будет коротка». Не мудрость предков, а целый бизнес-совет делать совместные проекты. Поэтому мы с MONT решили «утеплить» малый и средний бизнес и запустили систему виртуализации «Аэродиск vAIR Лайт».
Во-первых, потому что зима близко, а во-вторых, новинка реально нужна тем, кто хочет быстро и недорого запустить у себя российское решение виртуализации.
Эта система — облегченная версия нашего основного продукта vAIR, который теперь выпускается в двух редакциях «Лайт» и«Стандарт». Вся базовая функциональность в «Лайте» сохранена: HA-кластер, блочный и файловый доступ, живая миграция, клоны, снэпшоты, шаблоны, API и, конечно, встроенный инструмент для миграции виртуальной инфраструктуры с зарубежных гипервизоров. Еще по «начинке» — в комплект входит поддержка на 1 год, которую можно продлить до трех.
Для ознакомления с деталями можно посмотреть наш вебинар, если пропустили.
#виртуализация #разработка
@aerodisk_official — трезво про импортозамещение в ИТ
Во-первых, потому что зима близко, а во-вторых, новинка реально нужна тем, кто хочет быстро и недорого запустить у себя российское решение виртуализации.
Эта система — облегченная версия нашего основного продукта vAIR, который теперь выпускается в двух редакциях «Лайт» и«Стандарт». Вся базовая функциональность в «Лайте» сохранена: HA-кластер, блочный и файловый доступ, живая миграция, клоны, снэпшоты, шаблоны, API и, конечно, встроенный инструмент для миграции виртуальной инфраструктуры с зарубежных гипервизоров. Еще по «начинке» — в комплект входит поддержка на 1 год, которую можно продлить до трех.
Для ознакомления с деталями можно посмотреть наш вебинар, если пропустили.
#виртуализация #разработка
@aerodisk_official — трезво про импортозамещение в ИТ