Целью тестирования являлось максимально быстрое измерение производительности конкретной части инфраструктуры, кода, на который мы могли влиять непосредственно. Обвязка, шифрование и интеграция в лучшем случае вносят постоянную составляющую к производительности, в худшем — рандомизированную и не контролируемую. Исследование влияния разных типов шифрования, интеграций это отдельная, редкая и дорогая с точки зрения времени и ресурсов задача, которая не даёт быстрого и точного ответа про производительность каждого отдельного компонента, слишком много вокруг помех.
Коллеги, считаем нужным дать комментарий по статье в целом. DV это не только красивые графики. Он дополняет классическую платформу BI от Oracle и позволяет экономить время и деньги на создание новых отчетов с добавлением доп. источников данных. Это прежде всего актуально для пользователей, которые уже эксплуатируют OBI. Наша статья не посвящена сравнению данного продукта с конкурентными (это тема будущих статей J): задачей было донести новость о том, что Oracle BI совершил качественный рывок добавлением self-service.
Говоря об улучшении TCO и ROI, мы в первую очередь подразумеваем эффект от дополнения классического BI функциями DataDiscovery. Здесь самообслуживание позволяет экономить бюджет (исключаем вовлечение ИТ и интеграторов) и сокращать время (не требуется согласование изменения модели данных при насыщении ее аналитикой внешних источников) на реализацию новых идей анализа данных.
На DV можно купить хоть 1 лицензию и пользоваться, в том числе, серверной версией.
Коллеги, просьба по возможности комментировать свою «отрицательную» оценку поста. Хотелось бы разобраться в причинах, а из-за отсутствия вменяемой обратной связи, это невозможно.
По сути это значение зависит от того, какие приложения располагаются и какой процент записи. СХД на площадках различаются по конфигурации и между площадками распределены не все данные. На распределённых томах располагаются дата-сторы VMware. Нагрузка смешанная — как виртуализованные серверы, так и пользовательский VDI. Конкретные цифры сейчас уточним.
Когда только начинал работу на шине — восторг и веру в поверпоинты и картинки.
Через пару лет, оно сменилось и совпадало с Вашим!
Но еще через пару лет в результате очередного переосмысления, пришло понимание, что команды Систем всячески отказываются от принятия несколько несвойственных им функций. Так шина может приютить такие нестандартные требования, как менеджер сессий сайта к CRM системе. Или предоставить адаптер отсутствующий в Системе, например SMPP или LDAP.
Но это еще не все, часто внедрение Систем идет параллельно — и интегрировать в процессе разработки не с чем. Тут шина может дать заглушки, которые перерастут в полноценные прокси-сервисы. А так же внедренцы Систем обычно не уделяют должного внимания интеграции — в этом случае аналитик шины может играть роль двигателя и координатора процесса.
Так, что шина часто играет не только системную, а социальную роль.
Swift упомянут не как аналог Dropbox, а как объектное хранилище, написав к которому пользовательский интерфейс можно получить функциональный аналог Dropbox. Создание интерфейса как раз и потребует усилий программистов.
Статья является «расшифровкой» получасового выступления на семинаре, среди слушателей которого большинство составляли люди далекие от облачных технологий. Компоненты для ознакомления слушателей выбраны те, которые «не дохлые», да и не на компоненты акцентировалось внимание, а на область применения OpenStack.
По поводу сети — это не динамическое ограничение. Нельзя, afaik, реконфигурировать ВМ штатными средствами для применения новых ограничений (ssh на хост и ввод нескольких команд не в счет).
Из документации: «By default, the Compute service does not use the libvirt live migration functionality. The Compute service does not use libvirt's live migration by default because there is a risk that the migration process never ends. This can happen if the guest operating system dirties blocks on the disk faster than they can be migrated.»
В Джете мы используем разные инструментальные средства статического анализа кода. Сейчас все больше работаем с SonarQube, для которого у нас есть большая библиотека проприетарных правил. Так же из наиболее часто используемых ИС SCA можно назвать HP Fortify. Вообще, по запросу Заказчика выполняем SCA тем ИС SCA, на который договариваемся по тем или иным причинам (особенность разработки, пожелания Заказчика, наличие у Заказчика ИС SCA)
Фраза вырвана из контекста, но имеется ввиду, что НДВ могут быть реализованы посредством использования языковых конструкций, которые не имеют побочных эффектов. Например, у вас может быть вполне безобидный код, который проверяет IP адрес машины, с которой выполняется запрос, но, если этот IP == <some_var> программа предоставляет особенный доступ или пересылает особенные данные. Такую проблему можно идентифицировать только в полуавтоматическом режиме. Для эксплуатации злоумышленник должен знать о том, что в коде такое реализовано.
Под правильным кодом с точки зрения информационной безопасности понимается код, выполнение которого не имеет побочного эффекта.
Алгоритм поиска включал в себя достаточно сложную логику. Один из примеров — переход на разные экраны в зависимости от результатов.
Также, в дальнейшем, заказчик планировал производить самостоятельную модернизацию, поэтому было решено использовать таски, как наиболее универсальный механизм для всех процессов.
Действительно, трудно ожидать полной объективности от оценки компетенции. Во-первых, рассматриваемая методика сама по себе не является точным измерительным инструментом как весы или калькулятор, и она не оперирует абстрактными математическими понятиями :) Во-вторых, методику применяет человек, а любой человек имеет свои представления о том, что правильно и нет, что хорошо или плохо, как нужно работать, а как нельзя ни в коем случае. Каждый человек по-своему интерпретирует формулировки требований, несмотря на то, что они вроде бы согласованы всеми участниками взаимодействия. У всех есть свои личностные и психологические особенности, с которыми приходится считаться при взаимодействии людей, работающих вместе. Мы, собственно, и в статье обращаем на это внимание читателей. Цель методики — по возможности снизить степень необъективности, договориться о терминах, дать людям возможность обсуждений в общем контексте.
С тезисом о «подгонке» оценки под конкретных людей могу согласиться в одном случае — если методика используется формально либо, наоборот, с целью выдать «правильный» результат. Ну так это вряд ли проблема методики: некоторые, говорят, и пиво тапком открывают, это же не значит, что тапок плох :) Методику лучше применять для тех задач, для которых она предназначена.
Что же касается критерия компетенции «отсутствие „ляпов“ и ошибок», он, конечно, замечательный, но объективным его считать сложно: сразу хочется уточнить, что считать ошибкой в работе, кто будет определять, ошибка это или нет, чьи интересы при этом будут затронуты ну и так далее :)
На DV можно купить хоть 1 лицензию и пользоваться, в том числе, серверной версией.
Когда только начинал работу на шине — восторг и веру в поверпоинты и картинки.
Через пару лет, оно сменилось и совпадало с Вашим!
Но еще через пару лет в результате очередного переосмысления, пришло понимание, что команды Систем всячески отказываются от принятия несколько несвойственных им функций. Так шина может приютить такие нестандартные требования, как менеджер сессий сайта к CRM системе. Или предоставить адаптер отсутствующий в Системе, например SMPP или LDAP.
Но это еще не все, часто внедрение Систем идет параллельно — и интегрировать в процессе разработки не с чем. Тут шина может дать заглушки, которые перерастут в полноценные прокси-сервисы. А так же внедренцы Систем обычно не уделяют должного внимания интеграции — в этом случае аналитик шины может играть роль двигателя и координатора процесса.
Так, что шина часто играет не только системную, а социальную роль.
По поводу сети — это не динамическое ограничение. Нельзя, afaik, реконфигурировать ВМ штатными средствами для применения новых ограничений (ssh на хост и ввод нескольких команд не в счет).
Под правильным кодом с точки зрения информационной безопасности понимается код, выполнение которого не имеет побочного эффекта.
Также, в дальнейшем, заказчик планировал производить самостоятельную модернизацию, поэтому было решено использовать таски, как наиболее универсальный механизм для всех процессов.
С тезисом о «подгонке» оценки под конкретных людей могу согласиться в одном случае — если методика используется формально либо, наоборот, с целью выдать «правильный» результат. Ну так это вряд ли проблема методики: некоторые, говорят, и пиво тапком открывают, это же не значит, что тапок плох :) Методику лучше применять для тех задач, для которых она предназначена.
Что же касается критерия компетенции «отсутствие „ляпов“ и ошибок», он, конечно, замечательный, но объективным его считать сложно: сразу хочется уточнить, что считать ошибкой в работе, кто будет определять, ошибка это или нет, чьи интересы при этом будут затронуты ну и так далее :)