Pull to refresh

Comments 21

Читал эту книгу. Там в основном только философия и теория. Очень мало примеров.
Хотя пища для размышлений тоже есть.
UFO just landed and posted this here
Опять когда говорят про DevOps, то говорят про всё что угодно кроме подробного объяснения того чем DevOps занимается конкретно и методов его работы. У меня создаётся ощущение того, что в половине случаев DevOps это про что-то мифическое о связи управленческих и инженерных должностей в обход (или в дополнение?) руководителей отделов и групп. Из чего рождается вопрос о том, а зачем это нужно если уже есть люди которые занимаются близкими вопросами (этим самые руководители)?
Поясните, пожалуйста, запутавшемуся мне, как глупому и неразумеющему инженеру, за DevOps.
UFO just landed and posted this here
Работаю девопсом, прочитал статью и ничего не понял. Совсем.
В моем понимании на проекте девопс должен реализовать:
1. Инфраструктуру проекта. Подразумевается возможность работы с контейнеризацией и микросервисной архитектурой.
2. Непрерывную интеграцию, тестирование. Каждый коммит билдится, тестируется и деплоится в зависимости от требований проекта.
3. Сбор логов и статистики. С девопсом у вас явно больше 1 сервера, но логи и health сервисов всегда лучше смотреть в одном месте.
4. Гибкость проекта к нагрузкам. Автоскейлинг, даунскейлинг, алертинг и т.д.
Вы не можете работать девопсом, потому что DevOps-это методология, а не должность.
Вам придется смириться с тем, что на IT рынке присутствует должность DevOps Engineer.
А вам придется смириться с тем, что название этой должности к DevOps отношения не имеет…
Не могу не согласиться, даже в понимании должностей тут полный бардак. Есть developers, есть operations (админы), вместе они реализуют методологию DevOps. К сожалению слишком много хайпа вокруг обычный оптимизации разработки и деплоя.
Не знаю, почему Вас заминусовали. Определенно, отрасль во многих местах настолько нахваталась модных неологизмов, что зачастую ее участники перестали понимать, что DevOps — это философия разработки и доставки, HR — это не рекрутинг, а Architect — про архитектуру, а не когда Senior BE нужно зарплату повысить за выслугу лет.

За последние пару лет провёл технические интервью с толпой “DevOps Engineer” — чаще всего они понимают свою специальность как опыт с одним из облаков, умеют какой-нить оркестратор и парочку инструментов от HashiCorp. Никакого понимания о выстраивании процессов непрерывной доставки и философии вокруг этого. Тупо хайповые админы с небольшой специализацией в облачные вычисления.
Жаль что со мной не собеседовались.
Мне кажется, что вы путаете DevOps и какую-то смесь Project-manager'а, Team-lead'а и эникейщика в одном лице :) Попробую пояснить, как я понимаю, кто такие DevOps, ни разу не претендуя на истину в последней инстанции:

Со времени возникновения IT до его текущего состояния прошел очень большой период:

От голых языков программирования с бедными стандартными библиотеками мы пришли к вееру библиотек, сред исполнения, операционных систем, платформ (включая веб, мобильные платформы, серверы, IoT и другие), виртуализации, распределнным по кластерам вычислениям, кроссплатформенной разработке, частому деплою и т.д… Сложность IT-инфраструктуры, необходимой для разработки и выпуска конечного продукта возросла многократно. Если раньше достаточно было написать игру/приложение под Windows, скомпилировать все это msvc-компилятором, протестировать, записать на диск и спокойно продавать, то сейчас для создания какой-нибудь простенькой Веселой фермы с возможностью играть в нее с телефона и из браузера придется развернуть:

1. Окружение для кроссплаформенной разработки (Android, iOS, браузер), с библиотеками для связи с БД, поддержкой API соц. сетей, графикой, нативными библиотеками на устройства и т.д.
2. Систему CI/CD с автоматической пересборкой, автотестами, какой-нибудь распределенной системой контроля версий, типа git'а, чтобы обеспечить работоспособность продукта как на стадии разработки, так и в продакшне.
3. Функционирование всего этого в облаке (как минимум БД + браузерная версия на каком-нибудь популярном фреймворке).

Если речь идет о чем-нибудь более сложном, чем веселая ферма (например, о каком-нибудь крутом вычислительном кластере или сервисе поиска, типа Яндекса, который разрабатывают тысячи людей по всему миру), то все становится еще сложнее.

Собственно, DevOps — это человек, который всем этим занимается. Это далеко не просто сисадмин, который может поднять и настроить какой-нибудь удаленный почтовый сервер по ssh, это человек создающий и поддерживающий всю цепочную инфраструктуру от окружения разработчика до автоматического деплоя всего этого на серверы или устройства пользователей.
А если компания экономит на специалистах и я один поддерживаю всю инфраструктуру включая AWS, программируемые маршрутизаторы и виртуальные сервера в офисе, иногда Active Directory, если в ней что-то ломается, готовлю сервера для программистов, которые так далеко от того, на чем кончается их код, что не особо понимают почему после「chmod +x」программа начинает запускаться, то я DevOps?

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


А еще девопс должен быть подкован в ООП?

До того, как начала развиваться парадигма DevOps, инновации и инструментарий пребывали в стагнации
Да ну! Серьёзно?
Бывают случаи в настоящее время, когда на прямой вопрос к человеку, представляющему какой бы то ни было программный продукт: «Какая у тебя роль в проекте?» — отвечает «Я DevOps»… И что бы то ни было другое, он пояснить не в состоянии…
В связи с этим, считаю, что подобная методология все же считается не более чем трендом нынешнего мира.
Универсальные солдаты всегда в почете, но рожденный летать — плавать не сможет. Как то так)))
Ценности

Любой инженер заточен на поиск решения, и такая устремленность порой выливается в неприятие новых технологий, нежелание экспериментировать с новыми вещами, что выражается по-разному: от синдрома «неприятия чужой разработки» до контрпродуктивных попыток защищать свою нишу. Чтобы по-настоящему перейти на DevOps, эти предубеждения нужно сначала признать, а затем преодолеть. Ни одна технология, ни Docker, Kubernetes или Amazon Web Services не решит ваших проблем, если вы не понимаете, в чем заключается ценностное предложение.


Так в чем ценности то? так и не прозвучало.

И не увидел про цели.
Увидел про управление изменениями, blablabla-as-code, быструю доставку, и прочее.
Про цели — ни слова.
UFO just landed and posted this here
постоянно думаю как наладить больше циклов обратной связи
Sign up to leave a comment.