Системное администрирование *

Бессерверные вычисления: почему ваш код может стать заложником провайдера

Бессерверная архитектура обещает не думать об инфраструктуре, но скрывает риски vendor lock-in, которые проявятся слишком поздно. Пока вы наслаждаетесь отсутствием серверов, ваша бизнес-логика медленно превращается в заложника облачного провайдера.

Проблема:

• Cold start в критичных приложениях достигает 10-15 секунд

• Стоимость непредсказуема при скачках нагрузки

• Локальная разработка и отладка превращаются в квест

Реальные кейсы:

python

# Проблема: разрыв между продакшеном и локальной средой
def lambda_handler(event, context):
    # На локальной машине работает
    # В AWS Lambda падает с таймаутом
    return expensive_operation()  # 25+ секунд

Что мониторим в бессерверной среде:

1. Performance

   • Холодные/горячие старты

   • Потребление памяти

   • Execution duration

2. Безопасность

   • Права IAM-ролей

   • Доступ к секретам

   • Цепочки вызовов функций

3. Экономика

   • Стоимость вызова

   • Количество параллельных исполнений

   • Использование сторонних сервисов

Когда бессервер оправдан:

• Обработка событий с неравномерной нагрузкой

• Фоновые задачи (генерация отчетов, ночные джобы)

• API с низким RPS

Альтернативы:

• Kubernetes + Knative — гибридный подход

• Cloudflare Workers — edge-вычисления

• Self-hosted FaaS — полный контроль

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

ITAMday 2025: играем и выигрываем с «Инферит ИТМен»

Привет, Хабр! 👋
Меня зовут Данила Трусов, я директор продукта «Инферит ИТМен».

31 октября в Москве пройдет юбилейная X конференция ITAMday 2025 — ключевое событие для специалистов по управлению ИТ-активами. Ежегодно она собирает сотни практиков и экспертов, чтобы обсудить лучшие кейсы, обменяться опытом и взглянуть в будущее индустрии.

В этом году я выступлю с докладом «Агрегация — это еще не все: почему рынку требуется отдельный класс инструментов дискаверинга с гибкой настройкой под любую инфраструктуру в 2025–2028 годах».

Мы разберем:

• почему российские вендоры и аналитики делают ставку именно на дискаверинг, а не на простую агрегацию;

• зачем отдельный класс решений по дискаверингу необходим для ITSM/ ITAM/ SAM;

• какие подходы позволяют добиться 100% прозрачности и безопасности инфраструктуры;

• на что обратить внимание при выборе и настройке решений enterprise-уровня;

• как сохранить мультивендорность при контроле ИТ-ландшафта.

А еще мы подготовили для участников активность от «Инферит ИТМен» — динамичный онлайн-квиз. Проверите знания, получите драйв и сможете выиграть крутые призы:

🎁 Главный приз — ноутбук бизнес-класса INFERIT Mercury 15.6" i5-1334U
🥈 Подарки за второе и третье место
📸 Отдельный приз победителю фотоконкурса

ITAMday — это не только про доклады и нетворкинг, но и про живые впечатления. Будет азартно, полезно и кто-то уйдет домой с ноутбуком под мышкой 😉

📅 Когда: 31 октября 2025
📍 Где: Radisson Blu Олимпийский, Москва

Жду вас на ITAMday 2025 — на своем докладе и в квизе от «Инферит ИТМен»!

Контейнеры не панацея: скрытые затраты на содержание Kubernetes, о которых молчат вендоры

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

Что не учитывают при внедрении:

• Эффективность нод: В среднем 35-40% ресурсов простаивают "на всякий случай"

• Стоимость сетей: Service mesh + CNI добавляют 15-20% к потреблению CPU

• Трудозатраты: 1 инженер на 3-5 кластеров — утопия для средних компаний

Реальные метрики из практики:

bash

# Анализ утилизации за 3 месяца
kubectl top nodes | awk '{sum += $3} END {print "Средняя загрузка:", sum/NR "%"}'
# Результат: 41% по CPU, 28% по памяти

Где теряем деньги:

1. Overprovisioning
   "На всякий случай" развертываем на 200% больше ресурсов

2. Сложность мониторинга
   Требуется отдельный стек: Prometheus + Grafana + Alertmanager

3. Безопасность
   Pod Security Policies, network policies — +20% к времени развертывания

Когда Kubernetes оправдан:

• 50+ микросервисов

• Непредсказуемая нагрузка

• Команда из 3+ DevOps инженеров

Альтернативы для средних проектов:

• Nomad — проще оркестратор без привязки к контейнерам

• Docker Swarm — для простых сценариев

• Managed k8s — если нет своей экспертизы

Вывод:
Kubernetes — мощный инструмент, но не серебряная пуля. Прежде чем прыгать в эту экосистему, посчитайте TCO и убедитесь, что сложность управления не съест всю экономию от контейнеризации.

#Kubernetes #DevOps #контейнеризация #TCO #микросервисы

А как у вас с реальной утилизацией ресурсов в k8s? Делитесь наблюдениями в комментариях.

Записки параноика: почему Zero Trust — это не мода, а новая реальность для ИТ-инфраструктуры

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

Почему Zero Trust — это не просто buzzword:

• 68% компаний сталкивались с инцидентами внутренних угроз

• Среднее время обнаружения нарушителя в сети — 207 дней

• Традиционные VPN стали главным вектором атак в 2024

Как мы внедряли Zero Trust без переписывания всей инфраструктуры:

Сегментация на микроуровне:

yaml

# Instead of: Allow 10.0.0.0/8
# We use: 
- name: db-access
  source: app-server-01
  destination: postgres-01
  port: 5432
  auth: mTLS + service-account

Service Mesh вместо VPN:

• Istio для взаимной аутентификации сервисов

• Автоматическое шифрование всего трафика

• Детальный контроль доступа на уровне L7
  
  Непрерывная верификация:

bash

# Проверка целостности хостов каждые 30 сек
sudo attestation-agent verify --policy strict

Технические вызовы, с которыми столкнулись:

• Производительность: Overhead Istio ~3ms на hop

• Сложность отладки: Трассировка запросов через 5+ сервисов

• Миграция: Постепенный перенос legacy-систем

Метрики после 6 месяцев работы:

• Время сдерживания атаки сократилось с часов до минут

• Количество инцидентов снизилось на 73%

• Audit trail для compliance стал детализированным

Ключевые инсайты:

1. Начинайте с идентификации — без точной инвентаризации сервисов ничего не выйдет

2. Поэтапное внедрение — от критичных workload к периферии

3. Автоматизация политик — ручное управление не масштабируется

Zero Trust — это не продукт, а архитектурный принцип. И да, он требует изменений в менталитете команды больше, чем в технологиях.

Post-Quantum Cryptography: тихая революция в инфраструктуре, которую нельзя игнорировать

Пока большинство обсуждает ИИ, в мире криптографии происходит настоящая революция. NIST утвердил первые стандарты постквантовой криптографии, и это потребует фундаментальных изменений в ИТ-инфраструктуре уже в ближайшие 2–3 года.

Проблема:

Современные алгоритмы (RSA, ECC) могут быть взломаны квантовыми компьютерами в обозримом будущем. Миграция на PQC — не вопрос «если», а вопрос «когда».

Что меняется:

• Размер ключей увеличивается в 5-10 раз

• Процессоры испытывают нагрузку на 30-50% выше

• TLS-хендшейки становятся значительно объемнее

Наши тесты с OpenSSH 9.8:

bash

# Стандартный ключ Ed25519: 68 байт
# PQC-ключ Dilithium3: 1842 байта
# Рост трафика при подключении: ~2700%

Практические рекомендации:

1. Аудит инфраструктуры:

python

# Скрипт для поиска уязвимых сервисов
import ssl
for protocol in ['TLSv1.2', 'TLSv1.3']:
    ctx = ssl.create_default_context()
    ctx.set_ciphers(protocol)

2. План миграции:

• 2025: Тестирование гибридных схем (PQC + традиционные алгоритмы)

• 2026: Перевод внутренних сервисов

• 2027: Полный переход для внешних endpoint

3. Аппаратные требования:

• CPU с поддержкой AVX2/AVX-512

• Увеличение буферов сетевых карт

• +30% к оперативной памяти для сертификатов

Метрики производительности после перехода:

• 📉 Throughput VPN: снижение на 15%

• 📈 Потребление CPU: рост на 40%

• ⏱️ Время TLS-хендшейка: +80 мс

Вывод:

Откладывание перехода на PQC аналогично игнорированию проблемы Y2K в 90-х. Уже сегодня нужно начинать тестирование и планирование, чтобы избежать хаотичной миграции под давлением регуляторов.

Уже проводили тесты с постквантовыми алгоритмами? Делитесь результатами в комментариях — соберем статистику по разным конфигурациям.

Когда TLS 1.3 ломает мониторинг: тонкая настройка под новые протоколы

С переходом на TLS 1.3 многие системы мониторинга внезапно "ослепли". Старые методы перехвата трафика перестали работать, а бизнес требует полной видимости. Разбираем, как адаптировать мониторинг под современные стандарты безопасности.

Проблема:

• eSNI и Encrypted Client Hello шифруют метаданные подключения

• PFS (Perfect Forward Secrecy) делает историческую расшифровку трафика невозможной

• 70% инструментов мониторинга показывают "encrypted traffic" вместо полезных метрик

Решение через eBPF:

bash

# Вместо SSL-инспекции - анализ системных вызовов
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_connect {
    printf("%s → %s:%d\n", comm, args->uservaddr, args->port);
}'

Наша реализация:

1. Мониторинг на уровне ядра - eBPF-программы для анализа сокетов

2. Анализ временных метрик - latency между SYN и ACK без расшифровки содержимого

3. Косвенные метрики - количество новых соединений, размер передаваемых данных

Конфигурация для Prometheus:

yaml

- job_name: 'ebpf_metrics'
  static_configs:
    - targets: ['node-exporter:9100']
  metrics_path: /ebpf
  params:
    module: [tcp_tracer]

Результаты:

• Обнаружили 40% неоптимальных TLS-хендшейков

• Снизили время диагностики проблем с подключением с 25 до 3 минут

• Соответствуем требованиям GDPR и PCI DSS (без декриптации трафика)

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

#eBPF #TLS1.3 #мониторинг #кибербезопасность #observability

Какие подходы к мониторингу зашифрованного трафика используете вы? 

Grafana: когда красивые графики становятся рабочим инструментом

Все мы видели скриншоты дашбордов Grafana с красочными графиками. Но когда красивая визуализация становится реальным инструментом мониторинга, а не просто картинкой для отчёта?

Проблема типового подхода:

• Собираем все метрики подряд — «на всякий случай»

• Создаём дашборды с 20+ графиками, где невозможно найти нужную информацию

• Система есть, а пользы нет

Как мы построили эффективный мониторинг:

1. Инфраструктура сбора данных

text

Prometheus → Grafana (визуализация)
Loki → Grafana (логи)
Alertmanager → Grafana (алерты)

Один стек — единая картина происходящего.

2. Три уровня дашбордов:

• Оперативный (NOC): 3-5 ключевых метрик — доступность, ошибки, нагрузка

• Тактический (инженеры): детализация по сервисам + связанные логи

• Стратегический (руководство): SLA, бизнес-метрики, тренды

3. Пример полезного дашборда для веб-сервиса:

sql

- HTTP-коды ответов (1xx, 2xx, 3xx, 4xx, 5xx) 
- Latency: p50, p95, p99
- Rate of errors (> 5%)
- SLO: доступность за последний час

4. Интеграция логов и трейсов:
Теперь не просто видим, что latency вырос, а сразу находим причину в логах конкретного микросервиса.

Реальные результаты:

• Время диагностики инцидентов сократилось с 40 до 8 минут

• Количество ложных алертов уменьшили в 5 раз

• Единая система вместо 3 разных инструментов мониторинга

Ошибки, которых стоит избегать:

1. Не создавайте дашборды «для галочки»

2. Настройте meaningful алерты, а не «disk usage > 90%»

3. Используйте единый стек данных (метрики + логи + трейсы)

Вывод:
Grafana — это не про красивые графики, а про единое информационное пространство для принятия решений. Когда каждый инженер видит одну и ту же картину — проблемы решаются в разы быстрее.

А какие подходы к мониторингу используете вы? Делитесь кейсами в комментариях!

#grafana #мониторинг #prometheus #loki #devops #sre

Когда мониторинг слепнет: почему 90% алертов — это ложные срабатывания и как с этим жить

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

Проблема ложных срабатываний

• 📊 15% нагрузки на Zabbix/Prometheus — сбор и обработка бесполезных метрик

• ⏰ До 3 часов в день senior-инженеры тратят на фильтрацию алертов

• 🔕 68% инженеров признаются, что пропускали важные уведомления из-за "алертной усталости"

Почему это происходит

1. Мониторим всё подряд — собираем метрики "на всякий случай"

2. Неправильные пороги — одинаковые thresholds для dev и prod

3. Отсутствие бизнес-логики — система не понимает контекст сбоя

Решение: умный мониторинг

# Вместо этого:
alert: CPU > 90%

# Мониторим так:
alert: 
  condition: CPU > 90% 
  and LoadAverage > 5
  and duration > 5m
  and business_impact = true

Что внедрили у себя

1. Сезонные пороги — разные thresholds в рабочее/нерабочее время

2. Корреляцию событий — не алертим о высокой нагрузке, если это время бэкапов

3. Бизнес-метрики — мониторим не "доступность сервера", а "доступность оплаты"

Результаты через 3 месяца

• ✅ Снизили количество алертов в 7 раз

• ✅ 98% срабатываний требуют реакции

• ✅ Время реакции на реальные инциденты сократилось с 25 до 8 минут

Вывод
Мониторинг должен говорить, когда бизнес теряет деньги, а не когда у сервера чихнул процессор. Лучше 10 точных алертов, чем 1000 мусорных.

А как у вас с алертами? Тоже тонете в ложных срабатываниях?

#мониторинг #zabbix #prometheus #алерты #devops #sysadmin

P.S. В комментах жду ваши кейсы борьбы с алертной усталостью — соберем лучшие практики!

Надёжный пароль - это может быть плохо.

Надысь пил пиво, и была мне мысль. Если у нас есть юзвера, и они сами себе придумывают пароли, а мы им устанавливаем ограничения типа "8 знаков и обязательно с цифрами" - то значимая часть этих юзеров будет придумывать пароль, минимально подходящий под эти правила. Таким образом, если мы опасаемся брутфоса (а зачем ещё нужны сложные пароли?) а атакующему нужно сбрутить не конкретного юзверя, а хоть кого-нибудь, то ограничения пойдут атакующему на пользу.

• Стоит минимальная длина 6 знаков - перебираем только 6 знаков и переходим к следующему пользователю.

• Требуются обязательно буквы и цифры - перебираем варианты с 1-2 цифрами в конце, переходим к следующему.

• Требуются буквы, цифры, знаки препинания, не менее 4-х разных видов - это вообще лафа. Ставлю свою недопитую бутылку пива, что хоть у одного юзера будет пароль ABCD1234!@#$. Генерируем список тупых паролей под правила и брутим только по нему.

Всё сказал. Что делать с этой мыслью я не знаю, так что нате вам её.

Подборка обучающих материалов по Docker и Kubernetes

Привет, Хабр! Сегодня пятница, поэтому я снова со своей нерегулярной подборкой полезных материалов для начинающих специалистов. На этот раз несу статьи о Docker и Kubernetes. Как обычно: все бесплатно, без регистрации и смс. Читайте и практикуйте.

Первые шаги в Kubernetes

Здесь 12 статей примерно на два часа чтения. Будет полезно, если нужно освоить базу: что такое K8s, какие задачи помогает решить, основные понятия, с чего начать, как работать с контейнерами и настроить мониторинг.

Docker с нуля: как работают контейнеры и зачем они нужны

Эта подборка из шести статей — ваш гид в мир контейнеризации. Вы узнаете, что такое Docker, как запускать контейнеры, собирать образы и использовать Docker Compose, а еще разберетесь, чем эта технология отличается от Kubernetes. Все материалы подкреплены практическими примерами и будут понятны начинающим. На полное изучение уйдет менее двух часов.

Основы безопасности в Docker-контейнерах

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

Квиз: основы работы с базами данных

Если вы изучаете базы данных или давно не работали с ними и хотите проверить знания, приглашаем пройти наш новый квиз. Ответьте на несколько теоретических вопросов и попробуйте расшифровать SQL-запросы — в конце получите промокод на 1000 бонусов в панели Selectel.

Пройти квиз

Не забудьте поделиться результатами в комментариях!

Кажется я опять удалил бэкап из бакета... А нет, у меня ж стоит блокировка 😮‍💨

Добавили в S3 новую функцию — блокировку объектов (Object Lock). Теперь можно зафиксировать, или по-айтишному — «залочить» версии объектов так, что их нельзя удалить или изменить в течение заданного времени. Даже админу бакета.

👌 Идеально для архивов, резервных копий и важных логов.

Есть несколько режимов:

GOVERNANCE — «админ может удалять, а другие нет»

Объекты защищены от случайных действий, но пользователи с особыми правами могут их удалять в любой момент

COMPLIANCE — «тут и админ бессилен»

Объекты остаются нетронутыми до конца срока блокировки, даже если у вас админские права

Без глобальной защиты — «по дефолту»

Блокировка версий объектов не будет устанавливаться в бакете

⚙️ Подробности в доке →

Ну все, осталось только включить блокировку в настройках →

Как создать шаблон в Zabbix

Многим знаком Zabbix, помогающий мониторить и отслеживать состояние сетевых узлов, серверов и сервисов. Этот инструмент представляет собой open-source систему, которая поддерживает сбор метрик с различных устройств, анализ данных и оповещение при возникновении проблем. Благодаря своим функциям Zabbix позволяет автоматизировать мониторинг, гибко управлять конфигурациями и интегрировать сторонние решения.

А однo из ключевых инструментов — использование шаблонов, работа с которыми упрощает отслеживание и контроль сетевых узлов и серверов. Шаблоны помогают быстро настраивать группы хостов, синхронизировать мониторинг и минимизировать ручную работу. Подробнее о работе с пользовательскими шаблонами в Zabbix, их настройке и привязке к хосту рассказали в базе знаний Рег.облака.

19 сентября — СУБД-митап Tantor JAM

Митап от разработчика СУБД Tantor Postgres и машин баз данных Tantor XData пройдет в Москве. Это отличный повод встретиться для всех, кто интересуется развитием российских СУБД и будущим сферы управления корпоративными данными.

Регистрация завершена

В программе мероприятия:

• Стратегия «Тантор Лабс» на 3 года;

• Новая версия платформы Tantor — ведущего enterprise-решения для администрирования и мониторинга любых БД на основе PostgreSQL;

• Новинки СУБД Tantor Postgres для более высокой производительности и защищённости данных;

• Инструментарий для управления интеграциями и загрузкой данных, осуществления миграций с минимумом даунтайма;

• Особое внимание будет уделено Tantor XData — первой российской машине баз данных от вендора СУБД, созданной для самых сложных промышленных задач, высоконагруженных защищённых систем и крупномасштабной аналитики в стратегически важных отраслях.

Митап пройдет 19 сентября 2025 г. на 40-м этаже башни Mercury Space по адресу: Москва, 1-й Красногвардейский проезд, 15. Регистрация участников стартует в 12.00.

Будем рады видеть вас и ваших коллег!

WAF: как работает защита веб-приложений

Собрали подробную инструкцию по защите приложений — рассказываем, что такое WAF (Web Application Firewall) и как он функционирует. WAF — это специальный файервол для защиты сайтов, мобильных приложений и API от кибератак и различных угроз. Решение представляет собой фильтр, который отслеживает и проверяет весь входящий и исходящий HTTP/HTTPS-трафик и преждевременно блокирует подозрительные запросы. Сервис можно установить прямо на сервере, в сети компании или в облаке. 

В основе файервола лежат заранее заданные правила, по которым он определяет безопасность запроса и внимательно изучает ключевые части HTTP-коммуникации:

• GET-запросы, с помощью которых пользователь получает данные от сервера;

• POST-запросы, которые отправляют данные на сервер и могут менять его состояние;

• PUT-запросы, использующиеся для обновления или создания данных;

• DELETE-запросы, предназначенные для удаления данных.

Существует три основных вида WAF-решений: сетевой, хостовый и облачный. Подробнее о каждом из них, а также о возможностях защиты приложений читайте в базе знаний Рег.облака.

Начинаем собрание анонимных любителей S3 👀

С крутейшей новости — мы добавили возможность создавать неограниченное число дополнительных пользователей в S3, чтобы вы не скучали в своем бакете :)

Что входит в фичу:

➖ Настройка индивидуальных прав для пользователей
➖ Управление добавленными пользователями из бакета и из общего раздела
➖ Возможность сброса ключей доступа

Юзкейс 1: Можно выдать одному сотруднику доступ для просмотра, а другому — полное управление конкретным бакетом.

Юзкейс 2: Если у вас есть приложение, которое работает с S3, вы сможете завести для него отдельного пользователя с ограниченными правами.

Подключить допов можно в виджете на дашборде бакета → потом добавить в бакет через вкладку «Пользователи».

Потестить фичу в деле →

Как проверить, работает ли ECC-память в Windows: техническое руководство для системных администраторов

Введение

Недавно столкнулись с интересной задачей: нужно было убедиться, что ECC-память корректно функционирует на рабочей станции на базе AMD Ryzen. Как оказалось, стандартные методы проверки, которые находятся в топе поисковой выдачи, часто дают неверные результаты или попросту не работают в современных версиях Windows. В этой статье расскажем о проверенном методе, который сэкономит вам время и поможет точно определить статус ECC в вашей системе.

Почему стандартные методы не работают?

Во многих статьях в интернете для проверки ECC рекомендуется использовать команду wmic или PowerShell-скрипты. Однако у этих методов есть серьёзные ограничения:

1. Старые методы с wmic больше не работают в современных версиях Windows

2. Команда PowerShell Get-WmiObject Win32_MemoryDevice часто даёт неоднозначные результаты даже в системах с поддержкой ECC (включая Intel Xeon и AMD Threadripper с RDIMM)

3. Windows не предоставляет информацию о статусе ECC в диспетчере задач, что, честно говоря, странно для операционной системы, позиционируемой как корпоративное решение

Проблема в том, что Win32_MemoryDevice является производным от CIM_PhysicalMemory и предоставляет рассчитанную версию данных, которая может некорректно отображать определенные устройства. Для получения точной информации необходимо запрашивать данные напрямую из DMI/SMBIOS.

Проверка ECC с помощью CPU-Z: пошаговая инструкция

Шаг 1. Установка и запуск CPU-Z

Скачайте и установите последнюю версию CPU-Z с официального сайта. После запуска программы вы увидите стандартный интерфейс, но если перейти на вкладку «Память», то информации об ECC вы не найдёте.

Шаг 2. Создание отчёта

Вот ключевой момент, о котором многие не знают: нужно нажать кнопку «Инструменты» в нижней части программы и выбрать «Отчет». Для удобства анализа рекомендую выбрать текстовый формат вывода вместо HTML.

Шаг 3. Анализ отчёта

В созданном отчёте найдите разделы:

• Массив физической памяти DMI

• Устройство памяти DMI

Выполните поиск по ключевому слову «исправление». Возможные значения:

• «Нет» — коррекция ошибок отсутствует

• «Однобитовая ECC» — однобитовая коррекция ошибок (стандартная ECC)

• «Многобитовая ECC» — многобитовая коррекция ошибок

Также обратите внимание на параметры ширины:

• Общая ширина: 72 бита

• Ширина данных: 64 бита

Разница в 8 бит — это как раз те биты, которые используются для коррекции ошибок. Если вы видите такую разницу, но в поле коррекции указано «Нет», это может означать, что ECC поддерживается аппаратно, но не активирована в BIOS/UEFI.

Альтернативный метод: команда wmic

Более простой способ — использовать следующую команду в командной строке:

cmd

1

wmic memphysical get memoryerrorcorrection

Эта команда возвращает код, соответствующий типу установленной памяти:

0 (0x0) Зарезервировано

1 (0x1)Другое

2 (0x2)Неизвестно

3 (0x3)Нет коррекции

4 (0x4)Паритет

5 (0x5)Однобитовая ECC

6 (0x6)Многобитовая ECC

7 (0x7)CRC

Важные технические нюансы

1. Качество модулей ECC. Не все модули с маркировкой ECC обеспечивают надежную коррекцию. Например, модули с тремя линиями над логотипом Micron — это чипы, прошедшие электрический, но не механический тест. На такие микросхемы не распространяется гарантия, и они рекомендуются для использования в менее критичных приложениях.

2. DMIDecode как альтернатива. Для более глубокой диагностики рекомендуется использовать утилиту DMIDecode, которая предоставляет подробную информацию на основе данных SMBIOS. Это особенно полезно для серверных систем.

3. Проверка через BIOS/UEFI. В некоторых случаях информация об активации ECC доступна только в BIOS/UEFI. Обязательно проверьте настройки перед диагностикой в ОС.

Заключение

Проверка работы ECC-памяти — критически важный этап при настройке систем, в которых важна надёжность данных. Хотя Windows не предоставляет эту информацию в стандартном интерфейсе, использование CPU-Z или правильных команд wmic позволяет точно определить состояние ECC.

Мобильное приложение «Первой Формы»: новая версия и больше функций для быстрой работы

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

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

«За годы существования мобильного приложения мы решили много задач: добавляли функции, меняли дизайн. В процессе появился технический долг — старое API, программные модули, требующие глубоко рефакторинга, необходимость поддержки новых версий операционных систем. Технический долг можно сравнить с реликтовым излучением — он равномерно заполняет продукт, по нему можно отследить этапы эволюции, его можно игнорировать годами. Но чтобы развитие приложения проходило легче, с техническим долгом нужно работать», — комментирует Алексей Матвеев, директор по мобильным технологиям «Первой Формы».

В версии «Гамов» мы сосредоточились на уменьшении технического долга, обновлении архитектуры и новых функциях. Вот что нового появилось в этой сборке.

Общие обновления

• Теперь можно быстро искать и добавлять пользователей в тексты комментариев для упоминания через значок @.

• Добавить учётную запись в приложение можно, отсканировав QR-код в профиле веб-версии.

• Если переходы между статусами задачи скрыты (например, они нужны для автоматизаций), в мобильном приложении они тоже не отобразятся. 

• В списке задач теперь отображаются комбинированный индикатор всех и закрытых подзадач .

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

• Перешли на новое API для ускорения работы списков задач.

• Обновили ВКС-модуль, чтобы работал ещё стабильнее.

Больше о мобильном приложении «Первой Формы» →

Дополнительные функции iOS-версии

• Обновили вид новостей — в них отображаются реакции, описания и форматирование.

• Если нажать на упоминание комментария в ответе на него, чат прокрутится до этого комментария.

• Учётную запись можно добавить в приложение по ссылке.

Дополнительные функции Android-версии

• Поддержка полноэкранного (EdgeToEdge) интерфейса новых версий Android, оптимизация под Android 15.

• Нажатие на баннер входящего звонка выводит интерфейс созвона на весь экран.

• Для кнопок резолюций в подписях поддержали цветовую раскраску.

Через час начинаем митап для сетевых специалистов

Вместе с коллегами Selectel и экспертами из других компаний будем обсуждать вопросы, которые волнуют всех сетевых специалистов. Подключайтесь к Selectel Network MeetUp!

Программа

18:05-18:45 — Начнем вечер с доклада технического директора Selectel Кирилла Малеванова. Поговорим о переподписке в сетях CLOS’a, обсудим, зачем она нужна и какое значение коэффициента возможно в современных сетях.

18:45-19:25 — Передадим слово руководителю RnD Дмитрию Чигишеву. Присмотримся к разным открытым ОС и их архитектуре. Выясним, зачем нужен SAI, если есть SDK.

19:50-20:30 — После небольшого перерыва перечислим, что нужно знать при переходе на 400GE. Вместе с сетевыми инженерами Selectel Евгением Никифоровым и Алексеем Антоновым обсудим опыт работы с 400GE-решениями.

Смотреть трансляцию:

📱 на YouTube

📱 в VK

Увидимся в эфире!

В SpaceWeb усилили инфраструктуру связи и отказоустойчивость хостинг-систем

Сегодня делимся сетевыми новостями. Подключили в SpaceWeb дополнительного оператора и запустили пиринг через PiterIX. Теперь у нас есть два независимых магистральных канала связи и резерв. Оба защищены от DDoS-атак, а трафик направляется по наиболее короткому маршруту до пользователя. Если один канал даст сбой, то второй мгновенно берет на себя 100% нагрузки.

Также подключились к PiterIX — одной из крупнейших точек обмена интернет-трафиком в России:

• 500+ участников;

• 14,5 Тбит/с пропускной способности;

• узлы в 15 городах РФ.

Трафик от провайдеров, подключенных к этим точкам, идет в SpaceWeb напрямую, минуя лишние промежуточные сети.

Что это значит для пользователей:

• сайты и сервисы открываются быстрее;

• стабильная работа без задержек;

• дополнительная защита от перебоев.

Подробнее о нововведениях рассказали на сайте.