DevOps MemOps
6.48K subscribers
3.47K photos
547 videos
16 files
5.57K links
Всё о DevOps

Для связи - @raz_raz
Заказать рекламу через биржу: https://telega.in/c/devops_memops
Download Telegram
MemOps 😃
Please open Telegram to view this post
VIEW IN TELEGRAM
😁20
🫣 Актуальна реальная кулстори из одного ИТ-отдела.

ИБшники позвонили в 6:12 утра.

- Срочно патчите все PHP-серверы. Прямо сейчас.
- Что стряслось?
- Две критические уязвимости. RCE. Удаленное выполнение кода без авторизации.

Красота.

Спрашиваю: "А сколько у нас вообще серверов на пыхе?"
По CMDB и документации: 12.
По факту: хз.

Пошли искать по сетке. Нашли:
• Один полуживой WordPress;
• Три древних внутренних тулзы;
• Один гудящий системник под столом у завхоза;
• Два закрытых вендорских апплайнса;
• Забытый телефонный справочник сотрудников за 2016 год;
• И виртуалочку с именем PHP-STAROE-NE-TROGAT
Естественно, на ней крутится выгрузка зарплатных ведомостей.

Следом откопали тазик на PHP 5.6.
Спрашиваю: "Кто его запиливал?"
В README.txt в корне проекта написано: СЕРЁГА.
Серёга уволился в 2019 году.
Набрали Серёге. Серёга в трубку:
- "Охренеть, этот кусок говна до сих пор работает?!"
Душевно 🙂

К 8:00 на аварийный колл подтянулось руководство.

Генеральный:
- То есть хакеры реально могут зайти снаружи?
ИБ:
- Потенциально... да.
Генеральный:
- И даже без пароля?
ИБ:
- Вообще без пароля.
Генеральный:
- А нахрена МЫ тогда каждые три месяца эти пароли меняем?!
(Понятно, суть проблемы уловил не до конца) 🐒

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

В 9:17 кто-то предложил: " А давайте временно потушим уязвимые веб-морды".
Маркетинг в отказ: "Нельзя! У нас прямо сейчас крутится реклама вебинара со скидкой 20%!"

В итоге следующий час топ-менеджмент на полном серьёзе перетирал, что лендос со скидоном на вебинар важнее, чем полный захват инфраструктуры компании 🐒

Вроде всё нашли, изолировали, пропатчили. Выдохнули.
И тут сетевой сканер находит ещё один хост.

Имя: TEMP-PHP-2014
Аптайм: 4512 дней.

Никто не знает, что там крутится.
Ни за кем не числится.
Отключить нельзя - потому что как только мы рубим ему порт, у нас складе перестают печататься накладные.

ИБ вздохнуло и присвоило тачке статус "критическая инфраструктура".

Там стоит PHP 5.4.
Уязвимость в нём существует дольше, чем средний возраст джуна в компании.

Так и прошел один из дней на одной из реальных галер.

Типичный 🍺 Сисадмин
Please open Telegram to view this post
VIEW IN TELEGRAM
😁17🤯7❤1🔥1
В iximiuz Labs появился новый сложный челлендж по контейнеризации:

Отладить Go-контейнер, который перестал запускаться после недавнего изменения.


Сможете найти первопричину и исправить сборку?

📌 Подробнее: https://labs.iximiuz.com/challenges/fix-go-container-image-broken-by-recent-change

MemOps🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤3
MemOps 😃
Please open Telegram to view this post
VIEW IN TELEGRAM
😁36🔥3😭2
Glances — инструмент с открытым исходным кодом для мониторинга состояния серверов. Собирает основные показатели на одном экране и помогает быстро определить, какие процессы и ресурсы требуют внимания.

Возможности:

— Мониторинг CPU, оперативной памяти, дисков и сети.

— Просмотр работающих процессов и потребляемых ими ресурсов.

— Отображение температур, напряжений и скорости вентиляторов при наличии поддерживаемых датчиков.

— Мониторинг контейнеров Docker и LXC.

— Работа в терминале и через веб-интерфейс, наблюдение за удалёнными системами.

— Доступ к метрикам через REST API и экспорт данных в файлы и внешние системы хранения.

Glances написан на Python, поддерживает Linux, BSD, macOS и Windows. Также можно расширить его возможности при помощи плагинов.


📌 Подробнее: https://github.com/nicolargo/glances

MemOps🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
MemOps 😃
Please open Telegram to view this post
VIEW IN TELEGRAM
😁35🔥4
Grafana ограничивает рост числа рядов при автоматической оптимизации метрик

Автоматическая агрегация метрик экономит ресурсы, пока кто-нибудь не запросит подробные данные обратно. Восстановление детализации увеличивает число активных временных рядов.

В Adaptive Metrics появился режим cost-first. Сначала применяются рекомендации, уменьшающие число рядов. Затем система рассматривает увеличивающие рекомендации, начиная с самых небольших, и останавливается перед превышением исходного количества.

Допустим, есть три изменения: −10, +5 и +10 рядов. Первые два пройдут, последнее останется на рассмотрение. Итог цикла — на пять рядов меньше.

Режим coverage-first применяет все рекомендации, включая восстановление детализации для востребованных данных. Для критичных метрик это может быть предпочтительнее.

Режимы можно выбирать отдельно по сегментам: например, командам или окружениям. При этом ограничение прогнозируемого числа рядов в цикле не задаёт жёсткий потолок всему счёту Grafana Cloud.


📌 Подробнее: https://grafana.com/blog/coverage-first-or-cost-first-two-ways-to-automatically-apply-adaptive-metrics-recommendations/

MemOps🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
MemOps 😃
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16💯7
GitHub автоматизировал отзыв неподтверждённых доступов к репозиториям

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

В GitHub для одной из внутренних организаций сделали Evergreen. Раз в квартал приложение открывает задачу со списком внешних участников. Ответственный отмечает тех, кому доступ ещё нужен, и закрывает её.

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

Состояние проверок хранится в JSON-файлах в Git. По истории изменений видно, кто принял решение и что произошло. Отдельный процесс предупреждает о заброшенных репозиториях и затем архивирует их.

Авторы показывают внутреннюю реализацию на GitHub App, Actions и задачах. Этот процесс можно взять за основу для собственной проверки доступов.


📌 Подробнее: https://github.blog/engineering/platform-security/staying-evergreen-how-we-automated-secure-access-and-repo-hygiene-in-a-shared-org/

MemOps🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
Фул-стек разработчик

MemOps
😃
Please open Telegram to view this post
VIEW IN TELEGRAM
😁28👍1😭1
Изучайте Linux-сети на практике

Новый практический челлендж — потренируйтесь разбираться в сетевой конфигурации Linux-хостов: находить имена интерфейсов, IP- и MAC-адреса, шлюз по умолчанию, а также определять, какие маршруты сервер использует для доступа к разным адресам.


📌 Подробнее: https://labs.iximiuz.com/challenges/linux-inspect-network-interfaces-and-routes

MemOps🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍1🔥1😁1🫡1
MemOps 😃
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝8
Ozon Tech Platform Meetup — ничего страшного: исключительно полезные доклады

30 октября команда Ozon Tech расскажет, как устроена платформа большого бигтеха и какие инженерные решения помогают её развивать.

В программе:
— устройство платформы, стандарты разработки, CI/CD и сетевая инфраструктура;
— оптимизация архитектуры за счёт сокращения микросервисов и высвобождения 7000+ CPU;
— портал платформы данных и интеграция с множеством сервисов.

Доклады — по делу, а времени на общение хватит с запасом. Регистрируйтесь заранее, чтобы прийти офлайн, задать вопросы и пообщаться с руководителями платформенных команд Ozon Tech.

30 октября | 19:00 мск | Москва, лофт Casa Picassa

Регистрация: ozon.tech
Ждут всех, не только Go-разработчиков
❤3🔥1
Kubernetes тестирует вытеснение подов ради увеличения ресурсов работающего приложения

Работающий под запросил больше памяти, но на узле её нет. Увеличение ресурсов остаётся в состоянии Deferred, хотя сам запрос допустим. Появление свободного узла в кластере не добавляет памяти на текущем.

В Kubernetes 1.37 появилась альфа механизма, который позволяет планировщику освобождать место для такого увеличения. Он может вытеснить менее приоритетные поды с нужного узла, чтобы запрос более важного приложения выполнился.

Возможность включается через InPlacePodVerticalScalingSchedulerPreemption. Это экспериментальная функция, её нужно проверять отдельно от уже стабильного изменения ресурсов работающего пода.

Приоритеты здесь влияют на доступность соседних сервисов. До включения проверьте, кого допустимо вытеснять, и что произойдёт с этой нагрузкой после остановки.

Механизм помогает преодолеть нехватку свободной ёмкости на узле. Запрос, превышающий возможности самой машины, он выполнить не сможет.


📌 Подробнее: https://kubernetes.io/blog/2026/09/10/kubernetes-v1-37-scheduler-preemption-for-in-place-pod-resize-alpha/

MemOps🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
MemOps 😃
Please open Telegram to view this post
VIEW IN TELEGRAM
😁37
Перед закрытием HCP Vagrant нужно перенести образы и каталог их версий

HashiCorp закрывает HCP Vagrant поэтапно. Создание новых образов и реестров прекращено с 1 октября. Поддержка и обслуживание заканчиваются 2 ноября, работа сервиса — 31 декабря 2026 года.

Проверьте, откуда команда скачивает образы: ссылки в Vagrantfile, задачи CI/CD, скрипты и инструкции для новых сотрудников. Отдельно учтите собственные публичные и закрытые образы и тех, кто от них зависит.

Для переноса нужны файлы .box и метаданные каталога. В них хранятся версии, провайдеры виртуализации, архитектуры, адреса загрузки и контрольные суммы. Копирования одного последнего образа может оказаться недостаточно.

После переноса проверьте загрузку нужных версий с чистой машины и из CI. Локальный кеш способен скрыть неработающую ссылку.

Закрытие касается облачного сервиса. Vagrant CLI и исходный код остаются доступны, образы можно размещать на собственном хостинге.


📌 Подробнее: https://www.hashicorp.com/en/blog/hcp-vagrant-deprecation-important-dates-and-migration-guidance

MemOps🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
MemOps 😃
Please open Telegram to view this post
VIEW IN TELEGRAM
😁24
Grafana IRM сохраняет хронологию инцидента вместе с сообщениями команды

После восстановления сервиса приходится вспоминать, когда начались ошибки, кто предложил откат и почему одну из гипотез отбросили. Часть ответов остаётся в переписке.

В Grafana Cloud IRM сообщения из Slack можно добавлять в хронологию инцидента реакцией с эмодзи робота. Вместе с текстом сохраняются автор и время. Так полезное наблюдение попадает в запись сразу, пока команда ещё разбирается с проблемой.

К записи привязаны оповещения, панели и данные расследования. Grafana Assistant использует этот контекст для гипотез. Участники могут смотреть источники, опровергать предположения и возвращать их на проверку.

Такая история помогает подготовить разбор после инцидента: восстановить последовательность решений и найти пробелы в процессе.

Связи со Slack и другими сервисами нужно настроить заранее. Вывод помощника остаётся гипотезой, которую команда проверяет по данным.


📌 Подробнее: https://grafana.com/blog/go-from-alert-to-post-incident-review-with-grafana-cloud-irm-and-ai/

MemOps🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
MemOps 😃
Please open Telegram to view this post
VIEW IN TELEGRAM
😁23🫡3🤝2
Как conntrack обеспечивает работу Kubernetes Services

В этом гайде вы разберётесь, как работает conntrack на реальных сценариях Kubernetes-сетей, и поймёте, почему он играет критически важную роль в работе Kubernetes Services, kube-proxy, NAT и DNS-трафика.

Вы узнаете:
- что такое conntrack и зачем он нужен;
- почему Kubernetes Services зависят от него;
- как посмотреть таблицу conntrack;
- что происходит, когда таблица переполняется;
- как диагностировать и устранять исчерпание conntrack в продакшене.


📌 Подробнее: https://newsletter.devopscube.com/p/conntrack-in-kubernetes

MemOps🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3