Поимпортозамещали и хватит? Правительство хочет разрешить использовать софт ушедших из России вендоров. Да, да, вы не ослышались. К 1 октября власти должны разработать механизм, который бы позволил делать это официально. И, конечно, мы не могли обойти стороной эту чудесную новость. И попросили ее прокомментировать Рената Лашина, исполнительного директора Ассоциации разработчиков программных продуктов (АРПП) «Отечественный софт». Ловите 🙂
«Законопроект не решает самой важной задачи – обеспечения возможности эффективной и безопасной эксплуатации зарубежного софта. Дальнейшее использование такого ПО будет затруднено из-за отсутствия гарантийной поддержки правообладателя иностранного ПО и сопутствующих обновлений.
Если мы говорим о проприетарном программном обеспечении, то в таком случае изначально только разработчик имеет эксклюзивное право на доработку ПО и внесение изменений в исходный код программы, такие права обычно не передаются конечным пользователям. Поэтому если продолжить использование иностранного ПО на прежних условиях, в какой-то момент из-за отсутствия актуальных обновлений оно станет неэффективным и небезопасным.
Упрощение порядка получения лицензии иностранного правообладателя не будет способствовать уменьшению доли иностранного ПО на российском рынке. Использование нелицензионного, фактически бесплатного ПО, крайне нежелательно для отечественной ИТ-отрасли. Это затормозит развитие российского рынка ПО и сведет на нет все усилия по импортозамещению, которым страна активно и успешно занималась последние 8 лет. В результате это только усугубит нашу технологическую зависимость от зарубежного ПО.
А если более неформально, то принудительное лицензирование иностранного ПО позволит заказчикам продолжать бесплатно использовать зарубежный софт без возможности его доработки и обновления. Это, в свою очередь, несет огромные риски в сфере информационной безопасности и противоречит действующему курсу государства на обеспечение технологического суверенитета. Не стоит забывать и об экспорте отечественных решений, в отношении которых могут быть введены аналогичные меры воздействия».
Конец цитаты.
Что мы можем добавить к этому как разработчики? Инициатива бредовая. Лицензируем мы софт, а что дальше? Техподдержка от этого не появится, с ИБ тоже лучше не станет. Сделаем бумажку о том, что ПО «чистое», и? Мы боимся, что вендор подаст на нас в суд? Это навряд ли. А если подаст – дружно посмеемся.
Такая инициатива была бы уместна разве что в области интеллектуальных прав касательно творчества, например, фильмов. Почему это мы не должны смотреть иностранные фильмы? Нам нравится, будем смотреть. 🙂
#мнение #инициатива #новости #софт
@aerodisk_official — трезво про импортозамещение в ИТ
«Законопроект не решает самой важной задачи – обеспечения возможности эффективной и безопасной эксплуатации зарубежного софта. Дальнейшее использование такого ПО будет затруднено из-за отсутствия гарантийной поддержки правообладателя иностранного ПО и сопутствующих обновлений.
Если мы говорим о проприетарном программном обеспечении, то в таком случае изначально только разработчик имеет эксклюзивное право на доработку ПО и внесение изменений в исходный код программы, такие права обычно не передаются конечным пользователям. Поэтому если продолжить использование иностранного ПО на прежних условиях, в какой-то момент из-за отсутствия актуальных обновлений оно станет неэффективным и небезопасным.
Упрощение порядка получения лицензии иностранного правообладателя не будет способствовать уменьшению доли иностранного ПО на российском рынке. Использование нелицензионного, фактически бесплатного ПО, крайне нежелательно для отечественной ИТ-отрасли. Это затормозит развитие российского рынка ПО и сведет на нет все усилия по импортозамещению, которым страна активно и успешно занималась последние 8 лет. В результате это только усугубит нашу технологическую зависимость от зарубежного ПО.
А если более неформально, то принудительное лицензирование иностранного ПО позволит заказчикам продолжать бесплатно использовать зарубежный софт без возможности его доработки и обновления. Это, в свою очередь, несет огромные риски в сфере информационной безопасности и противоречит действующему курсу государства на обеспечение технологического суверенитета. Не стоит забывать и об экспорте отечественных решений, в отношении которых могут быть введены аналогичные меры воздействия».
Конец цитаты.
Что мы можем добавить к этому как разработчики? Инициатива бредовая. Лицензируем мы софт, а что дальше? Техподдержка от этого не появится, с ИБ тоже лучше не станет. Сделаем бумажку о том, что ПО «чистое», и? Мы боимся, что вендор подаст на нас в суд? Это навряд ли. А если подаст – дружно посмеемся.
Такая инициатива была бы уместна разве что в области интеллектуальных прав касательно творчества, например, фильмов. Почему это мы не должны смотреть иностранные фильмы? Нам нравится, будем смотреть. 🙂
#мнение #инициатива #новости #софт
@aerodisk_official — трезво про импортозамещение в ИТ
Под капотом СХД. Если мы в своем гараже решили сделать и выпустить на рынок систему хранения данных или любой другой сложный программно-аппаратный комплекс, что нам понадобится кроме мата? Каков путь разработчика?
🔧 Программное обеспечение. И это самый главный квест, без которого нет смысла даже вставать с дивана. Сначала – исследования, потом сбор и анализ хотелок, которые превращаются в требования, их проверка, после чего оказывается, что все неправильно – переделать. Затем разработка минимальной живой версии. Далее проводим тестирование в рамках разработки и после нее. И только потом уже выпускаем первую версию и оказывается, что опять все неправильно и надо переделать. 🙂
🔧 «Железо». Некоторые думают: «А что там мудрить: сервер воткнул в обычную полку, диски поставил – вот и "железо"». Однако все чуть-чуть сложнее. Часть компонентов действительно покупается. Только что-то производится в России – с поставками в этом случае больших проблем нет. А что-то разрабатывается не у нас, а «у них». И купить, привезти это что-то сейчас – особая уличная магия. А потом когда оказалось, что «железо» несовместимо с софтом, возвращаемся в пункт выше.
🔧 Поддержка. Правы те, кто говорят, что продукт на 50% состоит из саппорта. А поддержка СХД – особенно сложный и хитрый процесс. Почему?Требуется очень высокая степень доступности к ПО и «железу».
🔧 Сертификация. Это обязательная часть при производстве СХД. Они должны соответствовать требованиям рынка. А чем больше рынок, тем толще сертификаты. Не получишь одобрения тех или иных регуляторов – продукт не продашь. Не продашь продукт – а зачем его тогда вообще разрабатывали? Дома немецкое кино коллекционировать? Слишком дорогое удовольствие.
Для кого-то пункты выше – «сизифов труд», а для тех, кто занимается разработкой сложных систем – скучные будни. И это кратко, а если длинно – по каждому пункту мы пройдемся подробно в специальной серии постов с тегом #это_СХД. Уже скоро!
А пока пишите в комментариях, какие еще темы подсветить в этом цикле. 🙂
#это_СХД #СХД #разработка #железо #софт
@aerodisk_official — трезво про импортозамещение в ИТ
🔧 Программное обеспечение. И это самый главный квест, без которого нет смысла даже вставать с дивана. Сначала – исследования, потом сбор и анализ хотелок, которые превращаются в требования, их проверка, после чего оказывается, что все неправильно – переделать. Затем разработка минимальной живой версии. Далее проводим тестирование в рамках разработки и после нее. И только потом уже выпускаем первую версию и оказывается, что опять все неправильно и надо переделать. 🙂
🔧 «Железо». Некоторые думают: «А что там мудрить: сервер воткнул в обычную полку, диски поставил – вот и "железо"». Однако все чуть-чуть сложнее. Часть компонентов действительно покупается. Только что-то производится в России – с поставками в этом случае больших проблем нет. А что-то разрабатывается не у нас, а «у них». И купить, привезти это что-то сейчас – особая уличная магия. А потом когда оказалось, что «железо» несовместимо с софтом, возвращаемся в пункт выше.
🔧 Поддержка. Правы те, кто говорят, что продукт на 50% состоит из саппорта. А поддержка СХД – особенно сложный и хитрый процесс. Почему?
Для кого-то пункты выше – «сизифов труд», а для тех, кто занимается разработкой сложных систем – скучные будни. И это кратко, а если длинно – по каждому пункту мы пройдемся подробно в специальной серии постов с тегом #это_СХД. Уже скоро!
А пока пишите в комментариях, какие еще темы подсветить в этом цикле. 🙂
#это_СХД #СХД #разработка #железо #софт
@aerodisk_official — трезво про импортозамещение в ИТ
В серверной ночами время течет медленно, поэтому приходится чем-то заниматься, чтобы занять голову. Кто-то собирает марки, кто-то строит домики из спичек, а Энди прорыл в стене огромную дыру… Ой, это другая клевая история. А вот наша – вообще огонь. Так получилось, что у нас, что ни сотрудник – то и швец, и жнец, и на дуде игрец. И однажды наш системный администратор Дмитрий решил разработать систему мониторинга температуры для ректификационной колонны. А вот что из этого вышло:
«Ректификационная колонна – это такое устройство в самогонном аппарате для разделения бинарных и многокомпонентных жидкостей на фракции. Для управления процессами при ректификации через веб-интерфейс.
Изначально проект был на плате ESP8266 (выглядит так). Она хороша тем, что идет с IEEE 802.11 – набором стандартов связи для коммуникации в беспроводной локальной зоне (Wi-Fi). Это значит, что не нужно думать, как организовать связь микроконтроллера с интернетом – все уже в комплекте.
Чертеж прототипа был сделан в Sprint Layout, а методом лазерно-утюжной технологии изготовлен и опытный образец. После всех доработок продукт отправился на производство, кто бы мог подумать, куда – правильно, в Китай 😅.
Что касается платы, то ее размеры подбирались под дисплей LCD2004. Это облегчало монтаж в корпус.
Telegram-bot – всему голова
В один прекрасный день мы с руководителем задумались, как было бы здорово оптимизировать систему мониторинга температуры в серверной комнате. И тут меня осенило, а почему бы не использовать этот проект и для серверной, зря, что ли, изучал программирование на C++? Сказано – сделано.
В итоге программа работает так:
⚙️ при подаче питания на микроконтроллер выполняется инициализация дисплея LCD2004 и датчика DS18B20;
⚙️ идет подключение к Wi-Fi;
⚙️ если подключение успешно, отправляем в чат TG-бота «Bot started up»;
⚙️ идет мониторинг t, значение фиксируется в зависимости от условий.
Чем выше температура, тем чаще нужно отправлять уведомления, чтобы понять, надо ли бежать в серверную или еще можно попить кофе. Алгоритм следующий:
🔧 при t < 18 градусов – оповещение раз в час;
🔧 при t = 18-20 – раз в полчаса;
🔧 при t = 20-25 – раз в 10 минут;
🔧 при t > 25 – уведомление идет каждую минуту.
Реализовать такой алгоритм было для меня одной из самых сложных задач. А тут еще сразу при тестировании выяснилось, что если первое сообщение было получено при t до 18 градусов, то повторное оповещение будет только через час, независимо от того, насколько изменится температура. А час – это вечность, если «железо» кипит. Пришлось редачить код: ввести переменные, куда будут записываться время от старта ПО и время, прошедшее с момента отправки последнего сообщения. На каждой итерации – проверка текущего диапазона t.
В итоге получили небольшой и надежный код. Используем уже два таких устройства почти год – полет нормальный.
Отдельно хочу выразить огромную благодарность Арсению Акимову, который проконсультировал меня по многим вопросам относительно программирования на C++ и в целом оказал поддержку».
#софт
@aerodisk_official — трезво про импортозамещение в ИТ
«Ректификационная колонна – это такое устройство в самогонном аппарате для разделения бинарных и многокомпонентных жидкостей на фракции. Для управления процессами при ректификации через веб-интерфейс.
Изначально проект был на плате ESP8266 (выглядит так). Она хороша тем, что идет с IEEE 802.11 – набором стандартов связи для коммуникации в беспроводной локальной зоне (Wi-Fi). Это значит, что не нужно думать, как организовать связь микроконтроллера с интернетом – все уже в комплекте.
Чертеж прототипа был сделан в Sprint Layout, а методом лазерно-утюжной технологии изготовлен и опытный образец. После всех доработок продукт отправился на производство, кто бы мог подумать, куда – правильно, в Китай 😅.
Что касается платы, то ее размеры подбирались под дисплей LCD2004. Это облегчало монтаж в корпус.
Telegram-bot – всему голова
В один прекрасный день мы с руководителем задумались, как было бы здорово оптимизировать систему мониторинга температуры в серверной комнате. И тут меня осенило, а почему бы не использовать этот проект и для серверной, зря, что ли, изучал программирование на C++? Сказано – сделано.
В итоге программа работает так:
⚙️ при подаче питания на микроконтроллер выполняется инициализация дисплея LCD2004 и датчика DS18B20;
⚙️ идет подключение к Wi-Fi;
⚙️ если подключение успешно, отправляем в чат TG-бота «Bot started up»;
⚙️ идет мониторинг t, значение фиксируется в зависимости от условий.
Чем выше температура, тем чаще нужно отправлять уведомления, чтобы понять, надо ли бежать в серверную или еще можно попить кофе. Алгоритм следующий:
🔧 при t < 18 градусов – оповещение раз в час;
🔧 при t = 18-20 – раз в полчаса;
🔧 при t = 20-25 – раз в 10 минут;
🔧 при t > 25 – уведомление идет каждую минуту.
Реализовать такой алгоритм было для меня одной из самых сложных задач. А тут еще сразу при тестировании выяснилось, что если первое сообщение было получено при t до 18 градусов, то повторное оповещение будет только через час, независимо от того, насколько изменится температура. А час – это вечность, если «железо» кипит. Пришлось редачить код: ввести переменные, куда будут записываться время от старта ПО и время, прошедшее с момента отправки последнего сообщения. На каждой итерации – проверка текущего диапазона t.
В итоге получили небольшой и надежный код. Используем уже два таких устройства почти год – полет нормальный.
Отдельно хочу выразить огромную благодарность Арсению Акимову, который проконсультировал меня по многим вопросам относительно программирования на C++ и в целом оказал поддержку».
#софт
@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 — трезво про импортозамещение в ИТ
