Так обычно начинается повесть о созданном в рекордные сроки дашборде. А потом боль и унижение, и никто не хочет брать на себя ответственность, когда упал прод, потому что BI‑аналитик выгружал 90 миллионов строк join’ом без фильтра. А вашему бизнесу всё равно, кто виноват. Данные не пришли, отчёта нет, шеф злой.
В работе с публичными облаками много плюсов, но с точки зрения ИБ — есть свои риски по сравнению с on‑premises. Минимизировать их помогает выделенный Security Operation Center (SOC). При этом создать его у себя не так просто: для эффективной работы SOC в Yandex Cloud понадобилось несколько лет разработки, а также технологии и мощности Яндекса, которые развивались годами.
Поскольку у клиентов облака не всегда есть ресурсы и экспертиза, чтобы создать подобный SOC у себя, мы не только строили свой центр, но и параллельно делали на его основе управляемый сервис Yandex Cloud Detection & Response (YCDR). В процессе разработки мы должны были позаботиться о том, чтобы даже привилегированные учётные записи не могли обойти семь слоёв облачной безопасности, — и в итоге многие компоненты написали самостоятельно.
— Первая часть статьи для тех, кому важны механизмы безопасной изоляции ресурсов. Покажем, как мы строили SOC c учётом особенностей облачной защиты.
— Вторая часть для тех, кто интересуется большими данными. Продемонстрируем, что скрывает под капотом сервис, обрабатывающий более полумиллиона событий в секунду. А также расскажем, почему нам потребовалось создать для него собственную SIEM‑систему.
К сайтам медучреждений больше требований, чем к сайтам других бизнесов.
Вы можете игнорировать и отрицать это, но за несоблюдение правил платить штраф всё равно придётся.
Есть альтернативный вариант — доработать свой сайт и в разы снизить риски проблем с законом.
Как это сделать, чему уделить внимание, какие документы и согласия подготовить, я рассказала здесь: собрала всё самое важное и актуальное.
Наш ЦОД «Медведково», о котором мы уже рассказывали, в 2024 году стал кластером, так как рядом был построен еще один дата-центр — «Медведково-2». В этой статье мы покажем, как устроен новый ЦОД.
Здание «Медведково-2» возвели за год, параллельно проводили интеграцию инженерных систем. К 2024 году ЦОД полностью подготовили для проведения аудита и сертификации. Дата-центр успешно прошел испытания Uptime Facility и получил сертификат Tier III.
Все мы любим SQLite. Это идеальный движок БД, компактная библиотека размером менее 1 МБ, быстрая, автономная и неубиваемая. Более того, это в принципе удобный способ хранения информации, поскольку СУБД выигрывает у файловой системы по скорости доступа, сжатию, функциональности полнотекстового поиска и т. д. Например, она вдвое быстрее файловой системы Ext4 под Linux.
SQLite — самая популярная в мире СУБД. Как рассказывалось в статье «Безумные и забавные факты о SQLite», в мире активно используется более триллиона (!) БД SQLite, это невероятное число. Просто она встроена во все смартфоны, браузеры, операционные системы и бесчисленное число других приложений.
Проект по построению DWH с нуля был запущен по инициативе Заказчика в рамках крупной трансформации управленческой отчетности и аналитики.
В статье расскажу, как мы выстроили архитектуру DWH, какие подходы использовали на каждом уровне, с какими подводными камнями столкнулись и как обеспечили стабильную поставку данных для аналитики.
Любой гайд по Обсидиану начинается с совета не использовать плагины, дабы не усложнять систему и собственную жизнь. Большинство после этого тут же советует пару базовых плагинов - ну без которых вот прямо совсем сложно жить. На днях мне вообще попалась статья, где человек пытался сделать картотеку людей, но вместо того чтобы просто делать картотеку, он копировал какие-то шаблоны вручную, после чего написал мануал, как автоматизировать этот бесполезный труд.
Интересно то, что идея картотеки была взята из картотеки Джона Рокфеллера с отсылкой на Rolodex. И вот это реально интересная штука, которая меня сильно заинтересовала и дала вдохновение для её цифровой реализации.
Серверные обычно ассоциируются с дисками, сетями и бесперебойниками, но иногда в них попадаются экзотические сюрпризы. И если уже ставшая баяном новость про найденную в серверной противотанковую ракету 9M14 «Малютка» была фейком для сбора реакций, то в этой статье я расскажу о других находках сисадминов. Приглашаю под кат и в комментарии с вашей историей о неожиданных находках.
В статье рассказывается о типичной проблеме синхронизации данных между микросервисами через связку «снапшот + инкременты» и предлагается решение на основе Kafka Compact Topics. Это своего рода «волшебная тетрадь», которая автоматически оставляет только последние версии записей, избавляя от головной боли с рассинхронизацией.
Разбираются практические кейсы применения, подводные камни, тонкости настройки и интеграция с Debezium для автоматической выгрузки из PostgreSQL.
Что получите: понимание, когда компактные топики решают проблему, а когда лучше использовать классические подходы, плюс готовые конфиги для быстрого старта
Предыстория
Моя команда занимается разработкой медицинского ПО: приложения для передачи направлений пациентов в системе здравоохранения Австралии.
Принцип заключается в следующем: если терапевту нужно направить пациента для предоставления вторичных услуг здравоохранения, например, в стационар или в специализированную клинику, он должен написать направление с информацией о пациенте, его истории и причине направления. В прошлом эти операции выполнялись по факсу; это явно устаревшая технология, к тому же многие направления отклонялись, потому что в них отсутствовала часть необходимой информации.
Система электронных направлений удобна для всех. Когда врач создаёт новое направление, мы автоматически извлекаем информацию из PMS (patient management software, системы управления пациентами, которой владеет наша компания) с данными пациента, этнической принадлежностью, индексом массы тела, принимаемыми лекарствами, медицинской историей и всем остальным, что необходимо для направления. В бланке направления есть валидируемая «форма специализации» с полями, относящимися к конкретной услуге, для которой выписывается направление.
Благодаря этому в направлении содержится вся необходимая информация. И, разумеется, в форме также есть большое текстовое поле для свободного текста (referral letter), в котором терапевт может объяснить, почему он решил выписать пациенту направление.
При отправке направления данные передаются в цифровом виде. Они преобразуются в один из нескольких форматов в зависимости от получателя. Некоторые получатели используют для приёма направлений наш продукт Referral Manager; в этом случае нам не нужно ничего преобразовывать, они просто получают доступ в веб-интерфейсе к тем данным, которые хранятся в базе данных. Однако обычно данные преобразуются в HL7 (старый текстовый формат файлов медицинской информации), CDA (XML-документ с отдельной таблицей стилей) или просто в PDF с человекочитаемой информацией. Благодаря этому данные совместимы со множеством различных электронных систем других компаний.
Также выполняется сохранение PDF-копии направления в PMS врача для ведения его собственной картотеки. Это позволяет ему просматривать всю историю пациента в PMS без необходимости поиска документов в куче приложений разных разработчиков.
Системы хранения данных являются одним из обязательных компонентов построения центров обработки данных, особенно с учетом все большего объема генерируемой и потребляемой информации, также роста цифровизации услуг.
В этой статье мы рассмотрим различные виды СХД, и постараемся простыми словами описать их различия и отличительные особенности.
Мы надеемся, что этот материал поможет вам лучше ориентироваться в типах СХД и обычных сценариях их применения, так как выбор СХД определяется задачами, которые вы собираетесь решать с её помощью.
В современной цифровой экономике самый ценный ресурс — данные. Случается так, что инфраструктура для управления ими стремительно превращается из инструмента роста в причину трат, источник рисков и препятствие на пути к дальнейшему росту. Руководители сталкиваются с противоречием: с одной стороны ценность информации нужно приумножать, с другой — не утонуть в сложности и расходах. Решение этой дилеммы определяет не просто IT-стратегию, а конкурентоспособность и долгосрочную жизнеспособность бизнеса.
В этой статье мы проведем сравнительный анализ самостоятельного развертывания баз данных и управляемых DBaaS-решений. Посмотрим, какая модель дает стратегическое преимущество. Подробности под катом!
Привет, Хабр!
Когда речь заходит об отказоустойчивости между ЦОДами, метрокластер — почти всегда первое, что приходит в голову. Раньше это был стандарт: один ЦОД падает — второй подхватывает. Все работает, данные не теряются. Вместе с уходом западных вендоров их решения ушли вместе с ними либо появились огромные трудности с их конфигурированием и поддержкой.
С 2024 года у нас на тестовом стенде стоят системы хранения AQ440 от «Аэродиск». Мы их активно «мучаем»: имитируем отказы, нагружаем, меряем задержки, устраиваем испытания на выживание. Наш выбор связан с тем, что это единственное решение (на данный момент), у которого есть поддержка метрокластера. И основной фокус сегодняшнего рассказа — описать сценарии работы этой технологии. Не имитацию, не полумеру, а рабочую схему с реальным переключением между площадками, отказами и всем, что из этого следует.
«- Внимание! Нагрузка растёт неравномерно! О нет, ручное управление не помогает…
- Сбой! Повторяю: сбой! Инфраструктура падает!
- Нужно больше ресурсов!»
Звучит как сцена из фантастического фильма-катастрофы, но в компаниях с большим количеством хостов и высокой нагрузкой на них так могут выглядеть и обычные рабочие будни. Хабр и Octopus решили опросить айтишников из компаний с развитой инфраструктурой, чтобы узнать как те справляются со своими IT-ресурсами, какие инструменты для этого задействуют и чего им не хватает для счастья работы без перегрузок и нервов.
1. Назначение
CJON – это легковесный, компактный и человекочитаемый формат, предназначенный для использования в условиях ограниченных каналов связи, таких как SMS, DTMF, и низкоскоростная радиосвязь. Его основное назначение – передача структурированных телеметрических или управляющих данных в случаях, когда традиционный JSON слишком объёмен, а бинарные форматы непрактичны или плохо читаемы.
2. Области применения
• Дистанционная телеметрия для сельского хозяйства и промышленного оборудования
• Аварийные сообщения и тревоги
• Автоматизация в условиях низкоскоростной или оффлайн-связи
• Мобильные устройства, передающие структурированные данные через SMS или голосовую связь
• Передача данных по DTMF через GSM-сети
В статье рассматривается применение трассировок стандарта OpenTelemetry для реализации инструментов мониторинга микросервисов на базе продукта Smart Monitor. Решаются задачи инвентаризации сервисов и ресурсов, анализа трассировок и формирования модели здоровья микросервисных архитектур.
Всех постоянно интересует, как сделать Postgres быстрее, эффективнее и всё такое, но никто не задумывался, как её замедлить. Да, большинству этих людей платят за то, чтобы они повышали скорость, но ко мне это не относится. Недавно я писал более полезное руководство, и мне вдруг пришла мысль, что кто-то должен попробовать создать такую конфигурацию Postgres, которая будет настроена на максимально медленную обработку запросов. Зачем? Сложно сказать, но вот такая возникла мысль.
Привет, Хабр! Меня зовут Евгений Мартынов, я директор по информационным технологиям в Рег.ру. В декабре 2024 года мы запустили сервис объектного хранилища S3, построенный на Ceph. Тогда это был MVP с минимально необходимым функционалом — сейчас мы вышли из беты, добавили ключевые возможности, расширили хранилище и накопили первые 130+ ТБ пользовательских данных.
В этой статье я решил поделиться опытом облачной команды Рег.ру: почему выбрали Ceph, как проектировали квоты, масштабировали инсталляцию без остановки сервиса, какие вызовы нас ждали на проде и как мы их решили.
Привет, Хабр! Меня зовут Кирилл Белов (@KirillBelovTest на Хабре), я инженер по автоматизации тестирования. На работе я администрирую виртуальные машины и часто задумываюсь о том, насколько надежен доступ к той или иной виртуалке или сервису, который на ней запущен. На Хабре у меня уже почти два десятка статей, и сегодня я хочу рассказать о сервисе управления паролями Пассворк.
У нас в компании тоже используется корпоративный менеджер паролей, поэтому мне было особенно интересно сравнить функциональность Пассворка и нашего текущего менеджера. Перед тем как попробовать новую версию, я прочитал обзорную статью, где уже был подробный разбор возможностей.
Мне не хочется повторяться, поэтому я сосредоточусь только на нововведениях версии 7.0: изменении групп и ролей, улучшении пользовательского интерфейса, повышении безопасности, а также обновленной версии Python connector. Разбирать буду коробочную версию сервиса. За подробностями добро пожаловать под кат!
