IT-инфраструктура *

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

Более трех лет назад в YADRO поставили цель: улучшить процессы сервисного обслуживания за счет специального проектирования продуктов. Под эту задачу выделили специалистов, которые занялись проектированием функциональности по диагностике и обслуживанию, формируя требования к продуктам компании. Придя в компанию, я возглавила направление, выстроила его работу с нуля, трансформировала команду из трех человек в отдел с сотрудниками в разных городах страны. В статье расскажу, что такое serviceability, как строится работа отдела сервисного дизайна в компании, и приведу примеры его влияния на развитие продукта.

За последние несколько лет ОАЭ достигли статуса лидера в области технологий и инноваций и привлекли внимание глобальной технологической экосистемы. Сегодня этот сектор занимает 1-е место в регионе Ближнего Востока и Северной Африки. При этом ОАЭ, в частности Дубай, за последние 3-5 лет стали настоящим глобальным IT-хабом и магнитом для IT-стартапов. Я, Евгения Тяжкина, соучредитель и генеральный директор компании Бизнес Бутик в Дубае, расскажу, как открыть IT-компанию в ОАЭ и сделать это максимально выгодно и эффективно.

Если защитные системы молчат, это не значит, что систему безопасности компании не взломали. Возможно, хакеры уже проникли в инфраструктуру — еще не наследили, но шпионят и готовятся к масштабной атаке. Такие «призраки» могут годами прятаться в корпоративной сети прежде, чем нанести удар. Тут-то на помощь и приходит практика Compromise Assessment. 

В этой статье мы разберем:

— Что это за практика и какую пользу для бизнеса приносит;
— Чем она отличается от других методик поддержания информационной безопасности;
— Почему важно проводить Compromise Assessment;
— Каким компаниям и когда целесообразно прибегать к этой практике.

Привет, Хабр!

Так получилось, что с появлением отделов, служб или подразделений, связанных с информационной безопасностью, простые сетевики, сисадмины начали от них получать рекомендации о необходимости запретить доступ от пользователей до интернет‑ресурсов. И в обратном направлении запретить трафик от тысячи IP из интернета до узлов предприятия с белыми IP. Неважно, какую роль выполняет узел, в качестве VPN‑сервера или веб‑сайта.

Подвох в том, что в рекомендациях напрочь отсутствует подсказка, чем и как блокировать трафик.

Возможно, возмутитесь и скажете, что это не касается сетевиков, сисадминов, но реалии чаще такие, что бóльшую часть «дорожной карты по ИБ» снова «скидывают» на сетевиков, сисадминов и задание должны выполнить в кратчайшие сроки.

Поэтому, в статье рассказывается почему был выбран режим «прозрачного файрволла», чем подошёл и как его настроить на межсетевом экране ATP и USG Flex для блокировки транзитного интернет‑трафика.

Привет! Я Михаил Кадер, занимаюсь в Positive Technologies архитектурой решений по ИБ. Но в этой статье я хочу поговорить не об именно информационной безопасности, а затронуть по-прежнему актуальную тему импортозамещения. Если быть совсем точным, речь пойдет о модернизации сетевой инфраструктуры в условиях, когда многие зарубежные вендоры прекратили продажу и поддержку оборудования в России.

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

Писать о регрессе в 2024 году — казалось бы, странная идея: каждый, кто хоть как-то связан с IT-миром, знает, что такое регрессионное тестирование и зачем оно нужно. В каждом курсе, в каждой статье для новичка о нем рассказывается. Вроде бы можно закрыть тему… Но почти каждый раз, когда на собеседовании я задаю вопрос: «Как мне выбрать тесты для регресса?», четкого ответа я не получаю. Это не зависит от уровня тестировщика, его опыта и направления. 

Из интереса я пристала к разработчикам, аналитикам, менеджерам и архитекторам с этим же вопросом, но получила лишь размытые формулировки и жалобы на то, что мы слишком долго проводим регресс и давно пора все автоматизировать. Такое происходит, потому что с виду простой вопрос содержит множество уровней, о которых обычно нет времени задуматься. Меня зовут Алена Вахтина и я ведущий специалист по тестированию в Лиге Цифровой Экономики. В этой статье постараюсь хотя бы частично рассмотреть такие подводные камни регрессионного тестирования.

В предыдущих публикациях мы подробно рассмотрели вопросы выбора PDU для коммерческого ЦОД, одновременно выяснив, что большинство PDU на рынке, даже под российскими брендами, – это за редким исключением разновидности китайских изделий.

Другая ситуация с серверными стойками. Если раньше на рынке широко был известен только один достойный отечественный бренд, то сейчас таких как минимум три, производство на самом деле локализовано, производители учитывают опыт ушедших лидеров рынка, а также обратную связь потребителей, в том числе и от специалистов Linx. Однако, как и в любом новом деле, в отечественных стойках встречаются «детские» болезни, которые становятся особенно очевидны при сравнении, например, с хорошо знакомыми нам стойками APC.

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

Мы продолжаем следить за тем, как меняются DDoS-атаки на критическую инфраструктуру и не только, — их интенсивностью и характером. Сегодня говорим о том, что произошло за последние полгода.

Завершилась очередная выставка Securika Moscow. Из обилия представленного я выбрал то, что заинтересовало меня больше всего остального. В результате получился некий субъективный рейтинг, который я предлагаю вашему вниманию.

Всем привет! На связи Олег Сапрыкин, технический директор по инфраструктуре и тимлид DevOps-команд во «Фланте». В марте 2024 года мы с Андреем Радыгиным (ex-главный архитектор по внедрению Deckhouse) выступили на конференции DevOpsConf. Эта статья — текстовый вариант нашего доклада о развитии и нашем опыте использования Stateful в Kubernetes.

Мы рассказали, как оценивать Stateful-компонент, прежде чем запускать его в Kubernetes, показали нюансы работы с такими приложениями, а также поделились особенностями конфигурирования и опытом использования некоторых Stateful-операторов — ClickHouse, Redis, Kafka, PostgreSQL и MySQL.

Привет, Хабр! Меня зовут Антон Аплемах, и я владелец продукта cloudfort в облачном провайдере beeline cloud. В блоге на Хабре и в нашем медиа мы рассказываем про open source, тренды в разработке программного обеспечения и облачные технологии. И сегодня я хочу поговорить про хранилища S3, запуск и настройка которых — нетривиальная задача. Какие услуги на основе объектных хранилищ использует бизнес (включая наш новый продукт cloudfort), и что учитывать при выборе решения.

Коллеги, всем привет! Меня зовут Илья Косынкин. В компании Positive Technologies я руковожу разработкой продукта для глубокого анализа трафика в технологических сетях — PT ISIM. На проектах в различных компаниях мы много сталкиваемся с практическими вопросами о том, как выстроить мониторинг ИБ в АСУ ТП. И это закономерно, ведь наша система решает именно эту задачу.

Появилась идея описать, какую пользу может принести мониторинг ИБ в АСУ ТП, не уходя глубоко в детали функциональности продуктов, их классов и возможной архитектуры внедрения в инфраструктуру компании. Только value от этого процесса, без описания cost. При этом постараюсь рассказать вам научно-популярно, без воды. А для наглядности я буду использовать в статье скрины интерфейсов наших решений.

Всем привет, меня зовут Антон Малафеев, я руководитель группы инженеров IT‑инфраструктуры в СберМаркете. Моя команда вот уже больше 3-х лет занимается разработкой деплоя для PaaS и сопутствующих инструментов.

В этой статье я расскажу об особенностях канареечного деплоя, о том, как этот процесс строится у нас в СберМаркете и какие технологии мы при этом используем. Материал будет актуален для тех, кто хочет узнать еще один способ деплоя через канарейку. Или для тех, кто только присматривается к такой возможности.

Но сначала немного цифр. Ниже на рисунке — наша статистика использования канареечного деплоя. На момент написания статьи у нас в проде 200+ сервисов, 5300 подов PaaS, ежемесячно мы делаем 2 тысячи деплоев в продакшн и 11 тысяч деплоев в стейдж, которые проходят через канарейку.

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

Данная статья это авторский перевод/русскоязычная версия моей статьи на Medium, и первая из цикла про этот интересный инструмент.

Пожалуй, наиболее адекватным эпиграфом будет перефразированный английский перевод частушки «по реке плывет топор»:

Down the pipeline flows the code
From the towers of London.
Let it setup by itself
On this fancy piece of iron

Как это часто бывает, данный проект появился в результате случайности. Я всего лишь устанавливал Ubuntu на новую Dell rack workstation, когда элементарная задача неожиданно превратилась в «увлекательную». Зато открыло для меня совершенно новый уровень.

Этот материал создан коллективными усилиями преподавателя и студента. Первый и четвертый этапы были разработаны студентом, второй и третий — преподавателем, а пятый этап — результат совместной работы.

Привет, Хабр! На связи команда ad-hoc аналитики и модельного риска X5 Tech. В прошлой статье про модельный риск мы познакомились с концепцией risk-management’а для моделей машинного обучения в корпорации и оценили, какую пользу может принести модельный риск как для команд-разработчиков и аналитиков, так и для компании в целом.

В этой статье мы продолжим тему модельного риска, раскроем чуть больше секретов о том, как это устроено в X5 Tech и обсудим некоторые технические аспекты реализации подобной системы.