Однако здравствуйте!
Я все еще Владимир, меня все еще зовут голова жи есть разработка-операции Head of DevOps, внезапно евангелист DevOps и немного ambASS-a-door чего то там (привет, гачи!). Сегодня предлагаю обсудить одну интересную тему...
//лирическое отступление: Все, что я рассказываю, основано на моем личном опыте. Любые совпадения случайны, а персонажи вымышлены.
//лирическое отступление2: Пост пишу с колокольни команды DevOps в большом энтерпрайзе
DevOps. How to use?
Этот вопрос пришел ко мне после того, как я увидел пост в LinkedIn. Молодой девопс делился своим опытом: он написал скрипт, который фиксирует состояние виртуальных машин (CPU, MEM, DISK) на bash. Дальше я отвлекся на мем и не успел прочитать весь пост, но он задал мне интересные размышления.
Мой опыт
Молодой и зеленый
Когда-то совсем давно, когда я был молодой и зеленый, то сам писал множество скриптов, не задумываясь о том, зачем настраивать незнакомый софт. Я знал bash и думал, что могу справиться с любыми задачами, такими как бэкапы через scp или сбор метрик с помощью awk. Это был мой путь к оптимизации своей работы.
//тут что-то было про WindowsServer 2003 и 1c на никсах, но память заблокировала это страшное время.
Взрослый и бежевый
Когда-то совсем давно, когда я был взрослый и бежевый, открыл для себя Ansible и Zabbix, которые значительно упростили жизнь. Мои старые методы, такие как PowerShell, стали заменяться более современными инструментами. Я начал использовать RunDeck для автоматизации процессов и мониторинга.
Но перевернутый вертикально монитор с пингами еще не ушел.
Старый и душный
Когда-то совсем давно, когда я был старый и душный, стал использовать инструменты, такие как Terraform и Helm, чтобы управлять инфраструктурой и обеспечивать observability. Я больше не пишу простые скрипты, а создаю архитектуру и логику для более сложных систем.
Жестокая реальность
Сейчас у меня есть команда, в которой мы сталкиваемся с множеством вызовов:
Поддержка продукта, в котором нифига себе архитектор написал свой собственный докер, потому что лошадь-в-ванне-с-огурцами.жпг.
В закрытых корпоративных сетях кровавого энтерпрайза чихнуть нельзя, чтобы к тебе ИБ не приехало с демократизатором или изначально выключены все доступы, интернеты, сервера, изменены таймзоны, стоит арабский язык в консоли, сетевой кабель перегрыз безопасник... Так что временами проще, а иногда в принципе единственный возможный путь, это создавать сервисы (пайплайны через
crontab + git diff
, мониторинг черезcat <...> | grep <...>
, алерты черезsend mail
, ИИ через if-if-if-if) своими руками и chat-gpt.СфераТ1 - <нечленораздельная речь>
Частенько видел как DevOps-ы (кста, в основном из зеленой конторы) притаскивают с собой выстраданные годами скрипты пачками, которые втыкают в текущую логику работы продуктов
Есть GitLab CE, а хочется GitLab EE - денег нет, но вы держитесь пользуйте API
//например "голосовалка" за MR, штука полезная кста
То была присказка присказки, а вот и сказка
Периодически вижу в требованиях к Devops-ам знание GO или Python.
Если про GO, плюс минус, я еще понять могу - а давайте напишем оператор для kubernetes, да и в принципе штука прикольная (оценил на сетапах лоадтестов), но не скажу что обязательная. А давайте еще и парсер для логов на Python, чтобы <нечленораздельная речь>...
Но я продолжаю настаивать, что DevOps не должен писать свои сервисы. И с позиции себя, как DevOps-а, и с позиции лида команды:
Минусы самописных сервисов
//духота_mode_on
Так как я противник позиции самописных сервисов, то и начну с минусов:
Высокие затраты на разработку:
Создание и поддержка собственного сервиса требуют значительных ресурсов.Отсутствие документации:
Самописные решения часто страдают от недостатка документации и стандартов.Риски безопасности:
Безопасность может быть упущена при разработке собственных решений.Сложности с масштабированием:
Масштабируемость может стать проблемой без достаточного опыта.Необходимость экспертизы:
Команда должна обладать необходимыми знаниями для разработки качественного продукта.Долгосрочные обязательства:
Создание собственного сервиса может привести к зависимости от него.Ограниченные возможности интеграции:
Самописные решения могут иметь проблемы с интеграцией и обновлениями.Проблемы с пользовательским опытом:
Разработка интерфейсов может занять много времени и ресурсов.
Поинтов достаточно много, лаконично могу описать, как дорого-и-больно
Преимущества самописных сервисов
//этот блок можно пропустить
В собственных сервисах есть и свои преимущества, о которых я расскажу, но без удовольствия, не искренне...
Гибкость и контроль:
Самописные сервисы можно настроить под уникальные задачи.Оптимизация процессов:
Возможность интеграции с внутренними процессами компании.Отсутствие лицензионных отчислений:
Можно избежать постоянных затрат на лицензии.Инновации и эксперименты:
Возможность экспериментировать с новыми технологиями.Технические навыки команды:
Разработка повысит квалификацию и опыт команды.Адаптация к изменениям:
Самописные сервисы быстрее адаптируются к изменениям.Безопасность данных:
Лучшая защита конфиденциальной информации.Пользовательский опыт:
Возможность создания интерфейсов, ориентированных на пользователей.
Поинтов достаточно много, лаконично могу описать, как дорого-и-больно, но эффективно
//духота_mode_off
Итого
Если у вас большая команда DevOps, то можно экспериментировать, но лучше сосредоточиться на готовых решениях. Готовые сервисы поддерживаются другими людьми, имеют документацию и просты в интеграции. Они уже на 90% готовы к использованию после установки и могут быть адаптированы под ваши нужды.
Единожды настроив сервис в одном логическом пространстве - его можно распространить по всей разработке.
В целом я считаю, что DevOps должен сосредоточиться на настройке и интеграции существующих инструментов, а не на разработке собственных сервисов. Даже если есть возможность окунуться с головой в разработку, я думаю, что лучше направить этот ресурс в другое, более полезное русло. Однако открыт для дискуссии и сторонним мнениям.
Начинаю вести свой ТГ-канал, где пробую объяснять сложные вещи простым языком: https://t.me/it_marx
slavcopost
Интересно, весело, занимающее, но много.
Остановился на "Теги: devops разработка observability"
Ответьте пожалуйста кто дочитал, есть ответ на вопрос "Если все будут использовать, откуда они появятся эти сервисы"? Спасибо.
coolbobah Автор
В смысле читать тяжко до конца?) Что следует поправить?
По второму абзацу - в статье рассуждаю в контексте команды DevOps, а не разработки, как таковой. Старался донести в том числе, мол Google может себе позволить сделать Kubernetes, а локальная команда - вряд ли... Вряд ли ей вообще стоит этим заниматься.
slavcopost
Да нет же, читать легко и весело, я это в предыдущем комментарии указал.
А хотел сказать я, что топить за то что DevOps не должен писать, а только настраивать, это как утверждать что пекарь не должен тесто замешивать, а должен печь. Я вообще считаю, что девопс не должен ни писать, ни настраивать, а должен с детьми, внуками развлекаться, тусить с семьей и друзьями. Но меня никто не слушает :D
Не эксперт в теме, но "dev" в DevOps, идет от develope, т.е. разрабатывать.
coolbobah Автор
Интересный тезис, апробирую =)
Отчасти да, разработка присутствует, спору нет.
Впрочем и на феррари можно картошку возить, а не... а не ездить к внукам)