📣 Какой контент реально нужен девопсу

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

Многие считают, что девопсам нужно погружаться в глубокие технические темы — гайды по внедрению Terraform, Kubernetes, настройки сетевой инфраструктуры и AWS, потому что все с этим работают.

С другой стороны огромные гайды про AWS и другие облачные сервисы могут и не иметь смысла, если в реальности с ними работали единицы.

Всегда можно взять готовую статью или ресурс — а сейчас нужна информация, которая касается реальных и актуальных задач, таких как CI/CD, мониторинг и автоматизация.

💬 Что думаете вы? Какой контент нужен настоящему девопсу, а какой это просто пыль в глаза незнающим, чтобы они думали, что всё так сложно? Делитесь мыслями в комментариях 👇

🐸Библиотека devops'a #междусобойчик

📎 Когда пайплайн — это просто уведомления

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

История подписчика:

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

Когда разработчики ставили определённые сервисы, то в один из чатов приходило уведомление, спустя минут 15-20 разработчик писал мне и говорил, что у него не ставится сервис. Я начал разгребать что там такое.

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

Пайплайны, которые должны были автоматизировать процесс деплоя, на деле оказались лишь поверхностной иллюзией автоматизации.

💬 Были у вас странные наработки? Делитесь выходками своими или своих коллег в комментариях👇

P.S. Если хотите задать вопрос сообществу или поделиться историей, заполните нашу гугл-форму.

🐸Библиотека devops'a #междусобойчик

👀 Тест на внимание для DevOps

Перед вами сетка с терминами, спрятанные по вертикали и горизонтали, которые должны быть знакомы каждому специалисту в мире DevOps. Сколько терминов из священной библиотеки найдете вы?

💬 Делитесь результатами, но не раскрывайте все секреты сразу!

🐸Библиотека devops'a #междусобойчик

✏️ CMD vs ENTRYPOINT

Один из подписчиков недавно задал интересный вопрос:

Когда лучше использовать CMD, а когда ENTRYPOINT в Docker?

Эти два параметра могут запутать, но их применение зависит от того, как вы хотите запустить контейнер.

1️⃣ ENTRYPOINT — основная команда контейнера

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

Он задает команду, которая является обязательной для запуска контейнера, и её нельзя переопределить (без указания дополнительных аргументов).

Пример:

ENTRYPOINT ["python", "app.py"]

В этом случае контейнер всегда будет запускать python app.py

2️⃣ CMD — параметры по умолчанию

CMD — это параметры, которые могут быть переданы командной строкой при запуске контейнера.

Если CMD используется в Dockerfile, но команда не была указана при запуске контейнера, то используется команда из CMD. Он также может быть переопределен во время запуска.

Пример:

CMD ["python", "app.py"]

Но если вы хотите передать другие параметры, например:

docker run my_image python other_app.py

То CMD будет переопределен.

3️⃣ Комбинированное использование

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

Пример:

ENTRYPOINT ["python"]
CMD ["app.py"]

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

Используйте CMD, если хотите задать параметры по умолчанию, которые можно переопределить при запуске контейнера.

Используйте оба вместе, чтобы задать команду с возможностью замены параметров.

💬 А какие у вас есть примеры использования CMD и ENTRYPOINT? Поделитесь своим опытом в комментариях 👇

🐸Библиотека devops'a #междусобойчик

📣 Как правильно называть окружения

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

— Сторонники англоцентричной схемы

Prod / Pre-prod / Staging / Dev

Стандартизировано, «понимают» все инструменты CI/CD и внешние подрядчики.

Очевидный минус для русскоязычной команды — англицизмы раздражают, к тому же споры о дефисах и транслитерации («preprod» vs «pre-prod») могут затянуться.

— Сторонники русификации

Бой / Пром / Тест / Разраб.

Интуитивно для русскоязычных специалистов, нет путаницы в терминах. Но есть и минус — международные коллеги и документация на английском «теряются» без глоссария.

💬 Что думаете вы? Какие аргументы перевесили в ваших проектах — «Prod» или «Бой»? Разверните своё мнение в комментариях 👇

🐸Библиотека devops'a #междусобойчик

💬 Кубер это революция в управлении инфраструктурой или ненужная сложность

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

⚠️ Основные претензии к Kubernetes:

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

— Сложные кластерные технологии могут потреблять ресурсы, которые для небольших или средних проектов не оправданы.

— Сетевые и распределенные проблемы в Kubernetes могут быть сложными для диагностики.

Что думает наш админ:

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

💬 Какая ваша позиция по поводу Kubernetes? Супер-пупер игрушка или ненужный хлам? Делитесь мыслями в комментариях 👇

💃 Нравится контент? Отблагодарите нас бустом, а мы подготовим больше годного контента.

🐸Библиотека devops'a #междусобойчик

🧩 Эмодзи-ребус

Сегодня мы загадали то, что мы проводим не так часто. Что изображено на картинке? Пишите догадки в комментариях 👇

🐸Библиотека devops'a #междусобойчик

🛡 100.000 записей уже утекло и ещё 200.000 на подходе

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

Один из подписчиков недавно спросил:

Бывали ли у вас утечки данных или секретов? И как вы их обнаружили?

Чтобы помочь вам системно подойти к защите, рассмотрим ключевые шаги:

• Ведение централизованного доступа к секретам (Vault, AWS CloudTrail).

• Настройка алертов на аномалии: резкий рост числа запросов, доступ в нерабочие часы.

• Принцип наименьших привилегий: выдача минимальных прав сервисным аккаунтам.

• Автоматическое сканирование репозиториев на «вшитые» пароли и токены.

• Пост-инцидентный анализ (post-mortem) с документированием причин и уроков.

💬 А у вас были случаи утечек? Как вы их обнаружили и какие меры приняли? Поделитесь в комментариях 👇

Небольшая история от админа:

На нашем последнем проекте как-то раз один разработчик по-быстрому затащил в репозиторий приватный токен для тестового API прямо в коде. Никто этого не заметил, пока вечером в прод не пришёл шквал аномальных запросов.

С тех пор у нас в CI работал сканер git-secrets, и больше никто не позволяет себе «быстренько вставить» секреты в код.

P.S. Если хотите задать вопрос сообществу или поделиться историей, заполните нашу гугл-форму.

🐸Библиотека devops'a #междусобойчик

📣 Фоновые задачи в Linux: что использовать

В контексте системного администрирования и девопс-практик на Linux возникают споры о том, каким образом лучше планировать и выполнять фоновые задачи.

*️⃣cron — проверенная классика

• Простота настройки через crontab, знакома всем администраторам.

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

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

⏲️ systemd-таймеры — современный подход

• Единая точка управления сервисами и таймерами, интеграция с journalctl.

• Расширенные возможности: запуска по событиям, автоматический перезапуск, контроль зависимостей.

• Зависимость от systemd — не подходит для систем с альтернативными init-системами.

✏️ Специализированные планировщики (Jenkins, Rundeck, Apache Airflow)

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

• Централизованное управление, уведомления, отчётность и интеграции с разными системами.

• Повышенные накладные расходы на установку, настройку и сопровождение сервера планировщика.

💬 Какой инструмент для фоновых задач используете вы? Ждём вас в комментариях👇

🐸Библиотека devops'a #междусобойчик

💵 Виртуальные ошибки стоят реальных денег

Когда ты работаете в стартапе, всегда есть ощущение, что «мы справимся». Но когда начинается работа с облачными провайдерами, такие вещи могут привести к большим расходам.

Один из наших подписчиков поделился своей историей:

Работая в стартапе, я столкнулся с неожиданными расходами в DigitalOcean. Как-то раз я заметил, что наш счёт был значительно выше, чем ожидалось, и был в шоке, когда увидел итоговую сумму. Ошибки в конфигурации одного из наших облачных серверов.

💬 Вопрос к тем, кто работал не на своём железе — как это предотвратить? Делитесь своими способами, вдруг это спасёт чей-нибудь кошелёк 👇

P.S. Если хотите задать вопрос сообществу или поделиться историей, заполните нашу гугл-форму.

🐸 Библиотека devops'a #междусобойчик

🤨 DevOps в ловушке

В современных небольших компаниях роль DevOps всё чаще сводится к «единственному спасителю».

Вы настраиваете инфраструктуру, поддерживаете пайплайны CI/CD, отвечаете за мониторинг и безопасность — и при этом вам не позволяют уйти в отпуск.

Один из наших подписчиков недавно спросил:

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

Самый базовый совет — автоматизируйте и документируйте!

Опишите критичные сценарии (развёртывание, откаты, бэкапы) в виде Infrastructure as Code (Terraform, Ansible, Helm) и скриптов, чтобы любой администратор мог воспроизвести окружение за пару команд.

Централизуйте инциденты в системе тикетов с чёткими инструкциями и настройте on-call-роуминг, привлекая коллег из разработки или поддержку фрилансеров хотя бы на экстренные случаи.

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

Зафиксируйте условия в виде доп. ставки или компенсационных выходных в виде формального соглашения.

💬 Как бы вы справились на месте единственного девопса в компании? Делитесь в комментариях 👇

🐸Библиотека devops'a #междусобойчик

👨‍💻 Сколько должен получать джун

Тема зарплат в IT-индустрии всегда вызывает бурные обсуждения. Но что если мы возьмём девопс-джуна? Сколько вы бы дали свежему специалисту на старте.

• 40-60 тысяч — это нормально

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

На этом уровне от девопс-джуниора ожидают базовых знаний, таких как умение работать с Docker, Kubernetes, настройка Jenkins и базовая автоматизация процессов.

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

Значит, платить за это нужно немного — пока новичок не «встанет на ноги» и не покажет свою ценность.

• 100-120 тысяч — потому что это IT

В крупных городах, например в Москве или Санкт-Петербурге, спрос на девопс-специалистов огромен. Компании готовы платить больше, чтобы привлечь и удержать талантливых людей, даже если они только начинают свою карьеру.

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

Обслуживание этих систем требует много работы и ответственности. Привлечение новичка, который также работает с такими сложными системами, требует соответствующей компенсации.

💬 Что думаете вы? Сколько должен получать девопс-джуниор? Делитесь цифрами и доводами в комментариях 👇

🐸Библиотека devops'a #междусобойчик

👨‍💻 Putty vs SSH в Windows

Если вам нужно подключиться к удалённому серверу с винды, то есть два стула популярных варианта — Putty и встроенный SSH-клиент Windows.

Оба инструмента позволяют подключаться через SSH, но каждый из них имеет свои особенности. Разберём, что выбрать в зависимости от ваших нужд.

SSH крут, потому что

• Есть встроенная поддержка в Windows через PowerShell и Windows Terminal.

• Нет необходимости устанавливать сторонние приложения.

• Прямая работа с SSH-ключами и командами через командную строку.

Но и Putty тоже удобен

• Не требует установки больших приложений и занимает мало места.

• Более гибкая настройка соединений и поддержка различных протоколов (SSH, Telnet, SCP).

• Есть графический интерфейс и прост в использовании.

💬 Чем пользуетесь вы? Накидайте советов в комменты и поставьте реакцию за свою тулзу:
👍 — за чистый SSH
❤️ — за удобный Putty

🐸Библиотека devops'a #междусобойчик

⚡️ Как из одного DevOps-инженера вырастает целый отдел

В стартапах часто бывает так: один DevOps-инженер на всё.

Один из наших подписчиков рассказал свою историю:

В стартапе я был единственным DevOps-инженером, и со временем стал работать с Kubernetes, CI/CD, мониторингом и поддержкой продакшн-среды. Одному стало тяжко и наняли SRE, стало попроще, но думаю дальше будет больше.

Чем сложнее проект, тем больше ролей скрывается за одним словом «DevOps».

Появляется Kubernetes — нужна экспертиза, и это скорее всего вы. Со временем можно стать «универсальным солдатом», выполняющим все задачи, от автоматизации до настройки инфраструктуры.

💬 Как у вас на проекте? Целая команда девопсов или один терминатор, который и тут и там? Делитесь своими историями в комментариях 👇

P.S. Если хотите задать вопрос сообществу или поделиться историей, заполните нашу гугл-форму.

🐸Библиотека devops'a #междусобойчик

🤨 «Сам решуу» или всё же поделиться задачей

Быстрая доставка, стабильность, автоматизация — ключевые принципы работы. Но возникает вопрос: нужно ли всё контролировать лично или делегировать задачи команде?

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

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

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

💬 Вопрос остаётся открытым: всё ли стоит делегировать, или есть задачи, которые должны оставаться под контролем только у нас?

🐸Библиотека devops'a #междусобойчик

✈️ Разбор полётов

Недавний масштабный сбой в IT-инфраструктуре Аэрофлота — не просто технический инцидент, а пример системного провала. Давайте устроим компании postmortem.

Кратко: что случилось

• Аэрофлот на несколько часов остановил бронирования, регистрацию и доступ к сайту.

• Все системы зависели от централизованной IT-инфраструктуры, которая была выведена из строя.

• По симптомам — возможен сбой ЦОД, отказ кластеров, падение критических сервисов.

🛠 Что можно было сделать

1. Geo-распределённая отказоустойчивая архитектура

Active-active или хотя бы active-passive в двух независимых регионах, например, использование облаков с мультирегиональной поддержкой.

2. Резервные каналы связи и DNS Failover

Ротация DNS на резервную инфраструктуру — классическая страховка. Cloudflare Load Balancer, Route53, NS1 — дают гибкость при переключениях.

3. Холодный и горячий Disaster Recovery план

Тестируемый DR-сценарий с переключением в течение 15 минут. Как минимум – ежедневная проверка резервных копий и симуляции отказов.

4. Тестирование отказов хаосом

Периодическая случайная остановка нод или симуляция отказа БД.

5. Автоматизация развёртывания и восстановления

Возможность воссоздать инфраструктуру за час, а не за сутки вручную. GitOps с Terraform, Ansible, Pulumi, ArgoCD для восстановления конфигурации в любой момент.

Крупный бизнес без продуманной стратегии отказоустойчивости — это только вопрос времени, когда «всё упадёт».

💬 Что бы вы использовали для предотвращения такого инцидента? Или чем бы пользовались уже пост фактум для восстановления?

🐸Библиотека devops'a #междусобойчик

👻 Уязвимости не прощают: как объяснить коллегам важность безопасности

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

С таким вопросом пришёл подписчик в нашу рубрику:

У меня на работе процветает безалаберность. Каждый второй коллега это потенциальная дыра в безопасности. Как им объяснить, что безопасность это не только моё дело, но и их?

Не стоит быть примером для учебников по ИБ, вот несколько советов:

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

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

Демонстрация примеров угроз, таких как SQL Injection или Cross-Site Scripting, помогает понять, как уязвимости могут повлиять на систему. Чем ближе примеры к реальной практике, тем убедительнее.

Автоматизированные тесты и интеграция проверок безопасности в CI/CD пайплайны позволяют уменьшить риски на ранних этапах разработки.

Объясните важность минимальных прав доступа и принципа Zero Trust: доверять никому, даже своим пользователям или приложениям.

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

✉️ Как вы объясняете важность безопасности своим коллегам? Поделитесь своими методами в комментариях 👇

P.S. Если хотите задать вопрос сообществу или поделиться историей, заполните нашу гугл-форму.

🐸Библиотека devops'a

#междусобойчик

🧑‍💻 Так ли GNOME перегружен

GNOME — это одно из самых популярных графических окружений для Linux, но часто его обвиняют в «излишествах». И вот вопрос: что именно в GNOME кажется лишним и стоит ли с этим мириться.

Причины недовольства:

• GNOME имеет репутацию тяжёлой среды, критикуемой за потребление памяти и процессора.

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

• GNOME стремится к тесной интеграции всех своих приложений, что может быть лишним для тех, кто предпочитает более распределённый подход.

• Если вы хотите настроить GNOME по-своему, вам часто придётся полагаться на сторонние утилиты.

Но есть и плюсы:

• Для большинства пользователей GNOME — это удобный и быстрый выбор, особенно для новых устройств.

• Разработчики GNOME постоянно обновляют интерфейс, добавляют новые фичи и работают над улучшением производительности.

💬 GNOME — это стильная и удобная среда или излишне усложнённый выбор? Что вам нравится, а что кажется лишним?

🐸Библиотека devops'a

#междусобойчик

🚀 Как вы стали девопсом

Для многих путь в DevOps — это не линейный процесс, а целое путешествие через различные роли и технологии. Кто-то пришёл из системного администратора, кто-то — из разработки, а кто-то стал девопсом после нескольких лет работы в ИТ-сфере.

Какие шаги стали решающими на вашем пути

Были ли важные курсы или сертификаты, которые помогли вам перейти в эту роль?

Какую роль сыграли практические проекты и опыт работы с CI/CD, контейнерами или облачными сервисами?

Какие сложности возникли при переходе, и как вы их преодолели?

💬 Давайте обсудим! Поделитесь своей историей в комментариях 👇

🐸Библиотека devops'a

#междусобойчик