Полностью остановить деградацию не получится, так как всегда будут появляться срочные фичи, баги, которые нужно выполнять для бизнеса. Мы стараемся управлять деградацией, путем пометок "// TODO или FIXME с временем, прямо на том участке, где было нарушение", на это настроен линтер.
По dependency rule, сейчас она держится в основном на code review, автоматика точечная. Мы постепенно донастраиваем eslint-plugin-boundaries для части доменных продуктов, но распространить это на все сразу не получается, модули описаны по-разному и не всегда ложатся в целевую архитектуру. Так что полного автоматического покрытия dependency rule пока нет. По мере унификации модулей постепенно расширяем покрытие правил, чтобы в перспективе уйти от ручной проверки границ к автоматической.
Да, абсолютно верно подметили. Да, статья сильно упрощает вИдение системы логирования, тут имеется в виду вход программы, а не функции/метода/процедуры, отвечающей за конкретную команду.
Возможно, вы правы и стоит ловить событие на самом низком уровне, чтобы было удобно локализовать ошибку. Но материал опирался на стандарты W3C(https://w3c.github.io/), например. Возможно, практика и красивая теория расходятся и Вы можете рассказать об этом нам очень интересным комментарием.
Если не используется веб-технология, то trace_id может сформировать функция библиотеки логирования(если программа не на низкоуровневом языке программирования вроде assembler).
Разумеется, точки логирования Вы можете сами устанавливать под свои нужды.
Здравствуйте! На соревновании Data Fusion Contest задания достаточно сложные, требуется опыт работы с реальными задачами по машинному обучению и анализу данных. Для того, чтобы начать изучать эту тему, рекомендуем несколько проверенных временем источников:
Традиционно, первоочередной задачей тестирования систем хранения является достижение высоких показателей производительности. Для этих целей хорошо подходят небольшие SSD-диски. Гонки же в формате «кто больше может хранить» для традиционных СХД остались в прошлом и являются актуальными разве что для архивных систем хранения, но это уже совсем другая история.
Да, можно рассматривать преднамеренный архитектурный тех. долг как стадию реализации проекта. Впрочем, это касается тех. долга на любом уровне разработки — долг зафиксирован, оценен, и есть план по устранению: это уже не тех. долг в плохом смысле, а управляемая единица со своей целью.
Что касается частоты, тут имелось в виду, что архитектуру в больших компаниях обычно смотрят несколько независимых сотрудников и протащить явные косяки сложнее, но, к сожалению, это случается, и их устранение намного дороже.
Результаты fio при выполнении тестов на проверку надёжности мы не фиксировали. В этих тестах fio выполнял только функцию генерации нагрузки на СХД для имитации реальной работы системы.
СХД предназначено для широкого спектра задач, вендор позиционирует продукт как «Система для корпоративных приложений, больших данных и аналитики».
Что касается аппаратных и программных возможностей, то они постоянно добавляются и дорабатываются. А если говорить непосредственно про снэпшоты с группами консистентности — да, такая функциональность есть в текущей версии продукта. Мы постарались не перегружать вводные своего тестирования информацией, которую можно почерпнуть у вендора, например, вот из этой общедоступной презентации — https://st.yadro.com/docs/Tatlin/YADRO_TATLIN_UNIFIED_GEN2_Presentation_RUS.pdf
Оставшийся пул Ваших вопросов стоит рассматривать в рамках конкретной задачи сайзинга. В рамках базового тестирования, увы, невозможно охватить и учесть все возможные конфигурации и требования со стороны систем‑потребителей СХД. Надеемся, в будущем у нас будет возможность «похвастаться» конкретными конфигурациями и показателями, которые будут достигнуты на продуктивных внедрениях этой СХД у заказчиков.
Расхождение с расчётными показателями IOPS, на которое Вы обращаете внимание, вызвано использованием инфраструктуры FC 16 Гбит/сек, тогда как расчётные значения в таблице подразумевают инфраструктуру FC 32 Гбит/сек. Упоминание о таком ограничении присутствует в первом тесте.
Параметры надо выбирать примерно такие, какие будут на вашей реальной нагрузке. Или взять какие общеприняты. А самое правильное - вообще прогнать на нескольки вариантах (например, iodepth=1/4/8/16/32/64 numjobs=1/2/4/8/16).
Подбирать же параметры теста чтобы показать цифры получше, скажем так, считается не самой лучшей практикой
Абсолютно верно, при тестирования СХД под конкретную задачу параметры нагрузки должны максимально соответствовать реальным. Но в нашем случае такой задачи не стояло, поэтому взяты рекомендуемые вендором профили нагрузки для тестирования, и тут логично, что они призваны показать хорошие значения производительности СХД.
Исполнительная документация была, здесь нужно учитывать общие условия — оптика прокладывалась, когда это был еще один завод, потом уже все посносили, построили 2 ТЦ и ЖК, ну в какой-то момент и по оптике попали.
Спасибо за вопрос, но, к сожалению, раскрывать количество персонала дежурной смены мы не имеем права. Однако можем сказать, что сегодня на объекте уже создана собственная служба эксплуатации с диспетчерской, организованы дежурные смены. В состав дежурных смен входят диспетчера, осуществляющие круглосуточный контроль за объектом, а также функциональные инженеры по направлениям, отвечающие за работоспособность систем жизнеобеспечения объекта (таких как электроснабжение, механические системы, слаботочные системы и т.д.), проведение регламентных и ремонтных работ.
Служба эксплуатации не останавливается на достигнутом, проводит доукомплектование диспетчерских смен профильными специалистами на перспективу развития объекта и увеличения его мощности до номинальной величины.
Спасибо за вопрос! Вот ответ, который сегодня нам дал генеральный директор ООО «Авантаж» — Александр Крок: «Опыт строительства ЦОДов в северных широтах, например, в скандинавских странах, насчитывает уже много лет, однако, необходимо учитывать такие важные требования, как катастрофоустойчивость и отсутствие объектов повышенной опасности, в том числе природного характера. Тем более, инфраструктура наших северных широт не располагает нужными для строительства ЦОДов возможностями».
Отвечая на этот вопрос, генеральный директор ООО «Авантаж» — Александр Крок, сказал, что ЦОД будет функционировать в полном соответствии с законодательством РФ.
В статье я не указал детали, про что я имел ввиду, отсюда и возник вопрос, сейчас уточню.
Если брать Jackson и превратить объект в JSON, это одно, тут правда никаких проблем нет.
А в статье я сравнивал со встроенным механизмом в Java, java.io.Serializable. И вот с ним беда:
- поменял класс, старые данные могут не прочитаться;
- объект создаётся в обход конструктора, то есть может быть сломанным;
- каждая новая фича языка (records, sealed classes) должна с ним считаться.
Причина в том, что язык обязан поддерживать этот механизм ради обратной совместимости.
В новых проектах его почти никто не использует, берут json или Protobuf. Но в legacy он еще используется, и выкинуть java.io.Serializable нельзя.
Это не то, что нельзя сериализовать в json, а то, что язык тащит старый механизм, который почти никому не нужен.
И именно из-за него проектировщикам приходится считаться с этим механизмом при добавлении новых фич, вместо того чтобы просто исключить его.
Полностью остановить деградацию не получится, так как всегда будут появляться срочные фичи, баги, которые нужно выполнять для бизнеса. Мы стараемся управлять деградацией, путем пометок "// TODO или FIXME с временем, прямо на том участке, где было нарушение", на это настроен линтер.
По dependency rule, сейчас она держится в основном на code review, автоматика точечная. Мы постепенно донастраиваем eslint-plugin-boundaries для части доменных продуктов, но распространить это на все сразу не получается, модули описаны по-разному и не всегда ложатся в целевую архитектуру. Так что полного автоматического покрытия dependency rule пока нет. По мере унификации модулей постепенно расширяем покрытие правил, чтобы в перспективе уйти от ручной проверки границ к автоматической.
Да, абсолютно верно подметили. Да, статья сильно упрощает вИдение системы логирования, тут имеется в виду вход программы, а не функции/метода/процедуры, отвечающей за конкретную команду.
Возможно, вы правы и стоит ловить событие на самом низком уровне, чтобы было удобно локализовать ошибку. Но материал опирался на стандарты W3C(https://w3c.github.io/), например. Возможно, практика и красивая теория расходятся и Вы можете рассказать об этом нам очень интересным комментарием.
Пример работы с trace_id можно посмотреть у Яндекса: https://yandex.cloud/ru/docs/monium/traces/operations/traces-logs?utm_referrer=https%3A%2F%2Fwww.google.com%2F
Если не используется веб-технология, то trace_id может сформировать функция библиотеки логирования(если программа не на низкоуровневом языке программирования вроде assembler).
Разумеется, точки логирования Вы можете сами устанавливать под свои нужды.
Добрый день! Конкретно в нашей компании мы эту ошибку видели только до релизов на этапе статического анализа и исправляли.
На данный момент из-за логов никого не взломали. Пока что. Поэтому на прод-серверах я данное явление видели лишь в рамках CTF
Воздушное охлаждение
Курс от ODS
Здравствуйте!
На соревновании Data Fusion Contest задания достаточно сложные, требуется опыт работы с реальными задачами по машинному обучению и анализу данных. Для того, чтобы начать изучать эту тему, рекомендуем несколько проверенных временем источников:
Курс от ODS
Coursera "Машинное обучение" (Andrew Ng)
Курс лекций Константина Воронцова
Традиционно, первоочередной задачей тестирования систем хранения является достижение высоких показателей производительности. Для этих целей хорошо подходят небольшие SSD-диски. Гонки же в формате «кто больше может хранить» для традиционных СХД остались в прошлом и являются актуальными разве что для архивных систем хранения, но это уже совсем другая история.
Актуальный перечень поддерживаемых дисковых накопителей для системы TATLIN.UNIFIED Gen2 можно посмотреть по ссылке: https://yadro.com/ru/tatlin/unified/gen2/specs
Да, можно рассматривать преднамеренный архитектурный тех. долг как стадию реализации проекта. Впрочем, это касается тех. долга на любом уровне разработки — долг зафиксирован, оценен, и есть план по устранению: это уже не тех. долг в плохом смысле, а управляемая единица со своей целью.
Что касается частоты, тут имелось в виду, что архитектуру в больших компаниях обычно смотрят несколько независимых сотрудников и протащить явные косяки сложнее, но, к сожалению, это случается, и их устранение намного дороже.
Спасибо за высокую оценку.
Результаты fio при выполнении тестов на проверку надёжности мы не фиксировали. В этих тестах fio выполнял только функцию генерации нагрузки на СХД для имитации реальной работы системы.
СХД предназначено для широкого спектра задач, вендор позиционирует продукт как «Система для корпоративных приложений, больших данных и аналитики».
Что касается аппаратных и программных возможностей, то они постоянно добавляются и дорабатываются. А если говорить непосредственно про снэпшоты с группами консистентности — да, такая функциональность есть в текущей версии продукта. Мы постарались не перегружать вводные своего тестирования информацией, которую можно почерпнуть у вендора, например, вот из этой общедоступной презентации — https://st.yadro.com/docs/Tatlin/YADRO_TATLIN_UNIFIED_GEN2_Presentation_RUS.pdf
Оставшийся пул Ваших вопросов стоит рассматривать в рамках конкретной задачи сайзинга. В рамках базового тестирования, увы, невозможно охватить и учесть все возможные конфигурации и требования со стороны систем‑потребителей СХД. Надеемся, в будущем у нас будет возможность «похвастаться» конкретными конфигурациями и показателями, которые будут достигнуты на продуктивных внедрениях этой СХД у заказчиков.
Расхождение с расчётными показателями IOPS, на которое Вы обращаете внимание, вызвано использованием инфраструктуры FC 16 Гбит/сек, тогда как расчётные значения в таблице подразумевают инфраструктуру FC 32 Гбит/сек. Упоминание о таком ограничении присутствует в первом тесте.
Абсолютно верно, при тестирования СХД под конкретную задачу параметры нагрузки должны максимально соответствовать реальным. Но в нашем случае такой задачи не стояло, поэтому взяты рекомендуемые вендором профили нагрузки для тестирования, и тут логично, что они призваны показать хорошие значения производительности СХД.
Спасибо за внимательность, исправили :)
Служба эксплуатации не останавливается на достигнутом, проводит доукомплектование диспетчерских смен профильными специалистами на перспективу развития объекта и увеличения его мощности до номинальной величины.