🏗 Курс “Software Architect” от OTUS — набор заканчивается! 🚨

Успейте занять место в группе курса «Software Architect»! Станьте экспертом в проектировании отказоустойчивых и масштабируемых систем. Пройдите вступительный тест и получите скидку, чтобы не пропустить старт обучения!

✅ Почему стоит пойти:

- 100% практики на реальных проектах
- Проектирование гибких архитектур
- Микросервисы, интеграции, Big Data
- Современные паттерны: CQRS, Event Sourcing
- Карьерный рост: рекомендации партнёрам для лучших

✅ Кому подойдёт:

- Разработчики, готовые к новому уровню
- Архитекторы, углубляющие экспертизу
- Тимлиды

✅ Что освоите:

- Проектирование масштабируемых архитектур
- Оптимизация взаимодействия сервисов
- Повышение качества и устойчивости систем

📌 Пройдите тест и забронируйте место со скидкой. Не упустите шанс стать экспертом в архитектуре систем! Подробности уточняйте у менеджера

👉 Пройти тестирование https://otus.pw/IQOKD/?erid=2W5zFHNKuep

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

ИТ-инфраструктура стала критической частью бизнеса: от нее зависит стабильность операций, клиентский опыт и финансовые показатели. 

При этом атаки на компании растут — в 2025 году ущерб от ИТ-инцидентов в России измеряется уже десятками миллионов рублей.

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

Системный подход из гайда позволяет:

— Понять все возможные меры защиты и заранее устранить слабые места инфраструктуры
— На 99% подготовиться к разным видам атак  
— Избежать паники при аварии, быстро восстановиться и точно расследовать, что произошло
— Избежать миллионных убытков, сохранив работоспособность критичных систем 
— Превратить защиту инфраструктуры в прозрачную систему

Скачивайте руководство бесплатно

К2Тех уже помогли 500+ компаниям оценить готовность к киберрискам и усилить защиту. Они протестировали в лаборатории 230+ продуктов от 120+ вендоров и знают, какие тонкости каждого решения влияют на безопасность в реальных условиях.

26 сентября Cloudflare объявляет, что переписали критические компоненты на Rust с безопасной моделью работы с памятью. Обновление подаётся как «быстрее и безопаснее» благодаря Rust: https://blog.cloudflare.com/20-percent-internet-upgrade/


Проходит 53 дня.
18 ноября у Cloudflare случается крупный сбой, который положил значительную часть Интернета — из-за ошибки в том самом Rust-коде.

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

https://blog.cloudflare.com/18-november-2025-outage/

Костыли наглядно

💡 Хитрый DevOps-совет по Linux

Если нужно быстро понять, почему контейнер или сервис «жрёт» память, не полагайтесь только на top или htop - они показывают *виртуальную* память, которая может вводить в заблуждение.

Используй настоящий источник правды:

cat /proc/<PID>/smaps_rollup

Он покажет:
- реальное потребление RSS;
- приватные и анонимные страницы;
- сколько памяти действительно удерживает процесс.

Почему это полезно:
- можно мгновенно увидеть, растёт ли именно приватная память (утечки),
- или это просто shared-страницы, которые процесс почти не удерживает.

Сенатор Марк Уорнер предупреждает: в ближайшие годы безработица среди недавних выпускников колледжей в США может вырасти до 25%.

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

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

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

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

ИИ больше не «будущее». Его последствия уже начинают менять рынок труда прямо сейчас.

⚠️ Camunda 7: скрытые риски, о которых нельзя молчать

2 декабря в 17:00

Приглашаем на экспертный вебинар по безопасности! 

🧩14 октября официально завершилась поддержка Camunda 7. Многие ждали, что финальный релиз закроет критичные уязвимости, но этого не произошло.Компании продолжают использовать Camunda 7 в продакшене - и фактически держат у себя «бомбу замедленного действия».

📌 На вебинаре вы узнаете:
- какие уязвимости (CVE) всё ещё присутствуют в сборке Camunda 7;
- какие из них наиболее опасны и почему;
- существуют ли рабочие эксплоиты и как именно проявляются проблемы;
- как использование неподдерживаемой Camunda 7 соотносится с требованиями ФЗ-187 и ФЗ-152;
- какие шаги можно предпринять уже сейчас, чтобы снизить риски. 

Вебинар полезен специалистам по информационной безопасности и архитекторам, у которых Camunda 7 задействована в автоматизации критичных бизнес-процессов. 

☝️Не пропустите возможность разобраться, как защитить вашу инфраструктуру в условиях окончания поддержки Camunda 7.
Регистрируйтесь прямо сейчас!

#реклама
О рекламодателе

⚡️ Быстрый Linux-совет

Хочешь узнать, как давно работает процесс?
Используй колонку etime в команде ps - она показывает, сколько времени прошло с момента запуска процесса.

Это удобно, чтобы понять, какие процессы висят слишком долго или застряли.

1. Посмотреть, сколько памяти ест процесс:  
   Узнаешь, какие процессы расходуют больше всего RAM.  

   ps aux --sort=-%mem | head  


2. Показать загрузку CPU по процессам:
   Помогает найти самые прожорливые по вычислениям задачи.  

   ps -eo pid,comm,%cpu --sort=-%cpu | head  


3. Показать аптайм всех процессов с временем запуска:

   ps -eo pid,comm,etime,lstart --sort=etime  


4. Посмотреть дерево процессов (кто кого запустил):

   ps --forest -eo pid,ppid,cmd  


5. Найти процессы по ключевому слову: 

   ps -ef | grep python  


6. Следить за процессом в реальном времени:

   top -p <PID>

⚙️ Полезный Linux-совет: быстро найти, что занимает диск

Когда место на сервере внезапно заканчивается, большинство начинают вручную копать по папкам. Но есть команда, которая сразу покажет, что съедает пространство.

Используй:

du -h --max-depth=1 | sort -h

- du — показывает размер директорий
- -h — вывод в человекочитаемом формате (GB/MB)
- --max-depth=1 — только текущий уровень вложенности
- sort -h — сортировка по размеру

Хочешь сразу смотреть за корень ФС?

sudo du -h / --max-depth=1 | sort -h

Так моментально видно, где «раздулось» — логи, кеши, временные файлы или база данных.

Сэкономишь кучу времени на поиске виновника переполненного диска.

⚡️ Kubernetes Namespaces: базовое разделение ресурсов в кластере

Namespaces в Kubernetes используются для логического разбиения кластера и изоляции ресурсов между командами, проектами и средами.

Что такое Namespaces
- Представляют собой «виртуальные кластеры» внутри одного физического.
- Группируют Pods, Services, Deployments, ConfigMaps и другие объекты.
- Полезны для multi-team, multi-project и multi-environment конфигураций.

Зачем они нужны
- Упорядочивают ресурсы и уменьшают хаос в большом кластере.
- Исключают конфликты имён — одинаковые ресурсы могут существовать в разных пространствах.
- Обеспечивают изоляцию команд и повышают безопасность.
- Позволяют держать dev/staging/prod в одном кластере без пересечений.

Стандартные Namespaces
- default — используется, если не указан другой; размещает обычные рабочие нагрузки.
- kube-system — системные компоненты (CoreDNS, kube-proxy).
- kube-public — доступен всем, включая неаутентифицированных пользователей; хранит публичную информацию.
- kube-node-lease — хранит heartbeat-объекты для узлов, повышая производительность контроля состояния.

Работа с Namespaces
- Создание — через YAML или kubectl, используется для группировки и изоляции ресурсов.
- Переключение контекста — позволяет работать в нужном namespace без постоянного указания -n.
- Удаление — очищает пространство вместе со всеми объектами, удобно для сброса окружения.

Типовые use cases
- Разделение окружений: dev/test/prod.
- Изоляция команд.
- Ограничение потребления ресурсов с помощью quotas.
- Границы безопасности через NetworkPolicies.

Resource Quotas
- Ограничивают CPU, RAM и количество объектов внутри namespace.
- Защищают кластер от «пожирания» ресурсов одной командой или сервисом.

Network Policies
- Контролируют сетевой трафик между namespace'ами.
- Используются для разграничения изоляции в multi-tenant конфигурациях.

Best practices
- Разводить окружения по отдельным namespaces.
- Не размещать рабочие нагрузки в kube-system.
- Настраивать RBAC на уровне namespace.
- Использовать понятные naming-conventions.
- Добавлять quotas в общих кластерах.

📎 Полное руководство по Kubernetes: https://codewithdhanian.gumroad.com/l/jwjls

Мониторинг K8s: экономим время

Все знают, как провести мониторинг Kubernetes-кластера. Но как сделать его простым и полезным?
Приглашаем вас на вебинар 28 ноября, где раскроем все тонкости использования метрик в кластерах Deckhouse Kubernetes Platform (DKP). Мы расскажем и покажем, что уже есть «из коробки» в платформе, а также, какие инструменты и подходы упрощают настройку и повышают эффективность мониторинга приложений, запущенных в Kubernetes-кластере.

На вебинаре вы узнаете:
👉 чем наш подход к мониторингу отличается от других и как это вам поможет;
👉 как мультитенантность и интеграция с веб-интерфейсом облегчают ежедневные задачи по управлению кластерами;
👉 как готовые дашборды и алерты «из коробки» ускоряют расследование инцидентов и локализацию сбоев.

28 ноября, 12:00 | Онлайн
Регистрируйтесь по ссылке и повышайте эффективность работы с Kubernetes благодаря инструментам DKP!
<div></div><div></div>

🐧 Используй отдельный "чистый" shell для проверки окружения — через env -i

Очень много проблем в DevOps вызывает грязное окружение:
скрытые alias, неожиданные переменные, PATH переписанный старыми скриптами, остатки от предыдущих установок, глобальные переменные из .bashrc и .profile.

Из-за этого сервис может работать у одного инженера, но падать у другого.

Фокус:
проверяй, как команда ведёт себя в идеально чистой среде, где нет ничего лишнего.

💡 Команда

env -i bash --noprofile --norc


Это запускает абсолютно пустую среду, без:

- переменных
- alias
- функций
- настроек шелла
- кастомного PATH

И ты видишь честное поведение программы, как будто она запущена в контейнере.

🧠 Когда это нереально помогает

- "У меня всё работает, а у другого инженера нет"
- Сервис запускается в контейнере, но не работает локально
- PATH перепутан между системными и кастомными бинарями
- Переменные окружения конфликтуют между собой
- Стартовые скрипты ломают окружение

⚡ Бонус

Если хочешь передать только нужные переменные:

env -i PATH=/usr/bin:/bin HOME="$HOME" bash --noprofile --norc