Comments 26
А бывает девопс говорит: Я все ci/cd отладил, а sre - ищите другого, я чисто по процессам.
DevOps предполагает, что инженер не только следит за тем, чтобы ничего не падало, но и прививает команде ценности по фреймворку CALMS
Если я правильно понял ваше определение, то DevOps это админ-инфоцыган, который часть рабочего времени выполняет админскую работу, но помимо этого проводит регулярные тренинги CALMSовского роста внутри отдела.
Сейчас девопс кто угодно уже. SDET, auto, разработчик инфры - всех отправят делать задачи девопса.
DevOps-практики, DevOps-ценности, DevOps-культура... Возникает образ некого, почти секретного культа, хорошо бы с жертвоприношением) А я, проработав почти 5 лет девопсом, как-то не заметил никаких особых практик или особой культуры - обычная автоматизация.
А вот про эмпатию, это зря, она часто мешает. Например, захотел сделать какой-то скрипт по открытой жире, а к тебе лезут постоянно с проблемами. Вроде небольшими, но неформально поможешь одному, другому, третьему... День прошёл, а по жире ничего не сделано. Формально, я тунеядствовал. А если заставить народ делать новую жиру на каждый чих, они обижаются и все равно лезут за помощью без жир.
Зашел на описание позиции, а потом нажал на "еще 4 позиции" и попал в нечто. Нечто движущееся и абсолютно бессмысленно-бесполезное, иногда почему-то с намёками на Дойче Банк. Промаявшись на этом сайте c минуту, как-то, почти случайно, все же нашёл список вакансий, но список был уже на сайте hh. Зарплаты, конечно, скромно опущены - единственное, что важно в первую очередь ищущему работу. Эххх.
DevOps изначально был методологией. Специалист DevOps - это админ, который применяет эту методологию.
Представьте себе команду, которая пишет F2P-игру для мобильников. Даже если это инди-проект из трёх человек, в этой команде всё равно будут тестировщики и хоть кто-то ответственный за инфобезопасность.
Ну да команда из 3 человек, девопсер, кибербезопасность и тестировщик.
еще скраммастер, аджайкоуч и бизнес аналитик. Потом можно бизнес оунера добавить, проджект менеджера, дизайнера и системного аналитика.
Вот уже 10 рыл!
Редкий случай, когда кто-то на хабре вменяемо написал на эту тему, действительно у нас девопсами называют сисопсов и админов, девопс - это вообще не должность и не специальность, а подход, который обычно в небольших командах разработчиками реализуется в первую очередь, а не админами.
Подход, который обычно не нужен в небольших командах)
Скорее зависит от специфики продукта и организации разработки. Если это облачный сервис с релизами раз в две недели, например, то в реализации девопс-подхода очень много смысла, даже если вся команда - это два разработчика и один тестировщик.
Ну и понятно, что если вы хотите trunk based, то у вас девопс-подход естественным образом вырастет сам собой с большой вероятностью. А часто ядро команды приходит с trunk based проекта и им попросту удобнее так работать, так что они девопсом занимаются с самого начала, не сильно задумываясь, что это девопс.
Релиз, облако - это все способ достичь цели.
Если у тебя один инстанс бд, то твой выбор монолит и сервак на убунте по ssl.
Докеры, кубернетесы можно выкидывать. Зачем?
Автоматизировать стоит тогда, когда это экономит время.
Любое жава приложение перезапускается батником
Гит пул
Мвн клин инстал
Жава жар старт.
Что тут автоматизировать?
Когда я прихожу и вижу многостраничные многоклассовые скрипты на груви в раздел е девопс, я всегда думаю нахуа?
Когда у меня три девопсера разбирались как настройку подменить и где ее взять, нахрена мне эта автоматизация, причем локально это тупой спрингбут с application.yml.
Если два програмиста, то и женкинс и битбакет и код ревью и пулреквесты и гитфло избыточны.
Вся эта хрень нужна если есть десяток инстансов бд, десяток инстансов сервисов, которые автоматом взлётают и перезагиужаются при падении.
Во всех прочих случаях, только адов геморрой.
Любое жава приложение перезапускается батником
Гит пул
Мвн клин инстал
Жава жар старт.
Что тут автоматизировать?
А приложение при этом само что ли собирается и тестируется ?
Опишем реалистичный сценарий, как появляются проекты на двух программистов и тестировщика. В каком-нибудь развитом банке (или развитой цифровой компании типа мобильного оператора, большого интернет-провайдера или чего-то подобного) появляется идея нового сервиса для клиентов, находят пару скучающих разрабов с уже существующих проектов, берут тестировщика по совместительству с существующим проектом, начинают пилить, дают им так же из существующих проектов по совместительству лида и PM. У этих людей уже есть облако, с которым они уже работали на прошлых проектах, и если они решат выкладывать на какой-нибудь хостинг на VPS свое творение, на них посмотрят как на сумасшедших и объяснят, что это не дело.Поскольку проект предполагается предлагать многотысячной аудитории существующих клиентов, то требования к тестированию, автотестированию высокие, код ревью обязательно, тестировщик на полставки ожидает, что как и на других проектах он будет нажимать кнопочку в CI и ему будет выкатываться свежий инстанс с приложением, или даже без кнопочки, просто будет брать ветку из тикета и для нее уже есть инстанс. И по-другому работать как-то и не предполагается.Так понятнее?
Все бы хорошо, но однажды вы уволитесь и кто то придет на ваше место.
И вот это вот все ему нужно откуда-то взять (пул, клин и т.д.) и это хорошо если он имел опыт с spring boot а не с Django пришел фронтенд сапортить.
DevOps упрощает вход и выход, помимо прочего.
Контейнеризация, или тот самый Kubernetes
контейнеризация это скорее Docker
Инфраструктура как код
а вот здесь как раз тот самый Kubernetes
Наверное самая полная по основам и самая точная в плане рассмотрения самой методологии Devops и должности ИТ специалиста Devops статья. Огромная благодарность за проделанную работу. Бесконечные и такие же бессмысленные гайбдуки и роадмапы по Devops порядком достали и больше сбивают с толку, чем приносят хоть какую-то пользу. Потому что смысла особого в знании тех или иных технологий мало, пока не знаешь зачем именно её применять.
Спасибо
Нас почему-то так заминусили за эту статью, что ваш комментарий – бальзам на душу) Спасибо и вам за тёплые слова!
Сам удивился и продолжаю удивляться этому. Почему так? Хотя частично ответы на этот важный вопрос отсвечивают в комментариях в статье. Где-то прямо, где-то косвенно. Для кого-то это могло стать откровением и вызвать отторжение, потому что долгое время будучи опытным специалистом не знал основ. С другой стороны продавцы всевозможных курсов девопс по кубернетес, докер и линкс пайплайн. Для них минусов отсыпать ничего не стоит - просто бизнес, ничего личного. Как потом курсы впихивать, если совершенно на другую тему.
На самом деле статья глоток свежего воздуха, после невероятного количества иногда просто вредных статей.
«Это не админ на стероидах»: в чём суть роли DevOps