Отопление мегаполиса Москва от ТЭЦ. Массовая застройка «спальных районов» - как успешная реализация коммунистической утопии «общества всеобщего равенства».

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

https://habr.com/ru/articles/800317/

Теперь же рассмотрим вопрос теплоснабжения мегаполиса Москва в увязке с электрогенерацией на ТЭЦ.

Россия – это единственная страна в мире, где присутствует стабильное отопление в жилье, причём централизованное на весь город.

Центральное отопление в мегаполисе- это весьма яркое и важное достижение социализма в СССР, обеспечившее высокий стандарт качества  жизни широким слоям населения.

В тоже время  в капиталистических страна тепло в домах зимой  является предметом неслыханной роскоши. Так в Великобритании центрального  отопления в домах вообще практически нет.

Как устроена городская система теплоснабжения в мегаполисе Москва.

В качестве основного источника тепла на отопление и нагрев ГВС в Москве используются городские ТЭЦ и в дополнение к ним отдельные районные или индивидуальные котельные.(см.рис.1)

Мы уже писали о методах борьбы с DDoS и «слабых местах» Wi-Fi. Сегодня продолжим тему и поговорим о ресурсах, где можно найти актуальную информацию о сетевых уязвимостях и не только. Это — наша компактная подборка открытых баз, которые предлагают собственные API для получения данных и отправки уведомлений об угрозах.

Снятие снапшота - именно с этого начинается любой бекап. До тех пор, пока мы не знаем, как сбросить все буфера на диск и привести файлы с данными в консистентное состояние, мы не бекапы делаем, а занимаемся копированием файлов с непредсказуемым содержимым внутри. Понимая важность снапшотов, все вендоры стараются дать нам если не полностью готовую функцию (типа Time Mashine в MacOS), то хотя бы набор ручек, за которые можно подёргать (вроде модуля dm-snap в ядре Linux). 

Но сегодня речь пойдёт про самую распространённую ОС - Microsoft Windows, где эта задача решается с помощью Volume Shadow Copy сервиса, известного в народе под аббревиатурой VSS (Volume Snapshot Service). А нашего внимания он удостоился из-за того, что, несмотря на всю популярность своего материнского корабля, сам он окутан вуалью из тайн и мистических слухов. Давайте уже как-то разберёмся с этой штукой.

Сначала я думал просто перечислить наиболее распространенные проблемы, возникающие при переходе с MS SQL на PostgreSQL. Но решил, что просто перечисление будет мало информативным. Поэтому, пока ограничился наиболее частой проблемой, приводящей к деградации производительности при переходе с MS SQL на PostgreSQL. Если статья окажется нужной, то продолжу рассматривать остальные проблемы.

Итак, это случилось. Я добыл Flipper Zero в бою (ну, на самом деле мне его выдали на хакатоне), и естественно, что интереснее всего не играть в него, используя уже сделанные кем-то функции, а писать что-то новое. Примерно так же я развлекался с Pebble. Тут, кстати, все очень похоже — МК, RTOS, небольшой монохромный экранчик, си.

Поэтому давайте попробуем что-нибудь под него написать. Для начала, что-то совсем простое, чтобы освоиться с SDK, не закапываясь в отладку и сложности RTOS, но функциональное. Есть кнопки, есть экранчик, давайте напишем счетчик-кликер. Нажимаете кнопку — число увеличивается. Подойдет считать посетителей, круги на стадионе, взломанные домофоны или сообщения в чате русскоязычного комьюнити флиппера (по утрам, в особенно активное время там их бывает до 2к, так что я бы на вашем месте подумал, прежде чем нажимать кнопку Join).

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

Фирма 1С активно занимается развитием IT-образования. Мы сотрудничаем с десятками университетов, и сегодня хотим рассказать о нашем новом проекте совместно с Высшей Школой Экономики (НИУ ВШЭ).

Дружба с Вышкой у нас давно. В ВШЭ действуют две наши базовые кафедры (да, мы единственная компания, у которой аж две базовые кафедры): одна на факультете компьютерных наук (ФКН ВШЭ), вторая – на департаменте бизнес-информатики Высшей Школы Бизнеса ВШЭ (ВШБ ВШЭ).

Помимо этого мы создали проектный офис в Питерской Вышке, а именно – в Высшей школе физ.-мат. и компьютерных наук.

Вот о Питере сегодня и пойдет речь.

А именно – о новой магистерской программе «Внедрение и оптимизация комплексных информационных систем» в СПб ВШЭ.

Tempest — это официальный компонент OpenStack для интеграционного тестирования. Tempest поддерживает три вида тестов: API, сценарии (scenario) и стресс-тесты (stress). API-тесты проверяют функциональность API. Сценарии имитируют сложные многоэтапные операции. Стресс-тесты запускают задания параллельно для тестирования высокой нагрузки. Tempest использует собственную реализацию клиента вместо стандартных клиентов Python, поэтому может отправлять фейковые или некорректные запросы для проверки реализации API.

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

В этой статье рассмотрим использование клиента RefStack для запуска тестов Tempest. RefStack — это инструмент, разработанный для запуска тестов DefCore. DefCore — это набор требований, которым должно удовлетворять облако OpenStack, чтобы быть сертифицированным OpenStack Foundation. На момент написания статьи последняя версия тестов 2016.01, состоящая из 306 тестов. Tempest находится в активной разработке, и если вы посмотрите ветку master у Tempest, то увидите, что 10 из 306 тестов больше не актуальны.

Многие, кто работает с Openstack или собирается разворачивать облако с его последующим использованием, начинают со временем задумываться о тестировании развернутой облачной платформы. Ведь мало развернуть облачную платформу и поставить ее конечному пользователю (тут я подразумеваю под пользователем заказчика и дальше буду также называть пользователем заказчиков, которым поставляется наша облачная платформа). При поставке облачного решения очень важно не просто предоставить продукт, а поставить продукт высокого качества. И тут возникает дилемма: как проводить тестирование продукта, который состоит из большого количества компонентов и сервисов, и все эти компоненты связаны между собой. Другая проблема заключается в том, что приватное облако VK состоит из множества компонентов, которые разработаны компанией и поставляются в коробке облака. И такие компоненты так же необходимо тестировать.

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

Так вот, задача заключается в следующем: необходимо провести функциональное API тестирование приватного облака на Openstack. Давайте немного визуализируем структуру нашего SUT, с которым мы будем взаимодействовать из автотестов:

Средние значения нагрузки (Load averages) — это критически важная для индустрии метрика. Многие компании тратят миллионы долларов, автоматически масштабируя облачные инстансы на основании этой и ряда других метрик. Но на Linux она окутана некой тайной. Отслеживание средней нагрузки на Linux — это задача, работающая в непрерываемом состоянии сна (uninterruptible sleep state). Почему? Я никогда не встречал объяснений. В этой статье я хочу разгадать эту тайну, и создать референс по средним значениям нагрузки для всех, кто пытается их интерпретировать.

В этой статье рассмотрим установку, настройку tempest и запуск тестов. Tempest — это инструмент Openstack для интеграционного тестирования. В tempest есть как наборы интеграционных тестов, так и модульные тесты для отдельных проектов, например, для neutron-lbaas. Мы настроим tempest для работы со стеком с F5 Openstack Agent и F5 Openstack LBaaSv2 driver.

Всем привет. Меня зовут Добрый Кот Telegram.

В этой статье расскажем, как развернуть кластер чистыми бинарями и парочкой конфигов.

Вошли и вышли, приключение на 20 минут)

От коллектива FR-Solutions и при поддержке @irbgeo Telegram : Продолжаем серию статей о K8S.

В конце сентября сообщество OWASP (Open Web Application Security Project) выпустило обновленную версию списка наиболее опасных угроз для веб-приложений OWASP Top-10. Примечательным стало появление в нем A10:2021 – Server-Side Request Forgery (SSRF) или подделка запроса на стороне сервера. При этом 2 из 10 категорий угроз, включая SSRF, были отобраны по результатам опросов профессионального сообщества. Пока, по оценке экспертов OWASP, позволяющие проводить атаки SSRF уязвимости с высоким уровнем критичности встречаются нечасто. Но потенциал эксплуатабельности у них высокий, и скоро SSRF может стать серьезной киберугрозой. Мы тоже встречаем SSRF при проведении работ по анализу защищенности веб-приложений, и иногда эта атака открывает пентестерам (а, значит, и реальным хакерам) массу возможностей. А каких именно – расскажем в этом посте.

Авторитет института NIST (National Institute of Standards and Technology, Национальный Институт Стандартов и Технологии) в среде специалистов по информационной безопасности фактически непререкаем. На протяжении многих лет документы NIST (специальные публикации, рекомендации и стандарты) используются мировым сообществом кибербезопасности для выстраивания логически взаимосвязанных, прозрачных, измеримых процессов обеспечения информационной безопасности и управления киберрисками. Обзор самых интересных на наш взгляд публикаций NIST будет состоять из двух частей, эта – первая. Вперед!

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

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

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

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

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

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

CLD это система для обеспечения комплексной информационной безопасности и организации разграничения доступа к серверам и скриптам с возможностью оперативно внедрять пользовательские модули и инструменты автоматизации.
Мы высоко ценим автоматизацию процессов и унификацию инфраструктуры, проект призван объединить все используемые технологии в одном централизованном и само документируемом месте, с безопасным, прозрачным и логируемым доступом к любому серверу и инструменту сразу через несколько пользовательских интерфейсов (CLI, Web, API, Telegram, Discord, Mattermost, Slack).