👨‍💻 Технический долг под прикрытием

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

Плюсы feature flags:

+ Можно включать и выключать функции в любое время, даже после деплоя.

+ Возможность быстро отключить нерабочую или багованную функциональность без полного отката.

+ Поддержка A/B тестирования и постепенного развертывания.

+ Код можно внедрять «в тёмную», активируя позже.

Минусы feature flags:

- Неочищенные флаги превращают код в сложный для понимания и поддержки.

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

- Изменения через UI платформ часто не отражаются в Git, что мешает отслеживанию.

- Управление токенами и доступом часто организовано недостаточно строго.

- Платформы не всегда хорошо вписываются в существующие CI/CD процессы.

- Масштабирование и цены могут вырасти непредсказуемо.

💬 Как думаете, фича флаги это мастхев или без них намного лучше? Делитесь мыслями в комментариях 👇

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

💾 Когда GitOps не справляется

GitOps становится всё более популярным для автоматизации развертывания и управления инфраструктурой через Git. Как и с любым новым подходом — возникают вопросы.

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

GitOps утверждает, что все изменения должны быть в Git, но как быть с настройками и инфраструктурой, которые трудно или невозможно описать в коде?

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

Несколько способов решения этой проблемы:

1. Используйте инструменты типа Terraform или Ansible для настройки. Они могут работать параллельно с GitOps, обеспечивая гибкость.

2. Для чувствительных данных используйте хранилища секретов, чтобы избежать хранения паролей в Git.

3. Сочетайте GitOps для приложений с традиционными методами для специфических конфигураций.

Не обязательно строго придерживаться концепции, если она не позволяет эффективно работать.

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

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

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

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

Многие считают, что девопсам нужно погружаться в глубокие технические темы — гайды по внедрению 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 #междусобойчик