Сегодня об искусственном интеллекте не говорит только ленивый. Но для владельца реального бизнеса — будь то сеть ресторанов, ритейл или сфера услуг — все эти разговоры часто звучат слишком абстрактно. Как конкретно взять AI и встроить его в уже работающие процессы, чтобы он начал приносить измеримую пользу: повышать средний чек, укреплять лояльность клиентов и делать их опыт по-настоящему персональным?
Bluetooth десятилетиями связывал наши устройства «по воздуху» — от беспроводных наушников до умных замков. Но за это время протокол пережил ряд катастрофических уязвимостей: от BlueBorne, позволяющей атаковать устройства без единого клика, и цепочки дыр в BLE Secure (KNOB, BLESA и другие) ломало защиту на корню.
Как же за эти годы эволюционировали механизмы безопасности, чтобы сегодня Bluetooth оставался надёжным фундаментом для миллиардов устройств? Подробности — далее.
mdadm для отказоустойчивости, bcache — для ускорения медленных HDD, cryptsetup — для шифрования данных, LVM — потому что нужно создавать в рейде несколько блочных устройств, и btrfs — за любовь к сжатию и снапшотам. А теперь прихожу я и говорю, что все это можно заменить одной файловой системой — ZFS. Как именно? Под катом разберемся в ее устройстве, но без излишнего погружения — не будем превращать статью в «простыню».
В 2024 году рынок SSD-накопителей вступил в новую фазу развития — SK Hynix и Samsung представили накопители с объемом 61,44 ТБ, а Solidigm начала продажи SSD D5-P5336 рекордной емкостью 122,88 ТБ.
Попытки создать сверхъемкие SSD предпринимались и раньше. В 2018 году компания Nimbus Data анонсировала ExaDrive DC100 — накопитель емкостью 100 ТБ для корпоративного сегмента, который начал продаваться в 2020 году. Однако его цена в 40 000 долларов и ограниченная доступность сделали его скорее технологической демонстрацией, чем массовым продуктом. Сегодня же высокоемкие SSD становятся всё более доступными.
В этой статье проанализируем, как будет развиваться емкость SSD-накопителей в ближайшие годы, какие объемы хранения данных станут доступны к 2027 году и сможет ли SSD окончательно вытеснить HDD в корпоративном сегменте.
Если внедрять и поддерживать ITSM-систему, обязательно столкнешься с заявками по ошибочно выбранным услугам и прочими неприятностями.
Привет, Хабр! Я — Ксения Попова, младший бизнес-аналитик в ITSM 365. Сейчас расскажу, как мы минимизируем проблемы в предоставлении сервисов.
Тема ошибок, которые могут допускать специалисты в различных областях, практически неисчерпаема, но некоторые ошибки, вернее, их результаты, могут быть заметны далеко не всем. Так, ненастроенное журналирование событий совершенно незаметно обычным пользователям. И даже взлом, который произошел из‑за этих ненастроенных событий, тоже вряд ли заметят пользователи, если только потом об этом напишут в новостях.
Но вот ошибки при проектировании и эксплуатации сети становятся заметны сразу и всем — в случае если они приводят к проблемам в работе сети. В этой статье мы попробуем сделать разбор наиболее распространенных ошибок, которые могут допустить как проектировщики при планировании архитектуры сети, так и сетевые администраторы при эксплуатации.
ИТ-стойка — базовый, но стратегически важный элемент инфраструктуры дата-центра. От правильного выбора серверного шкафа зависит не только эффективность размещения оборудования, но и надежность и, как это ни странно, энергоэффективность всей инженерной инфраструктуры. А еще правильный выбор ИТ-стойки сокращает время установки и обслуживания оборудования, т.е. экономит время инженеров, и делает этот процесс понятным и даже приятным.
В этой статье разберем ключевые критерии выбора ИТ-стоек и расскажем, какие преимущества предлагают стойки Uniprom Rack от Systeme Electric, уже зарекомендовавшие себя в сложных проектах.
Привет, меня зовут Анатолий Чикирев, и сегодня я расскажу вам о Lean-практиках сокращения потерь в IT-сфере. Для начала давайте договоримся о терминологии. Lean и бережливое производство — это синонимы. Я буду использовать оба термина, но речь пойдёт об одном и том же. Но сначала пара слов обо мне и моём опыте.
Я работаю продактом в SM Lab с 2022 года, в целом в IT пришел в 2018 году — тогда я занимался заказной разработкой. Впервые я узнал о бережливом производстве в Высшей школе экономики, где изучил базовую теорию и основные понятия. Уже тогда мне показалось это интересным, но, разумеется, практики ещё не было никакой. Потом я пришел на свою первую работу на завод, где участвовал в пилотном проекте по внедрению Lean с привлечением консультантов. Там я руководил проектным офисом, поэтому сам проект видел больше с административной точки зрения и только несколько раз выходил «в поле» с руководителем проекта, а глубже в суть методологии погрузился уже позже.
Следующим этапом стала работа в международной FMCG-компании, где бережливое производство уже было внедрено, и я пришёл, как говорится, «на готовенькое»: моей задачей было поддерживать систему, развивать её и внедрять новые инструменты и практики, которые предлагала международная команда. Именно тогда я по-настоящему прочувствовал пользу и мощь Lean, увидев, как эти принципы работают на практике в производстве и какой эффект они могут приносить бизнесу.
Когда я перешёл в IT (сразу после той самой FMCG-компании), у меня возник большой вопрос: «А работает ли Lean здесь?». Я понимал, что теоретически — должно. Но как именно это применять? Как перенести инструменты, которые я применял на производстве, на IT-процессы? Поначалу это было неочевидно. Со временем, когда я освоился и в IT, и в роли продакта, и в самой SM Lab, всё встало на свои места. Я разобрался, как Lean может работать здесь, начал внедрять его на практике — и применяю до сих пор.
Всем привет! Продолжаем погружение в ИТ-инфраструктуру глазами хакера. В предыдущей статье мы рассказали про процесс создания графа моделирования киберугроз – цифровой модели инфраструктуры, которая учитывает потенциальные действия злоумышленников, и про алгоритмы, которые рассчитывают возможные маршруты перемещения атакующих внутри системы.
Следующий шаг – это оценка опасности найденных маршрутов. В этом случае, метрика времени атаки – это один из ключевых параметров анализа. Чем меньше времени потенциально требуется для реализации атаки, тем больше вероятность, что средства защиты и ИБ-специалисты не смогут вовремя обнаружить злоумышленника и остановить взлом. Что же нам даёт метрика времени?
Первая бета уже скачана и установлена, сессии просмотрены. Начинается пора тестирования новой macOS. В этой статье мы сделаем краткий обзор новых возможностей по управлению устройствами Apple в корпоративной среде и образовании. Материалы по обзору новой macOS Tahoe для сисадминов уже в работе и будут поспевать к традиционному осеннему релизу.
Можно выделить два направления развития инфраструктуры квантовых вычислений: больше кубитов или больше чипов, объединенных в сеть. Посмотрим, кто занимается такими проектами и что в целом происходит с квантовыми коммуникациями в мире.
У нас были две сотни брокеров, шесть тысяч топиков, клиенты на четырех языках программирования, миллионы сообщений в секунду и целое море различных паттернов использования Kafka. А также жесткие требования по latency, тонна SLA и желание сделать гибкую систему аутентификации и авторизации для сервисов. Не то, чтобы все это было категорически необходимо для начала этой истории, но если уж начал рассказывать про асинхронные взаимодействия, то иди в этом до конца.
Единственное, что меня беспокоило — это авторизация. В мире нет ничего более желанного для ИБ и ненавистного разработчиками, чем контроль доступа. И я знал, что довольно скоро мы доберёмся и до этого вопроса.
Если вам интересно распутать клубок асинхронного взаимодействия тысяч продюссеров и консьюмеров, узнать, где документация Kafka нас обманывает, а librdkafka и Confluent.Kafka не могут договориться, и как один потерянный пакет может привести к Permission denied, добро пожаловать под хабракат. Эта история для тех, кто догадался, что недостаточно было «просто включить флажок в конфиге».
Привет, Хабр! Меня зовут Виктор Корейша и я — руководитель направления Managed Services в Ozon. Я и моя команда, в том числе, отвечаем за всю инфраструктуру асинхронного взаимодействия между сервисами, которую строим на базе Kafka. А ещё я ведущий подкастов «Кода кода» и «Три тимлида заходят в бар».
Эта статья написана по мотивам моего доклада для DevOps Conf 2025. Расскажу нашу историю про внедрение авторизации и аутентификации в Kafka. Инженеры по эксплуатации найдут в ней обзор решений реализации SASL-сервера, разработчики — историю о конфликтах в production-ready клиентах, архитекторы — любопытные кейсы взаимодействия высоконагруженных систем, ну а менеджеры — эпос о внедрении технически сложных изменений в больших компаниях.
Любой бизнес — от индивидуального предпринимателя до крупной международной компании — вынужден адаптироваться под запросы рынка и потребности потребителей. А поскольку сегодня бизнес практически неотделим от ИТ: потребность в изменениях бизнес-процессов = потребности в изменениях в ИТ.
Изменения могут носить эпизодический характер, быть шаблонными и регулярными, малыми и большими по объему, масштабу и бюджету. Однако, изменения — не всегда про улучшения. Иногда, если что-то работает ну уж слишком хорошо, можно это и «ухудшить» в хорошем смысле этого слова. Например, снизить уровень сервиса, или сделать круглосуточную службу некруглосуточной.
Южная Корея запускает KISTI-6 — самый мощный суперкомпьютер в стране. В качестве подрядчика Корейский институт научной и технической информации (KISTI) выбрал Hewlett Packard Enterprise (HPE).
Компания возьмет на себя строительство шестого по счёту кластера KISTI, получившего название KISTI-6. Он станет самым мощным суперкомпьютером в Южной Корее с передовой системой безвентиляторного прямого жидкостного охлаждения.
Применение данной технологии обеспечит плотность размещения, эффективность и устойчивость системы на новом уровне.
По моему опыту, все обновления Cisco ACI, начиная с мажорной версии 4 и далее, ставили только одну серьезную задачу — найти достаточно чая, чтобы пить его на протяжении обновления фабрики. Кроме шуток, процесс построен очень удачно, и справиться с ним может даже сотрудник с junior-подготовкой, естественно, если заранее ознакомится с Release notes и рекомендациями вендора. Но в этот раз все пошло не по плану.
На обновление фабрики у нас ушло несколько бессонных суток, в течение которых мы пережили частичный выход из строя кластера, выход из строя RAID контроллера одного из серверов и, потенциально, полный wipe топологии... Но все закончилось хорошо, мы обновили фабрику, решили проблему заказчика, а самое главное – получили по островку седых волос бесценный опыт.
Меня зовут Сергей Балдаков, в компании К2Тех наша команда занимается комплексной технической поддержкой мультивендорной инфраструктуры. В том числе производителей, ушедших из России. Надеюсь, наш опыт поможет инженерам, которые обслуживают оборудование без поддержки вендора и позволит избежать граблей, которые мы с лихвой насобирали в этой истории.
Контейнеры падают, а вы узнаёте об этом постфактум? Ошибки в логах проходят мимо?
Собрал Rattle за три дня — простой self-hosted инструмент, который отправляет события из Docker в Telegram. Без лишних панелей, без сложной настройки — просто работает и сообщает о самом важном.
В статье рассказываю, зачем он мне понадобился, как устроен внутри и как можно быстро развернуть его у себя. Покажу Telegram Mini App, через которую удобно управлять уведомлениями.
📎 Ссылка на репозиторий: github.com/rattle-bot/rattle
Привет, Хабр! Меня зовут Павел Князькин, я системный архитектор в команде платформы виртуализации zVirt в компании Orion soft. Отказоустойчивость — важнейшая характеристика системы виртуализации, поэтому мы регулярно проверяем ее, имитируя различные кейсы отключения оборудования. Сегодня мы протестируем:
• Поведение системы и ВМ при разрыве соединения между сервером и менеджером управления при различных настройках ВМ;
• Срабатывание функциональности HA при отсутствии коммуникации с хранилищем;
• Отказ одного из сетевых адаптеров сервера;
• и все это на примере 7 различных настроек ВМ.
Привет, Хабр, с вами Вера Орлова и Саша Журавлев (@Zhurma) — мы отвечаем за контейнерную безопасность в Cloud.ru и возглавляем команду спасателей для решения проблем в этой сфере. Атаки на инфраструктуру с каждым днем становятся всё изощреннее, поэтому при организации безопасности контейнеров важен комплексный подход.
В прошлой статье мы уже делились нашим опытом защиты от киберрисков. В этой — расскажем историю, что бывает, если вовремя не защитить контейнер, и что делать, чтобы с вами такого не приключилось. И помогут нам в этом несколько базовых сервисов, которые быстро приходят на помощь, чтобы устроить полную доминацию над уязвимостями в контейнерной инфраструктуре.
При планировании репликации, аварийного восстановления, резервного копирования и восстановления данных мы выбираем из нескольких стратегий — в зависимости от требований к уровню SLA по восстановлению данных и приложений. Ключевые факторы при выборе включают в себя целевое время восстановления (RTO) и целевую точку восстановления (RPO). Синхронная репликация дает минимальную RPO, что означает невозможность потери данных. Ceph может реализовать синхронную репликацию между локациями, «растянув» свой кластер на несколько дата-центров.
Асинхронная репликация по своей сути подразумевает ненулевое значение RPO. В Ceph асинхронная multi-site репликация подразумевает репликацию данных в другой кластер Ceph. Каждый метод доступа к хранилищу (объект, блок и файл) обладает собственным методом асинхронной репликации, реализованным на уровне конкретного компонента Ceph.
Если кто-то ещё думает, что дата-центр — это про стойки, клауд и «пятую зону отказоустойчивости», стоит посмотреть на его платёжку за свет. В реальности ЦОД — это про энергетику: большинство современных ЦОДов потребляют мегаватты ежедневно, и именно за киловатты приходится платить больше всего.
Даже если ИТ-нагрузка у вас составляет 1 мегаватт, реальное потребление ЦОДа будет 1,5–2 МВт — в зависимости от архитектуры. И пока стоимость железа и лицензий списывается по амортизации, электричество капает в счёт каждый час. День за днём. Год за годом.
Эта статья — про то, почему энергия дороже всего, как устроено энергопотребление дата-центров и почему архитектурные решения, режимы охлаждения и плотность стоек в итоге превращаются в рубли.