Обновить

Администрирование

Сначала показывать
Порог рейтинга

Управлять облачными расходами часто сложнее, чем кажется

FinOps Community Bot
FinOps Community Bot

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

Чтобы помочь компаниям системнее подойти к FinOps, мы собрали FinOps Community Bot. Это Telegram-бот, который объединяет несколько инструментов:

  • Тест по FinOps. 9 вопросов за 5–7 минут. Бот рассчитает уровень зрелости вашей компании в управлении облачными затратами и подскажет следующие шаги.

  • База знаний. Подборка статей, инструкций и практических материалов по FinOps.

  • Календарь событий. Митапы, вебинары и конференции для специалистов и руководителей.

  • Закрытый чат. Возможность обсудить опыт с коллегами и задать вопросы сообществу.

Бот полезен для любых ролей: CEO увидит картину в целом, CFO получит идеи по оптимизации расходов, DevOps-инженеры и CTO — практические шаги для улучшения процессов.

Начать просто: пройдите тест, получите рекомендации и используйте остальные функции бота для глубокого погружения и обмена опытом.

👉 Попробовать

Теги:
Всего голосов 7: ↑6 и ↓1+5
Комментарии0

В репозитории Awesome First Pull Request Opportunities больше сотни проектов, в которые новички могут делать пул-реквесты и получать обратную связь и даже советы по изучению программирования. Все проекты разделены по языкам и темам: C#, C++, Java, JS, фронтенд, бэкенд, информбезопасность, мобильная разработка под iOS и Android. Каждый найдет проект и стек. Проекты и репозитории ведут реальные разработчики и постоянно их поддерживают. Каждая команда всегда читает пул-реквесты, часто дает советы по разработке и обучению, обратную связь новичкам и даже шанс попасть на стажировку.

Теги:
Рейтинг0
Комментарии0

Собственный VDI и протокол: подробности

Привет, Хабр! Мы расширяем портфель решений — теперь в нашей экосистеме есть новая функциональность виртуализации рабочих столов и приложений (VDI) в рамках интеграции продуктов zVirt и Termit. Благодаря ей заказчики могут прямо в пользовательском интерфейсе Termit настроить автоматическое создание групп виртуальных рабочих мест из шаблона. 

Это стало возможно благодаря глубокой интеграции с системой виртуализации zVirt. В интерфейсе Termit можно настроить сопряжение с zVirt, там же создать группу виртуальных рабочих мест, и в нее автоматически будут добавляться виртуальные машины, создаваемые в zVirt по заданному шаблону — “золотому образу”. Они также автоматически будут вводиться в домен. На стороне виртуализации нужно только настроить “золотой образ”, все остальные операции можно совершать в интерфейсе Termit.

VDI в наших продуктах обеспечивает возможность создания как сессионных, так и персонализированных виртуальных машин, а также поддерживает кроссплатформенность, многофакторную аутентификацию и SSO, протоколы X2Go, RDP и Loudplay, перенаправление устройств, различные ОС: Windows, Astra Linux, РЕД ОС, ОС Альт. Функциональность представлена как отдельно в рамках продукта Termit, так и в новом модуле платформы виртуализации zVirt Apps and Desktops.

Среди других обновлений релиза Termit 2.4 — улучшение пользовательского опыта и усиление безопасности. В частности, появилась возможность настройки перемещаемых профилей для Linux. Теперь, когда пользователь отключается от рабочего стола, все его актуальные настройки и изменения остаются в удаленном хранилище и при следующем подключении перемещаются за пользователем на новый сервер или виртуальную машину. Это позволяет сохранять единое рабочее окружение для сотрудников и снижает количество обращений в техподдержку.  

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

Кроме того, мы начали разработку собственного протокола доставки удаленного рабочего стола и терминального доступа. Он будет реализован внутренними силами и без использования Open Source.

Мы изучили существующие на рынке разработки и патенты, наняли сильных специалистов и в этом году начали разработку собственного протокола. Мы пишем его сами, не используем ни X2Go, ни SPICE, ни FreeRDP. Это в первую очередь UDP, но одновременно будет реализована и поддержка TCP. В протоколе “из коробки” будет поддержка виртуальных каналов и мультисессионности.

Теги:
Всего голосов 1: ↑1 и ↓0+2
Комментарии0

Репозиторий с тысячами приложений, которые можно захостить на своем сервере. Больше 50 категорий приложений, внутри которых сотни инструментов под различные задачи. Есть всё для аналитики, бронирования ресторанов и отелей, автоматизации рутины, чтения книг и журналов. Можно использовать файлообменники, парсеры, приложения для мониторинга и многое другое. Каждая программа работает только локально.

Теги:
Всего голосов 8: ↑7 и ↓1+9
Комментарии0

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

Бессерверная архитектура обещает не думать об инфраструктуре, но скрывает риски 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, оцените, готовы ли вы к зависимости от вендора и непредсказуемым расходам.

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии0

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 — на своем докладе и в квизе от «Инферит ИТМен»!

Теги:
Всего голосов 6: ↑6 и ↓0+8
Комментарии2

Контейнеры не панацея: скрытые затраты на содержание 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? Делитесь наблюдениями в комментариях.

Теги:
Всего голосов 1: ↑0 и ↓1-1
Комментарии0

Записки параноика: почему 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 — это не продукт, а архитектурный принцип. И да, он требует изменений в менталитете команды больше, чем в технологиях.

Теги:
Всего голосов 4: ↑4 и ↓0+6
Комментарии0

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)
  1. План миграции:

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

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

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

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

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

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

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

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

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

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

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

Вывод:

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

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

Теги:
Всего голосов 4: ↑3 и ↓1+2
Комментарии5

Привет, потенциал kui еще немного увеличился! Случилось то что случилось, в продской cronjoпеb'е что-то застряло. Добавил в kui ручной запуск кронжоб и kui'ем протолкнул застрявшее в кронжобе ...

manual run cronjob
manual run cronjob

Творите, выдумывайте, пробуйте!)

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Когда 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

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

Теги:
Рейтинг0
Комментарии0

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

Теги:
Всего голосов 4: ↑3 и ↓1+2
Комментарии1

Когда мониторинг слепнет: почему 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. В комментах жду ваши кейсы борьбы с алертной усталостью — соберем лучшие практики!

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии0

Ближайшие события

Небольшой анонс: издательство БХВ теперь ведет собственный корпоративный блог на Хабре

Рады вам сообщить, что теперь вы сможете чаще читать рецензии на книги по ИТ от БХВ, Alist, Фолиант и наверняка что-то выберите себе для роста личных хард-скилов и компетенций.

Мы, в свою очередь — контент-команда SSP SOFT — уже около двух лет публикуем в нашем блоге рецензии на книги БХВ, но делаем это выборочно: только те издания, которые пересекаются с нашей основной деятельностью — заказным программированием, системным ПО, ИТ-аутсорсингом, внутренней архитектурой ПО и смежными темами.

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

И вот первый такой анонс.

📘 «Чистовики патриарха. О трёх последних книгах Олега Цилюрика»

В своей статье БХВ публикует обзор трех недавних работ известного Линукс-гуру и автора технической литературы Олега Цилюрика.

  • Первая рекомендуемая книгиа — «Расширения ядра Linux. Драйверы и модули», книга объёмом ~688 страниц по версии ядра 5.15, детально раскрывающая внутренние API ядра, взаимодействие с периферией, USB, PCI и многое другое (ссылку на книгу).

  • Также БХВ рассказывает о книге «Linux и Go» — экспериментальном проекте объединения низкоуровневого программирования и Go, где автор исследует переход некоторых подсистем ядра и функций на Go, и подробно рассматривает вопросы производительности, взаимодействия C и Go, многопроцессорности.

  • Третья книга — а это перевод «Изучаем eBPF» — показывает, что авторские компетенции охватывали не только ядро, но и современные технологии мониторинга, безопасности и расширения функций ядра.

Статья в блоге БХВ лампово освещает рабочие моменты сотрудничества издательства и автора: как проходила верстка, как уточнялись детали кода, как велись обсуждения правок. Материал про творчество Олега Цилюрика важен для профессионального сообщества — чтобы вызвать готовность «заглянуть за обложку».

Теги:
Всего голосов 3: ↑3 и ↓0+6
Комментарии0

Представлен репозиторий Free Certifications с бесплатными сертификациями по IT-технологиям от Google, Oracle Microsoft и других компаний. Все сертификаты строго разделены по категориям: фронтенд, бэкенд, SQL, Data Science, информбезопасность, аналитика и ещё множество тем.

Теги:
Всего голосов 5: ↑4 и ↓1+5
Комментарии0

2 октября встречаемся на Infra Meetup от Wildberries & Russ!

Где: Москва + онлайн-трансляция
Когда: 2 октября 19:00, сбор гостей начинается в 18:00

Зарегистрироваться!

Приглашаем на Infra Meetup от Wildberries & Russ! Расскажем про внутреннее файловое хранилище собственной разработки, поговорим о методах автоматизации репозиториев в Nexus, разберём существующие сервисы и процедуры их сопровождения, обеспечивающие бесперебойную работу. И обязательно затронем важнейшую тему культуры инженерного взаимодействия в команде.

В программе:

Файловое хранилище Wildberries: бескомпромиссный HighLoad | Иван Волков, CTO CDN

  • Как устроено одно из важнейших файловых хранилищ Wildberries

  • 1,2+ млн RPS на выдачу фото и видео — и это не предел

  • Код Оккама: органический подход к разработке и процессам

Путь автоматизации репозиториев в Nexus | Владислав Раев, DevOps & DevTools Engineer

  • Автоматизация без стандартизации, или путь в никуда

  • Что работает для 10, может сломаться на 100

  • Меньше состояния — меньше проблем

  • Явное лучше неявного

У вас завелся сервис: рекомендации лучших сервисоводов (наверное) | Александр Стовбунский, Tools Team TechLead

  • «Пап, можно мы его оставим?» — почему приносят одни, а чиним мы

  • «А выгуливать кто будет?» — что может требовать тот, у кого нет права отказаться

  • «Он большим не вырастет!» — как считать трудозатраты и сроки

  • Вредные советы: как гарантировано всё испортить

Для участия в офлайне она обязательна. После докладов — продуктивный нетворкинг и афтерпати.

Зарегистрироваться!

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

В SpaceWeb обновили юзабилити в S3

В SpaceWeb выкатили новую порцию полезных фич и обновлений в S3! Теперь к сервису можно подключаться не только через утилиту, но и все нужные настройки получится установить напрямую и через панель управления — сделали всё для удобства пользователя.

Основные апдейты:

  • открыли доступ к самостоятельному управлению файлами — их можно и загружать, и удалять;

  • подключили чекбоксы — документы удобно просматриваются компактным списком и по нему можно проводить поиск, что особенно важно при огромном количестве данных в S3;

  • из хранилища теперь можно получить прямой адрес загруженного файла — это поможет в дальнейшем управлении и работе с ним.

Протестировать обновленный S3 можно уже сейчас в панели управления SpaceWeb.

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

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

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

Пройти квиз

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

Теги:
Всего голосов 6: ↑6 и ↓0+11
Комментарии1

Так как мои статьи "на поныть" как выстраивать организационные процессы со своей маленькой колокольни без пап, мам и смс безбожно минусят (хотя считаю, что несправедливо! мне мой подбор слов и их порядок упаковки в предложения очень нравится) я продолжу потихонечку записывать (в основном для себя правда, потому что я немножко рыбка) мои изыскания с администрированием различных операционных систем и поиск решений тупых проблем на уровне "почему оно все не работает".

Кроме удовольствия от переноса многочисленных мыслей в текст, это безобразие меня еще и мотивирует этим заниматься и структурирует тот бардак, который живет у меня в голове. Потому что хочется спасать человечество, искать средство от смерти или думать о вечном, а вот решать проблему, почему очередной раз не выполняется элементарный apt-get update на машинке совсем не хочется. Сразу появляются мыслишки, что я трачу свое время на что-то бессмысленное и глупое и сажусь играть в "собери три предмета в ряд", потому что там в отличие от элементарных проблем с линуксом я не чувствую себя тупой, а при окончании ходов тебе всегда услужливо предлагают посмотреть рекламу за несколько дополнительных, чтобы ты снова чувствовала себя победителем.

По сложившейся традиции моих немногочисленных постов

Мое маленькое ДАНО ХОЧУ:

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

И да, я знаю, что вполне можно нарыть это в тырнетике или спросить у чата жипити, но я опрометчиво решила, что установить ее и посмотреть ручками будет проще, а когда это не получилось командой apt-get install postgres мое самолюбие было уже не остановить и срочно надо было доказать дурацкой базе данных, что я умнее (ну как иначе, то?). Вообще не то, чтобы я никогда не работала с постгрей, в моей голове достаточно смутные воспоминания, что скорее всего она пишет лог в /var/log/, а настройки у нее вообще живут только в двух файлах. Но точных имен я не помню, поэтому имеем, что имеем.

А вот теперь ДАНО:

У меня есть в запасе чистый диски на VirtualBox'e винды и дебиана, вот клон последней и было решено использовать для изысканий.

Шаг 1

Пробуем запустить apt-get install postgres, потому что что может быть проще... учитывая, что в ТЗ даже версия мне безразлична... просто вспомнить название файликов...

На что умный дебиан нам напоминает про безопасность и права (женщины боролись за права с 18 века!!!! а мне до сих пор не хватает =( )

Поэтому заходим под рутом, выполняем apt-get update - радуемся, когда тот успешно выполняется и идем искать нужный нам пакет apt search postgres.

В получившейся портянке ищем саму постгрю, потому что apt-search выдает результаты со словом postgres не только в названии пакета, но и в его описании. Лично мой взор привлекает пакет postgresql-all, где в описании обещают, что это metapackage depending on all PostgreSQL server packages. Его и пробуем поставить.

На удивление пакет (а точнее пакеты) ставится без ошибок, и в цмдушечке появляется заветный psql, который правда говорит, что подключаться ни к чему он не хочет, сокета на 5432 у него нет, а роль root вообще не существует.

Но по крайней мере у меня есть ответ на мой первый вопрос. Основные файлы конфигурации живут в /etc/postgres/ее версия/main/ и зовутся pg_hba.conf и posgresql.conf, где первый отвечает за разрешения подключения к этой самой бдушечки, а второй как раз хранит в себе все переменные ее настройки - в том числе и куда хранить лог "log_directory" которая по умолчанию закомментирована.

Удивительно и невероятное, если запустить apt-get update из под пользователя, у которого нет прав, под рутом этот самый apt-get update выдает обшибку.

Удивительно и невероятновое 2: Почему-то мой быстрый путь тяп ляп и готово по добавлению извера в /etc/sudoers не помог дать ему необходимых прав, а дебиан под ним пакеты не захотел устанавливать.

Но об этом в лучших традициях Скарлетт О'Хара я подумаю завтра, потому что количество букв в посте сильно ограничены.

Теги:
Всего голосов 3: ↑0 и ↓3-3
Комментарии0

В Рег.облаке запустили новую зону доступности публичного облака в Москве

Сегодня подключили в московском регионе новую облачную локацию Рег.облака. Теперь в столице в публичном облаке доступна и вторая площадка на базе дата-центра «Медведково-2». 

Новая площадка расширяет пул ресурсов и делает московский контур отказоустойчивым: теперь сценарии disaster recovery можно строить внутри региона, без компромиссов по производительности и связности.

Внутренняя «начинка» в новой локации:

  • до 25 000 vCPU и 30 ТБ RAM;

  • более 1 ПБ хранилища;

  • серверы разных классов, включая высокочастотные AMD EPYC и новую линейку «Стандартные+» на Intel Xeon с NVMe SSD;

  • интерконнект: 40 Гбит/с к серверам, 100 Гбит/с между стойками;

  • отказоустойчивость по схеме N+1.

Что нового в архитектуре:

  • API работает без пауз при переключениях: BGP+ECMP вместо keepalived;

  • служебный и клиентский трафики изолированы на трех уровнях («матрешка» туннелей);

  • расширенный мониторинг дает прозрачность и быстрый разбор инцидентов.

Протестировать и заказать облачные серверы в новой локации уже можно сейчас на сайте Рег.облака.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0