DevOps: Писать или настраивать инструменты?

Однако здравствуйте!

Я все еще Владимир, меня все еще зовут голова жи есть разработка-операции 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. Я больше не пишу простые скрипты, а создаю архитектуру и логику для более сложных систем.

Жестокая реальность:

Сейчас у меня есть команда, в которой мы сталкиваемся с множеством вызовов:

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

2. В закрытых корпоративных сетях кровавого энтерпрайза чихнуть нельзя, чтобы к тебе ИБ не приехало с демократизатором или изначально выключены все доступы, интернеты, сервера, изменены таймзоны, стоит арабский язык в консоли, сетевой кабель перегрыз безопасник… Так что временами проще, а иногда в принципе единственный возможный путь, это создавать сервисы (пайплайны через crontab + git diff, мониторинг через cat <...> | grep <...> , алерты через send mail , ИИ через if-if-if-if) своими руками и chat-gpt.

3. СфераТ1 — <нечленораздельная речь>

4. Частенько видел как DevOps-ы (кста, в основном из зеленой конторы) притаскивают с собой выстраданные годами скрипты пачками, которые втыкают в текущую логику работы продуктов

5. Есть GitLab CE, а хочется GitLab EE — денег нет, но вы держитесь пользуйте API
   //например «голосовалка» за MR, штука полезная кста

То была присказка присказки, а вот и сказка

Периодически вижу в требованиях к Devops-ам знание GO или Python.

Если про GO, плюс минус, я еще понять могу — а давайте напишем оператор для kubernetes, да и в принципе штука прикольная (оценил на сетапах лоадтестов), но не скажу что обязательная. А давайте еще и парсер для логов на Python, чтобы <нечленораздельная речь>…

Но я продолжаю настаивать, что DevOps не должен писать свои сервисы. И с позиции себя, как DevOps-а, и с позиции лида команды:

Минусы самописных сервисов:

//духота_mode_on

Так как я противник позиции самописных сервисов, то и начну с минусов:

1. Высокие затраты на разработку:
   Создание и поддержка собственного сервиса требуют значительных ресурсов.

2. Отсутствие документации:
   Самописные решения часто страдают от недостатка документации и стандартов.

3. Риски безопасности:
   Безопасность может быть упущена при разработке собственных решений.

4. Сложности с масштабированием:
   Масштабируемость может стать проблемой без достаточного опыта.

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

6. Долгосрочные обязательства:
   Создание собственного сервиса может привести к зависимости от него.

7. Ограниченные возможности интеграции:
   Самописные решения могут иметь проблемы с интеграцией и обновлениями.

8. Проблемы с пользовательским опытом:
   Разработка интерфейсов может занять много времени и ресурсов.

Поинтов достаточно много, лаконично могу описать, как дорого-и-больно

Преимущества самописных сервисов:

//этот блок можно пропустить

В собственных сервисах есть и свои преимущества, о которых я расскажу, но без удовольствия, не искренне…

1. Гибкость и контроль:
   Самописные сервисы можно настроить под уникальные задачи.

2. Оптимизация процессов:
   Возможность интеграции с внутренними процессами компании.

3. Отсутствие лицензионных отчислений:
   Можно избежать постоянных затрат на лицензии.

4. Инновации и эксперименты:
   Возможность экспериментировать с новыми технологиями.

5. Технические навыки команды:
   Разработка повысит квалификацию и опыт команды.

6. Адаптация к изменениям:
   Самописные сервисы быстрее адаптируются к изменениям.

7. Безопасность данных:
   Лучшая защита конфиденциальной информации.

8. Пользовательский опыт:
   Возможность создания интерфейсов, ориентированных на пользователей.

Поинтов достаточно много, лаконично могу описать, как дорого-и-больно, но эффективно

//духота_mode_off

Итого:

Если у вас большая команда DevOps, то можно экспериментировать, но лучше сосредоточиться на готовых решениях. Готовые сервисы поддерживаются другими людьми, имеют документацию и просты в интеграции. Они уже на 90% готовы к использованию после установки и могут быть адаптированы под ваши нужды.

Единожды настроив сервис в одном логическом пространстве — его можно распространить по всей разработке.

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

Начинаю вести свой ТГ-канал, где пробую объяснять сложные вещи простым языком: https://t.me/it_marx