DevOps FM
4.94K subscribers
641 photos
12 videos
10 files
756 links
♾️ Канал для тех, кто живёт DevOps и системным администрированием.

Новости, статьи, best practices, инструменты и чилл-аут контент. Cloud Native, Docker, Kubernetes, CI/CD, БД, мониторинг etc.

По вопросам — к Ладе @b_vls
Download Telegram
Legacy vs прогресс: как работать с системами прошлого

👤На Reddit обсудили боль DevOps-инженеров: как работать с системами, которые устарели пять лет назад и блокируют внедрение новых решений.
Каждое обновление с Legacy-системами превращается в квест: старые решения не интегрируются с современными процессами, руководство действует по правилу "не чини, если не сломано", инженеры тратят силы на сопровождение устаревшей инфраструктуры вместо развития.

Что предлагают коллеги?

jbandinixx:если не можешь уничтожить, заставь их работать на тебя. Оберни в API, автоматизируй рутину и устраняй проблемы по частям. Для повторяющихся задач (ввод данных, создание аккаунтов, планирование и т.д.) инструменты вроде Cyberdesk реально помогают снять часть нагрузки.


sysadmintemp: старое редко умирает, потому что всё ещё используется, а новое ПО не покрывает все сценарии. Автоматизируй процессы. У нас была C++ .exe программа, мы обернули её в Python API и загрузили рабочую версию в артефакт-репозиторий. Это позволило разворачивать ПО с актуальным Python-кодом и часто обновлять хост.


elucify: мне понадобилось 3 года, чтобы убедить руководство поменять систему. Менеджменту не нужны проблемы, им нужны решения с цифрами.


sschueller: по-нашему “модернизация” — это упаковать умирающий сервер в Docker и кинуть его в облако.


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

С какими сложностями вы сталкиваетесь при работе с legacy системами?

#devops #reddit #legacy
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔73🔥3👍1💅1
👩‍💻 Автоматическое восстановление служб в Kubernetes — контроль, прозрачность и спокойный сон

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

Что внедрить первым?
- Экспорт метрик и базовые алерты в тестовом namespace.
- Оператор расширения дискового пространства в dry-run с трассировкой действий.
- Сценарии отказов в staging: full-disk, failed-resize, node-failure.

🤝После базовой настройки включаем контроль.
Что проверить?
- Snapshots перед изменениями.
- Ограничение параллельных операций.
- Метрики эффективности: MTTR, число автопочиненных инцидентов, вмешательств оператора.

📎 Совет: встраивайте автоматизацию с runbooks и audit-логами рядом — так автоматические действия остаются прозрачными и воспроизводимыми. Читайте весь гайд по ссылке.

👩‍💻 Делимся репозиториями:
Draino — оператор от Planet Labs, который автоматически изолирует и очищает (cordon/drain) узлы Kubernetes, когда они переходят в неработоспособное состояние.
Volume Expander Operator — проект от Red Hat COP для автоматического расширения Persistent Volumes при достижении порога заполнения.

#devops #kubernetes #storage #autoremediation
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥63